[strongSwan] [strongSwan-dev] PASS and DROP shunt policies

[Andreas Steffen]

Hello Daniel,

On 22.07.2011 17:56, Daniel Mentz wrote:
> 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.
>
Fixed the diagram of the network topology:

http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=7ec35f561c207cb82786ec973697cea62070ae5b

> 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.
>
The problem with the source routes is that all traffic will go through
the tunnel including the traffic that you want to exclude by using
shunt policies. Tobias had a look into this and came to the conclusion
that the sitation cannot be easily fixed, i.e. to define a special
route which would have precedence over the general source route.

> 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.
>
Daniel, you are right. Actually with shunt policies we don't process and
use left|right and left|rightauth or authby at all. I just thought that
overriding these values with %any in the ipsec statusall output

Connections:
   local-net:  %any...%any
   local-net:   local:  [%any] uses any authentication
   local-net:   remote: [%any] uses any authentication
   local-net:   child:  10.1.0.0/16 === 10.1.0.0/16 PASS
  venus-icmp:   child:  10.1.0.20/32[icmp] === 0.0.0.0/0[icmp] DROP

might confuse the user. An alternative would be just to suppress the
first three lines of the ike and peer config output but this would
mean that stroke would first have to process the child configs attached
to the ike config before writing the output for the ike and peer config
to the console which seems quite tiresome and not worth the effort to
me

> Thanks
> -Daniel

Best regards and many thanks

Andreas

======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==