[win 7 x64 client] Ping required after location is changed

[janjust]

after about 1 hour the VPN client detects 'inactivity" and decides to do a restart; during the restart the DNS name resolution does not work properly; this could be a DNS caching issue where the VPN client tries to query a DNS server via the (now dead) VPN tunnel.

Can you try using an IP address for the remote end, just to see if that solves the DNS resolving issue?

[gork]

I am having this same issue with the "name is valid but..." error. I can confirm, at least for me, that using the IP address on the remote end solves the problem. I am using OpenVPN v2.2.1.

EDIT
Fwiw, I've tested this from four different locations using Google's DNS servers, Comcast's and I have no idea what the other two were. And I'm unable to compare my findings to "how it used to be" because I am a new OpenVPN user. I only share this information to indicate this is not simply an issue of DNS entries being blocked, or the like.

[gork]

I use the redirect-gateway option, so at least in my case, this seems to be the problem (from the HOWTO):

"Many OpenVPN client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The redirect-gateway option might prevent the client from reaching the local DHCP server (because DHCP messages would be routed over the VPN), causing it to lose its IP address lease."

It seems odd this would be by design. I would have assumed an exception would have been built in for when the DCHP address on the client machine is renewed (or in my case gets disconnected.) If I understand correctly, if we're using the redirect-gateway option we will not be able to use a URL, only an IP address, to connect the OpenVPN client to the OpenVPN server. I think the issue I'm having is more of a problem than with some because my client connects over wifi.

[Mimiko]

It seems odd this would be by design. I would have assumed an exception would have been built in for when the DCHP address on the client machine is renewed (or in my case gets disconnected.)

In the OpenVPN server config add "float" option.

[gork]

Thank you! It would probably have been a long time (if ever) before I found that gem in the manual... Even had I run across it I probably wouldn't have recognized it as a solution to this issue.

EDIT:
After about an hour of testing, as expected, adding the FLOAT option to the server's configuration file did the trick.

[gork]

It appears I spoke too soon. After a much longer period of testing the same problem cropped up even using the FLOAT option in the server config file. I lose connection between the client and server and the following message scrolls down the terminal screen, attempting to resolve every 20 seconds:

RESOLVE: Canot resolve host address: {my_url}: [NO_DATA] The requested name is valid but does not have an IP address.

As janjust mentioned above, the problem during this last testing appears to crop up after an inactivity timeout:

Code: Select all

Sat Nov 26 02:26:38 2011 Initialization Sequence Completed
Sat Nov 26 11:13:05 2011 [server] Inactivity timeout (--ping-restart), restartin
g
Sat Nov 26 11:13:05 2011 SIGUSR1[soft,ping-restart] received, process restarting

Sat Nov 26 11:13:07 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or hig
her to call user-defined scripts or executables
Sat Nov 26 11:13:07 2011 Re-using SSL/TLS context
Sat Nov 26 11:13:07 2011 LZO compression initialized
Sat Nov 26 11:13:22 2011 RESOLVE: Cannot resolve host address: remote.gorksplace
.com: [NO_DATA] The requested name is valid but does not have an IP address.

As soon as I shut down the OpenVPN client (F4) I have full access again through the wifi connection. I can also immediately set up another tunnel using the URL without a problem. That RESOLVE message continued on for over an hour until I shut down the VPN tunnel

[Mimiko]

DNS name resolving and IP change of the client is different matters. Use remote IP of the server, not its dns name. Because the all redirect traffic after a while, when DNS name in cache expires, it has to requery the dns server which is not accesible thru the dead tunnel. Or use this combination of commands:

Code: Select all

push "dhcp-option DNS 8.8.8.8"
route 8.8.8.8 255.255.255.255 net_gateway

So, the query to dns server will always go thru the local internet provider, not thru tunnel.

[gork]

I've been thinking about this and came to understand what the FLOAT option was really doing. I came back to post the misunderstanding due my lack of proper explanation but you beat me here and I can see you already understand my error in explaining. (I'm glad for the error, though, since you introduced me to the FLOAT option...)

My thanks once again; I already push Google's public addresses from the server and can see how your routing entry on the client would fix the problem I'm having. I'm not sure if outside DNS servers will be accessible for my application, but I plan on trying it - it is not a security issue in my case. I do know that some DNS entries are blocked through the default DNS server we use client-side. (I'm connecting from work, with permission, but have been told they will not make network/security changes to accomodate my needs.) And yes, if this method fails me I can just use the IP address of the server to create the tunnel. Though I'm connecting to a server behind a dynamic IP address, it rarely changes and would cause little if any problems. It just seems like an "incorrect" way of doing it, if that makes any sense.

