Opened 9 years ago
Last modified 7 years ago
#607 new Bug / Defect
Default route not cleared on network fail.
Reported by: | Guinness2702 | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Networking | Version: | OpenVPN 2.3.8 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | default route reconnect |
Cc: |
Description
Steps to reproduce:-
Set up and start openvpn connection with default route via tunnel (i.e. config redirect-gateway defl).
Disable/Enable? network (e.g. pull network cable, wait for failure, and reconnect).
Expected behaviour: openvpn reconnects.
Actual behaviour: openvpn client cannot re-connect to server, because the default route is still via the now down tunnel (see below).
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 <OVPN-GW> 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 <REAL-GW> 0.0.0.0 UG 0 0 0 eth0
...
Proposed solution: Either remove the default route, when the link goes down, or don't remove the route entry for the server (when the link is up, I also have the following route line)
<OVPN-SERVER> <REAL-GW> 255.255.255.255 UGH 0 0 0 eth0
This is a daily occurrance for me, as I commonly move from my desk to meetings, and disconnect from the physical network on the way. The current workaround is to manually restart the openvpn service every time this happens.
# openvpn --version
OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@…>
Compile time defines: enable_crypto=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_eurephia=yes enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_maintainer_mode=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=yes with_crypto_library=openssl with_gnu_ld=yes with_ifconfig_path=/sbin/ifconfig with_iproute_path=/sbin/ip with_mem_check=no with_plugindir='${prefix}/lib/openvpn' with_route_path=/sbin/route with_sysroot=no
# cat /etc/openvpn/my.conf
client
dev tun
remote <OVPN-SERVER> 1194
nobind
resolv-retry infinite
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
tls-auth /etc/openvpn/server-ta.key 1
comp-lzo
proto tcp
ping 15
ping-restart 45
ping-timer-rem
redirect-gateway def1
dhcp-option DNS 8.8.8.8
up /etc/openvpn/server.up # Just rewrites resolv.conf - but note server, above, is specified by IP address
Change History (4)
comment:1 Changed 9 years ago by
Version: | 2.2.2 → 2.3.8 |
---|
comment:2 follow-up: 3 Changed 8 years ago by
I seem to have the same problem, rendering --keep-alive useless.
After Inactivity timeout (--ping-restart), restarting, openvpn tries to set up a new connection, but because the 0.0.0.0/1 via 193.180.165.129 dev tun0 route onto the tunnel is still there, DNS look-ups fail and no new connection can be established.
Why not just remove all routes onto the tunnel when it goes down?
comment:3 Changed 8 years ago by
Replying to bneijt:
seem to have the same problem, rendering --keep-alive useless.
No. In your case, the DNS servers cannot be reached, which can be worked around by adding --bypass-dns to your openvpn config, or ignored by just caching the remote IP, configuring --persist-remote-ip. This has nothing to do with "the underlying network connection goes away, so the tunnel dies".
Why not just remove all routes onto the tunnel when it goes down?
We distinguish between "soft" and "hard" restarts - the "soft" one keeps the tunnel around (so it can be used in environments where OpenVPN drops privileges after tunnel init, and will not be able to bring it back up). A normal timeout/restart will be a "soft" one - depending on the other options in use, reactivating of the tunnel works perfectly fine.
To always make "soft" restarts a "full" restart, use --remap-usr1 SIGHUP
.
comment:4 Changed 7 years ago by
Remove persist-tun from the client config so the tun interface closes and the routes reset to your default interface.
I have seen this behaviour, but the fix is actually not that simple - it's not OpenVPN that is removing the route, but the underlying operating system, or specifically, the DHCP client ("link down" = "forget everything you know about IP config and routing for this interface"), and we don't even know it's gone.
Not exactly sure how to tackle this.