[strongSwan] Linux routing issue
Carlos G Mendioroz
tron at huapi.ba.ar
Mon Jan 24 21:16:53 CET 2022
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