netdev - Re: v6/sit tunnels and VRFs

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:   Fri, 27 Oct 2017 16:59:16 -0400
From:   Jeff Barnhill <0xeffeff@...il.com>
To:     David Ahern <dsahern@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: v6/sit tunnels and VRFs

w/regards to this comment:
   You have a remote address with no qualification about which VRF to
use for the lookup.

I was using this to enslave the tunnel:
sudo ip link set jtun vrf myvrf

and assumed this would be enough to cause all tunnel traffic to be
part of this VRF.

You are right about the tunnel link/dev configuration. (re-stating to
be sure we are saying the same thing)  I can use either the VRF device
or the v4 device and the packet will get sent.  If I use the VRF
device, when the reply packet is received, the tunnel is found
successfully.  If I use the v4 device, then I need the patch you
provided earlier to successfully look up the tunnel.  You mentioned
that both should be supported...Back to my previous comment about
enslaving the tunnel...shouldn't a tunnel being enslaved to a VRF also
be enough to allow sending and receiving on any device in that VRF
(that is, not having to configure the link/dev on the tunnel) ?

Fyi...with regards to the v4 ping, adding the loopback address/network
didn't work for me.  I'll see if I can get anymore info on this and
maybe start a new thread.

Thanks,
Jeff


jeff@VM2:~$ ping -I myvrf 127.0.0.1
ping: Warning: source address might be selected on device other than myvrf.
PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 myvrf: 56(84) bytes of data.
^C
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2051ms

jeff@VM2:~$ sudo ip addr add dev myvrf 127.0.0.1/8
jeff@VM2:~$ ping -I myvrf 127.0.0.1
PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 myvrf: 56(84) bytes of data.
^C
--- 127.0.0.1 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6149ms

jeff@VM2:~$ ip addr list myvrf
4: myvrf: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP
group default qlen 1000
    link/ether 82:2b:08:8f:a9:f3 brd ff:ff:ff:ff:ff:ff
    inet 127.0.0.1/8 scope host myvrf
       valid_lft forever preferred_lft forever

On Fri, Oct 27, 2017 at 12:25 PM, David Ahern <dsahern@...il.com> wrote:
> On 10/26/17 11:19 PM, Jeff Barnhill wrote:
>> Thanks, David.
>>
>> I corrected the static route, applied the patch, and set the
>> link/output dev on the tunnel and it works now.  Is it required to set
>> the link/output dev?  I was thinking that this should not be required
>> for cases where the outgoing device is not known, for instance on a
>> router or device with multiple interfaces.
>
> In a VRF environment, addresses have to be qualified with a VRF. Running
> the command:
>
> ip tunnel add jtun mode sit remote 192.168.200.1 local 192.168.210.2
>
> You have a remote address with no qualification about which VRF to use
> for the lookup.
>
> Digging into the sit code and how the link parameter is used, the
> existing code works just fine if you use:
>
> sudo ip tunnel add jtun mode sit remote 192.168.200.1 local
> 192.168.210.2 dev myvrf
>
> The tunnel link parameter is myvrf and it is used for tunnel lookups and
> route lookups to forward the packet. So, really I should allow both
> cases -- dev is a VRF and dev is a link that could be in a vrf.
>
>>
>> Also, what is the expected behavior of loopback addresses in a VRF
>> context?  For instance, if an application were being run under "ip vrf
>> exec" and it tried to use these addresses.
>
> The 127.0.0.1 address needs to exist in the VRF. The one on 'lo' is in
> the default VRF only. VRF devices act as the VRF-local loopback, so you
> can put the IPv4 loopback address on it.
>
>>
>> jeff@VM2:~$ ping -I myvrf 127.0.0.1
>> PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 myvrf: 56(84) bytes of data.
>> ^C
>> --- 127.0.0.1 ping statistics ---
>> 3 packets transmitted, 0 received, 100% packet loss, time 2033ms
>
> If you add the loopback address to the
>     ip addr add dev myvrf 127.0.0.1/8
>
> root@...ny-jessie3:~# ip addr add dev myvrf 127.0.0.1/8
> root@...ny-jessie3:~# ping -I myvrf 127.0.0.1
> PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 myvrf: 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.045 ms
> ^C
> --- 127.0.0.1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.045/0.045/0.045/0.000 ms
>
>
>>
>> jeff@VM2:~$ ping -I myvrf ::1
>> connect: Network is unreachable
>
> I need to add support for ::1/128 on a VRF device.