Re: Generic IPSEC vpn plugin

[Dan Williams <dcbw redhat com>]

On Sun, 2009-04-19 at 20:17 +0100, David Woodhouse wrote:
> On Tue, 2009-04-07 at 11:23 -0400, Paul Wouters wrote:
> > Openswan has a GSoC project submission for this. One of the issues is
> > the architecture of NM, which focusses on user-based, and the the
> > architecture of ipsec, which is host-based. This creates some issues,
> > one of which is where and how to store and pass user/host credentials.

The original use-case for VPNs was mobile laptop users, and at the time
nobody was using IPSec VPNs.  We arguably haven't kept up with that,
because there's been larger fish to fry (better wifi, multi-device, 3G,
etc, better config, etc).

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
    - multiple VPN connections

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.

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.

* Ability to take secrets from external processes
For some of the same reasons config files don't work well; secrets can
come from a bunch of different places, so a static config file with the
secrets doesn't make a lot of sense.  Second, for the same reason that
config files don't work well, writing the secret out to a file doesn't
work well.  OpenVPN uses a management socket here, which works out OK,
and vpnc uses config on stdin so that works out OK too (except for
periodic reauthentication).

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

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

> NetworkManager has all those problems anyway -- they aren't specific to
> IPSec. Other VPNs, wireless and even wired connections are system-wide
> things; once they're set up, any user can use them. None of it is
> _really_ a per-user thing. It's a complete pain in the arse that my
> wireless network doesn't come up after I reboot my laptop, for example,
> until I physically walk up to it and log in. This _used_ to work in
> early versions of NetworkManager, but then broke because of this
> misguided per-user thing.

Oh come off it David.  It *is* a per-user thing if you're not talking
about a multi-user system.  If I log into my work VPN, but then a
house-guest asks to use the system, I'm going to fast-user-switch, and I
certainly don't want that person to have access to my VPN.  Connections
can be *both* per-user in a single-user system, or system-wide on any
system.

If you're using WPA, you should be using the 0.7.1 snapshots in Fedora
testing, and your connections can now be system connections and you can
set them up to connect before login.  Try it.  I'll even fix your bugs
too.

Dan