Wireguard Neighborhood (IPv6)

Wireguard Neighborhood (IPv6)

[tlhackque]

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

TLDR; It seems that WireGuard isn't supporting IPv6 NDP, and it should. 
Use case & a work-around.

Full story:

Configuration:

WireGuard server (Linux, details below) behind a site router that
handles IPv4 NAT & an IPv6 tunnel.

Server LAN has other hosts (and multiple subnets/vlans) - mostly dual stack.

The WireGuard server is able to access the WireGuard peers (clients)
over IPv6.  The other hosts (and the router) are not.

The clients can't even ping the other hosts - the echo replies are
generated, but they end up with an icmp6 unreachable.

It turns out that the other hosts (and router) send an icmp6 Neighbor
Solicitation for the clients, which is never answered.

My interim solution was to implement
https://github.com/setaou/ndp-proxy, which will respond with Neighbor
Advertisements for the entire WireGuard subnet.

This is a rather crude solution - since ndp-proxy doesn't know what
clients are connected, and since it requires one proxy process/wg interface.

It seems to me that WireGuard (in this case on the server) should at
least be responding to Neighbor Solicitations for AllowedIPs of its
active peers... Of course in the case of a WireGuard tunnel between two
such sites, this is symmetric.

I did look at net.ipv6.conf.*.proxy_ndp, but that requires adding each
address - and in any case I couldn't get it to work.  Neither did
advertising the server as a "router" with radvd.

Unless I'm missing something, it seems to me that supporting NDP is the
simplest "it just works" approach in any case...

wireguard-tools v1.0.20210424 - https://git.zx2c4.com/wireguard-tools/

Linux hagrid 5.13.16-200.fc34.x86_64 #1 SMP Mon Sep 13 12:39:36 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: Wireguard Neighborhood (IPv6)

[Jeroen Massar]

If you have something like the very common setup:

{internet} -> [wgserver] -> [wgclient] -> [local LAN]

Then if you have address space routed to wgserver, just route a /64 to wgclient and then normally radvd(&dhcpv6) it, done.

If you only have a single /64 on the server, then indeed you need to hack around with ndproxy.

But given that ISPs have near infinite IPv6 space... they should be able to route you a simple /64 and technically, from a RIR perspective should even be doing minimal /56 or even a /48...

Greets,
 Jeroen

--

> On 20210924, at 17:31, tlhackque <tlhackque@yahoo.com> wrote:
> 
> TLDR; It seems that WireGuard isn't supporting IPv6 NDP, and it should. 
> Use case & a work-around.
> 
> Full story:
> 
> Configuration:
> 
> WireGuard server (Linux, details below) behind a site router that
> handles IPv4 NAT & an IPv6 tunnel.
> 
> Server LAN has other hosts (and multiple subnets/vlans) - mostly dual stack.
> 
> The WireGuard server is able to access the WireGuard peers (clients)
> over IPv6.  The other hosts (and the router) are not.
> 
> The clients can't even ping the other hosts - the echo replies are
> generated, but they end up with an icmp6 unreachable.
> 
> It turns out that the other hosts (and router) send an icmp6 Neighbor
> Solicitation for the clients, which is never answered.
> 
> My interim solution was to implement
> https://github.com/setaou/ndp-proxy, which will respond with Neighbor
> Advertisements for the entire WireGuard subnet.
> 
> This is a rather crude solution - since ndp-proxy doesn't know what
> clients are connected, and since it requires one proxy process/wg interface.
> 
> It seems to me that WireGuard (in this case on the server) should at
> least be responding to Neighbor Solicitations for AllowedIPs of its
> active peers... Of course in the case of a WireGuard tunnel between two
> such sites, this is symmetric.
> 
> I did look at net.ipv6.conf.*.proxy_ndp, but that requires adding each
> address - and in any case I couldn't get it to work.  Neither did
> advertising the server as a "router" with radvd.
> 
> Unless I'm missing something, it seems to me that supporting NDP is the
> simplest "it just works" approach in any case...
> 
> wireguard-tools v1.0.20210424 - https://git.zx2c4.com/wireguard-tools/
> 
> Linux hagrid 5.13.16-200.fc34.x86_64 #1 SMP Mon Sep 13 12:39:36 UTC 2021
> x86_64 x86_64 x86_64 GNU/Linux
> 
> 

Re: Wireguard Neighborhood (IPv6)

[Roman Mamedov]

On Fri, 24 Sep 2021 11:31:40 -0400
tlhackque <tlhackque@yahoo.com> wrote:

> WireGuard server (Linux, details below) behind a site router that
> handles IPv4 NAT & an IPv6 tunnel.
> 
> Server LAN has other hosts (and multiple subnets/vlans) - mostly dual stack.
> 
> The WireGuard server is able to access the WireGuard peers (clients)
> over IPv6.  The other hosts (and the router) are not.
> 
> The clients can't even ping the other hosts - the echo replies are
> generated, but they end up with an icmp6 unreachable.
> 
> It turns out that the other hosts (and router) send an icmp6 Neighbor
> Solicitation for the clients, which is never answered.
> 
> My interim solution was to implement
> https://github.com/setaou/ndp-proxy, which will respond with Neighbor
> Advertisements for the entire WireGuard subnet.
> 
> This is a rather crude solution - since ndp-proxy doesn't know what
> clients are connected, and since it requires one proxy process/wg interface.
> 
> It seems to me that WireGuard (in this case on the server) should at
> least be responding to Neighbor Solicitations for AllowedIPs of its
> active peers... Of course in the case of a WireGuard tunnel between two
> such sites, this is symmetric.
> 
> I did look at net.ipv6.conf.*.proxy_ndp, but that requires adding each
> address - and in any case I couldn't get it to work.  Neither did
> advertising the server as a "router" with radvd.
> 
> Unless I'm missing something, it seems to me that supporting NDP is the
> simplest "it just works" approach in any case...

You are not configuring your network correctly routing-wise, and the issue is
not "WireGuard not supporting NDP" -- yes it doesn't, but that's not the point
to blame for the behavior that you observe -- which is completely normal.

Server LAN is one L2 network, the WG network is *another* and L3 network.
There is nothing nowhere that dictates that there would be NDP replies
*across* separate networks, let alone L2 vs L3.

The WG network needs its own separate IPv6 range, and other hosts need to have
a route to that range "via" the VPN server (if its not their default gateway).
Then, the WG clients need to know the route back to those other hosts, i.e.
the network they use needs to be in AllowedIPs for the VPN server.

-- 
With respect,
Roman