[strongSwan-dev] Dynamic Multipoint VPN (opennhrp) with strongswan

[Timo Teras]

Hi,

Coming finally back to this dmvpn topic.

Quite a bit has changed since that. strongSwan has gained vici support,
and dmvpn phase 4 is out with revised design.

Instead of porting opennhrp to work with strongSwan, I'm actually now
looking into rewriting opennhrp as quagga plugin that would talk to
strongSwan.

On Thu, 21 Nov 2013 12:07:24 +0200
Timo Teras <timo.teras at iki.fi> wrote:

> On Thu, 21 Nov 2013 10:02:14 +0100
> Martin Willi <martin at strongswan.org> wrote:
> 
> > Hi Timo,
> > 
> > > 1) Allow wildcard transport mode "traps" to be installed to kernel
> > > to get acquires. (I already have semi-working patch for this.)
> > 
> > Tobias did some experiments with %any transport mode traps, see
> > [1]. I don't know what the current state of this work is, though.
> 
> Ah that looks exactly what I need. Will test. It also shows how to
> instantiate new ike_sa (checkout_new) and construct the instantiated
> transport mode stuff - so it'll help a lot in writing the similar code
> on stroke / plugin side.

Any plans to merge trap-any branch to master? This would be useful, and
a prerequisite for my use case.

> > > 4) Extend 'ipsec stroke' (or some other means) for opennhrp to
> > > initiate and terminate tunnels. It knows the logical connection
> > > name, source IP and destination IP.
> > 
> > >    I would also need a way to extract the authentication
> > > information (remote identity, and x509 certificate used in
> > > authenticated) having the same information.
> > 
> > stroke is not very good in getting scripted. It was never designed
> > for that, and to read back any result you'd have to parse the
> > output. 
> > 
> > Instead I'd recommend to go with a custom plugin. Certainly
> > requires a little more work, but gives you full control using our
> > internal APIs. From a custom plugin you can use controller_t to
> > initiate and terminate connections. To find entries, you may
> > enumerate IKE/ISAKMP_SAs from the manager, or build-up a local
> > cache for fast lookups by registering a listener.
> 
> Ok, Ill think about it. I don't need to parse output for 'up' and
> 'down'. In fact what I want 'up' to do is:
>  - check if IKE_SA+CHILD_SA exists for the src-ip dst-ip pair
>     if yes, return true
>     if no, attempt creating them and return true if they got
> established
> 
> So as long as 'stroke' return proper exit code, I'm good. Of course
> the 'get-certificate' would need to output (prerably PEM encoded)
> certificate.

This seems to be where 'vici' does already a majority of the work.

I basically would need to track active SAs. As minimum the following
two extensions are needed:

1) Send notifications on SA creation/deletion. Should simple to add as
list-sa already does the tedious work of serializing the information.
Would be practical if x509 cert was sent automatically in the
notification too.

2) A way to request instantiation/termination of transport mode
"right=%any" connection with specific value for 'right'. Needed to
bootstrap spoke-hub connections (and hub-hub depending on config).

Additionally, it would be helpful to have:

3) Additional 'connection configuration origin' field. So that dmvpn
and swanctl can manage their set of configs without deleting each
others conn entries on reload.

4) Way to influence CFG_REQUEST/CFG_REPLY/CFG_SET during negotiation.
This would be required for full Cisco compatibility as they use those
to exchange the IP-configuration. Though, as first step, I plan to be
defining those in the x509 certificate.

Any help or suggestions how to do these properly are appreciated.
Especially to start with 1 & 2.

Thanks,
Timo