Re: Generic IPSEC vpn plugin

[Paul Wouters <paul xelerance com>]

On Fri, 24 Apr 2009, Dan Williams wrote:

> The current VPN handling in NM does need a rework, and I started on that
> last fall but it was too close to release to land.  Specific issues that
> need to be fixed include:
>
>    - interactive authentication instead of one-shot credentials

I would not put too much effort in this. Most "interactive" authentication
(I assume you mean XAUTH password or L2TP password) can be "remembered"
on most OS'es. Openswan for a long time refused to support XAUTH
passwords being configured, but we ended up helping people write stupid
shell scripts to work around it. Also, not all IPsec devices worked
properly with XAUTH rekying, when the credentials are needed again. So
in the end we just made it an option and recommend people not to use it.

>    - multiple VPN connections

There is no problem from an ipsec/openwan point of view, as long as you
pass along unique names for these connections to openswan. Note that
there are some unsolvable options, such as ending up having connections
to two remote networks with the same IP range, or one with the same
IP range as your NAT'ed range. I'd recommend ignoring these problems.

> The largest problem with IPSec is that since it's half-kernel and
> half-daemon, there isn't necessarily something there (AFAIK) to alert
> NetworkManager to the presence of a dropped connection or something like
> that.  If there is, that's great, lets use it and it'll be awesome.

DPD RFC 3706. Though Openswan needs to signal this to NM. Openswan
has settings for dpdtimeout, dppdelay= and dpdaction=. Actions can
be to turn off the vpn or to try and restart it.

> There's a few things we'll need from the specific VPN stack in *any*
> case:
>
> * Configuration readable on stdin
> Since config files would need to be written out before starting the
> connection and removed cleanly after the connection goes away, whatever
> daemon manages the connection needs to accept configuration on stdin.
> Command-line based configuration doesn't work because the command line
> is visible in /proc/pid.

How about a socket? NM should be able to talk to the pluto IKE daemon
of openswan using a socket and sending it commands via the "whack" API.

> * Ability to take secrets from external processes

This functionaliy is missing and will need to be added, though it should
be a relatively simple change. XAUTH credentials can already be passed
in via whack. xl2tpd (the client to start l2tp after ipsec is established)
takes commands (including passwwords) on a named pipe, so this should also
not be a problem.

> * Ability to notify external process of connection failures
> This is crucial.  Users need to know what's going on and when there's a
> failure.  Daemons work well here because when they die, we know the
> connection is down.

This is also fairly easy to add, but you should less us know how best to
do this for NM. Is there a NM "helper" command we can use for this? Does
this require any authentication?

> * Descriptive error codes
> Also crucial; vpnc for example doesn't provide much information during
> the connection process, and only 2 exit error codes.  Quite unhelpful if
> the user can't figure out whether their group password or user password
> was wrong, and then of course NM can't do anything intelligent about the
> failure either.

This is not always possible, as commercial end points tend to believe it
is more secure not to explain the reason of failure, but just stop to
communicate with you. So you only find out after a few retransmits that
something is wrong. Where possible, xl2tpd and openswan do know about the
reason for failure, and we just need to add a way of signaling this back
to other applications.

Paul