Cannot ping OpenVPN client after server restart
 

I briefly touched on this in my other thread (OpenVPN 'privileged' clients), but I thought I'd go into it with a little more detail.

I have my OpenVPN server setup and working properly. I have a collection of clients that connect to the server and I've been able to successfully connect from the server (and recently from other clients) to these other VPN clients.

Last night I had an issue with my server box and was forced to reboot. I also made some changes to the OpenVPN server config prior to rebooting- nothing extensive (disabled 'client-to-client').

The server came back up, and along with it, the OpenVPN server. I scanned the openvpn-status.log file to see whether any of the VPN client machines were reconnecting to the server. They all seemed to (my laptop required me to kill the OpenVPN client and restart it- but once connected, there were not problems).

However, one of the Windows XP clients (the only Windows client that had previously been connected prior to the server reboot) claimed to reconnect, but I cannot connect to it from the server at all! I can 'see' the XP client in the status log, and didn't see anything that would suggest a problem in the server log itself- but I cannot even so much as ping that remote system from the server- much less connect to it using rdesktop.

I'm baffled as to why this is happening. I figure that if it reconnects to the server and I can 'see' the XP client in the server status logs, then I should be able to access it from the server without any problems. Any ideas why this is happening, what I should look for, and how to resolve the problem? Any help is greatly appreciated. :)

Thanks,

- skubik

Whoops. Posted the wrong thing to the wrong thread. :)

To answer Andrew's question from the previous thread...

Yes I do have a keepalive directive active in my server config file. It's the default one that 'came with' OpenVPN (an example script I believe). I do not, however, have any such directive in my client config files. Not sure if that's even necessary/possible.

By 'restart', yes, I mean rebooting the computer in it's entirety. I do not have the openvpn-gui installed (or at least running) partially for transparency to the user of that Windows client machine, and partially for security (so they don't screw anything up). I have openvpn running as a service at boot-time so that it runs and connects regardless of who logs into that machine.

I have found with Vista (Home Premium) that everything works great until it goes into a 'sleep' mode- usually by closing the lid (it's a laptop). If we leave it open, then I can ping no problem (remote desktop is another issue, but I think that's related more to the firewall moreso than anything- had Norton on there and remote desktop worked great. Took Norton off to use Microsoft's firewall and there's no obvious way to allow rdp connections- but that's aside from the connection issue.

I figure that since Vista will only utilize OpenVPN 2.1 RC4(?) that there are probably still some bugs to be weeded out (well, that's on-par with Vista itself), and luckily my only Vista client isn't of great importance. But the XP clients are pretty important.

I've done a fair share of digging through documentations, mailing lists and other forums to figure out what might be the connection issue with the XP client- sounds like it might be an ARP/MAC address issue, but not sure. The client in-question is literally across the city, so getting to it and looking at the logs or doing any extensive testing isn't very easy. :/

Thoughts?

I use the openvpn-gui with a restricted set of options - no editing of config file - my XP users are ordinary users and I've gone down the route of granting them specific rights to start and stop just the openvpn-gui service using subinacl from the Windows Resource Kit. I did worry that they would be confused or fed up with having to click on an icon, but they understand that if it's red it won't work and if it does stop working clicking disconnect and then connect usually gets it back. The other nice thing is that I can have start-up scripts (to map network drives etc) run automatically on connection.

I'll have a chat to my Vista user to see what they have to do when it freezes.

Just a slight update on this scenario.
Over the weekend I had to reboot my VPN server box no thanks to the ATI fglrx driver. *rolleyes*

As it turns out, all of the VPN clients were able to successfully reconnect to the VPN server, and I'm even able to ping them from all the designated clients and connect to them remotely! This is unlike the problems I encountered before.

Vista is still a problem- but I at least have an inkling as to what the problem is (at least initially- firewall).

But it appears as though if you do not change any of the server configurations, the clients are able to automatically reconnect on their own without problems. It's when you do make a change to the server config that the clients will 'connect' but not be reachable. I don't know the specifics of these limitations, but it's worth noting this I think.

- skubik