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

[Noel Kuntze]

Hello Carlos,

Can you provide me your complete current iptables-save?

Kind regards
Noel

Am 31.01.22 um 15:23 schrieb Carlos G Mendioroz:
> Aha!
> Originating from an ethernet interface works.
> And I tried using the subjacent ethernet in the pppoe link and it does not cut it. So there is something I still don't get about the policy mapping logic, or else I hit a bug.
>
> -Carlos
>
> (Hmm, less terse version, I do have two Internet uplinks, one cable modem bridged in ethernet and one ADSL with pppoe. I was using the pppoe link for the testing, moved to the cable one.)
>
> Carlos G Mendioroz @ 31/1/2022 09:00 -0300 dixit:
>> Noel,
>> I'm starting to be a stone in the shoe it seems.
>> I've migrated the config to swanctl.
>> (There are some syntax details that did not seem apparent from reading the docs, like PSKs names having to start with ike, but in the end got it up and running.)
>>
>> But now I'm kind of in the same place: I see traffic going out (from a test ping), coming back in encapsulated but it never gets decapsulated or assigned to my local if. XfrmInNoPols goes up, conn stats show ipsec (i.e. child) packets in and out.
>>
>> I'm sort of in the same place I was before, but now I have if_id matching in the policy, state and interface.
>>
>> Anything else I might be missing ?
>> This is using ESP on UDP (Nat traversal) and the main if is ppp.
>> No marks in the mix now...
>>
>> TIA,
>> -Carlos
>>
>> Noel Kuntze @ 28/1/2022 16:58 -0300 dixit:
>>> 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/20220131/6c884cdb/attachment.sig>