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

[Noel Kuntze]

Hello Carlos,

I propose you "swiftly" migrate your config to `swanctl`. fully usable examples with all bells and whistles are on the wiki[1].
The mark on the state is used when looking up the state as an additional selector, same with the mark on the inbound policies.
Or "normal" mark fields on any policy or state. They're just used for matching the mark on the skb, not assigning a mark to the skb.
The latter can be configured in swanctl.conf only by using `connections.<conn>.children.<child>.set_mark_in` and `connections.<conn>.children.<child>.set_mark_out`.

> 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). 

You need to bind the states to the interface using the if_id_in and if_it_out keys in strongswan, or try to manipulate them by yourself using `ip xfrm` (massive waste of time because they are removed/updated/replaced when the tunnel gets renegotiated and understanding how to use the tool takes way longer than just migrating the config.

As long as the if_id fields on the XFRM state and policies are not set, they disregard the existence of any XFRM interfaces.


For the VTI, the configured tunnel endpoints on the VTI interface itself also must matchthe ones on the inbound packets.
The problem doesn't get easier with marks and VTIs, which are the only interfaces you can use with `ipsec.conf`

Kind regards
Noel

[1] https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples


Am 28.01.22 um 20:38 schrieb Carlos G Mendioroz:
>
>
> Noel Kuntze @ 28/1/2022 16:35 -0300 dixit:
>>  > 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.
>
> Why does policy fail ? I have any - any policy !
> Oh well, I'm missing things here evidently.
>
>

-------------- 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/e337b04a/attachment.sig>