netdev - Re: VRF + ip xfrm, egress ESP packet looping when qdisc configured

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:   Mon, 13 Jan 2020 09:48:48 -0700
From:   David Ahern <dsahern@...il.com>
To:     Ben Greear <greearb@...delatech.com>, Trev Larock <trev@...ock.ca>
Cc:     netdev@...r.kernel.org
Subject: Re: VRF + ip xfrm, egress ESP packet looping when qdisc configured

On 1/7/20 3:59 PM, Ben Greear wrote:
> 
> As luck would have it, I am investigating problems that sound very similar
> today.

Trev's problem is looping due to the presence of the qdisc. The vrf
driver needs to detect that it has seen the packet and not redirect it
again.

> 
> In my case, I'm not using network name spaces.  For instance:

use of the namespaces is solely for a standalone (single node) test. It
has no bearing on the problem.

> 
> eth1 is the un-encrypted interface
> x_eth1 is the xfrm network device on top of eth1
> both belong to _vrf1
> 
> What I see is that packets coming in eth1 from the VPN are encrypted and
> received
> on x_eth1.
> 
> But, UDP frames that I am trying very hard to send on x_eth1
> (SO_BINDTODEVICE is called)
> are not actually sent from there but instead go out of eth1 un-encrypted.

have you added debugs to the udp code to check that device binding? What
about the fib_table_lookup tracepoint?