[Openswan dev] Simple connect feature for xl2tpd (fwd)
paul at xelerance.com
Sat Jun 28 12:02:33 EDT 2008
[Forgot to send it to the openswan-dev list]
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
Since openswan can do multiple connections, and one can do both an l2tp
ipsec connection and other connections, it is somewhat complicated. In
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.
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
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'.
ipsec whack can also be used to add/remove connections to the configuration
without putting those in a config file.
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.
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.
For non-l2tp XAUTH based connections, the XAUTH password can also be stored
in ipsec.secrets (and the username passed using whack options)
Note that communication with the xl2tpd daemon happens over a named pipe,
so you can also send commands to the xl2tpd fairly easilly.
Building and integrating Virtual Private Networks with Openswan:
More information about the Dev