Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Control: tags -1 + pending On Thu, Aug 03, 2017 at 11:21:28AM +0200, Bernhard Schmidt wrote: > stretch-pu filed as > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870604 Accepted into p-u, will be part of Debian 9.2 and should be available shortly on https://www.debian.org/releases/proposed-updates.en.html Best Regards, Bernhard
Processed: Re: Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Processing control commands:
> tags -1 + pending
Bug #863110 {Done: Bernhard Schmidt } [openvpn] openvpn: VPN
remains connected, but network is unreachable after 30-45 min and requires
reconnect
Added tag(s) pending.
--
863110: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863110
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
On 18.07.2017 13:26, Patrick Matthäi wrote: > Am 18.07.2017 um 13:05 schrieb Patrick Matthäi: >>> I've browsed through the git commits between 2.4.0 and 2.4.3, these >>> might be relevant here >>> >>> https://community.openvpn.net/openvpn/ticket/812 >>> https://community.openvpn.net/openvpn/ticket/887 >>> >>> Are you able to build a version with these patches applied yourself? >> I will build it for one of the notworking nodes and see what happens and >> give a feedback > > Yeah very nice! With both patches applied it is working :D Like the > version 2.4.3-4 I get now a "NOTE: Pulled options changed on restart, > will need to close and reopen TUN/TAP device", all routes are removed > and readded and the connection works again. Two hosts, which are not > working after a restart of the server, do not have got this and refuse > to work. > Would love to see these patches in 9.1 :) stretch-pu filed as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870604 Bernhard
Processed: Re: Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Processing control commands: > forwarded -1 https://community.openvpn.net/openvpn/ticket/812 Bug #863110 [openvpn] openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect Set Bug forwarded-to-address to 'https://community.openvpn.net/openvpn/ticket/812'. -- 863110: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863110 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Control: forwarded -1 https://community.openvpn.net/openvpn/ticket/812 > I have tested it three times, it is definitly > https://community.openvpn.net/openvpn/ticket/812 which fixes this issue Thanks, I'll fix it ASAP. Bernhard
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Am 18.07.2017 um 13:29 schrieb Bernhard Schmidt: I've browsed through the git commits between 2.4.0 and 2.4.3, these might be relevant here https://community.openvpn.net/openvpn/ticket/812 https://community.openvpn.net/openvpn/ticket/887 Are you able to build a version with these patches applied yourself? >>> I will build it for one of the notworking nodes and see what happens and >>> give a feedback >> Yeah very nice! With both patches applied it is working :D Like the >> version 2.4.3-4 I get now a "NOTE: Pulled options changed on restart, >> will need to close and reopen TUN/TAP device", all routes are removed >> and readded and the connection works again. Two hosts, which are not >> working after a restart of the server, do not have got this and refuse >> to work. > Can you try to test which of those it is? I need a specific patch to get > into stable. I have tested it three times, it is definitly https://community.openvpn.net/openvpn/ticket/812 which fixes this issue > >> Would love to see these patches in 9.1 :) > 9.1 is already frozen, but I will submit it into 9.2 as soon as I know > which patch it is. Urgs right.. ;) -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Am 18.07.2017 um 13:05 schrieb Patrick Matthäi: >> I've browsed through the git commits between 2.4.0 and 2.4.3, these >> might be relevant here >> >> https://community.openvpn.net/openvpn/ticket/812 >> https://community.openvpn.net/openvpn/ticket/887 >> >> Are you able to build a version with these patches applied yourself? > I will build it for one of the notworking nodes and see what happens and > give a feedback Yeah very nice! With both patches applied it is working :D Like the version 2.4.3-4 I get now a "NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device", all routes are removed and readded and the connection works again. Two hosts, which are not working after a restart of the server, do not have got this and refuse to work. Would love to see these patches in 9.1 :) -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Am 18.07.2017 um 13:26 schrieb Patrick Matthäi: Hi, > Am 18.07.2017 um 13:05 schrieb Patrick Matthäi: >>> I've browsed through the git commits between 2.4.0 and 2.4.3, these >>> might be relevant here >>> >>> https://community.openvpn.net/openvpn/ticket/812 >>> https://community.openvpn.net/openvpn/ticket/887 >>> >>> Are you able to build a version with these patches applied yourself? >> I will build it for one of the notworking nodes and see what happens and >> give a feedback > > Yeah very nice! With both patches applied it is working :D Like the > version 2.4.3-4 I get now a "NOTE: Pulled options changed on restart, > will need to close and reopen TUN/TAP device", all routes are removed > and readded and the connection works again. Two hosts, which are not > working after a restart of the server, do not have got this and refuse > to work. Can you try to test which of those it is? I need a specific patch to get into stable. > Would love to see these patches in 9.1 :) 9.1 is already frozen, but I will submit it into 9.2 as soon as I know which patch it is. Bernhard
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Am 18.07.2017 um 12:58 schrieb Bernhard Schmidt: > The notworking version does nothing like this. This smells like a bug. > > What I don't understand is that you claim the VPN endpoint is not > reachable on the dead nodes (the outer IP I presume). Both nodes still > have a hostroute towards the VPN gateway in their routing table > I mean not the external VPN endpoint address, but the VPN internal server address (10.200.13.1 here). > > I've browsed through the git commits between 2.4.0 and 2.4.3, these > might be relevant here > > https://community.openvpn.net/openvpn/ticket/812 > https://community.openvpn.net/openvpn/ticket/887 > > Are you able to build a version with these patches applied yourself? I will build it for one of the notworking nodes and see what happens and give a feedback -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Control: fixed -1 2.4.3-4 Am 18.07.2017 um 10:44 schrieb Patrick Matthäi: Hi, thanks for the logs! > we have got the same issue with all our VPNs upgraded to Stretch now. > Most VPNs are connected about a 1 GBit/s datacenter connection with each > other (also same LAN), the other ones are connected about a 100 MBit/s > connection. >>> I also uploaded the current testing version to stretch-bpo and deployed >>> it on one host, to see if there is a difference later >> Ah, I was already wondering who did. >> >> > > Today I updated our Sophos UTM, which is one OpenVPN server, where are > here multiple vpn clients are connected with. While updating the UTM, > there are 2 reboots of the devices, so the client needs a reconnect. > > The client with version openvpn_2.4.3-4~bpo9+1 still works, all > 2.4.0-6+deb9u1 are dead. Also the VPN endpoint is not reachable on the > dead nodes. > Please note, that I replaced many IPs and hostnames with other stuff. Thanks, so 2.4.0 is affected and 2.4.3-4 is not anymore. I have adjusted the fixed version accordingly. I have cleaned up your logs from working and notworking1 to get something I can feed to diff, see attached. There is one remarkable difference. When the working client reconnects it logs Preserving previous TUN/TAP instance: tun0 +NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device. +/sbin/ip route del EXT.IP.FROM.VPN/32 +/sbin/ip route del INT.BEHIND.VPN2.0/24 +/sbin/ip route del INT.BEHIND.VPN1.0/24 +Closing TUN/TAP interface +/sbin/ip addr del dev tun0 10.200.13.2/24 +ROUTE_GATEWAY TWO.NETWORK.2.1/255.255.255.0 IFACE=eth0 HWADDR=00:0c:29:cd:45:cc +TUN/TAP device tun0 opened +TUN/TAP TX queue length set to 100 +do_ifconfig, tt->did_ifconfig_ipv6_setup=0 +/sbin/ip link set dev tun0 up mtu 1500 +/sbin/ip addr add dev tun0 10.200.13.4/24 broadcast 10.200.13.255 +/sbin/ip route add EXT.IP.FROM.VPN/32 via TWO.NETWORK.2.1 +/sbin/ip route add INT.BEHIND.VPN2.0/24 via 10.200.13.1 +/sbin/ip route add INT.BEHIND.VPN1.0/24 via 10.200.13.1 Initialization Sequence Completed The notworking version does nothing like this. This smells like a bug. What I don't understand is that you claim the VPN endpoint is not reachable on the dead nodes (the outer IP I presume). Both nodes still have a hostroute towards the VPN gateway in their routing table root@login:~# ip r default via TWO.NETWORK.2.1 dev eth0 onlink EXT.IP.FROM.VPN via TWO.NETWORK.2.1 dev eth0 root@notworking1:~# ip r default via ONE.NETWORK.1.1 dev eth0 onlink EXT.IP.FROM.VPN via ONE.NETWORK.1.1 dev eth0 and you can see in the log that notworking1 actually has reconnected just fine, so the outer communication seems to be working. Restart pause, 5 second(s) TCP/UDP: Preserving recently used remote address: [AF_INET]EXT.IP.FROM.VPN:1197 Socket Buffers: R=[212992->212992] S=[212992->212992] UDP link local: (not bound) UDP link remote: [AF_INET]EXT.IP.FROM.VPN:1197 TLS: Initial packet from [AF_INET]EXT.IP.FROM.VPN:1197, sid=05d4dc5d c20155bd VERIFY OK: depth=1, C=de, L=Paderborn, O=company Internet GmbH, CN=company Internet GmbH VPN CA, emailAddress=tech...@company.de VERIFY X509NAME OK: C=de, ST=Nordrhein-Westfalen, L=Paderborn, O=company Internet GmbH, OU=Technik, CN=address.of.utm.de, emailAddress=tech...@company.de VERIFY OK: depth=0, C=de, ST=Nordrhein-Westfalen, L=Paderborn, O=company Internet GmbH, OU=Technik, CN=address.of.utm.de, emailAddress=tech...@company.de Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA [address.of.utm.de] Peer Connection Initiated with [AF_INET]EXT.IP.FROM.VPN:1197 so it's not the dreaded routing "loop". I've browsed through the git commits between 2.4.0 and 2.4.3, these might be relevant here https://community.openvpn.net/openvpn/ticket/812 https://community.openvpn.net/openvpn/ticket/887 Are you able to build a version with these patches applied yourself? Bernhard [address.of.utm.de] Inactivity timeout (--ping-restart), restarting SIGUSR1[soft,ping-restart] received, process restarting Restart pause, 5 second(s) TCP/UDP: Preserving recently used remote address: [AF_INET]EXT.IP.FROM.VPN:1197 Socket Buffers: R=[212992->212992] S=[212992->212992] UDP link local: (not bound) UDP link remote: [AF_INET]EXT.IP.FROM.VPN:1197 TLS: Initial packet from [AF_INET]EXT.IP.FROM.VPN:1197, sid=4030f3bf 8b41b71f VERIFY OK: depth=1, C=de, L=Paderborn, O=company Internet GmbH, CN=company Internet GmbH VPN CA, emailAddress=tech...@company.de VERIFY X509NAME OK: C=de, ST=Nordrhein-Westfalen, L=Paderborn, O=company Internet GmbH, OU=Technik, CN=address.of.utm.de, emailAddress=tech...@company.de VERIFY OK: depth=0, C=de, ST=Nordrhein-Westfalen, L=Paderborn, O=company Internet GmbH, OU=Technik, CN=address.of.utm.de, emailAddress=tech...@company.de Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA [address.of.utm.de] Peer Connection Initiated with
Processed: Re: Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Processing control commands: > fixed -1 2.4.3-4 Bug #863110 [openvpn] openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect Marked as fixed in versions openvpn/2.4.3-4. -- 863110: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863110 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Am 12.07.2017 um 16:17 schrieb Bernhard Schmidt: > Am 12.07.2017 um 15:41 schrieb Patrick Matthäi: > > Hi, > we have got the same issue with all our VPNs upgraded to Stretch now. Most VPNs are connected about a 1 GBit/s datacenter connection with each other (also same LAN), the other ones are connected about a 100 MBit/s connection. >>> >> I also uploaded the current testing version to stretch-bpo and deployed >> it on one host, to see if there is a difference later > Ah, I was already wondering who did. > > Today I updated our Sophos UTM, which is one OpenVPN server, where are here multiple vpn clients are connected with. While updating the UTM, there are 2 reboots of the devices, so the client needs a reconnect. The client with version openvpn_2.4.3-4~bpo9+1 still works, all 2.4.0-6+deb9u1 are dead. Also the VPN endpoint is not reachable on the dead nodes. Please note, that I replaced many IPs and hostnames with other stuff. Working one (tun0 affected, tun1 is another VPN): Jul 18 09:32:25 login ovpn-utm[8335]: [address.of.utm.de] Inactivity timeout (--ping-restart), restarting Jul 18 09:32:25 login ovpn-utm[8335]: SIGUSR1[soft,ping-restart] received, process restarting Jul 18 09:32:25 login ovpn-utm[8335]: Restart pause, 5 second(s) Jul 18 09:32:30 login ovpn-utm[8335]: TCP/UDP: Preserving recently used remote address: [AF_INET]EXT.IP.FROM.VPN:1197 Jul 18 09:32:30 login ovpn-utm[8335]: Socket Buffers: R=[212992->212992] S=[212992->212992] Jul 18 09:32:30 login ovpn-utm[8335]: UDP link local: (not bound) Jul 18 09:32:30 login ovpn-utm[8335]: UDP link remote: [AF_INET]EXT.IP.FROM.VPN:1197 Jul 18 09:32:30 login ovpn-utm[8335]: TLS: Initial packet from [AF_INET]EXT.IP.FROM.VPN:1197, sid=4030f3bf 8b41b71f Jul 18 09:32:31 login ovpn-utm[8335]: VERIFY OK: depth=1, C=de, L=Paderborn, O=company Internet GmbH, CN=company Internet GmbH VPN CA, emailAddress=tech...@company.de Jul 18 09:32:31 login ovpn-utm[8335]: VERIFY X509NAME OK: C=de, ST=Nordrhein-Westfalen, L=Paderborn, O=company Internet GmbH, OU=Technik, CN=address.of.utm.de, emailAddress=tech...@company.de Jul 18 09:32:31 login ovpn-utm[8335]: VERIFY OK: depth=0, C=de, ST=Nordrhein-Westfalen, L=Paderborn, O=company Internet GmbH, OU=Technik, CN=address.of.utm.de, emailAddress=tech...@company.de Jul 18 09:32:33 login ovpn-utm[8335]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA Jul 18 09:32:33 login ovpn-utm[8335]: [address.of.utm.de] Peer Connection Initiated with [AF_INET]EXT.IP.FROM.VPN:1197 Jul 18 09:32:34 login ovpn-utm[8335]: SENT CONTROL [address.of.utm.de]: 'PUSH_REQUEST' (status=1) Jul 18 09:32:35 login ovpn-utm[8335]: PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.200.13.1,route-gateway 10.200.13.1,topology subnet,ping 10,ping-restart 120,route INT.BEHIND.VPN2.0 255.255.255.0,route INT.BEHIND.VPN1.0 255.255.255.0,dhcp-option DNS INT.BEHIND.VPN1.210,dhcp-option DNS INT.BEHIND.VPN2.250,dhcp-option DOMAIN domäne.intern,ifconfig 10.200.13.4 255.255.255.0' Jul 18 09:32:35 login ovpn-utm[8335]: OPTIONS IMPORT: timers and/or timeouts modified Jul 18 09:32:35 login ovpn-utm[8335]: OPTIONS IMPORT: --ifconfig/up options modified Jul 18 09:32:35 login ovpn-utm[8335]: OPTIONS IMPORT: route options modified Jul 18 09:32:35 login ovpn-utm[8335]: OPTIONS IMPORT: route-related options modified Jul 18 09:32:35 login ovpn-utm[8335]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Jul 18 09:32:35 login ovpn-utm[8335]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Jul 18 09:32:35 login ovpn-utm[8335]: Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Jul 18 09:32:35 login ovpn-utm[8335]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Jul 18 09:32:35 login ovpn-utm[8335]: Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Jul 18 09:32:35 login ovpn-utm[8335]: Preserving previous TUN/TAP instance: tun0 Jul 18 09:32:35 login ovpn-utm[8335]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device. Jul 18 09:32:35 login ovpn-utm[8335]: /sbin/ip route del EXT.IP.FROM.VPN/32 Jul 18 09:32:35 login ovpn-utm[8335]: /sbin/ip route del INT.BEHIND.VPN2.0/24 Jul 18 09:32:35 login ovpn-utm[8335]: /sbin/ip route del INT.BEHIND.VPN1.0/24 Jul 18 09:32:35 login ovpn-utm[8335]: Closing TUN/TAP interface Jul 18 09:32:35 login ovpn-utm[8335]: /sbin/ip addr del dev tun0 10.200.13.2/24 Jul 18 09:32:36 login ovpn-utm[8335]: ROUTE_GATEWAY TWO.NETWORK.2.1/255.255.255.0 IFACE=eth0 HWADDR=00:0c:29:cd:45:cc Jul 18 09:32:36 login ovpn-utm[8335]: TUN/TAP device tun0 opened Jul 18 09:32:36 login ovpn-utm[8335]: TUN/TAP TX queue length set to 100 Jul 18 09:32:36 login ovpn-utm[8335]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Jul 18 09:32:36 login ovpn-utm[8335]: /sbin/ip link set dev tun0 up mtu 1500 Jul 18 09:32:36 login ovpn-utm[8335]: /sbin/ip addr add dev tun0
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Hi, > I also uploaded the current testing version to stretch-bpo and deployed > it on one host, to see if there is a difference later BTW, right now the version from Buster (2.4.3-4) is installable on Stretch just fine, so no need for an official backport if you are doing a short test. Bernhard
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Am 12.07.2017 um 15:41 schrieb Patrick Matthäi: Hi, >>> we have got the same issue with all our VPNs upgraded to Stretch now. >>> Most VPNs are connected about a 1 GBit/s datacenter connection with each >>> other (also same LAN), the other ones are connected about a 100 MBit/s >>> connection. >> >>> route remote_host 255.255.255.255 net_gateway >> This suggests that the VPN server is inside the netblocks routed through >> the tunnel, right? > If I understood you correct: yes - all VPNs are "clients" No, the question is whether the outer IP address (the IP address of the VPN server, "remote_host" here) is within the network that is routed through the VPN tunnel. Example: VPN-Server at 10.1.1.1 routed network 10.0.0.0/8 A client has a wired connection with a default route to 1.1.1.1 default via 1.1.1.1 dev eth0 You can reach 10.1.1.1 through that default route. However, when the tunnel is established the routing table would look like this default via 1.1.1.1 dev eth0 10.0.0.0/8 via tun0 Traffic to 10.1.1.1 would be sent to tun0, encapsulated in OpenVPN into a packet to 10.1.1.1, which would be sent to tun0, ... So the statement above would create a more-specific route for the remote address through the wired connection default via 1.1.1.1 dev eth0 10.0.0.0/8 via tun0 10.1.1.1/32 via 1.1.1.1 dev eth0 The problem is, when eth0 flaps both routes are deleted, but only the default route is recreated. So you end up with the described internal routing loop until you restart OpenVPN (which recreates the /32 route). > I also uploaded the current testing version to stretch-bpo and deployed > it on one host, to see if there is a difference later Ah, I was already wondering who did. Bernhard
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
Am 12.07.2017 um 12:10 schrieb Bernhard Schmidt:
> On Wed, Jul 12, 2017 at 09:35:53AM +0200, Patrick Matthäi wrote:
>
> Hi,
>
>> we have got the same issue with all our VPNs upgraded to Stretch now.
>> Most VPNs are connected about a 1 GBit/s datacenter connection with each
>> other (also same LAN), the other ones are connected about a 100 MBit/s
>> connection.
>
>> route remote_host 255.255.255.255 net_gateway
> This suggests that the VPN server is inside the netblocks routed through
> the tunnel, right?
If I understood you correct: yes - all VPNs are "clients"
>
> When the problem happens, can you check whether the static /32 route
> towards the VPN server still exists and points outside the tunnel.
We will check if it occurs again and give you the output of "ip {a,r,l}"
Anything else needed?
>
> Please also check a couple of minutes before the ping timeout whether you
> see anything network related. Are you using ifupdown or NetworkManager
> on the client?
>
> Bernhard
>
That is mostly hard to check, because that are many endpoints and
clients. One client is located in the hosteurope network, which had got
a maintainance this night (with a short outage), but also many other
customer VPNs (sophos, self hosted VPNs and so on) were affected from
different locations and links. So I dont think that this is the whole
thing triggering this bug.
I also uploaded the current testing version to stretch-bpo and deployed
it on one host, to see if there is a difference later
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
On Wed, Jul 12, 2017 at 09:35:53AM +0200, Patrick Matthäi wrote: Hi, > we have got the same issue with all our VPNs upgraded to Stretch now. > Most VPNs are connected about a 1 GBit/s datacenter connection with each > other (also same LAN), the other ones are connected about a 100 MBit/s > connection. > route remote_host 255.255.255.255 net_gateway This suggests that the VPN server is inside the netblocks routed through the tunnel, right? When the problem happens, can you check whether the static /32 route towards the VPN server still exists and points outside the tunnel. Please also check a couple of minutes before the ping timeout whether you see anything network related. Are you using ifupdown or NetworkManager on the client? Bernhard
Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect
severity #863110 serious thanks Hi, we have got the same issue with all our VPNs upgraded to Stretch now. Most VPNs are connected about a 1 GBit/s datacenter connection with each other (also same LAN), the other ones are connected about a 100 MBit/s connection. Example configuration: client dev tun proto udp remote XYZ 1197 verify-x509-name "C=de, ST=Nordrhein-Westfalen, L=, O=., OU=, CN=, emailAddress=" route remote_host 255.255.255.255 net_gateway resolv-retry infinite nobind persist-key persist-tun ca cert key . auth-user-pass cipher AES-256-CBC auth SHA256 comp-lzo route-delay 4 verb 3 reneg-sec 0 The only thing I have got in my logs is e.g. this: Jul 12 03:02:39 HOST ovpn-ABC_network[20317]: [gateway01] Inactivity timeout (--ping-restart), restarting Jul 12 03:02:39 HOST ovpn-ABC_network[20317]: SIGUSR1[soft,ping-restart] received, process restarting Jul 12 03:02:39 HOST ovpn-ABC_network[20317]: Restart pause, 5 second(s) Jul 12 03:02:44 HOST ovpn-ABC_network[20317]: TCP/UDP: Preserving recently used remote address: [AF_INET].:3 Jul 12 03:02:44 HOST ovpn-ABC_network[20317]: Socket Buffers: R=[87380->87380] S=[16384->16384] Jul 12 03:02:44 HOST ovpn-ABC_network[20317]: Attempting to establish TCP connection with [AF_INET]..:3 [nonblock] Jul 12 03:04:44 HOST ovpn-ABC_network[20317]: TCP: connect to [AF_INET]:3 failed: Connection timed out Jul 12 03:04:44 HOST ovpn-ABC_network[20317]: SIGUSR1[connection failed(soft),init_instance] received, process restarting Jul 12 03:04:44 HOST ovpn-ABC_network[20317]: Restart pause, 5 second(s) Jul 12 03:04:49 HOST ovpn-ABC_network[20317]: TCP/UDP: Preserving recently used remote address: [AF_INET]:3 Jul 12 03:04:49 HOST ovpn-ABC_network[20317]: Socket Buffers: R=[87380->87380] S=[16384->16384] Jul 12 03:04:49 HOST ovpn-ABC_network[20317]: Attempting to establish TCP connection with [AF_INET]..:3 [nonblock] After this the connection was down, until we manualy restarted it. Since all Stretch VPNs are affected here raised the severity of this issue. -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer Blog: http://www.linux-dev.org/ E-Mail: pmatth...@debian.org patr...@linux-dev.org */
