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

[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


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