netdev - Re: vrf and ipsec xfrm routing problem

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: <d6840ae9-bfce-7ea8-9d44-7f8ee99874ab@candelatech.com>
Date:   Mon, 20 Jan 2020 21:29:41 -0800
From:   Ben Greear <greearb@...delatech.com>
To:     David Ahern <dsahern@...il.com>, netdev <netdev@...r.kernel.org>
Subject: Re: vrf and ipsec xfrm routing problem



On 01/20/2020 07:21 PM, David Ahern wrote:
> On 1/17/20 2:52 PM, Ben Greear wrote:
>>> I tried adding a route to specify the x_frm as source, but that does
>>> not appear to work:
>>>
>>> [root@...313-63e7 lanforge]# ip route add 192.168.10.0/24 via
>>> 192.168.5.1 dev x_eth4 table 4
>>> [root@...313-63e7 lanforge]# ip route show vrf _vrf4
>>> default via 192.168.5.1 dev eth4
>>> 192.168.5.0/24 dev eth4 scope link src 192.168.5.4
>>> 192.168.10.0/24 via 192.168.5.1 dev eth4
>>>
>>> I also tried this, but no luck:
>>>
>>> [root@...313-63e7 lanforge]# ip route add 192.168.10.0/24 via
>>> 192.168.10.1 dev x_eth4 table 4
>>> Error: Nexthop has invalid gateway.
>>
>> I went looking for why this was failing.  The reason is that this code
>> is hitting the error case
>> in the code snippet below (from 5.2.21+ kernel).
>>
>> The oif is that of _vrf4, not the x_eth4 device.
>>
>> David:  Is this expected behaviour?  Do you know how to tell vrf to use
>> the x_eth4
>
> It is expected behavior for VRF. l3mdev_update_flow changes the oif to
> the VRF device if the passed in oif is enslaved to a VRF.
>
>> xfrm device as oif when routing output to certain destinations?
>>
>>     rcu_read_lock();
>>     {
>>         struct fib_table *tbl = NULL;
>>         struct flowi4 fl4 = {
>>             .daddr = nh->fib_nh_gw4,
>>             .flowi4_scope = scope + 1,
>>             .flowi4_oif = nh->fib_nh_oif,
>>             .flowi4_iif = LOOPBACK_IFINDEX,
>>         };
>>
>>         /* It is not necessary, but requires a bit of thinking */
>>         if (fl4.flowi4_scope < RT_SCOPE_LINK)
>>             fl4.flowi4_scope = RT_SCOPE_LINK;
>
> If you put your debug here, flowi4_oif should be fib_nh_oif per the
> above initialization. It gets changed by the call to fib_lookup.
>
> --
>
> Sabrina sent me a short script on using xfrm devices to help me get up
> to speed on that config (much simpler than using any of the *SWAN
> programs). I have incorporated the xfrm device setup into a script of
> other vrf + ipsec tests. A couple of tests are failing the basic setup.
> I have a fix for one of them (as well as the fix for the qdisc on a VRF
> device). I did notice trying to add routes with the xfrm device as the
> nexthop dev was failing but have not had time to dig into it. I have
> busy week but will try to spend some time on this use case this week.

I dug into the nexthop thing a bit earlier.  It fails because oif is always forced to
be the VRF device, and then the nexthop is considered unreachable for reasons that
escape me.

Thanks,
Ben

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