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 _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list