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

[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
> 

-- 
Carlos G Mendioroz  <tron at huapi.ba.ar>  LW7 EQI  Argentina