I guess it would just make more sense to me for OpenVPN to have an option, when setting up the tunnel, to "remember" the IP address for the URL used for that connection instead of trying to resolve the URL again if the tunnel is disrupted. This would cause no more problems that the client trying to use DHCP through the dead tunnel for resolution. The more sensical approach would be for the client to be able to realize the tunnel is down and use the client computer's DNS entry to re-establish the tunnel, just as it did when creating the tunnel in the first place. But I'm not knowledgeable enough to know if that's even possible.

I can see there is a lot more for me to learn with regard to OpenVPN!

[gork]

Unfortunately the PUSH and ROUTE commands you suggested should work have failed my testing process. Unfortunately the URL still doesn't resolve when the tunnel is dropped and tries to reconnect automatically. I'll keep looking into this, but it appears my only option may be to use the dynamic IP address itself to connect the tunnel. Sad.

[Mimiko]

So its obvious you have a problem with DNS cache. Its not the problem of routes or OpenVPN. You have to reinstall the system or disable DNS cache as of this link: http://support.microsoft.com/kb/318803

[gork]

If this absolutely should be working and OpenVPN 2.2.1 is not currently experiencing a bug related to the issue at hand then I'm doing something wrong. I checked the DNS cache with ipconfig /displaydns on the client machine both before and after connecting a tunnel and there is nothing cached which is related to my OpenVPN connection or the DNS servers. I can still try disabling cache to be sure though.

Is this what you're thinking... When wifi drops it drops my tunnel. When wifi comes back up, OpenVPN tries to reconnect but when it tries to resolve the URL it fails because of a bad DNS cache? If so, perhaps I need to try to display the DNS cache when the tunnel can't be connected to see what's in there and maybe shed some light on this. IF I'm understanding your thought process properly, I mean. And of course, I need to try disabling cache as well - though I would like to see the whys of it all.

It just feels to me that OpenVPN is doing something funky, though I can't yet put my finger on it. I'm no pro at any of this though, so I could totally be overlooking something. I do have to remind myself that the URL works properly when I first create the tunnel - which means this isn't a DNS issue until after the tunnel is connected. I'll keep working on it!

Just fwiw, I'm running on a fresh install of WinXP SP3. I've done nothing with the install but install and play around with Shrew (a VPN client - tried to use it to VPN directly to my router and failed) and OpenVPN.

EDIT:
Ok, here's a little tidbit that might help shed some light on this. I have to mull it over for a bit before it means more to me, but I just conducted a test. I connected the tunnel (using the URL though I think that is probably insignificant) and ensured my connection through the tunnel was running correctly. I then disconnected my wifi connection from the client computer for 30 seconds and reconnected it to simulate my wifi going down. After I did this neither the client nor the server's OpenVPN connection indicated the connection had been interrupted. The client machine at this point had NO access to the network/Internet. Upon a hard restart of the OpenVPN client (F3) everything worked fine.

And though these messages didn't show up before the hard restart, they were the first messages to show up in the console on the client after I hit F3. Just one message, repeated three times all with the same time stamp:

Code: Select all

Sun Nov 27 14:31:02 2011 ROUTE: route deletion failed using DeleteIpForwardEntry: The parameter is incorrect.

My guess these messages are not significant and only show up because the client computer has no network connection at that time.

I have now been able to verify that if I conduct this test by disconnecting the wifi for a very short period of time (10 seconds instead of 30) and reconnect it the same thing happens. Also, not only does restarting the OpenVPN client give my client machine's network access back, so does exiting OpenVPN (F4 from the console.)

And one last thing... The "route deletion" message showed up again, three times as before, after I used F4 to close the OpenVPN session client-side.

