netdev - Re: Strange routing with VRF and 5.2.7+

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e8e7fd75-7486-0fc8-3ea0-95debe2d37b2@candelatech.com>
Date:   Mon, 14 Oct 2019 10:33:26 -0700
From:   Ben Greear <greearb@...delatech.com>
To:     David Ahern <dsahern@...il.com>, netdev <netdev@...r.kernel.org>
Subject: Re: Strange routing with VRF and 5.2.7+

On 9/30/19 11:45 AM, Ben Greear wrote:
> On 9/22/19 12:23 PM, David Ahern wrote:
>> On 9/20/19 9:57 AM, Ben Greear wrote:
>>> On 9/10/19 6:08 PM, Ben Greear wrote:
>>>> On 9/10/19 3:17 PM, Ben Greear wrote:
>>>>> Today we were testing creating 200 virtual station vdevs on ath9k,
>>>>> and using
>>>>> VRF for the routing.
>>>>
>>>> Looks like the same issue happens w/out VRF, but there I have oodles
>>>> of routing
>>>> rules, so it is an area ripe for failure.
>>>>
>>>> Will upgrade to 5.2.14+ and retest, and try 4.20 as well....
>>>
>>> Turns out, this was ipsec (strongswan) inserting a rule that pointed to
>>> a table
>>> that we then used for a vrf w/out realizing the rule was added.
>>>
>>> Stopping strongswan and/or reconfiguring how routing tables are assigned
>>> resolved the issue.
>>>
>>
>> Hi Ben:
>>
>> Since you are the pioneer with vrf and ipsec, can you add an ipsec
>> section with some notes to Documentation/networking/vrf.txt?
> 
> I need to to some more testing, an initial attempt to reproduce my working
> config on another system did not work properly, and I have not yet dug into
> it.

I'm still grinding out the bugs...  Here is my current quandry.

In the VRF I have the 'real' device, say eth4 with IP 192.168.5.5.  This talks to
the VPN gateway device at 192.168.5.1.

When I add the xfrm, it is given the address 192.168.10.100.

I need all traffic routing out the vrf to use the xfrm as source IP,
except the eth4 still needs to be able to talk to the 5.1 device
(I think?)

Evidently, adding this type of route below will do the trick, at least in
non-vrf setup, and with this route in its own table that is queried after
'local' routing table, but before the others via use of a fairly generic rule....

default via 192.168.5.1 dev enp1s0 proto static src 192.168.10.100

I am guessing that in VRF world, I can get rid of the rule, and replace the
existing default route (given to eth4 when it does DHCP or is statically assigned)
with something like the above.  And, maybe I need a special route for the VPN
gateway itself as destination so that ipsec logic on eth4 can still talk to it?

(I am thinking of the case where the VPN gateway is not on the local subnet
and so we have to route to it special???)

Any insight is welcome.

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com