[strongSwan-dev] Dynamic Multipoint VPN (opennhrp) with strongswan
timo.teras at iki.fi
Thu Nov 21 11:07:24 CET 2013
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 . 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.
> > 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 . 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.
Ok. I'll dig in on this then.
> > 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)
> > 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  you can register from a plugin gets different events for
> different situations.
Oh, ok. Then I probably need to do something - or add some environment
variable. The trigger case that I need is basically: "The node with IP
is has no longer any IKE_SA or CHILD_SA". The idea is that use it to
flush all NHRP cache entries for that public IP. It'll make sure that
routing convergence fast (e.g. if BGP or OSPF routing is used on top -
it allows BGP to faster migrate to alternate route).
> > 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  if you consider upstreaming
> your changes.
Thanks - I'm sure I'll get questions. The trap-any branch is a good
starting point for me.
More information about the Dev