Re: Generic IPSEC vpn plugin

[David Woodhouse <dwmw2 infradead org>]

On Fri, 2009-04-24 at 11:32 -0400, Dan Williams wrote:
> 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

This is actually working in some cases, like openconnect. The
auth-dialog there is a standalone GUI program in its own right which
does a whole bunch of stuff including SSL certificates from file system
or TPM, and letting the user fill in arbitrary forms. Then when it's
rewarded for a successful login with an HTTP cookie from the server, it
just passes that cookie back to the nm-openconnect-service which uses it
to make the actual connection.

Can IPSec-based VPNs do something similar?

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

Yeah, that would be nice -- I'd give better feedback in OpenConnect if
it was actually getting through to the user.

> > 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 you're not talking about a multi-user system, then it is both a
per-user thing _and_ a systemwide thing. The whole debate is meaningless
in that case -- whichever way you handle it is 'right'.

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

I'm guessing that you're in the minority, if you actually bother to set
up an account for them and switch to it. To be honest, I don't even know
how to do that without resorting to the command line.

Many people would just disconnect from the VPN and let their guest use a
web browser or SSH client in the existing session. Not the right thing
to do according to the tinfoil-hat wearers, arguably -- but common
behaviour nonetheless.

And I bet that even _fewer_ people actually remove the account after the
guest is done using the computer, thus actually preventing said guest
from logging into your laptop later from elsewhere, while you're on the
VPN...

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

I'm using WEP, but I don't think that matters. I checked the 'Available
to all users' checkbox in the configuration.

That name is a strange choice, because it implies that if I _uncheck_
it, you'll install some kind of per-user iptables filtering to, well,
stop the network connection being available to all users. But that
aside, I think it's working. Thanks for fixing it.

-- 
dwmw2