Re: nm-openswan is alive again!

[steve <keyhman gmail com>]

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 <dcbw redhat com> 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
>
>
>
>