[SOLVED] can't connect to a remote node until I ping first

networkspeedy

I have a setup where I've installed an openvpn server in a business office. I have the office router set up to forward all incoming traffic to that machine on the default openvpn port. Then I set up the openvpn server correctly so that it pushes out a route to remote clients in order to allow them to access machines on the subnet in the office.

remote client ==> office router ==> openvpn server ==> office computer

Then I set up a static route on the office router so that it sends any traffic bound for 10.0.2.0/24 to the vpn server.

...and it all works great! ...Except one thing: I can't my remote client to the windows 2003 domain controller until I ping it first. I'm talking about both VNC connections as well as native RDP connections. I can connect to other computers in the office running windows XP or windows 7 and I never have this issue. Only with the windows domain controller server do I have this problem.

To be clear, I'll elaborate some more: when I connect to the office vpn from my house and attempt to connect to the windows server, it fails. The connection can't be made via VNC or RDP. This is true from my windows workstation, my macbook, and my linux laptop: all clients MUST ping 192.168.16.3 before a connection can be made.

Any time I ping the server there are never dropped or lost packets. It always works, first time, every time. It's like a key I have that unlocks the door so I can connect via RDP after I've "turned the key" by pinging.

This is a ENORMOUS problem for me, because I'm not the end user; I'm the administrator. The personnel who work in the office do not have the proficiency nor the patience to open a terminal and ping a given computer before logging in to it.

The problem isn't isolated to this one office either: I manage 3 offices and all of them have the same problem. It is only the windows 2003 Active Directory domain controllers that exhibit this behavior.

I've found nothing in the docs, on this and other forums, or on google. PLEASE help if you can. What could possibly be wrong, and how can I fix it?

...posting server and client configs in a reply below

janjust

If you can reach all hosts except the domain controller after the VPN comes up then it's most likely related to a firewalling issue on the domain controller.

Is the domain controller the same machine as the VPN server?
do post your config files , perhaps there's an oddity in there somewhere.

OpenVPN does not do anything specific with domain controllers, it just routes traffic; if you can route traffic from the client to any hosts behind the DC *except* the DC itself then I'd start troubleshooting the DC, not the OpenVPN server. Check firewalls, run a packet sniffer on the DC and compare the traffic with and without the 'magic ping' etc.

networkspeedy

SERVER CONFIG: --------------------------------------

port 1194
proto udp
dev tun0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/myservername.crt
key /etc/openvpn/keys/myservername.key # This file should be kept secret
dh /etc/openvpn/keys/dh2048.pem
server 10.0.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.16.0 255.255.255.0"
client-to-client
keepalive 10 120
cipher AES-128-CBC # AES
comp-lzo
max-clients 100
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
mute 20

CLIENT CONFIG: --------------------------------------
client
dev tun0
proto udp
resolv-retry infinite
keepalive 10 30
nobind
mute-replay-warnings
ns-cert-type server
cipher AES-128-CBC
comp-lzo
persist-key
persist-tun
verb 1
tls-exit
cert /home/myusername/vpns/myservername/myusername.crt
key /home/myusername/vpns/myservername/myusername.key
ca /home/myusername/vpns/myservername/ca.crt
remote myservername.com 1194

networkspeedy

Yesterday I windows firewall was disabled on all machines (including the Microsoft Active Directory server), so we can rule that out as a potential issue.

New Details:
During my testing today I confirmed (sadly) that this is happening with every windows workstation, laptop, and netbook in the office. My original experience that this was only happening on the server has proven incorrect =(

If I want to log in to a given windows XP workstation via either VNC or RDP, it won't work until I ping it first. Once I hit it with a ping or two, I can immediately get in. It's so bizarre and consistent that I'm thinking of taking a video of my desktop just to show first hand how weird this is. I'm stumped, confused, and baffled here.

Did the configuration files I posted earlier provide any clues?

janjust

your server and client seem to be linux boxen...
install wireshark or tcpdump on the server, then listen on the 'tun' interface first

tcpdump -nnel -i tun0

and try to access a Windows XP on the server-side LAN using RDP (NOT ping!). My guess would be that ARP replies are not coming through correctly...

You can repeat the exercise by listening on the 'eth0' interface and watch for similar traffic (e.g. 'tcp port 3389' for RDP)

networkspeedy

My own client is a linux box yes. The customer's clients are windows boxen and macbooks. We all have the same issue--it's a platform-independent problem.

New developments: a test lab...

As mentioned before, I have this same problem occurring in 2 different offices. As a test, I set up a lab environment at my partner's home last night to mirror the office environments. I wanted to see if the problem repeated itself. So I went to his house, I configured his home router so that it port forwarded 1194 UDP to a new wireless router (which is the same secure wireless router we use everywhere else). That secure wireless router then forwards port 1194 UDP to the OpenVPN server on its own subnet. Home network is 192.168.1.0/24 and the NAT'ted subnet for the secure wireless router is 172.16.0.0/24. I configured the secure wireless router with a static route that would send traffic for 10.0.3.0/24 to 172.16.0.253 (that is the OpenVPN server).

I then configured the OpenVPN server correctly with the ipv4 forwarding and iptables rules as set forth in the OpenVPN documentation, set up and configured the OpenVPN service, and attached a windows7 laptop to the same network as the OpenVPN server. Then I went home. When I got home I logged into the VPN without any problems and attempted to connect via VNC to the windows7 laptop (with its windows firewall completely disabled). I could not connect. THEN I attempted to ping it. It pinged successfully! Then I attempted again to connect via VNC and IT WORKED.

I have successfully duplicated the problem in three different locations!

I would like to pay someone to log in and fix it in the lab environment and tell me what's wrong so I can fix the other locations. Is anyone willing to offer a bit of paid support work?

janjust

I've sent you a PM

networkspeedy

Janjust,

I REALLY appreciate your willingness to be of assistance. We finally solved the problem though. We found out that nothing was wrong with openvpn, but instead with the network equipment we are using. We fixed the issue by moving DHCP service to the openvpn server and deactivating it on the secure wireless router. In the DHCP configuration on the openvpn server, we specify a (non-standard, microsoft-specific) DHCP option that pushes out the static route to each windows client on the remote LAN. We then reboot the windows machines and they get the static route from the DHCP server and we don't have anymore of this nonsense.

This just goes to show:
1) How awesome openvpn is
2) What a great support community we have here
3) How great Linux can be
4) How difficult it can be to work with closed source microsoft systems and other proprietary gear

My company is going to make a donation to the OpenVPN community because of the help we received here and on IRC at freenode, #openvpn

janjust

Excellent news, and thanks for any contributions.
Closing topic.