[strongSwan] Rule Priorities Across Connections

[Noel Kuntze]

The prioritiy is determined by the (obviously named) priority field in the security policies. Charon calculates the priority based on the prefix length and if protocol selectors are given.
You need to read the source code to find out what exactly it does.

On 10.10.2017 21:38, Jafar Al-Gharaibeh wrote:
>
> Is the behavior documented anywhere?
>
> Thanks,
> Jafar
>
> On 10/5/2017 11:24 AM, Jafar Al-Gharaibeh wrote:
>> Hi,
>>
>>     I know that the most specific rule is applied a given traffic if multiple overlapping rules exist. But How is the priority determined when rules are specific in different ways Like the cases below. Not sure if this is a strongSwan question or a OS Kernel question  as it seems this is more of how the Linux  kernel handles it for example, but I hope someone here can shed some light on this subject.
>>
>> Example 1:
>>
>> Connection 1 :
>>                     rightsubnet=10.0.0.1/32
>>
>> Connection 2 :
>>                      rightsubnet=10.0.0.0/24[udp]
>>
>> If a udp packet is going to 10.0.0.1, which connection config will be use? Does the priority starts with subnet where the most specific subnet takes precedence before moving to protocols/ports?
>>
>> What is the priority between the protocols and ports themselves?
>>
>>
>> Example 2:
>>
>> Connection 1 :  
>>                     leftsubnet=10.0.0.1/32
>>                     rightsubnet=192.168.0.0/24
>>  
>> Connection 2 :    
>>                     leftsubnet=10.0.0.0/24
>>                     rightsubnet=192.168.0.1/32
>>
>> For a packet going from 10.0.0.1 to 192.168.0.1,  based on the source connection 1 has higher priority, but based on the destination connection 2 has a higher priority. How is this handled?
>>
>> Regards,
>> Jafar
>>  
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171011/d9c20185/attachment.sig>