netdev - Re: VRF Issue Since kernel 5

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: <00917d3a-17f8-b772-5b93-3abdf1540b94@gmail.com>
Date:   Wed, 1 Apr 2020 14:41:56 -0600
From:   David Ahern <dsahern@...il.com>
To:     Maximilian Bosch <maximilian@...sch.me>, netdev@...r.kernel.org
Subject: Re: VRF Issue Since kernel 5

On 4/1/20 2:35 PM, Maximilian Bosch wrote:
> Hi!
> 
>> This should work:
>>     make -C tools/testing/selftests/net nettest
>>     PATH=$PWD/tools/testing/selftests/net:$PATH
>>     tools/testing/selftests/net/fcnal-test.sh
> 
> Thanks, will try this out later.
> 
>> If you want that ssh connection to work over a VRF you either need to
>> set the shell context:
>>     ip vrf exec <NAME> su - $USER
>>
> 
> Yes, using `ip vrf exec` is basically my current workaround.

that's not a workaround, it's a requirement. With VRF configured all
addresses are relative to the L3 domain. When trying to connect to a
remote host, the VRF needs to be given.

> 
>> or add 'ip vrf exec' before the ssh. If it is an incoming connection to
>> a server the ssh server either needs to be bound to the VRF or you need
>> 'net.ipv4.tcp_l3mdev_accept = 1'
> 
> Does this mean that the `*l3mdev_accept`-parameters only "fix" this
> issue if the VRF is on the server I connect to?

server side setting only.

> 
> In my case the VRF is on my local machine and I try to connect through
> the VRF to the server.
> 
>> The tcp reset suggests you are doing an outbound connection but the
>> lookup for what must be the SYN-ACK is not finding the local socket -
>> and that is because of the missing 'ip vrf exec' above.
> 
> I only experience this behavior on a 5.x kernel, not on e.g. 4.19
> though. I may be wrong, but isn't this a breaking change for userspace
> applications in the end?

I do not see how this worked on 4.19. My comment above is a fundamental
property of VRF and has been needed since day 1. That's why 'ip vrf
exec' exists.