On Thu, 2018-03-08 at 20:14 +0000, David Woodhouse wrote:
On Thu, 2018-03-08 at 11:35 +0000, David Woodhouse wrote:There is one problem with NetworkManager which has users still sticking to the proprietary Cisco AnyConnect client, and I'm trying to work out how to fix it properly. The problem is that when your underlying Ethernet or wifi connection flaps, or when you suspend/resume or switch networks, the VPN connection is terminated and you have to manually reconnect and authenticate again (in my case, using your hardware token).Hm, so how did I never see *this* before? https://github.com/NetworkManager/NetworkManager/commit/1f544d337c With this in NetworkManager-openconnect: https://git.gnome.org/browse/network-manager-openconnect/commit/?id=f 8e386e2c95 and either: nmcli con modify 'My VPN' vpn.persistent yes
it should be this^^
or nmcli con modify 'My VPN' +vpn.data "persistent=yes" (or both; not sure which it was that made the difference) I now have a persistent VPN connection! It stays up when the underlying physical device goes away. However, it doesn't come *back*. When the VPN first connects, NM adds an explicit route to the VPN gateway through the original physical device. After a disconnect/reconnect of the underlying device, nothing adds that back so we're routing to the VPN server through the VPN. I can add that route back manually, and *then* it re-establishes the connection. It helps if I send the running openconnect a SIGUSR2 to make it immediately reconnect instead of continuing its Dead Peer Detection and periodic retries with backoff. However, NM is still a bit confused: $ nmcli con show 'My VPN' | grep DEVICE GENERAL.DEVICES: vpn0 And I think it's now preferring the DNS servers from the local Ethernet, when it should be *only* using the DNS servers of the VPN connection. It would also be extremely useful for the default route to the VPN to go down while the VPN isn't connected because its underlying device is down. Otherwise, all kinds of connections are timing out instead of failing fast as they should. All this is tested with a fairly old NM 1.2 found in Ubuntu 16.04 — is this expected to work better with something newer? Should I try to update and file bugs for the issues that remain?
Hi, I think on recent versions it should work mostly similar. On the other hand, 1.2 is really old. It would be better to start testing on master, fixing it there, and then see what it needs to get it working on older versions. This requirement that NM needs to add a route for the external gateway is quite annoying. I wish there would be a special route type that says, "do not ever route to destination $EXT_GW/32 via this interface, and continue route-lookup". There are route types like "throw", but that is only for policy routing and not really a nice solution. The advantage is, that the NetworkManager can add this route to the VPN device, instead of searching for some underlying device where it thinks the gateway is reachable. best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part