eBPF + IPv6 + WireGuard

[Alex <wireguard@centromere.net>]

Hi all,

I am championing WireGuard at work, and I have been granted permission
to use it for establishing remote access to a private IPv6 VLAN for all
employees. I have experimented with different approaches and ran in to
an issue.

With the help of a machine dedicated fully to the job of remote access
(Ubuntu 20.04 / Linux 5.4), I've managed to establish end-to-end
connectivity between my work laptop and the servers. The VPN gateway
has a wg0 interface for employees and a "private0" interface for
private VLAN connectivity. The goal is to link the two.

I noticed an odd quirk: It only works when
"net.ipv6.conf.all.forwarding" is 1. If this value is 0,
"net.ipv6.conf.[wg0 | private0].forwarding" has no effect. In other
words, I cannot seem to enable forwarding for *only* the interfaces
that need it. It only works when forwarding is enabled for *all*
interfaces. This is a problem because when the "all" value is set to 1,
the machine will start to behave as a router on VLANs for which it is
most definitely not a router.

For the servers, I am using the officially defined[0] subnet-router
anycast address as the default IPv6 gateway, and it works well.
However, when I flipped the switch on "net.ipv6.conf.all.forwarding",
the VPN gateway started using NDP to announce that it was a router
across *all* VLANs! Specifically, it was claiming ownership over our
global subnet anycast address 2001:aaaa:bbbb:cccc::. This is neither
true nor desired. The VPN gateway started to receive outbound non-VPN
Internet traffic which broke Internet connectivity for all servers. 

This leads me to my first question: Why does
"net.ipv6.conf.wg0.forwarding" have no effect?

In researching a solution, I decided to give eBPF a try. I attached an
XDP program to "private0" (a layer 2 device, naturally) and
successfully redirected packets to "wg0" (a layer 3 device) with
bpf_redirect[1]. If the packets are unmodified, WireGuard will happily
pass them to the remote hosts. This is an issue because the remote
hosts are expecting to receive IP(v6) packets, not Ethernet frames. If
I use bpf_xdp_adjust_head[1] to strip off the Ethernet frame, WireGuard
will drop the packet[2] before it can be sent to the remote host.

My theory is that bpf_xdp_adjust_head is modifying the data pointer
only and not any underlying structures that may be associated with the
packet (sk_buff perhaps).

This leads me to my second question: Why can't I redirect traffic
received on an L2 interface to an L3 interface, *even after stripping
off the Ethernet frame?*

Finally, during this whole process I was using WireShark to inspect
traffic received by the remote host (i.e. my work laptop). With the
help of the extract-handshakes.sh script, I was able to decrypt traffic.
I did discover a bug though. I believe "index_hashtable_insert" should
actually be "wg_index_hashtable_insert"[3].

Does anyone have any insights as to what a proper solution would look
like? Is there a way to achieve my goal without introducing eBPF? Is
XDP completely unsuited for this particular purpose? Do I actually need
to operate on the sk_buff level, as opposed to the xdp_buff level?

Thank you all for your time.

 - Alex

[0] https://datatracker.ietf.org/doc/rfc1884/ (Section 2.5.1)
[1] https://www.man7.org/linux/man-pages/man7/bpf-helpers.7.html
[2] https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/device.c#n131
[3] https://git.zx2c4.com/wireguard-tools/tree/contrib/extract-handshakes/extract-handshakes.sh#n46