Here are my client and server config files, just for reference. (Asterisks indiate information I didn't want to publish, and I took all my REMs (notes) out for simplicity.) As you can see, my goal is to be able to access all network resources, including Internet access, through the VPN connection. And it all works fine up until the wifi connection "hiccups."

And now, btw, I'm starting to realize that my problem may not at all be related to that of the OP and that I should have started a new thread. I'm not sure why I've not experienced a problem when connecting via IP address instead of URL from the client, but conducting a test by disconnecting my wifi for a few seconds after connecting the tunnel initially using an IP address instead of a URL yields the same result as what I posted above. I'm now not sure if I've just been "lucky" when using the IP address directly, or if I've been suffering from two different problems.

Am I correct to assume that a "hiccup" by the wifi connection shouldn't cause complete disconnection from the network for the client machine and that, rather, the tunnel should re-establish itself? I would assume so, in which case I may need to take a closer look at some of my config file settings. I should note that during today's testing I've been at home and my client computer is assigned a static IP address from my router via DHCP, so a changing IP address for my client computer is not an issue. (Plus I haven't been on the computer long enough for the DHCP lease to reset anyway.)

Code: Select all

client
dev tap
proto udp
remote remote.*myurl*.com 1194
route 8.8.8.8 255.255.255.255 net_gateway
route 8.8.4.4 255.255.255.255 net_gateway
route *server_network_ipaddr* 255.255.255.0 vpn_gateway 3
resolv-retry infinite
nobind
persist-key
persist-tun
ca "C:\\Programs\\Comm\\OpenVPN\\easy-rsa\\keys\\*mykeyfile*"
cert "C:\\Programs\\Comm\\OpenVPN\\easy-rsa\\keys\\*mykeyfile2*"
key "C:\\Programs\\Comm\\OpenVPN\\easy-rsa\\keys\\*mykeyfile3*"
tls-auth *mykeyfile4* 1
ns-cert-type server
cipher AES-128-CBC
comp-lzo
verb 1

Code: Select all

# SERVER
local *local_ipaddr*
port *local_port*
proto udp
mssfix 1400
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
dev tap
ca "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\*mykeyfile*"  
cert "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\*mykeyfile2*"
key "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\*mykeyfile3*"
dh "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\*mykeyfile4*"
tls-auth *mykeyfile5* 0
server *local_ipaddr* 255.255.255.128
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
keepalive 10 120
cipher AES-128-CBC
comp-lzo
max-clients 4
persist-key
persist-tun
status openvpn-status.log
verb 1

[gork]

I'm still experimenting and trying to fiugre out a way to prevent this from happening, but I'm formulating a hypothesis. I think, though I need more time with testing, that this problem reconnecting is only happening when the wifi connection is dropped for a short period of time. I've noticed a few times now that if the wifi connection is down long enough that a "fail" type message shows up, when I bring wifi back up everything reconnects on its own and I'm good to go. If wifi comes up before this message appears, however, then I have no connection - as described above - either through the client machine or through the tunnel until I restart or shut down the client.

I wonder if I may need to change the keepalive setting to a shorter period or find another applicable setting in the manual to make the pings on a UDP connection happen more frequently. Anyway, this is the route I'm currently thinking I should take.

But it bugs me that this doesn't happen already if wifi is down for only a short period of time. Common sense tells me OpenVPN should be able to recognize the problem just as it does if wifi is down for a longer period of time...

[Mimiko]

Add a keepalive option on client too. Use the minimum seconds to be a little lower then short period of disconnect.

[gork]

Ok, I made it somewhere with this - but I'm still in confusing territory for me. First, according to the manual using KEEPALIVE on the server pushes PING and PING RESTART commands to the client thereby negating the need to have keepalive in the client config file. However, I did remove it from the server and add it to the client to ensure I wasn't having a problem with the commands not being PUSHed properly. It turns out this was not the problem. But you led me down an interesting path...

