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

Fri Jan 28 20:35:01 CET 2022

Hello Carlos,

For translating the configuration formats, I made a python script[1] that should already handle most/all cases well enough to get going.

 > So I removed the incoming marking (from mangle) and now instead of seeing an incrementing XfrmInTmplMismatch counter, I see an XfrmInNoPols
 > counter, but... state does show incrementing numbers on the lifetime counters of both direction SAs:

Yeah, state can be used to decapsulate the packet but then the policy check fails so naturally these counters increase.

 > Any last thing I can take a look at before forgetting about ipsec.conf starter configuration ?

Sadly not really, no. In your case because you already use mark, XFRM interfaces are really the way to go. :|

Kind regards
Noel

[1] https://gitlab.com/Thermi/ipsec2swanctl

Am 28.01.22 um 14:25 schrieb Carlos G Mendioroz:
> Noel,
> from what I've read, it seems using the new swanctl config is the way to go, and I guess I'll take that route. It is a shame that all available examples that are there for using dynamic routing are made with ipsec.conf (i.e. starter).
>
> On the other hand, it would seem that I'm quite near to somehow have it working. Now I can see the markings and I have discovered that even though mark is declared in the connection, the incoming policy shows the marks but the state (ip xfrm state) does not.
> So I removed the incoming marking (from mangle) and now instead of seeing an incrementing XfrmInTmplMismatch counter, I see an XfrmInNoPols
> counter, but... state does show incrementing numbers on the lifetime counters of both direction SAs:
>
> src <my IP> dst <AWS IP>
>         proto esp spi 0xcdc36329(3452134185) reqid 1(0x00000001) mode tunnel
>         replay-window 0 seq 0x00000000 flag af-unspec (0x00100000)
>         mark 0x20/0xffffffff
>         auth-trunc hmac(sha256) 0x982164ca5ee779cee42f4322897af058c736529ef57f58ea7c0d8451e9299854 (256 bits) 128
>         enc cbc(aes) 0x52feeb677f7dd36712821491cd040299e538e8606aae499a0706b31b7edda70e (256 bits)
>         encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
>         anti-replay context: seq 0x0, oseq 0x2, bitmap 0x00000000
>         lifetime config:
>           limit: soft (INF)(bytes), hard (INF)(bytes)
>           limit: soft (INF)(packets), hard (INF)(packets)
>           expire add: soft 977(sec), hard 1200(sec)
>           expire use: soft 0(sec), hard 0(sec)
>         lifetime current:
>           168(bytes), 2(packets)
>           add 2022-01-28 10:03:50 use 2022-01-28 10:09:05
>         stats:
>           replay-window 0 replay 0 failed 0
> src <AWS IP> dst <my IP>
>         proto esp spi 0xcb7d9bfb(3414006779) reqid 1(0x00000001) mode tunnel
>         replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
>         auth-trunc hmac(sha256) 0x359a122f25b73a2e4476345b9c6d8241c45803fdab09a8196f04d5adb2a3be0c (256 bits) 128
>         enc cbc(aes) 0x0792c1df050c1616683fd13ade83731d12bed07ae10372391cb02aaa5646a637 (256 bits)
>         encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
>         anti-replay context: seq 0x16, oseq 0x0, bitmap 0x003fffff
>         lifetime config:
>           limit: soft (INF)(bytes), hard (INF)(bytes)
>           limit: soft (INF)(packets), hard (INF)(packets)
>           expire add: soft 851(sec), hard 1200(sec)
>           expire use: soft 0(sec), hard 0(sec)
>         lifetime current:
>           1368(bytes), 22(packets)
>           add 2022-01-28 10:03:50 use 2022-01-28 10:04:15
>         stats:
>           replay-window 0 replay 0 failed 0
>
> which sounds like the return is making it but it does not,
> and a log of ipsec "inside" content 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
>
> only shows outgoing pings.
>
> Any last thing I can take a look at before forgetting about ipsec.conf starter configuration ?
>
> -Carlos
>
> Carlos G Mendioroz @ 27/1/2022 19:13 -0300 dixit:
>> Noel,
>>
>>> 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.
>>
>> But I still don't know when are they supposed to appear. I'll have to read and understand the process...
>>
>>>
>>>  > 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.
>>
>> So the problem is mark related.
>>
>>> 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 am using an XFRM interface, but as soon as I clear the mark config from the ipsec.conf, havoc happens and my routing priorities do not work as intended. (In fact, I get disconnected from the system as I'm managing it from the local network).
>>
>>>
>>>
>>>  > 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.
>>
>> Grr, digesting this information is proving harder than expected.
>>
>>>
>>> Kind regards
>>> Noel
>>>
>>
>> Much appreciated,
>> -Carlos
>>
>

-------------- 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/20220128/08520b4d/attachment-0001.sig>