Re: VPN reconnect

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
to the proprietary Cisco AnyConnect client, and I'm trying to work
how to fix it properly.

The problem is that when your underlying Ethernet or wifi
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?

With this in NetworkManager-openconnect:

and either:
 nmcli con modify 'My VPN' vpn.persistent yes

it should be this^^

 nmcli con modify 'My VPN' "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
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

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
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 —
this expected to work better with something newer? Should I try to
update and file bugs for the issues that remain?


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

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.


Attachment: signature.asc
Description: This is a digitally signed message part

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