Re: VPN reconnect



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=f8e386e2c95

and either:
 nmcli con modify 'My VPN' vpn.persistent yes
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?

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]