[strongSwan-dev] PASS and DROP shunt policies (was: ANNOUNCE: strongswan-4.5.3rc1 released)

Daniel Mentz daniel at exxm.de
Fri Jul 22 17:56:58 CEST 2011


Dear strongSwan team,

thanks for the great work. I have some comments regarding the following 
change:

On 07/19/2011 01:00 AM, Andreas Steffen wrote:
> PASS and DROP shunt policies configurable by charon
> ---------------------------------------------------
>
>    The IKEv2 charon daemon supports type=pass and type=drop shunt
>    policies preventing specific traffic to go through IPsec connections.
>    Installation of the shunt policies are possible either via the XFRM
>    netfilter or PFKEYv2 IPsec kernel interfaces as the following two
>    scenarios show:
>
>    http://www.strongswan.org/uml/testresults45rc/ikev2/shunt-policies/
>
>    http://www.strongswan.org/uml/testresults45rc/pfkey/shunt-policies/

I'm looking at the IKEv2 example. It talks about a host called venus, 
but I can't find it in the picture. I believe that adding it to the 
picture would help avoid confusion.

You say that "install_routes=no" has to be added to strongswan.conf. 
This raises some concerns. Doesn't this break other connections that 
depend on install_routes being set to "yes"? Why not change strongSwan 
in a way such that "install_routes=no" is applied to "type=pass" 
connections automatically? I believe that this would be an improvement 
in terms of user friendliness.

I'm curious what would happen if you do not set install_routes to no. 
What do the routes look like and why are they causing failure.

Again, from a user perspective, I see "authby=never" as part of the 
"local-net" connection which is of "type=pass". On the same note, "conn 
venus-icmp" has the parameters "leftauth=any" and "rightauth=any". 
Wouldn't it be nice to get rid of these parameters in this scenario? I'm 
thinking that authby, leftauth and rightauth are not applicable if the 
connection is of "type=drop" or "type=pass". If it's an internal thing, 
maybe starter or charon can add this automatically.

Thanks
-Daniel




More information about the Dev mailing list