VPN reconnect

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).

This shouldn't be necessary. OpenConnect would happily reconnect
automatically, even when the local IP address changes. If it's run
manually from the command line, this Just Works™ — as long as its
vpnc-script will do the right thing for routing, of course.

It would be good to have a 'persistent' mode for VPN connections in
NetworkManager, so they aren't automatically taken down when the
underlying physical network goes away, and can reconnect themselves.

In the short term though, there might be a simpler option. It's OK to
tear down the logical connection and spawn a new one, as long as I can
re-use the hard-won authentication cookie. Currently, that's ephemeral,
and the auth-dialog provides it to nm-openconnect-service which uses it
once and then forgets it. I'm sure I can work out some way of caching
it, even if it lives in the user's session.

However... when NetworkManager tells nm-openconnect-service to
terminate the session, it doesn't tell it *why* it's disconnecting.
Currently nm-openconnect-service will send openconnect(8) a SIGINT
which tells it to log off properly, terminating the auth session so the
cookie *can't* be re-used for a subsequent connection. In the case
where we're disconnecting because of an underlying route flap, and we
are going to reconnect, we should instead send SIGTERM to make it just
close the connection without logging off.

Now we *might* get away with sending SIGINT and just relying on the
fact that it'll *fail* to log off because the underlying network just
went away anyway... but that's probably not always reliable, even if it
does work sometimes.

I'd be very grateful for ideas on fixing this properly in NM, and even
hacks I might throw together in the meantime to allow my potential
users to switch from the Cisco client.


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

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