Re: Generic IPSEC vpn plugin

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

Well there's two main types of vpn connection. There's the site to
site type and the road-warrior type. The first type is generally run
on a server or router and connects multiple sites, then the later is
very much like the wifi use case of NetworkManager. Its probably quite
like network support in that NM initially supported the single user
case and then later added they system case as well.

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

Other than the proprietary or non standard clients like openvpn and
the cisco stuff I suspect most support would be achievable with two
clients. One that supports IPSEC vpns and one that supports SSL vpns.
After that some templates which work with each of the different
vendors interpretation of the standards as part of the setup wizard
would be probably all thats required (not that its a small amount of
work) to make them cover most of the common instances. I mentioned
previously that through my work I have access to alot of the different
vendors products and would be quite happy to assist in testing to get
the settings for templates.

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

Well there's the ipsec-tools utilities but I suspect any NM support
will need something like what was done with wpa_supplicant where there
was patches needed.

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

That comes back to the Site-to-Site vs Road-Warrior configuration. Its
the same argument that no doubt went on for the system wide ethernet
vs the login and then connect single user argument and support


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]