| 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
| ||
|
Message-ID: <642fb4d6-4188-968f-6d43-249ca8e38d7a@gmail.com> Date: Mon, 15 Mar 2021 12:41:05 -0600 From: David Ahern <dsahern@...il.com> To: Greesha Mikhalkin <grigoriymikhalkin@...il.com> Cc: netdev@...r.kernel.org Subject: Re: VRF leaking doesn't work On 3/15/21 11:10 AM, Greesha Mikhalkin wrote: >> That's the way the source address selection works -- it takes the fib >> lookup result and finds the best source address match for it. >> >> Try adding 'src a.b.c.d' to the leaked route. e.g., >> ip ro add 172.16.1.0/24 dev red vrf blue src 172.16.2.1 >> >> where red and blue are VRFs, 172.16.2.1 is a valid source address in VRF >> blue and VRF red has the reverse route installed. > > Tried to do that. Added reverse route to vrf red like that: > ip ro add vrf red 172.16.2.1/32 dev blue > > 172.16.2.1 is selected as source address when i ping. But now, when i > look at `tcpdump icmp` i only see requests: > 172.16.2.1 > 172.16.1.3: ICMP echo request, id 9, seq 10, length 64 > > And no replies and anything else. If i look into tcpdump on machine > that's pinged -- it doesn't receive anything. > > So it looks like it's not using nexthops from vrf red in that case. > Maybe it has something to do with how address is setup. In routing > table it looks like: > local 172.16.2.1 dev vlanblue proto kernel scope host src 172.16.2.1 > VRF is implemented via policy routing. did you re-order the FIB rules? http://schd.ws/hosted_files/ossna2017/fe/vrf-tutorial-oss.pdf
Powered by blists - more mailing lists