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

[Carlos G Mendioroz]

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