* Tunnel traffic in VRF
@ 2020-01-24 0:03 Daniele Orlandi
2020-01-25 6:55 ` Steven Honson
0 siblings, 1 reply; 6+ messages in thread
From: Daniele Orlandi @ 2020-01-24 0:03 UTC (permalink / raw)
To: WireGuard
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tunnel traffic in VRF
2020-01-24 0:03 Tunnel traffic in VRF Daniele Orlandi
@ 2020-01-25 6:55 ` Steven Honson
2020-01-25 9:13 ` Toke Høiland-Jørgensen
2020-01-25 14:10 ` Daniele Orlandi
0 siblings, 2 replies; 6+ messages in thread
From: Steven Honson @ 2020-01-25 6:55 UTC (permalink / raw)
To: wireguard
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tunnel traffic in VRF
2020-01-25 6:55 ` Steven Honson
@ 2020-01-25 9:13 ` Toke Høiland-Jørgensen
2020-01-25 14:10 ` Daniele Orlandi
1 sibling, 0 replies; 6+ messages in thread
From: Toke Høiland-Jørgensen @ 2020-01-25 9:13 UTC (permalink / raw)
To: Steven Honson, wireguard
"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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tunnel traffic in VRF
2020-01-25 6:55 ` Steven Honson
2020-01-25 9:13 ` Toke Høiland-Jørgensen
@ 2020-01-25 14:10 ` Daniele Orlandi
2020-01-25 16:03 ` b13253
2020-01-26 19:46 ` Serge
1 sibling, 2 replies; 6+ messages in thread
From: Daniele Orlandi @ 2020-01-25 14:10 UTC (permalink / raw)
To: wireguard
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tunnel traffic in VRF
2020-01-25 14:10 ` Daniele Orlandi
@ 2020-01-25 16:03 ` b13253
2020-01-26 19:46 ` Serge
1 sibling, 0 replies; 6+ messages in thread
From: b13253 @ 2020-01-25 16:03 UTC (permalink / raw)
To: wireguard
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tunnel traffic in VRF
2020-01-25 14:10 ` Daniele Orlandi
2020-01-25 16:03 ` b13253
@ 2020-01-26 19:46 ` Serge
1 sibling, 0 replies; 6+ messages in thread
From: Serge @ 2020-01-26 19:46 UTC (permalink / raw)
To: wireguard
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-30 2:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-24 0:03 Tunnel traffic in VRF Daniele Orlandi
2020-01-25 6:55 ` Steven Honson
2020-01-25 9:13 ` Toke Høiland-Jørgensen
2020-01-25 14:10 ` Daniele Orlandi
2020-01-25 16:03 ` b13253
2020-01-26 19:46 ` Serge
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).