Tunnel traffic in VRF

Tunnel traffic in VRF

[Daniele Orlandi]

Hello,

I'm attempting to route the WG tunnel traffic (not the inside traffic)
on a VRF.

I was able to use an ip rule + fwmark to route outgoing packets to the
proper VRF, however the incoming traffic *seems* to be rejected due to
the UDP socket not being bound to an interface in the VRF.

00:56:35.606766 IP 172.16.16.32.5180 > 45.66.80.144.5180: UDP, length 148
00:56:35.922547 IP 45.66.80.144.5180 > 172.16.16.32.5180: UDP, length 92
00:56:35.922680 IP 172.16.16.32 > 45.66.80.144: ICMP 172.16.16.32 udp
port 5180 unreachable, length 128


Is there any workaround you know of? Would you consider implementing
binding to an interface like other tunnel interfaces do?


(The infrastructure is already present by using the bind_ifindex field
of udp_port_cfg passed to udp_sock_create)

Thank you,
regards,

-- 
  Daniele Orlandi
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Tunnel traffic in VRF

[Steven Honson]

Hi Daniele,

By VRFs, do you mean Linux network namespaces, or something different?

If network namespaces, https://www.wireguard.com/netns/#routing-network-namespace-integration talks a little about WireGuards behaviour, but the TLDR is that you need to create the WireGuard interface in the namespace you wish for the outer packets to be bound to, and then move it to the namespace you wish the inner packets to be in, which can be the `init` namespace if you desire.

Cheers,
Steven

On Fri, 24 Jan 2020, at 11:03 AM, Daniele Orlandi wrote:
> 
> Hello,
> 
> I'm attempting to route the WG tunnel traffic (not the inside traffic)
> on a VRF.
> 
> I was able to use an ip rule + fwmark to route outgoing packets to the
> proper VRF, however the incoming traffic *seems* to be rejected due to
> the UDP socket not being bound to an interface in the VRF.
> 
> 00:56:35.606766 IP 172.16.16.32.5180 > 45.66.80.144.5180: UDP, length 148
> 00:56:35.922547 IP 45.66.80.144.5180 > 172.16.16.32.5180: UDP, length 92
> 00:56:35.922680 IP 172.16.16.32 > 45.66.80.144: ICMP 172.16.16.32 udp
> port 5180 unreachable, length 128
> 
> 
> Is there any workaround you know of? Would you consider implementing
> binding to an interface like other tunnel interfaces do?
> 
> 
> (The infrastructure is already present by using the bind_ifindex field
> of udp_port_cfg passed to udp_sock_create)
> 
> Thank you,
> regards,
> 
> -- 
>   Daniele Orlandi
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Tunnel traffic in VRF

[Toke Høiland-Jørgensen]

"Steven Honson" <steven@honson.id.au> writes:

> Hi Daniele,
>
> By VRFs, do you mean Linux network namespaces, or something different?

VRFs are a separate feature from namespaces - see
https://cumulusnetworks.com/blog/vrf-for-linux/

-Toke
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Tunnel traffic in VRF

[Daniele Orlandi]

On 25/01/2020 07:55, Steven Honson wrote:
> Hi Daniele,
> 
> By VRFs, do you mean Linux network namespaces, or something different?

They are a different feature. In short VRFs are separate routing tables
to provide routing isolation. They are somewhat different with respect
to namespaces as the isolation is visible to userspace.

In the meantime I was able to find a workaround by setting the sysctl
variable:

net.ipv4.udp_l3mdev_accept=1

this way the socket that is created in the default VRF is automatically
visible in all VRFs.

A proper binding to the correct VRF would be a better approach, however.

Regards,

-- 
  Daniele Orlandi
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Tunnel traffic in VRF

[b13253]

On Sat, Jan 25, 2020 at 10:10 PM Daniele Orlandi <daniele@orlandi.com> wrote:
>
> On 25/01/2020 07:55, Steven Honson wrote:
> > Hi Daniele,
> >
> > By VRFs, do you mean Linux network namespaces, or something different?
>
> They are a different feature. In short VRFs are separate routing tables
> to provide routing isolation. They are somewhat different with respect
> to namespaces as the isolation is visible to userspace.

Hi Daniele,

VRF is different from network namespaces.

I have collected some materials about the VRF implementation of Linux:
- https://schd.ws/hosted_files/ossna2017/fe/vrf-tutorial-oss.pdf
(Slides introducing VRF)
- https://cumulusnetworks.com/blog/vrf-for-linux/ (Article describing
the differences among VRF, ip rule, and namespace)
Hope they help.

Best regards,
StarBrilliant
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Tunnel traffic in VRF

[Serge]

[-- Attachment #1.1: Type: text/plain, Size: 728 bytes --]

On Sat, 25 Jan 2020 at 14:24, Daniele Orlandi <daniele@orlandi.com> wrote:
> A proper binding to the correct VRF would be a better approach, however.

On user-level it can be done by SO_BINDTODEVICE socket option:

«Applications that are to work within a VRF need to bind their socket to
the VRF device:
    setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);
»

But I am not sure how things work on kernel level.

It would be great to add an option like 'listen-interfaces':

wg set <interface> [listen-port <port>] [listen-interfaces
<interface1>[,<interface2>]... ]

[Interface]
ListenPort=54002
ListenInterfaces=vrf-red,vrf-green

This option can be useful in a non-VRF environment too.

[-- Attachment #1.2: Type: text/html, Size: 869 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard