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

Martin Willi martin at strongswan.org
Thu Nov 21 10:02:14 CET 2013

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.

> 3) Supporting GRE KEY in SPD traffic selectors. This might be tricky
>    because GRE KEY is 32-bit tunnel identifier, and it is split to be
>    in the TS source port, and destination port - similarly to how ICMP
>    message type/code is split [4]. Would be nice to have config syntax
>    like: leftproto = gre/1234 # 1234 being the 32-bit gre key

That shouldn't be too hard, more a configuration/backend thing. Maybe
some minimal changes to the traffic selector code are required, but
probably not.

> 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

> 5) I should also get a hook that is executed when all IKE_SAs are
>    deleted (but before new ones are established - e.g. due to
>    lifetime end, DPD or INITIAL-CONTACT). I believe the updown script
>    hook is usable as-is, but would need to just verify this.

updown gets invoked for CHILD_SA up/down events. The listener_t
interface [1] you can register from a plugin gets different events for
different situations.

> I'm willing to write the code, but would appreciate comments on what
> the architecture should be like. Even better if you can help with the
> code too.

I myself probably can't make available any resources for coding in the
next months, but we're certainly happy to help if you have any
questions. Please also have a look [3] if you consider upstreaming your

Kind Regards


More information about the Dev mailing list