Tony van der Hoff wrote: > I have OpenVPN on my KDE Wheezy laptop configured to connect to my > wheezy VPS. When booting from scratch this works fine. Works for me too. Note that I am not using KDE however. Doesn't seem like that should matter. Unless you are using some KDE specific network something. > However, if I close the lid, thus putting the lappie into sleep mode, > then re-open it, OpenVPN appears to start, but I'm unable to access any > address outside of my local network, until I run <sudo service openvpn > restart>. You say "address" which sounds promising that you are actually talking about addresses explicitly. But most people confuse names and addresses and mix them up in conversation. Do you have a caching nameserver installed? bind9 or other? Does restarting just bind9 also solve the problem? # service bind9 restart One of the more fragile things I have found with VPNs is the DNS server caches responses. It caches negative responses, failures, for a short time too. Therefore it is sometimes the case that a name can't be resolved to an address through the nameserver until it has timed out even though the underlying networking is operating correctly. Restarting the nameserver causes all of the temporary caching such as negative responses to be flushed and they will then be read through from upstream again. When using a vpn you are also very likely using private resources behind that vpn. Probably also using DNS names from that private resource. Yes? In which case special configuration must also be added to ensure that your nameserver is looking up names from the private vpn space and not from the public space. The coffee shop, airport, public wifi won't know about the private names. Does this apply to your configuration? If so then how are you handling this in your configuration? There is currently no standard method in the Debian openvpn package and you will need to write and install your own solution to it. To diagnose the difference look specifically for each individual component of the issue. Perform a ping by address. Perform a name lookup by name. $ host example.com example.com has address 93.184.216.34 example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946 $ ping -c3 93.184.216.34 PING 93.184.216.34 (93.184.216.34) 56(84) bytes of data. 64 bytes from 93.184.216.34: icmp_seq=1 ttl=54 time=56.8 ms 64 bytes from 93.184.216.34: icmp_seq=2 ttl=54 time=58.1 ms 64 bytes from 93.184.216.34: icmp_seq=3 ttl=54 time=57.2 ms --- 93.184.216.34 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 56.862/57.407/58.120/0.527 ms If a ping to the address succeeds and the DNS lookup fails then you know the networking is okay. I suspect this to be the problem. The reason that restarting openvpn causes things to work is that restarting openvpn also restarts installed nameservers too. (Or was that just a local hack I did on my laptop? I don't remember now.) > Google doesn't make any useful suggestions, so does anyone here know > how to fix this? Another useful debugging hint is to run this in a text window and watch the display change. watch ip route show Or the shortest save the keystrokes typing abbreviation. watch ip r When the vpn is offline there won't be any routes for the tunnel devices. After the vpn is established it will register routes corresponding to the tunnels. Seeing them be dropped and established is useful for me to see when the tunnels become usable. Another useful debugging hint is to run this in a window and watch the log file. tail -F /var/log/syslog That will display the actions of openvpn daemon as they are logged to the system log file. Watching that will display what is happening as it happens. Bob
Attachment:
signature.asc
Description: Digital signature