Reconnect after wifi drop and reconnect, no route, no dns etc.

Hi,

i have an issue with openconnect reconnection after wifi reconnect.

Setup:

• Wifi connection running
• Openconnect connection established -> tun0 with ip address, routes fine, dns resolf over vpn ok

Scenario: Wifi drop connection, ip address lost and later reconnect wifi.

Problems: Because of tun0 with ip address still present, default route still on tun0 and no route to openconnect server via wifi: no openconnect reconnect possible. After i add a route, and openconnect reconnect was successful: no dns resolv over vpn.

Fix:

1. add route to server via upcomming interface
2. after establish vpn connection again(which works after i add a route manually), add dns resolf from vpn again to tun0

Is it possible to fix this in openconnect?

ragards

Strictly speaking, this isn't an OpenConnect problem. OpenConnect does the right thing here — it reconnects, then re-invokes its vpnc-script with reason=reconnect.

If you're using it from NetworkManager, it does work (ish. cf. https://bugzilla.gnome.org/show_bug.cgi?id=794190 )

What we need to do to handle the non-NetworkManager case is fix up vpnc-script so that it will reinstate the appropriate routes when being invoked for a reconnect. IIRC it does nothing right now, but making it behave like the connect action might be a good start. I suspect you'll have one or two things to fix up after doing that (especially with saving/restoring DNS perhaps?).

Hm, perhaps we do also want a pre-reconnect invocation of the vpnc-script, to ensure that the route to the VPN server is through the physical network, not through the VPN itself?

Yes, and a resolv update after reconnect like e.g. systemd-resolv -i tun0 --set-domain xxx --set-dns x.x.x.x --set-dns y.y.y.y

mentioned in commit 5e83e6a4

I've pushed a commit to the attempt-reconnect branch which will invoke vpnc-script with reason=attempt-reconnect before it tries to reconnect. You should be able to contrive something which will check for the route to the server being through the tunnel itself, and reinstate it through the physical network instead.

Thx, i will try

mentioned in commit vpnc-scripts@1000e0f6

mentioned in commit c2755eef

I've pushed the OpenConnect part, which seems to be doing the right thing, and a stub to vpnc-script here. Let's follow up on the vpnc-script part separately. Thanks.

closed

mentioned in commit vpnc-scripts@42993172

mentioned in merge request vpnc-scripts!14 (merged)

mentioned in commit vpnc-scripts@8e2fb9c4

mentioned in commit vpnc-scripts@75268022

mentioned in issue #297

mentioned in merge request vpnc-scripts!69