[strongSwan] Linux xfrm integration (was: Linux routing issue)

[Noel Kuntze]

Hello Carlos,

Marks are sadly not visible in the data dumped with nflog. You can see them in the output of the TRACE and LOG iptables targets though.

 > I have not been able to trace the incoming packets to pinpoint incoming marks. To be honest, I don't know at wich stage makrks are supposed to be visible.

When you take a look at the kernel output in `dmesg`, then AFAIR the marks are only printed if they are set on the skb (don't know if they are just not printed if the the value is 0).

 > Checked xfrm_stat and I see some possible issue there:
 > XfrmInTmplMismatch              99
 > XfrmInNoPols                    1717

Yeah, the marks on the incoming packets doesn't match the ones the inbound policy requires.

Just do away with marks on the policies and use an XFRM interface. Then the marks are disregarded (mask for mark comparison is set to 0x0, meaning any mark is fine for the policies, thus disregarded).


 > I'm using xfrm interfaces now, but behaviour is simmilar when using vtis.
 > Last, I'm using ipsec.conf for configuration and I see no way to define the if_id_in/out other than using mark ? The reqid value also escapes me.

You can only set the if_id_in and if_id_out values in swanctl. These values are also independent of marks.
Marks are part of the skb, the packet in the Linux kernel.
The if_id is part of the policy and the XFRM interface.
The if_id of a policy is *not* used for checking if a packet matches the policy. It is used to connect the XFRM interfaces on your system with the corresponding XFRM policies and ensuring the packets matched by the policies are "redirected" so to say to appear on the XFRM interface instead of on the receiving interface (e.g. eth0), and for steering the packets sent over an XFRM interface to the right XFRM policy for lookup.

Kind regards
Noel


Am 27.01.22 um 14:37 schrieb Carlos G Mendioroz:
> Noel,
> once again, thank you for your kind support.
>
> I have inspected the ipsec encapsulated traffic using:
>
> iptables -t mangle -I PREROUTING -m policy --pol ipsec --dir in -j NFLOG --nflog-group 1
> iptables -t mangle -I POSTROUTING -m policy --pol ipsec --dir out -j NFLOG --nflog-group 1
>
> and I only see my outgoing traffic, not the return. (But I do see the corresponding ESP packets, both ways.
>
> I have not been able to trace the incoming packets to pinpoint incoming marks. To be honest, I don't know at wich stage makrks are supposed to be visible.
>
> Checked xfrm_stat and I see some possible issue there:
> XfrmInTmplMismatch              99
> XfrmInNoPols                    1717
>
> I'm using xfrm interfaces now, but behaviour is simmilar when using vtis.
> Last, I'm using ipsec.conf for configuration and I see no way to define the if_id_in/out other than using mark ? The reqid value also escapes me.
>
> Hope you have some extra piece of advise for me!
> -Carlos
>
>> Hello Carlos,
>>
>> That is great to hear.
>>
>>> I have not created a vti interface, but I'm using mangle to mark packets destined to the other tunnel endpoint.
>>
>> I see. Please take a look at the article about route based VPNs[1] which includes VTIs and XFRM interfaces. It's been some months already since I last dealt with configuring a VTI so I can't help you with that particular issue and the reason for it from the top of my head with the information available.
>> You probably want to check what the mark value on the incoming packets is (best checked with the iptables TRACE target, described on the man page for iptables-extensions), if the inbound policies have the same mark (best checked with ip -d x p), and if there are any problems with decapsulating the packets by the kernel (check /proc/net/xfrm_stat).
>>
>> The behaviour of the kernel in regards to the decapsulation changes if a VTI with a matching mark exists or not. It's not that much a self contained solution as in "once a VTI for the mark exists the packets just appear in it" - no, the existence (AFAIR) also changes if the packets can be decapsulated at all (if the input policy has a mark but the packets to be decapsulated don't? I don't remember the specifics.
>>
>> 1) set up the VTI with mark_out as described on the wiki
>> 2) completely switch to an XFRM interface and thus don't need to deal with marks and the interaction with the routing engine configuration and the firewall rules
>>
>> With an XFRM interface you don't have to deal with any marks or any other possible interaction with the routing engine or any other components using marks. XFRM interfaces are basically self contained in regards to if packets can be decapsulated or not. If you have an if_id set on the inbound policy then that just means that the packets will appear in the/a XFRM interfaces with the corresponding if_id and not if they don't exist at all. So it's much easier to distinguish the failure cases with XFRM interfaces.
>>
>> Kind regards
>> Noel
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20220127/207c4a1f/attachment.sig>