You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Handle reason='attempt-reconnect' on Linux, and stub for it on macOS/*BSD
The case where the "real" network device disappears or disconnects, while
the VPN/tunnel device stays up is a surprisingly complex one to handle
correctly. The main issue is that the "explicit route" to the VPN gateway
on the underlying network device may have disappeared, and the OS routing
utilities may erroneously suggest a looped-back route (over the VPN/tunnel
device) as the optimal route to the gateway.
This issue arises particularly — but NOT exclusively — if the *default*
route for the relevant network family is now assigned to the VPN/tunnel
device.
See:
- https://gitlab.com/openconnect/openconnect/issues/17 for the initial report of this problem,
- https://gitlab.com/openconnect/openconnect/-/commit/c2755eefb4e00e915c330495b33d3f5db926615b
for where the vpnc-script call with reason='attempt-reconnect' was added
to OpenConnect (merged in v8.02)
- https://gitlab.com/openconnect/vpnc-scripts/-/commit/1000e0f6dd7d6bff163169a46359211c1fc3a6d2
for where an initial placeholder was first added to vpnc-script
- https://gitlab.com/openconnect/vpnc-scripts/-/merge_requests/14 for the
first actually-working support in vpnc-script (for Linux)m
- and numerous subsequent changes to handle macOS/*BSD, IPv6, and corner cases
We need to handle attempt-reconnect in vpn-slice. This mostly borrows from
what vpnc-script does.
Still TODO:
- Flesh out the macOS/*BSD implementation. Instead of 'route -n get', we should use 'netstat -r -n'
to ensure that we don't get a looped-back route, as vpnc-script does since
https://gitlab.com/openconnect/vpnc-scripts/-/blob/412a1faffa72fcda54e8c42d22e0057e56240ff1/vpnc-script#L395-402
- Linux: preserve the 'onlink' route flag. This requires replacing 'ip route get' with 'ip route show'
in all cases. See https://gitlab.com/openconnect/vpnc-scripts/-/merge_requests/27
Here is an example of OpenConnect + vpn-slice correctly re-establishing the route
to the VPN gateway even after it's removed by a network outage, leaving the default route looped-back
through the VPN/tunnel interface.
$ openconnect --script 'vpn-slice --dump -vvv 0.0.0.0/0'
...
... <authenticate successfully>
...
Called by /usr/sbin/openconnect (PID 123456) with environment variables for vpnc-script:
reason => reason=<reasons.connect: 2>
VPNGATEWAY => gateway=IPv4Address('1.2.3.4')
TUNDEV => tundev='tun0'
....
Complete set of subnets to include in VPN routes:
0.0.0.0/0
Set explicit route to VPN gateway 1.2.3.4 (via 10.224.0.1, dev wlan0, src 10.224.0.123)
Blocked incoming traffic from VPN interface with iptables.
Adding route to nameserver 8.8.8.8 through tun0.
Adding route to nameserver 1.1.1.1 through tun0.
Adding route to subnet 0.0.0.0/0 through tun0. # <----
Added routes for 2 nameservers, 1 subnets, 0 aliases.
...
... <we have successfully connected>
...
... <disconnect and reconnect from WiFi, so that explicit route to gateway is lost>
...
... <OpenConnect dead peer detection kicks in>
...
Failed to reconnect to host vpn.company.com: Interrupted system call
sleep 10s, remaining timeout 300s
...
Called by /usr/sbin/openconnect (PID 551671) with environment variables for vpnc-script:
reason => reason=<reasons.attempt_reconnect: 5>
VPNGATEWAY => gateway=IPv4Address('1.2.3.4')
TUNDEV => tundev='tun0'
...
Complete set of subnets to include in VPN routes:
0.0.0.0/0
Reset explicit route to VPN gateway 1.2.3.4 (via 10.224.0.1, dev wlan0, metric 600) # <---
SSL negotiation with vpn.company.com
Connected to HTTPS on vpn.company.com with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM)
0 commit comments