[strongSwan] Running dual instances of strongswan

Tobias Brunner tobias at strongswan.org
Thu Sep 13 10:27:56 CEST 2012

Hi Terry,

> It's good to know that there is the installpolicy option.  Even though
> I cannot use it, I can probably check
> out how it is implemented.

You could, but that is one of these options that requires changes all
over the place (as it is connection specific).  Might be easier to add
an option in strongswan.conf, similar to charon.install_routes.

> 1) Is my assumption correct?  Do I need the policies to control
> routing?  I am talking about where
> there are multiple subnets values in the left|rightsubnet parameters
> so that packets can be routed
> thru the tunnel.

Not really.  The kernel will first do a routing lookup for the outgoing
packet, then (after possibly modifying the source address) check if it
finds an IPsec policy matching the packet.  If it does not, the packet
is just sent out, if it does, it tries to find an IPsec SA for that
policy.  If one is found the packet is handled by that SA (or SA bundle)
and then again sent back through the outbound processing stack,
including a check if the packet has to be routed differently (which is
probably the case when tunnel mode is used).  If no SA is found the
kernel will send an acquire to the keying daemon (in your case both
instances will receive this event, but only handle it if the reqid of
the policy is known and can be associated with a trap policy) which is
expected to negotiate and install an SA.  Until an SA is installed or
the acquire times out the packet is on hold.  After the timeout the next
packet matching the policy will again cause an acquire being generated.
 Basically, you really only need policies if you also use the SA
functionality of the kernel.  I guess this also answers some of the
other questions you had.

Whether you need a separate kernel interface plugin depends on how your
crypto hardware works, how you communicate with it from the daemon and
how it interacts with the kernel.  We might help you with this if you
are interested.

Just as a reminder (also for other readers of this mailing list),
plugins generally fall under the GPL [1], as do, of course, other code
changes.  To avoid any GPL violations you might be interested in the
commercial licensing we provide (if so, please contact us directly).


[1] http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins

More information about the Users mailing list