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]

Message-ID: <0d920356-8d12-b0b5-c14b-3600e54e9390@gmail.com>
Date:   Fri, 24 May 2019 14:19:45 -0600
From:   David Ahern <dsahern@...il.com>
To:     George Wilkie <gwilkie@...tta.att-mail.com>,
        Shrijeet Mukherjee <shrijeet@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next] vrf: local route leaking

On 5/24/19 2:05 AM, George Wilkie wrote:
> If have an interface in vrf A:
> 
>   10.10.2.0/24 dev ens9 proto kernel scope link src 10.10.2.2
>   local 10.10.2.2 dev ens9 proto kernel scope host src 10.10.2.2
> 
> and want to leak it into vrf B, it is not sufficient to leak just
> the interface route:
> 
>   ip route add 10.10.2.0/24 vrf B dev ens9
> 
> as traffic arriving into vrf B that is destined for 10.10.2.2 will
> not arrive - it will be sent to the ens9 interface and nobody will
> respond to the ARP.
> 
> In order to handle the traffic locally, the local route must also
> be leaked to vrf B:
> 
>   ip route add local 10.10.2.2 vrf B dev ens9
> 
> However, that still doesn't work as the traffic is processed in
> the context of the input vrf B and does not find a socket that is
> bound to the destination vrf A.

I presume you mean traffic arrives on another interface assigned to VRF
B with the final destination being the local address of ens9 in VRF-A.


I think this codifies the use case:
  ip li add vrf-a up type vrf table 1
  ip route add vrf vrf-a unreachable default
  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.1.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.1.1.11/24
  ip -netns foo ro add 10.1.2.0/24 via 10.1.1.1

  ip netns add bar
  ip li add veth2 type veth peer name veth12 netns bar
  ip li set veth2 vrf vrf-a up
  ip addr add dev veth2 10.1.2.1/24
  ip -netns bar li set veth12 up
  ip -netns bar addr add dev veth12 10.1.2.12/24

If you do route leaking this way:
  ip ro add vrf vrf-b 10.1.2.0/24 dev veth2
  ip ro add vrf vrf-a 10.1.1.0/24 dev veth1

yes, you hit problems trying to connect to a local address.

If you do route leaking this way:
  ip ro add vrf vrf-b 10.1.2.0/24 dev vrf-a
  ip ro add vrf vrf-a 10.1.1.0/24 dev vrf-b

you do not.