Tony van der Hoff wrote: > I meant 'addresses' <ping 8.8.8.8> gives 100% packet loss. > <ping router> or <ping 192.168.1.1> succeed as expected, so networking > is up. If ping 8.8.8.8 has 100% packet loss then I would say full networking is down. It will be impossible for DNS to function that way. Does that mean your server isn't routing packets for you? The thread started out talking about needing a manual restart after resuming from suspend. But this above makes it sound like you actually have a problem routing packets normally as a separate problem too. > > When using a vpn you are also very likely using private resources > > behind that vpn. > > No, my setup is extremely simple. My only reason for using VPN is to > defeat geolocation filters. I use no resources on the remote host. It > does run a nameserver, but only for a subdomain, which I'm not trying to > access. Very good then. Noted. > > 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. > > I'm not sure that I fully understand your logic, but no matter, it is > the entire network beyond my router that appears unresponsive. I think > DNS is a red herring. That was the root of my question. Is the problem related to networking or related to DNS. I think you have refined the answer to that it is network related. And therefore any use of DNS is going to be a cascade failure behind it. > The routing table is identical for the failing case and the non-failing one: > every 2.0s: ip route show > > 0.0.0.0/1 via 10.8.0.13 dev tun0 > default via 192.168.1.1 dev wlan0 proto static > 10.8.0.1 via 10.8.0.13 dev tun0 > 10.8.0.13 dev tun0 proto kernel scope link src 10.8.0.14 > 128.0.0.0/1 via 10.8.0.13 dev tun0 > 169.254.0.0/16 dev wlan0 scope link metric 1000 > 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.223 Looks to me like you are following the strategy here: https://openvpn.net/index.php/open-source/documentation/howto.html#redirect > This seems to be the most fruitful approach, but my networking knowledge > is severely challenged by the results: > > Attachment 1: syslog -- After the wake-up from suspend. > Attachment 2: syslog2 -- after issuing openvpn restart. There is a lot of information there. Frankly more than I can read through at the moment. However I gave them a quick look and I see that syslog doesn't include any openvpn entries. Shouldn't it? I just now suspended and resumed my openvpn running laptop. It automatically restarted. I don't know why yours does not. It has been long enough since I have worked with my openvpn configuration on my laptop that frankly I am not sure if this is a stock behavior or something I wired in along the way. But a quick look and I don't see anything custom for this part of it. However I will be setting up another laptop very soon and will be able to investigate from a pristine installation then. Bob Apr 20 13:23:46 dismay ovpn-phobia[2786]: /sbin/ifconfig tun0 0.0.0.0 Apr 20 13:23:46 dismay ovpn-phobia[2786]: SIGUSR1[soft,ping-restart] received, process restarting Apr 20 13:23:48 dismay ovpn-phobia[2786]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Apr 20 13:23:48 dismay ovpn-phobia[2786]: /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted> Apr 20 13:23:48 dismay ovpn-phobia[2786]: Control Channel Authentication: using 'ta.key' as a OpenVPN static key file Apr 20 13:23:48 dismay ovpn-phobia[2786]: UDPv4 link local: [undef] Apr 20 13:23:48 dismay ovpn-phobia[2786]: UDPv4 link remote: [AF_INET]216.17.153.62:1194 Apr 20 13:24:23 dismay ovpn-phobia[2786]: [server] Peer Connection Initiated with [AF_INET]216.17.153.62:1194 Apr 20 13:24:30 dismay ovpn-phobia[2786]: TUN/TAP device tun0 opened Apr 20 13:24:30 dismay ovpn-phobia[2786]: /sbin/ifconfig tun0 172.27.61.4 pointopoint 172.27.61.1 mtu 1500 Apr 20 13:24:30 dismay named[16709]: received control channel command 'reload' Apr 20 13:24:30 dismay named[16709]: loading configuration from '/etc/bind/named.conf' Apr 20 13:24:30 dismay named[16709]: reading built-in trusted keys from file '/etc/bind/bind.keys' Apr 20 13:24:30 dismay named[16709]: using default UDP/IPv4 port range: [1024, 65535] Apr 20 13:24:30 dismay named[16709]: using default UDP/IPv6 port range: [1024, 65535] Apr 20 13:24:30 dismay named[16709]: no IPv6 interfaces found Apr 20 13:24:30 dismay named[16709]: reloading configuration succeeded Apr 20 13:24:30 dismay named[16709]: reloading zones succeeded Apr 20 13:24:30 dismay ovpn-phobia[2786]: Initialization Sequence Completed
Attachment:
signature.asc
Description: Digital signature