Re: Simple connect feature for xl2tpd

[Dan Williams <dcbw redhat com>]

On Sat, 2008-06-28 at 11:26 -0400, Paul Wouters wrote:
> On Sat, 28 Jun 2008, Vincent Bernat wrote:
> 
> > For pppd, they use a plugin that  ask the password on dbus. I don't know
> > if it would be possible/easy  to do the same things for PSK/certificates
> > for OpenSWAN.  Or just  on standard input,  like passphrase  for private
> > keys.
> 
> Since openswan can do multiple connections, and one can do both an l2tp
> ipsec connection and other connections, it is somewhat complicated. In

I'd always planned on multiple active VPN connections, but it was a
lower priority.  The current NM API (0.7) allows for more than one
active VPN connection but internally it's limited to one at a time until
we get some effort in that direction.

> other words, network manager cannot "take over" complete operations of
> openswan, since that might kill other IPsec tunnels. It should only add,
> remove and up/down its own tunnels.

That's fine; basically if openswan is already running then the ipsec vpn
plugin would add/remove as necessary.  Otherwise it would have to start
up openswan.

> Almost all openswan options can be send to openswan via the whack interface,
> which uses a socket to talk to the openswan pluto daemon. eg one can use

Ideally we don't do system("ipsec whack ..."), so we'd end up writing
code to talk to openswan over the socket interface.  Or is there a
convenience library that handles the whack socket protocol nicely that
we could link to?

> ipsec whack --initiaite l2tp
> 
> One thing for instance that is needed is that if the host's IP address
> changes, to run 'ipsec whack --listen'.

Ok; good to know since the IP address may change at any point in time
depending on which network interfaces are up or down.  Are tunnels
expected to persist across interface changes?  If not, then we would
simply tear down the tunnel when the current interface goes down, and
bring it back up again when a different interface came up.

> ipsec whack can also be used to add/remove connections to the configuration
> without putting those in a config file.

Great; that's exactly what we'd like.

> The one tricky thing there is, is passing x509 certificates and PSK's into
> pluto. It can reread the /etc/ipsec.secrets (and include files) via
> the command 'ipsec secrets'. so one somewhat hacky way of doing things
> could be to add an include into /etc/ipsec.secrets for /tmp/foobar.secrets,
> then run 'ipsec secrets' and immediately remove /tmp/foobar.secrets. The
> secret will then be loaded into the openswan pluto daemon.

Hmm, that's icky.  I'd rather be able to push stuff directly to openswan
via whack.  Is there no facility to do that at this point?  Basically,
there's data that describes a single IPSec connection which would
presumably include any x509 certificates or PSKs the connection
requires.  All necessary data should be pushed down to openswan when the
connection is added, and should be updated when necessary by
NetworkManager or whatever.

> When a connection is terminated, rerun 'ipsec secrets' to lose the secret.
> 
> A similar thing is possible for x.509 support. But perhaps we can improve
> on it to make it easier for network managaer to add/remove certificates.
> Though it is not so much the certificates that need removal, as it is the
> passphrase to unlock the private key. To make things easier, network
> manager should supposed reading and splitting the PKCS#12 file format
> normally used to hand out CAcert+cert+key information.

Right.

> For non-l2tp XAUTH based connections, the XAUTH password can also be stored
> in ipsec.secrets (and the username passed using whack options)

We can't store that in ipsec.secrets, because that's not system-wide
information in all cases; it's pulled either from the user's local data
or entered by the user themselves during the connection or out-of-band.
It might change regularly (OTP) or could be stored on a cryptokey.
That's the crux of the issue with config files; they are almost always
assumed to be static and system-wide, but often VPN connections are
_user_-specific.

We need to be able to push the key down to openswan when openswan needs
the key, and if the key is wrong (can't decrypt a private key, or the
server denies auth) we'd need to know about that so we can ask the user
for a different key.

> Note that communication with the xl2tpd daemon happens over a named pipe,
> so you can also send commands to the xl2tpd fairly easilly.

Ah, good.  I hope we can push forward and get this working!

Thanks all,
Dan