Re: Generic IPSEC vpn plugin
Hi Paul, On Tue, Apr 7, 2009 at 4:23 PM, Paul Wouters p...@xelerance.com wrote: On Tue, 7 Apr 2009, Peter Robinson wrote: Is there, or is there planned, a generic IPSEC vpn plugin for NetworkManager? I can see support for the cisco vpnc client, and then some other various ones. I would have thought with the site-to-site ipsec and client side stuff being the major enterprise way of doing it, and the kernel having full IPSEC support that there would have been a generic ipsec plugin ages ago. And one with profiles for most of the common hardware out there (cisco/netscreen/alteon/checkpoint/fortigate etc) would be very cool :-) 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. By next week we should know if this project is starting. We did get a few applications for this. Did this ever happen for the GSOC? Peter ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 18 Sep 2009, Peter Robinson wrote: By next week we should know if this project is starting. We did get a few applications for this. Did this ever happen for the GSOC? http://gsoc.xelerance.com/projects/openswan-nm It's a work in progress though. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 2009-09-18 at 10:47 -0400, Paul Wouters wrote: On Fri, 18 Sep 2009, Peter Robinson wrote: By next week we should know if this project is starting. We did get a few applications for this. Did this ever happen for the GSOC? http://gsoc.xelerance.com/projects/openswan-nm It's a work in progress though. Will this support L2TP? (I think my university uses L2TP but without IPSEC I currently use the PPTP which they also support Best regards, Maxim Levitsky ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 18 Sep 2009, Maxim Levitsky wrote: http://gsoc.xelerance.com/projects/openswan-nm It's a work in progress though. Will this support L2TP? Yes. (I think my university uses L2TP but without IPSEC That's very unlikely but possible. I feel no need to support such an insecure rollout though. Though if someone would write the code for it, I would not object to it either, as long as it does not take over the default of ipsec+l2tp. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 2009-04-24 at 16:16 -0400, Paul Wouters wrote: On Fri, 24 Apr 2009, Dan Williams wrote: people want to get notifications in userland on tunnels failing, they should configure the ipsec tunnel to use Dead Peer Detection (RFC3706) Ok, how does that actually show up in userspace? What can we make the NM vpn plugin daemon listen for? You tell me. What infrastructure is there for NM? I know there is dbus, but I don't think that channel can be secured at all. Would unauthenticated announcements be okay? Does NM have any other listening or polling methods? D-Bus can certainly be secured. D-Bus security is based on a few different mechanisms; one of which is user-based authentication. So you can make sure that only the root user can access the D-Bus interface, or only a certain group, or only users determined to be at console (ie, physically present and not via SSH or remote X). Beyond that, finer-grained access control is accomplished with stuff like PolicyKit, but you probably don't need that. Otherwise, socket-based mechanisms (that user peer credentials to authenticate the remote UID, which is what D-Bus uses too) would be fine too, as long as that socket-based API was sane. I guess I would have assumed something like this would be available already via whack, but perhaps I misunderstand how the stack fits together. Dan Yeah there's support for this. Basically, you have two classes of connections: system and user. Just like OS X actually. User connections credentials and details are stored in the user session and do not survive fast-user-switch. System connections are stored outside of the user session, and thus are available before login and survive a fast user switch. So if you don't want your VPN to be avialable to everyone, you keep it as a user connection. If you don't care, you make it a system connection and available to all users as the UI checkbutton puts it. That's good. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 2009-04-24 at 16:40 -0400, Paul Wouters wrote: On Fri, 24 Apr 2009, Dan Williams wrote: Except for rekeying with OTP tokens like RSA SecurKey or whatever they are called. That's a pretty huge use-case where the authentication isn't the same the next time a reauth happens. Intentionally so of course. Those connections tend to use 8 hour plus IKE/IPsec SA lifetimes, so they basically never rekey. But you are right. There are two ways of handling this. Either you just bring down the IKE connection (while the IPsec SA is still up so packets still flow) and this triggers an event to NM so it can ask for the OTP and then rekey the IKE connection, or you kill the connection and let the user connect from scratch. The latter is mostly found in GUI software. Openswan currently does not have a method for signaling, but if we're building that in via dbus or something anyway, this becomes an easy possibility, and with no packet loss to the end user. Ideally the first thing you mentioned occurs, the daemon somehow signals NM that it needs new credentials, and pauses the connection for a bit until they are entered. I assume if the user isn't around to type in the password, then the connection should just die after a timeout since those resources won't be allocated forever on both sides (otherwise it's a nice DoS). We can (and should) handle this intelligently in the NM stack as long as there's supporting infrastructure in the VPN stack itself. Right. We pretty much ignore that problem right now anyway; whatever gets the highest priority in the routing table wins. That's not something that we can really fix, that's a VPN configuration problem for the user and their sysadmin, if any. Agreed. 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. DPD RFC 3706. Though Openswan needs to signal this to NM. Openswan has settings for dpdtimeout, dppdelay= and dpdaction=. Actions can be to turn off the vpn or to try and restart it. You mean a daemon component, right? If there's a daemon watching the connection already, that's awesome, since then the notifications can be delivered somehow. There is. The IKE daemon always runs. I am not sure how familiar you are with IKE, so let me give an exec summary. The IKE daemon establish a command channel over which they agree IPsec paramters. These daemons always run. Once they agree something, they inform the kernel, which install the actual keying information along with lifetime information for the tunnel (in time units or in byte units) The kernel never talks to userland IKE, it only listens for it. IKE makes all the decisions. IKE is userland, which is the openswan pluto daemon. That entity will have to listen and talk to NM somehow. Excellent. That means (as I understand it) that since pluto has the whack-style control interface, we could use that for communication with the IKE daemon? That could work, yes. As long as connection setup, authentication, and reauthentication can all happen without using config files or statically stored on-disk secrets that sounds fine. Not yet, but that modification will be made for you. Excellent. Certificates should actually be stored on-disk or in a Certificate Store like NSS. Private keys should typically not be expected to be stored on-disk since they may exist in a PKCS#11 device or some other location. Openswan 2.6.21 has limited support for NSS. The current development release 2.6.22dr1 has (full?) NSS support. So this should not be a problem anymore. Yeah, though we have a general problem in that we don't have a coherent story on Linux for a good system certificate store. That's not openswan's problem but something we need to solve as a whole. In the future that means passing not certificate/key data, but a token that's used as a reference into the NSS certificate store to get the actual certificate (which might be on a card) or which tells NSS which private key (which might also be on a card and not retrievable) to use for encryption/decryption. This functionaliy is missing and will need to be added, though it should be a relatively simple change. XAUTH credentials can already be passed in via whack. xl2tpd (the client to start l2tp after ipsec is established) takes commands (including passwwords) on a named pipe, so this should also not be a problem. Hmm, I'll have to dig in the l2tp stuff a bit more. I'll need to check that too. Currently, from the unit test in openswan-2.x.y/testing/pluto/*l2tp* I only see us do: echo c server /var/run/l2tp-control I think this is taking the user/password information from /etc/ppp, so if you have a system in place for pppd already, I
Re: Generic IPSEC vpn plugin
On Tue, 2009-04-28 at 12:32 -0400, Dan Williams wrote: That's fine, since NM (and the VPN plugin) would be running as root for the time being. David woodhouse wants to make them not run as root, but that might only happen for the VPN daemons that don't actually need root. Sounds like for now, the openswan one would. We already have that working for OpenConnect. It's optional, and I haven't changed any other VPN dæmons to do it. -- dwmw2 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Tue, 2009-04-28 at 18:35 +0100, David Woodhouse wrote: On Tue, 2009-04-28 at 12:32 -0400, Dan Williams wrote: That's fine, since NM (and the VPN plugin) would be running as root for the time being. David woodhouse wants to make them not run as root, but that might only happen for the VPN daemons that don't actually need root. Sounds like for now, the openswan one would. We already have that working for OpenConnect. It's optional, and I haven't changed any other VPN dæmons to do it. I assume that would mean the vpn daemon opening the pluto socket before dropping privs, right? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
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 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 24 Apr 2009, Peter Robinson wrote: Openswan has a GSoC project submission for this. One of the issues is btw. that project got the go ahead and we have a student for this now. 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. ipsec-tools is not required for ipsec operation using openswan. If people want to get notifications in userland on tunnels failing, they should configure the ipsec tunnel to use Dead Peer Detection (RFC3706) 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 I take it NM already has some kind of user-switching support that takes this difference into account, and can take down the tunnel. Though if I remember correcty, OSX gave you a preference option for this choice. (you might be transferring data from your vpn and give control to another user while expecting the vpn stas up) Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 24 Apr 2009, Dan Williams wrote: 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 I would not put too much effort in this. Most interactive authentication (I assume you mean XAUTH password or L2TP password) can be remembered on most OS'es. Openswan for a long time refused to support XAUTH passwords being configured, but we ended up helping people write stupid shell scripts to work around it. Also, not all IPsec devices worked properly with XAUTH rekying, when the credentials are needed again. So in the end we just made it an option and recommend people not to use it. - multiple VPN connections There is no problem from an ipsec/openwan point of view, as long as you pass along unique names for these connections to openswan. Note that there are some unsolvable options, such as ending up having connections to two remote networks with the same IP range, or one with the same IP range as your NAT'ed range. I'd recommend ignoring these problems. 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. DPD RFC 3706. Though Openswan needs to signal this to NM. Openswan has settings for dpdtimeout, dppdelay= and dpdaction=. Actions can be to turn off the vpn or to try and restart it. 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. How about a socket? NM should be able to talk to the pluto IKE daemon of openswan using a socket and sending it commands via the whack API. * Ability to take secrets from external processes This functionaliy is missing and will need to be added, though it should be a relatively simple change. XAUTH credentials can already be passed in via whack. xl2tpd (the client to start l2tp after ipsec is established) takes commands (including passwwords) on a named pipe, so this should also not be a problem. * 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. This is also fairly easy to add, but you should less us know how best to do this for NM. Is there a NM helper command we can use for this? Does this require any authentication? * 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. This is not always possible, as commercial end points tend to believe it is more secure not to explain the reason of failure, but just stop to communicate with you. So you only find out after a few retransmits that something is wrong. Where possible, xl2tpd and openswan do know about the reason for failure, and we just need to add a way of signaling this back to other applications. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
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
Re: Generic IPSEC vpn plugin
On Fri, 2009-04-24 at 11:50 -0400, Paul Wouters wrote: On Fri, 24 Apr 2009, Peter Robinson wrote: Openswan has a GSoC project submission for this. One of the issues is btw. that project got the go ahead and we have a student for this now. 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. ipsec-tools is not required for ipsec operation using openswan. If people want to get notifications in userland on tunnels failing, they should configure the ipsec tunnel to use Dead Peer Detection (RFC3706) Ok, how does that actually show up in userspace? What can we make the NM vpn plugin daemon listen for? 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 I take it NM already has some kind of user-switching support that takes this difference into account, and can take down the tunnel. Though if I remember correcty, OSX gave you a preference option for this choice. (you might be transferring data from your vpn and give control to another user while expecting the vpn stas up) Yeah there's support for this. Basically, you have two classes of connections: system and user. Just like OS X actually. User connections credentials and details are stored in the user session and do not survive fast-user-switch. System connections are stored outside of the user session, and thus are available before login and survive a fast user switch. So if you don't want your VPN to be avialable to everyone, you keep it as a user connection. If you don't care, you make it a system connection and available to all users as the UI checkbutton puts it. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 2009-04-24 at 12:03 -0400, Paul Wouters wrote: On Fri, 24 Apr 2009, Dan Williams wrote: 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 I would not put too much effort in this. Most interactive authentication (I assume you mean XAUTH password or L2TP password) can be remembered on most OS'es. Openswan for a long time refused to support XAUTH passwords being configured, but we ended up helping people write stupid shell scripts to work around it. Also, not all IPsec devices worked properly with XAUTH rekying, when the credentials are needed again. So in the end we just made it an option and recommend people not to use it. Except for rekeying with OTP tokens like RSA SecurKey or whatever they are called. That's a pretty huge use-case where the authentication isn't the same the next time a reauth happens. Intentionally so of course. - multiple VPN connections There is no problem from an ipsec/openwan point of view, as long as you pass along unique names for these connections to openswan. Note that there are some unsolvable options, such as ending up having connections to two remote networks with the same IP range, or one with the same IP range as your NAT'ed range. I'd recommend ignoring these problems. Right. We pretty much ignore that problem right now anyway; whatever gets the highest priority in the routing table wins. That's not something that we can really fix, that's a VPN configuration problem for the user and their sysadmin, if any. 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. DPD RFC 3706. Though Openswan needs to signal this to NM. Openswan has settings for dpdtimeout, dppdelay= and dpdaction=. Actions can be to turn off the vpn or to try and restart it. You mean a daemon component, right? If there's a daemon watching the connection already, that's awesome, since then the notifications can be delivered somehow. 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. How about a socket? NM should be able to talk to the pluto IKE daemon of openswan using a socket and sending it commands via the whack API. That could work, yes. As long as connection setup, authentication, and reauthentication can all happen without using config files or statically stored on-disk secrets that sounds fine. Certificates should actually be stored on-disk or in a Certificate Store like NSS. Private keys should typically not be expected to be stored on-disk since they may exist in a PKCS#11 device or some other location. * Ability to take secrets from external processes This functionaliy is missing and will need to be added, though it should be a relatively simple change. XAUTH credentials can already be passed in via whack. xl2tpd (the client to start l2tp after ipsec is established) takes commands (including passwwords) on a named pipe, so this should also not be a problem. Hmm, I'll have to dig in the l2tp stuff a bit more. * 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. This is also fairly easy to add, but you should less us know how best to do this for NM. Is there a NM helper command we can use for this? Does this require any authentication? How about an unsolicited message on the whack socket? Isn't there already some mechanism to emit status messages or something? Or does it depend on periodically polling the connection status? * 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. This is not always possible, as commercial end points tend to believe it is more secure not to explain the reason of failure, but just stop to communicate with you. So you only find out after a few retransmits that something is wrong. Where possible, xl2tpd and openswan do know about the reason for
Re: Generic IPSEC vpn plugin
On Fri, 24 Apr 2009, Dan Williams wrote: people want to get notifications in userland on tunnels failing, they should configure the ipsec tunnel to use Dead Peer Detection (RFC3706) Ok, how does that actually show up in userspace? What can we make the NM vpn plugin daemon listen for? You tell me. What infrastructure is there for NM? I know there is dbus, but I don't think that channel can be secured at all. Would unauthenticated announcements be okay? Does NM have any other listening or polling methods? Yeah there's support for this. Basically, you have two classes of connections: system and user. Just like OS X actually. User connections credentials and details are stored in the user session and do not survive fast-user-switch. System connections are stored outside of the user session, and thus are available before login and survive a fast user switch. So if you don't want your VPN to be avialable to everyone, you keep it as a user connection. If you don't care, you make it a system connection and available to all users as the UI checkbutton puts it. That's good. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 24 Apr 2009, David Woodhouse wrote: - 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? Yes. The only question is who caches the credentials. Currently openswan can cache xauth passwords (from ipsec.secrets, but once we can take them from the socket, NM can give it to us). Upon closing the connection, these credentials could be purged. 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. With fedora, NM seems to be the default manager for all connections, so if it becomes the defacto tool to configure site-to-site tunnels, then this might not even be the minority case. 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... A real guest account should automatically purge and put back a skeleton account. I know debian/ubuntu has this feature. I am not sure if Fedora has it. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 24 Apr 2009, Dan Williams wrote: Except for rekeying with OTP tokens like RSA SecurKey or whatever they are called. That's a pretty huge use-case where the authentication isn't the same the next time a reauth happens. Intentionally so of course. Those connections tend to use 8 hour plus IKE/IPsec SA lifetimes, so they basically never rekey. But you are right. There are two ways of handling this. Either you just bring down the IKE connection (while the IPsec SA is still up so packets still flow) and this triggers an event to NM so it can ask for the OTP and then rekey the IKE connection, or you kill the connection and let the user connect from scratch. The latter is mostly found in GUI software. Openswan currently does not have a method for signaling, but if we're building that in via dbus or something anyway, this becomes an easy possibility, and with no packet loss to the end user. Right. We pretty much ignore that problem right now anyway; whatever gets the highest priority in the routing table wins. That's not something that we can really fix, that's a VPN configuration problem for the user and their sysadmin, if any. Agreed. 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. DPD RFC 3706. Though Openswan needs to signal this to NM. Openswan has settings for dpdtimeout, dppdelay= and dpdaction=. Actions can be to turn off the vpn or to try and restart it. You mean a daemon component, right? If there's a daemon watching the connection already, that's awesome, since then the notifications can be delivered somehow. There is. The IKE daemon always runs. I am not sure how familiar you are with IKE, so let me give an exec summary. The IKE daemon establish a command channel over which they agree IPsec paramters. These daemons always run. Once they agree something, they inform the kernel, which install the actual keying information along with lifetime information for the tunnel (in time units or in byte units) The kernel never talks to userland IKE, it only listens for it. IKE makes all the decisions. IKE is userland, which is the openswan pluto daemon. That entity will have to listen and talk to NM somehow. That could work, yes. As long as connection setup, authentication, and reauthentication can all happen without using config files or statically stored on-disk secrets that sounds fine. Not yet, but that modification will be made for you. Certificates should actually be stored on-disk or in a Certificate Store like NSS. Private keys should typically not be expected to be stored on-disk since they may exist in a PKCS#11 device or some other location. Openswan 2.6.21 has limited support for NSS. The current development release 2.6.22dr1 has (full?) NSS support. So this should not be a problem anymore. This functionaliy is missing and will need to be added, though it should be a relatively simple change. XAUTH credentials can already be passed in via whack. xl2tpd (the client to start l2tp after ipsec is established) takes commands (including passwwords) on a named pipe, so this should also not be a problem. Hmm, I'll have to dig in the l2tp stuff a bit more. I'll need to check that too. Currently, from the unit test in openswan-2.x.y/testing/pluto/*l2tp* I only see us do: echo c server /var/run/l2tp-control I think this is taking the user/password information from /etc/ppp, so if you have a system in place for pppd already, I think this should just work as well. This is also fairly easy to add, but you should less us know how best to do this for NM. Is there a NM helper command we can use for this? Does this require any authentication? How about an unsolicited message on the whack socket? Isn't there already some mechanism to emit status messages or something? Or does it depend on periodically polling the connection status? Yes, you can do the whack equivalent of ipsec auto --status to get a lot of information from the ike daemon. This currently required root to be able to send the whack command. This is not always possible, as commercial end points tend to believe it is more secure not to explain the reason of failure, but just stop to communicate with you. So you only find out after a few retransmits that something is wrong. Where possible, xl2tpd and openswan do know about the reason for failure, and we just need to add a way of signaling this back to other applications. Ok, that should be fine, ideally via the socket used to control the connection. Obviously the client side can only return as much as it knows. That's right. But you might need to depend on whack.h to interpret some of the resulting codes. Then again, you would probably want to link against libwhack anyway, though I don't think we currently export that
Re: Generic IPSEC vpn plugin
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. 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. (I do actually want to set up VPN connectivity which doesn't tell the kernel about itself at all, but just listens as a SOCKS server and provides access to the VPN that way, thus giving access to the VPN _without_ necessarily giving access to arbitrary users and untrusted code on the box in question. But that's outside the scope of NetworkManager discussion). -- dwmw2 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Generic IPSEC vpn plugin
Hi All, Is there, or is there planned, a generic IPSEC vpn plugin for NetworkManager? I can see support for the cisco vpnc client, and then some other various ones. I would have thought with the site-to-site ipsec and client side stuff being the major enterprise way of doing it, and the kernel having full IPSEC support that there would have been a generic ipsec plugin ages ago. And one with profiles for most of the common hardware out there (cisco/netscreen/alteon/checkpoint/fortigate etc) would be very cool :-) Cheers, peter ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Tue, 7 Apr 2009, Peter Robinson wrote: Is there, or is there planned, a generic IPSEC vpn plugin for NetworkManager? I can see support for the cisco vpnc client, and then some other various ones. I would have thought with the site-to-site ipsec and client side stuff being the major enterprise way of doing it, and the kernel having full IPSEC support that there would have been a generic ipsec plugin ages ago. And one with profiles for most of the common hardware out there (cisco/netscreen/alteon/checkpoint/fortigate etc) would be very cool :-) 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. By next week we should know if this project is starting. We did get a few applications for this. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Tue, 7 Apr 2009, Peter Robinson 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. Well an ipsec vpn can be either a site-to-site tunnel which is system wide, but it can also be client side which is just like vpnc or any of the other current vpn ones which would be user based. I wouldn't have thought it would be any different to the issues that were had with the system wide ethernet vs bringing it up on login. There is only one ethernet. There can be many tunnels, some might even conflict between users who are logged in. Also, ethernet has no credentials, while for IPsec and L2TP you are talking about X.509 certificates, PSK's, username's and passwords. Openswan, xl2tpd and NM need to agree on where this information is stored, and they all have their own methods now, and now everything can be passed via the commandline. By next week we should know if this project is starting. We did get a few applications for this. Awesome! Out of interest is there a list of the network manager gsoc stuff for NetworkManger? Feel free to add me to the testing list. I have access through my job for testing of either site-to-site or client side IPSEC with cisco PIX, cisco IOS, Alteon VPN concentrator, juniper netscreen, fortigate and checkpoint firewalls. That probably covers most of the enterprise stuff out there. We're hanging out on freenode at #xelerance-gsoc Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
