0

Scenario:

I have a functioning openVPN connection on my Debian Server (it's a virtual server, so there are some restrictions what I may access/modify) and Windows 7/8 and OS X Lion/Mountain Lion clients. The clients can't and shouldn't see/ping each other, however they should be of course able to access the server. Every client gets an IP-Address assigned from the server in the defined 10.240.43.x range (the servers VPN IP-address is obviously 10.240.43.1) and connects without errors (according to the openVPN log) but ONLY the OS X Mountain Lion client is able to ping the server and use the installed services (e.g. phpmyadmin) on it. The windows clients connect and get an IP but not a single one of them (there are 5 currently) can ping the server.* I get a "Ping request timeout" everytime.

Attempts:

  1. added rule to firewall to allow ICMPv4 traffic to enable ping requests sent & received
  2. excluded tun-interface from the firewall for private profiles & domains (under Firewall settings) - changed nothing
  3. disabled firewall completely - changed nothing
  4. pushed "route 10.240.43.1 255.255.255.0" to clients (in server.conf) - changed nothing
  5. pushed "redirect-gateway def1" to clients (in server.conf) - changed nothing
  6. added dummy default gateway to work around Windows 'unidentified network' issue (see client.conf below) and be able to set VPN network as "private network" - worked, but didn't solve the "ping issue"
  7. compared the routing tables to the working OS X client routing table - couldn't find any differences

*one client (a Windows 7 bootcamp install on a Macbook) was able to ping the server one evening, however the next day, without changing client.conf OR server.conf, this wasn't possible..very weird.

Since none of the attempts above worked I have run out of ideas. Eventually I will install openVPN with my configuration on some other Windows 7 devices, although I don't think this will be successful. Does anybody of you see what I haven't tried yet or sees an error in my configuration file? I am sure there is someone out there who has had a very similar scenario..

Note: I may have asked a similar question before where you can also find more information about the configuration ( openvpn: connection established, can't ping server tun interface (debian server, windows & os x clients) ) but this one is about the possibilities to successfully ping the VPN server from a windows client. All the other questions I saw could solve their problems with one of the attempts described above, however this did not work for me.

Thank you very much!

Below my client configuration:


dev tun
dev-node openVPN

proto udp

remote <my-server-ip> 1194

#Dummy default gateway to work around Windows 'unidentified network'/'unknown network' (put a "#" in front of this)
route-metric 50
route 0.0.0.0 0.0.0.0 10.240.43.1

resolv-retry infinite
nobind
persist-key
persist-tun

ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\client1_win7.crt"
key "C:\\Program Files\\OpenVPN\\config\\client1_win7.key"

ns-cert-type server

tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 1
comp-lzo
verb 3
hreimer
  • 171
  • 1
  • 2
  • 9

1 Answers1

0

For future reference, if anyone encouters similar problems: After reinstalling openvpn the issue was not solved, however there was an interesting reproducable effect: when changing something in the server config (e.g. enabling/disabling the line with ipp.txt persist) and restarting the openvpn service on the server the first client could connect, but not the others, unless the service was restarted again as described above.

This question of mine deals with that issue: openvpn - only one client key/certificate pair working

The final solution was to get rid of the vServer (with Linux-vServer technology) and switch to a KVM-based vServer from the same company since there were too many restrictions on the Linux-vServer (loading custom kernel modules like iptables..).

Now everything concerning openvpn works flawlessly

hreimer
  • 171
  • 1
  • 2
  • 9