Re: Simple connect feature for xl2tpd

[Paul Wouters <paul xelerance com>]

On Wed, 2 Jul 2008, Dan Williams wrote:

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

Good.

> > 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?

There is openswan-2.x.y/lib/libwhack and lib/libopenswan and lib/libpluto, but
currently those are just linked into the openswan programs pluto and whack
directly. I guess we could turn those into shared libraries.

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

It's not MOBIKE yet, so yeah, you'd have to tear them down.

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

The pluto daemon does not keep track of certificates coupled to conns. It
keeps a pool of secrets, a pool of public certs, a pool of CA's and a pool
of connections. When it initiates or responds to one, it will try to find
the proper CA, public key/cert, private key or preshared secret from the pool

I think the best we can do is allow one to specify additional files to use
when reading. Remember that IPsec technically is a host to host connection,
and not a user to host connection. But perhaps we can extend openswan to
also look in a user's home directory for certain files.

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

Right. See above. IPsec is a host to host protocol with user stuff put on
top of it. That's why importing X.509 certs on OSX and Windows is such a
nightmare too.

> 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!

Having proper NM integration for openswan would be a good thing to have!

Paul