[strongSwan] Linux routing issue

Carlos G Mendioroz tron at huapi.ba.ar
Tue Jan 25 00:06:13 CET 2022


I transcribed the policy as in ip xfrm policy before, I don't see any 
reference to a mark there.
Talking about marks, I'm also using them for policy routing and QoS, 
using shorewall as a manager. Just in case there is any clash.

-Carlos

Noel Kuntze @ 24/1/2022 19:23 -0300 dixit:
> Hello Carlos,
> 
> I see, yes. Can you check if the XFRM policies have the mark value set 
> you indended in that config?
> 
> Kind regards
> Noel
> 
> Am 24.01.22 um 23:12 schrieb Carlos G Mendioroz:
>> Noel,
>> thanks again for your time and dedication. FTR, I understand ipsec to 
>> some extent, and know the difference between policy and route based.
>> The whole thing is about implementing route based ipsec VPNs to AWS, BTW.
>>
>> I did set mark in the connection configuration:
>>
>> conn %default
>>     ikelifetime=60m
>>     keylife=20m
>>     rekeymargin=3m
>>     keyingtries=1
>>     keyexchange=ikev2
>>     authby=secret
>>     mark=32
>>
>> conn vpc-cust-gw1
>>     left=<my IP>
>>     leftid=vpc-cust-gw1
>>     leftsubnet=0.0.0.0/0
>>     rightsubnet=0.0.0.0/0
>>     leftfirewall=yes
>>     keyexchange=ikev2
>>     ike=aes256-sha256-modp2048
>>     ikelifetime=28800
>>     esp=aes256-sha256-modp2048
>>     leftauth=psk
>>     rightauth=psk
>>     dpdtimeout=60
>>     lifebytes=0
>>     lifepackets=0
>>     lifetime=1h
>>     right=<AWS IP>
>>     auto=start
>>
>> I'm sort of using 
>> https://cloud.google.com/community/tutorials/using-cloud-vpn-with-strongswan 
>> as an example, but have not decided how to implement the BGP yet 
>> (Bird, FRR, ???, main or VRF).
>>
>> -Carlos
>>
>> Noel Kuntze @ 24/1/2022 18:11 -0300 dixit:
>>> Hello Carlos,
>>>
>>> XFRM policies, XFRM states, and XFRM interfaces derive their name 
>>> from the common subsystem XFRM, not because they would be exclusively 
>>> used with each other.
>>> By default strongSwan builds a policy based VPN, thus enabling the 
>>> default use case of IPsec which is protecting traffic between IP 
>>> addresses without intermediate IP addresses like some types of 
>>> tunnels. IPsec is meant to be transparent.
>>>
>>> If you want your policies to only apply to an XFRM interface (XFRM 
>>> interfaces are a relatively recent addition to the Linux kernel), you 
>>> need to set the if_id_in and if_id_out parameters in the connection 
>>> configuration.
>>>
>>> If you do not set the if_id_in and if_id_out parameters, the policies 
>>> are applied regardless of interface (yes you can set the interface as 
>>> part of the config but that is only taken into account by the kernel 
>>> for outgoing traffic matching).
>>>
>>> Also please take into consideration that having an XFRM policy with 
>>> mode "require" (default, can't configure the alternative value "use") 
>>> implies that traffic matching that policy that is not being processed 
>>> by a linked state is DROPPED.
>>>
>>> Can you verify for me that you did set if_id_in and if_id_out 
>>> (assuming your versions of Linux and strongSwan support it), or that 
>>> you did set mark_in and mark_out (alternatively mark, which is 
>>> supposed to set mark_in and mark_out)?
>>>
>>> Kind regards
>>> Noel
>>>
>>> Am 24.01.22 um 21:16 schrieb Carlos G Mendioroz:
>>>> Noel Kuntze @ 24/1/2022 17:11 -0300 dixit:
>>>>> Hello Carlos,
>>>>>
>>>>> Well yes but no:
>>>>
>>>> Hmm, I don't follow.
>>>>>
>>>>>
>>>>>
>>>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>>>      dir out priority 399999
>>>>>      tmpl src <my IP> dst <AWS IP>
>>>>>          proto esp spi 0xcfef925b reqid 1 mode tunnel
>>>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>>>      dir fwd priority 399999
>>>>>      tmpl src <AWS IP> dst <my IP>
>>>>>          proto esp reqid 1 mode tunnel
>>>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>>>      dir in priority 399999
>>>>>      tmpl src <AWS IP> dst <my IP>
>>>>>          proto esp reqid 1 mode tunnel
>>>>>
>>>>> Those are policies that match all traffic.
>>>>>
>>>>> Maybe `ip -d x p` shows the marks if any are set.
>>>>>
>>>>> Kind regards
>>>>> Noel
>>>>
>>>> This is in preparation for a routed VPN, so I wanted a full traffic 
>>>> policy and expecting to bring up a dynamic routing on top. Again, 
>>>> I'm building my understanding... and surprised of the behaviour.
>>>>
>>>> -Carlos
>>>>
>>>>>
>>>>> Am 24.01.22 um 21:09 schrieb Carlos G Mendioroz:
>>>>>> Noel Kuntze @ 24/1/2022 16:55 -0300 dixit:
>>>>>>> Hello Carlos,
>>>>>>>
>>>>>>>
>>>>>>>  > The mark did take, but the rest (i.e. non secured traffic) is 
>>>>>>> being affected, I may have been unclear about the
>>>>>>>
>>>>>>> Please check the routing rules and tables too. E.g. ask the 
>>>>>>> kernel what the route would be for an IP address using `ip r get 
>>>>>>> X` and check if it matches what you expect it to be.
>>>>>>
>>>>>> The "ip route get " shows what I would expect, but not what is 
>>>>>> being done.
>>>>>> Case in point, I do have a tunnel that terminates traffic to a 
>>>>>> given IP. To be able to serve traffic to that IP, any returning 
>>>>>> traffic is source routed via a rule (say prio 600) that forces the 
>>>>>> tunnel as default route. But that would disconnect my local net 
>>>>>> from testing to that address, so prio 0 has a lookup on local 
>>>>>> table, which has a route for the local net to the local interface.
>>>>>>
>>>>>> When I started the ipsec SA, all traffic was routed by main table, 
>>>>>> and sent to default gateway, not paying attention to other rules 
>>>>>> it would seem.
>>>>>>
>>>>>>>
>>>>>>>  > The state shows it:
>>>>>>>
>>>>>>> Can you check `ip xfrm policy`? That shows you the policies, 
>>>>>>> which are the crucial parts. States without policies don't do 
>>>>>>> anything. Policies without states drop everything.
>>>>>>
>>>>>> AFAIK, policy looks good too:
>>>>>>
>>>>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>>>>     dir out priority 399999
>>>>>>     tmpl src <my IP> dst <AWS IP>
>>>>>>         proto esp spi 0xcfef925b reqid 1 mode tunnel
>>>>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>>>>     dir fwd priority 399999
>>>>>>     tmpl src <AWS IP> dst <my IP>
>>>>>>         proto esp reqid 1 mode tunnel
>>>>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>>>>     dir in priority 399999
>>>>>>     tmpl src <AWS IP> dst <my IP>
>>>>>>         proto esp reqid 1 mode tunnel
>>>>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>>>>     socket in priority 0
>>>>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>>>>     socket out priority 0
>>>>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>>>>     socket in priority 0
>>>>>> src 0.0.0.0/0 dst 0.0.0.0/0
>>>>>>     socket out priority 0
>>>>>> src ::/0 dst ::/0
>>>>>>     socket in priority 0
>>>>>> src ::/0 dst ::/0
>>>>>>     socket out priority 0
>>>>>> src ::/0 dst ::/0
>>>>>>     socket in priority 0
>>>>>> src ::/0 dst ::/0
>>>>>>     socket out priority 0
>>>>>>
>>>>>> Note that I have not instantiated an XFRM if yet. I may be missing 
>>>>>> something obvious, but the change of regular traffic behaviour 
>>>>>> surprised me.
>>>>>>
>>>>>> -Carlos
>>>>>>
>>>>>>>
>>>>>>> Kind regards
>>>>>>> Noel
>>>>>>>
>>>>>>> Am 24.01.22 um 20:49 schrieb Carlos G Mendioroz:
>>>>>>>> Noel,
>>>>>>>> thanks for answering. Please see inline:
>>>>>>>>
>>>>>>>> Noel Kuntze @ 24/1/2022 16:24 -0300 dixit:
>>>>>>>>> Hello Carlos,
>>>>>>>>>
>>>>>>>>> Either the mark didn't take, you're using an old version (some 
>>>>>>>>> had a different behaviour in regards to marks and how routes 
>>>>>>>>> are set when marks are set on the connection configuration).
>>>>>>>>
>>>>>>>> I'm using 5.8.2 as distributed by Ubuntu 20.04 LTS.
>>>>>>>> The mark did take, but the rest (i.e. non secured traffic) is 
>>>>>>>> being affected, I may have been unclear about the issue.
>>>>>>>>
>>>>>>>> The state shows it:
>>>>>>>>
>>>>>>>> src <my IP> dst <AWS IP>
>>>>>>>>     proto esp spi 0xcf54acd4 reqid 1 mode tunnel
>>>>>>>>     replay-window 0 flag af-unspec
>>>>>>>>     mark 0x20/0xffffffff
>>>>>>>>     auth-trunc hmac(sha256) 0xd5... 128
>>>>>>>>     enc cbc(aes) 0x1a...
>>>>>>>>     encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
>>>>>>>>     anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
>>>>>>>> src <AWS IP> <my IP>
>>>>>>>>     proto esp spi 0xc1a5cd59 reqid 1 mode tunnel
>>>>>>>>     replay-window 32 flag af-unspec
>>>>>>>>     auth-trunc hmac(sha256) 0xbe... 128
>>>>>>>>     enc cbc(aes) 0xd9...
>>>>>>>>     encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
>>>>>>>>     anti-replay context: seq 0x22, oseq 0x0, bitmap 0xffffffff
>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you do not require the setting of source IP addresses for 
>>>>>>>>> the remote subnets, just disable installing of routes, and use 
>>>>>>>>> XFRM interfaces so you can use routes to direct traffic instead 
>>>>>>>>> of dealing with the XFRM policies.
>>>>>>>>
>>>>>>>> I'm trying to understand, not to have a working config. For now, 
>>>>>>>> at least :)
>>>>>>>>
>>>>>>>> -Carlos
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Kind regards
>>>>>>>>> Noel
>>>>>>>>>
>>>>>>>>> Am 24.01.22 um 12:44 schrieb Carlos G Mendioroz:
>>>>>>>>>> Hi,
>>>>>>>>>> trying to set up a VPN on a lab system with many interfaces
>>>>>>>>>> (Ubuntu 20.04, 2 uplinks, IPv6 tunnel, vlans, openvpn and IPIP 
>>>>>>>>>> tunnel).
>>>>>>>>>>
>>>>>>>>>> It's been a while since I used strongswan, but it was easy to 
>>>>>>>>>> set up using ipsec command and ipsec.conf policies. ipsec 
>>>>>>>>>> route table (220) played fine with my own rules I use mainly 
>>>>>>>>>> to source route to Internet uplinks.
>>>>>>>>>>
>>>>>>>>>> Now I want to setup a routed VPN (AWS transit gateway on the 
>>>>>>>>>> other end) and as soon as link comes up, all my traffic gets 
>>>>>>>>>> routed by main table.
>>>>>>>>>> (I changed policy to any any and at first did not specifiy 
>>>>>>>>>> mark, and it even disconnected from the local net, not nice on 
>>>>>>>>>> a headless server)
>>>>>>>>>> Now with mark it still makes all the traffic ignore rule 
>>>>>>>>>> priorities.
>>>>>>>>>>
>>>>>>>>>> Any pointer to what to check ?
>>>>>>>>>> TIA,
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

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


More information about the Users mailing list