[strongSwan] redundant routing with IPSec
nithinaprakash at gmail.com
Thu Sep 23 14:19:18 CEST 2010
Has this issue been taken care of in later versions of strongswan?
> Hi Pavel,
> thank you very much for your patch. We are fully aware of the
> fact that the NETKEY stack does not require the setting up
> of any routes. And actually the "charon" IKEv2 daemon currently
> does not do any routing. Therefore rather than to introduce a
> needsroute parameter in strongswan-4.x we are going to add routes only
> in the presence of a Virtual IP (leftsourceip parameter). This means that
> we are going to change the behaviour of the "pluto" daemon in one of
> the next releases of strongswan-4.x.
> Best regards
On Tue, 10 Oct 2006 11:24:14 +0400, Pavel Levshin <Pavel at
>>* *>>* I've made it possible to tell pluto do not route particular connections.*>>* Here is the patch. It should be considered draft and unstable, but it*>>* works for me.*>>* *>>* It adds one more optional parameter to connection description:*>>* needsroute=[yes|no]*>>* (yes by default).*>>* *>>* When needsroute=no, conventional routing will not be checked for this*>>* connection, and updown route will not be invoked. This makes transport*>>* mode with Netkey stack happy. I believe that this should be default for*>>* transport mode - for strongSwan4, in particular.*>>* *>>>* But in Netkey stack, there is no interfaces to route plaintext*>>>* traffic. I suspect that Pluto does not need to play with routes at*>>>* all, because all routing for gateways should be in place before we*>>>* start. In my case, this should be done using source routing.*>>>* Therefore, my question: isn't it feasible to remove some routability*>>>* checks for transport mode? Am I missing anything?*>>* *>>* _______________________________________________*>>* Users mailing list*>>* Users at lists.strongswan.org <https://lists.strongswan.org/mailman/listinfo/users>*>>* https://lists.strongswan.org/mailman/listinfo/users*
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users