The problem appears to be the RESOLV-RETRY setting. If it is set to infinite (which I believe is the default) and wifi disconnects and reconnects before a PING-RESTART is received then I am left with no connection to the network (either through the tunnel or not) while the VPN tunnel is still up (or thinks it's up.) With RESOLV-RETRY set to infinite, I apparently end up in a never-ending loop while the client tries to resolve the IP address and it never restarts due to the PING-RESTART (KEEPALIVE) setting. If I change RESOLV-RETRY to 5 instead of infinite, my problem is resolved.

BUT, I remain confused. First, why do I lose all connectivity if wifi goes down while the tunnel is up in the first place? I would think OpenVPN should at worst drop me back to my local network connection. I also was under the assumption that if a network resource isn't available through the primary connection (OpenVPN is set as primary) it will try the remaining connections (which includes my wifi interface). So, assuming Windows is working in this manner, OpenVPN is blocking that from happening because the OpenVPN networking device remains active. Maybe? Perhaps this goes back to the RESOLV-RETRY setting... Perhaps the OpenVPN device never tells the operating system it is down because OpenVPN keeps trying to resolve the host address?

The other confusing point for me is why the RESOLV-RETRY setting should affect this "wifi disconnect" scenario at all if I'm using an IP address to connect from client to server. According to my understanding of the manual RESOLV-RETRY should only work in instances where a "hostname" is used in the REMOTE setting, not an IP address...

I have done some initital testing using both a URL and an IP address to connect from client to server and my solution to change the RESOLV-RETRY setting seems to work in both scenarios.

EDIT:
It appears I'm also forced to remove the PERSIST-TUN option as well to get this solution to work. I have no clue what ramifications may be involved with removing this option. It appears that whatever issue causes my problem can only be rectified by a restart involving closing and re-opening the OpenVPN device on the client side. Because including the PRESIST-TUN option caused the same error I mentioned earlier in this thread regarding an inabiliity to resolve the domain name, I tried using both the IP address and domain name in the REMOTE option to connect with PERSIST-TUN enabled. Same results either way.

So this is a third point of confusion for me. Why is a full restart required (necessitating the TAP/TUN device to be closed and re-opened) in order to reconnect the tunnel after the wifi connection on the client machine is dropped briefly?
I should also indicate that all this testing was done with the option "ROUTE 8.8.8.8 255.255.255.255 net_gateway" in place on the client. But removing this option doesn't appear to affect the outcome.

And one last thing, fwiw. I am now using KEEPALIVE 10 20 instead of KEEPALIVE 10 120 in hopes it'll bring the tunnel back up quickly enough to suit my needs. I'll need to test further to know if this will work for me.

Sorry for all the edits if anyone else has been following this. I think I'm done with this specific post now. /sigh

[Mimiko]

I'm more and more worried that your system is malfunctioning. Having so much different problem brings the idea of a broken system. I will sugest you to do a clean install of the system.

[gork]

Well, I have no base from which to compare how these OpenVPN installations should work. The client machine is a fresh install, but the server machine is not. I suppose it's a little difficult to find out from someone else if their similar setup works differently than mine currently does becuase there are so many different options/settings. Because if this it's difficult for me to differentiate between bugs/setups/OS problems etc.

I'm hoping the way it's working now will do what I need - and I hope others who try to do the same thing may have additional comments/thoughts at some point I can learn even more from. Reinstalling the server OS isn't something that will happen anytime soon, sadly, that is my "server computer" and does way too much for me to just take it down. And a reinstallation would be a nightmare!

Once I have a chance to do further testing I'll post back with my finaly client and sever config files, if everything seems to be working properly. I'll also watch the thread for any more thoughts you or anyone else may have. I have appreciated your posts so much, and have learned a lot! I also kind of hope that our back-and-forth may help the OP with a somewhat possibly related issue if s/he ever checks back.

[gork]

As promised, here's what I ended up going with. It's not perfect because when the wifi hiccups the tunnel is completely lost and anything I'm doing through the tunnel which requires a constant connection goes down. The tunnel is automatically rebuilt aftwards though, but I have to manually reconnect my applications when this happens. Thankfully I don't have problems with the wifi connection very often.

As I've mentioned in previous posts, I had to remove the PERSIST-TUN option from the client config file. I can't help but think if the VPN reconnected properly with this option enabled that maybe my applications would reconnect automatically after the tunnel is re-established. I would guess that my applications permanently lose connectivity because removing this option forces the virtual NIC into a hard reset when a ping doesn't return. I feel my setup should work fine with PERSIST-TUN enabled, but I can't figure out why it doesn't.

Code: Select all

# SERVER #

local 10.168.1.34
port 1194
proto udp
mssfix 1400
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
dev tap
ca "C:\\xxx.crt"  
cert "C:\\xxx.crt"
key "C:\\xxx.key"
dh "C:\\xxx.pem"
tls-auth xxx.key 0
server x.x.x.x 255.255.255.128
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
keepalive 10 20
cipher AES-128-CBC
comp-lzo
max-clients 4
persist-key
persist-tun
status openvpn-status.log
verb 1

Code: Select all

client
dev tap
proto udp
remote remote.myurl.com 1194
route x.x.x.x 255.255.255.0 vpn_gateway 3
resolv-retry 5
nobind
persist-key
ca "xxx.crt"
cert "xxx.crt"
key "xxx.key"
tls-auth xxx.key 1
ns-cert-type server
cipher AES-128-CBC
comp-lzo
verb 1