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]

Message-ID: <9777beb0-0c9c-ef8b-22f0-81373b635e50@candelatech.com>
Date:   Tue, 7 Jan 2020 14:59:46 -0800
From:   Ben Greear <greearb@...delatech.com>
To:     Trev Larock <trev@...ock.ca>, David Ahern <dsahern@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: VRF + ip xfrm, egress ESP packet looping when qdisc configured

On 1/5/20 9:58 PM, Trev Larock wrote:
> On Sun, Jan 5, 2020 at 11:29 PM David Ahern <dsahern@...il.com> wrote:
>> I was able to adapt your commands with the above and reproduced the
>> problem. I need to think about the proper solution.
>>
> Ok thanks for investigating.
> 
>> Also, I looked at my commands from a few years ago (IPsec with VRF) and
>> noticed you are not adding a device context to the xfrm policy and
>> state. e.g.,
>>
> Yes was part of my original query, that makes sense in order to be able to have
> multiple vrf each with their own xfrm policies.
> I will investigate further on it.  The oif passed to xfrm_lookup seemed to be
> enp0s8 oif rather than vrf0 oif, so I was observing just cleartext
> pings go out / policy wouldn't match.
> Perhaps I'm missing something to get vrf0 oif passed for the ping packet.

As luck would have it, I am investigating problems that sound very similar
today.

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

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.

David:  I'll be happy to test patches, and if you think it will be a while
before you can write them, if you want to point me to the likely problem places,
I can make an attempt at fixing it.

Thanks,
Ben

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