netdev - Re: [PATCH net-next] vrf: local route leaking

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 May 2019 21:52:50 +0100
From:   George Wilkie <gwilkie@...tta.att-mail.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Shrijeet Mukherjee <shrijeet@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next] vrf: local route leaking

On Wed, May 29, 2019 at 09:29:22PM -0600, David Ahern wrote:
> you are correct that use of loopback here for default VRF does not work
> -- the lookup code gets confused because it is a forward path (as
> opposed to MPLS which is a local input). I found a couple of solutions
> that work for default VRF.
> 
> Again, using namespaces to demonstrate within a single node. This is the
> base setup:
> 
>  ip li add vrf-b up type vrf table 2
>  ip route add vrf vrf-b unreachable default
>  ip ru add pref 32765 from all lookup local
>  ip ru del pref 0
> 
>  ip netns add foo
>  ip li add veth1 type veth peer name veth11 netns foo
>  ip addr add dev veth1 10.200.1.1/24
>  ip li set veth1 vrf vrf-b up
>  ip -netns foo li set veth11 up
>  ip -netns foo addr add dev veth11 10.200.1.11/24
>  ip -netns foo ro add 10.200.2.0/24 via 10.200.1.1
> 
>  ip netns add bar
>  ip li add veth2 type veth peer name veth12 netns bar
>  ip li set veth2 up
>  ip addr add dev veth2 10.200.2.1/24
>  ip -netns bar li set veth12 up
>  ip -netns bar addr add dev veth12 10.200.2.12/24
> 
> Cross VRF routing can be done with a veth pair, without addresses:
> 
>  ip li add xvrf1 type veth peer name xvrf2
>  ip li set xvrf1 up
>  ip li set xvrf2 master vrf-b up
> 
>  ip ro add vrf vrf-b 10.200.2.0/24 dev xvrf2
>  ip ro add 10.200.1.0/24 dev vrf-b


This doesn't work for me (again, not using namespaces).
For traffic coming in on vrf-b to a destination on 10.200.2.0,
I see ARPs going out for the destination on xvrf2/in on xvrf1,
but nothing replies to it.

> 
> or with addresses:
> 
>  ip li add xvrf1 type veth peer name xvrf2
>  ip li set xvrf1 up
>  ip addr add dev xvrf1 10.200.3.1/30
>  ip li set xvrf2 master vrf-b up
>  ip addr add dev xvrf2 10.200.3.2/30
> 
>  ip ro add vrf vrf-b 10.200.2.0/24 via 10.200.3.1 dev xvrf2
>  ip ro add 10.200.1.0/24 via 10.200.3.2 dev xvrf1

Having to use additional addresses is not ideal.

However, there does seem to be an alternative approach which works.
If I create another vrf "vrfdefault" and associate it with table "local"
and use that to leak routes from global into a vrf, then it seems to
work for both v4 and v6.
Can reach both local and remote destinations
(which was somewhat surprising to me anyway).

 ip link add vrfdefault type vrf table local
 ip route add 10.10.4.0/24 vrf vrfA dev vrfdefault
 ip -6 route add 10:10:4::/64 vrf vrfA dev vrfdefault

Do you see any issue with relying on that?
Thx.