Technically speaking, you should be able to run as many concurrent IPsec connections as you want. In reality, I've used openswan to run up to 4 seperate and independant concurrent IPsec tunnels, some with and without Virtual interfaces (for DHCP over IPsec).
My goal is to make NM-Openswan capable of doing the same thing, but as we've discussed previously, the nm-VPN API's weren't really designed to handle the case of multiple concurrent vpn connections. I'm currently reviewing the proposed changes to the VPN API and comparing it to the over all design of my plugin to see how to find a working model that can be used for any VPN client (not just openswan). Ideally, I think NM should be able to handle any number of concurrent Point-to-Point vpn connections with split tunneling. Of course some vpn clients don't support split tunneling (Cisco vpn is one I think) which is more akin to the one-off style design of the current API. It all comes down to routing table modifications. For example, Pluto (the daemonized portion of Openswan) automatically handles routing table modifications, whereas others will recieve those modifcations and pass them back to nm for processing in: nm_vpn_ip4config(). given that vpnc, openswan, openvpn, and most other vpn clients are simply getting front-ends and DBUS integration, I'd like to allow the native clients to handle the requsite routing table mods and use nm to montior, control, and create / modify the parameters of the connection configs passed the the actual vpn client. To try and supplant that functionality within the nm-vpn plugin architecture will introduce dependencies between nm and specific versions of various vpn clients which is not what we want (IMHO). For example, if the internal API's of Openswan change, and my nm-openswan plugin replaces the functionality of parts of the openswan distribution, then there's a good chance my plugin will break on new subsequent releases of the openswan client. Whereas if I simply control the components of Openswan from my plugin, along with passing connection configs and status across DBUS for monitoring, I can expect that the user-end functionality of the openswan client to change very little, and *hopefully* my nm-openswan vpn plugin will work with new releases of openswan, regardless of any internal API changes to the openswan client. If I'm repeating someone else's ideas, it's because I'm still catching up on the mailing list. As always, all comments are welcome. Steve. NB: Thanks for all the replies, it's good to know so many are interested in this plugin. As a bonus, I've been given access to a variety of "supposedly" IPsec compliant gateways. I'll have lots of variety for my testing, and it should validate my initial testing results that showed OpenSwan as the ideal choice for standard IPsec vpn connections when I started writing the nm-vpn plugin. Dan Williams wrote: > On Mon, 2007-06-11 at 23:34 +0200, Tomáš Hnyk wrote: > >> On Sun, 10 Jun 2007 01:46:15 +0200, Dan Williams <[EMAIL PROTECTED]> wrote: >> >> >>> On Sat, 2007-06-09 at 18:03 -0400, steve wrote: >>> >>>> Hi, >>>> >>>> Just a quick post to inform anyone who cares, that I've finished my >>>> employment transition, re-created my development environment and I've >>>> re-started work on the openswan vpn plugin. >>>> >>>> I've made two design changes to allow for multiple concurrent vpn >>>> connections (in future releases) as it will be required for my new job. >>>> I'll post again when I've got a tar ball for others to test. >>>> >>> Awesome! You might want to look at an email recently sent about a new >>> API for VPNs to see if it would also work for openswan. >>> >>> "Proposal for a new VPN DBUS interface" - May 8th >>> >>> Dan >>> >>> >>>> If anyone feels inclined to help with the effort (which is mainly bug >>>> fixing at this point), feel free to contact me. >>>> >>>> Steve. >>>> >> Does this also mean that it will possible to use VPN even if the network >> connection is not managed through NM but is set to static as described >> here: >> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/115750 - or >> is that only Ubuntu thing? >> > > NM by definition won't know (and therefore won't care) about connections > that aren't know to NM. That's as it should be. On the other hand, the > configuration information will soon be flexible enough to deal with most > of the cases, but that's already mostly the case for VPNs. > > Dan > > > > _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
