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
