Wireguard with IPv6 not working as expected

[Sibbefufzich]

Hey everyone,

for the sake of completeness: I already started a Discussion of this topic on Reddit: https://www.reddit.com/r/WireGuard/comm ... king_post/ and hijacked another discussion in the DietPi Forum: viewtopic.php?f=9&t=8537
However, I start from the beginning:

I run Dietpi on a Raspi with PiHole set up and working fine.

Next step was to set up Wireguard to have PiHole functionality and access to LAN on the go. My ISP provides only DS Lite, so just having IPv6 was the first problem for me (IPv4 is so much easier to understand). However, i managed to get a connection from WAN via Wireguard to the Dietpi with these configs:

Code: Select all

[Interface]
Address = 192.168.0.3/24, fe80::dea6:32ff:fe33:85cb/64
PrivateKey = *Key*
ListenPort = 51902

PreUp = /boot/dietpi/func/obtain_network_details
PostUp = sysctl net.ipv4.conf.%i.forwarding=1 net.ipv4.conf.$(mawk 'NR==3' /run/dietpi/.network).forwarding=1
PostUp = sysctl net.ipv6.conf.$(mawk 'NR==3' /run/dietpi/.network).accept_ra=2
PostUp = sysctl net.ipv6.conf.%i.forwarding=1 net.ipv6.conf.$(mawk 'NR==3' /run/dietpi/.network).forwarding=1
PostUp = ip neigh add proxy fe80::dea6:32ff:fe33:85c2 dev eth0
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o $(mawk 'NR==3' /run/dietpi/.network) -j MASQUERADE
PostUp = ip6tables -A FORWARD -i %i -j ACCEPT; ip6tables -t nat -A POSTROUTING -o $(mawk 'NR==3' /run/dietpi/.network) -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o $(mawk 'NR==3' /run/dietpi/.network) -j MASQUERADE
PostDown = ip6tables -D FORWARD -i %i -j ACCEPT; ip6tables -t nat -D POSTROUTING -o $(mawk 'NR==3' /run/dietpi/.network) -j MASQUERADE

# Client 1
[Peer]
PublicKey = *Key*
AllowedIPs = 192.168.0.5/32, fe80::dea6:32ff:fe33:85c2/128

Client.conf:

Code: Select all

[Interface]
Address = 192.168.0.5/32, fe80::dea6:32ff:fe33:85c2/128
PrivateKey = *Key*
DNS = fe80::dea6:32ff:fe33:85cb, 192.168.0.3

[Peer]
PublicKey = *Key*
Endpoint = *correct-ipv6-address*:51902
AllowedIPs = 0.0.0.0/0, ::/0

My sysctl.conf looks like this:

Code: Select all

net.ipv6.conf.all.accept_ra = 2
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.wg0.accept_ra = 2
net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1

net.ipv6.conf.all.proxy_ndp = 1
net.ipv6.conf.eth0.proxy_ndp=1
ip neigh add proxy fe80::dea6:32ff:fe33:85c2 dev fe80::dea6:32ff:fe33:85cb

So by checking with the wg command a connection is established, as well as PiHole queries indicate that DNS requests are being made, so routing doesn't seem to be the problem. However, no packets seem to get through (or just not back?) because whenever i test the connection by trying to load a website, I always get a "server stopped responding" message.

sudo wg gives this:

Code: Select all

  endpoint: *public IPv6*:51393
  allowed ips: 192.168.0.5/32, fe80::dea6:32ff:fe33:85c2/128
  latest handshake: 42 seconds ago
  transfer: 50.75 KiB received, 1.02 KiB sent

wg setconf wg0 wg0.conf gives:

Code: Select all

Line unrecognized: `Address=192.168.0.3/24,fe80::dea6:32ff:fe33:85cb/64'
Configuration parsing error

I also thought that maybe my choice of private IPv6 was wrong, but then PiHole wouldn't show queries from that IP....I guess.

@trendy and @Joulinar noted in the other DietPi Forum Thread that if I have or had Docker installed, it might be a problem, however I never had Docker installed.

So, that's my problem with I hope nearly all information required given. Let the trouble shooting begin

[trendy]

First of all the address you are using is link local, it cannot be routed. Use a ULA address for example fddd:aaaa:bbbb::/48 for the whole site and assign a /64 for the tunnel.
Or if you have a prefix delegated from the provider you can use from that.
In case you use the ULA, then NAT6 is necessary to access the internet.
If you use GUA from the delegated prefix, then no NAT is necessary, just to make sure that the ISP router has a route for it via your dietpi.

[Sibbefufzich]

Ok, so now my absolute absence of IPv6 knowledge comes to light.
Honestly, the choice of the internal IPv6 adress for the client came from the DietPi. I took the IPv6 adress of it and just changed the last digit. Seemed like a good idea, especially because I was able to even establish the connection after that.

I will be able to test your supposed IPv6 use later but for now, do I understand correctly that I can use the prefix delegated from my ISP used for the Wireguard Server as the "Allowed IP" in the client setting?
It MAY be that then the router won't be too happy with it, as it is the one given from my ISP with very limited settings but I will see when I'm able to test it later.

[trendy]

Yes, you can use a subnet of the delegated prefix for the wg tunnel.
Ideally dietpi should request a delegated prefix from the ISP router, which then will be used in the tunnel. This however has a few drawbacks, especially in case the prefix you have from the ISP is not static. Then you'd have to change it somehow, or use the ULA and NAT6.

[Joulinar]

is there a strong need to use IPv6?

[Sibbefufzich]

Ok now I can try it out a bit.

@Joulinar Yes, my ISP only provides DS Lite, so no IPv4 unfortunately.

So i tried to use the dietpi subnet with the ISP prefix I got by using

Code: Select all

ip addr

and then taking from eth0 the /64 inet6 address whereafter it said "scope global dynamic mngtmpaddr".

I used this address as IPv6 address in the "Interface" section of my wg0.conf and in the "Peer" section for "Allowed IPs" I used the same address, but with the last digit changed and with /128. (Here I think may be an logic error on my side as I not quite understand IPv6 yet)

In the wg0-client.conf I then used the same /128 IP in the "Interface" section, but still using the local IPv6 for DNS (which I think makes sense so I don't route the DNS lookup over WAN back to my DietPi)


This whole setup "worked" in the way that I still could connect, PiHole still showed queries but the problem remains the same, no packets coming back to my client, wg shows:

Code: Select all

transfer: 29.15 KiB received, 468 B sent

[Joulinar]

if you have a windows box, you could use wireshark to check what and if packages are arriving

[trendy]

I used this address as IPv6 address in the "Interface" section of my wg0.conf and in the "Peer" section for "Allowed IPs" I used the same address, but with the last digit changed and with /128. (Here I think may be an logic error on my side as I not quite understand IPv6 yet)

In the wg0-client.conf I then used the same /128 IP in the "Interface" section, but still using the local IPv6 for DNS (which I think makes sense so I don't route the DNS lookup over WAN back to my DietPi)

This is not how I meant to delegate a prefix. You cannot assign IPs from the lan into the wg.It has to be a separate network.
E.g if lan is 2001:aaaa:bbbb:ccc0::/64 you could ask from the ISP router a prefix for delegation by dhcp6 client and let's say it assigns you 2001:aaaa:bbbb:ccc1::/64 , that can be assigned to the wg.

[Joulinar]

I need to say, I don't use IPv6 at all. Therefore the question might be useless. But would it be possible to work inside the local network using IPv4. The IPv6 connection is between mobile device and the router, and inside the VPN tunnel, IPv4 is used?

[Sibbefufzich]

Hey guys,

sorry I wasn't able to play with the problem as I was preoccupied with other things...

@Joulinar, Interesting approach. Tried that, just commenting out the IPv6 addresses (except the Endpoint one in the client.conf, this obviously needs to stay IPv6). And.....it worked. Well, at least it worked the same as before. So, connection is established, I can ssh into the pi from the wg client and PiHole on the server sees queries, but no packets get through.
I also tried to ping the wg client (192.168.0.5) with a machine on LAN and with the DietPi wg server Raspi

On the machine on LAN, I got

Code: Select all

Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down
Request timeout for icmp_seq 6
ping: sendto: Host is down
Request timeout for icmp_seq 7
ping: sendto: Host is down
Request timeout for icmp_seq 8
^Xping: sendto: Host is down
Request timeout for icmp_seq 9
ping: sendto: Host is down
Request timeout for icmp_seq 10

and on the DietPi

Code: Select all

PING 192.168.0.5 (192.168.0.5) 56(84) bytes of data.
From 192.168.0.3 icmp_seq=1 Destination Host Unreachable
From 192.168.0.3 icmp_seq=2 Destination Host Unreachable
From 192.168.0.3 icmp_seq=3 Destination Host Unreachable
From 192.168.0.3 icmp_seq=4 Destination Host Unreachable
From 192.168.0.3 icmp_seq=5 Destination Host Unreachable
From 192.168.0.3 icmp_seq=6 Destination Host Unreachable
From 192.168.0.3 icmp_seq=7 Destination Host Unreachable
From 192.168.0.3 icmp_seq=8 Destination Host Unreachable
From 192.168.0.3 icmp_seq=9 Destination Host Unreachable
From 192.168.0.3 icmp_seq=10 Destination Host Unreachable
From 192.168.0.3 icmp_seq=11 Destination Host Unreachable

which I don't understand because PiHole sees the queries. I'm pretty confused now.

Edit:

This is not how I meant to delegate a prefix. You cannot assign IPs from the lan into the wg.It has to be a separate network.
E.g if lan is 2001:aaaa:bbbb:ccc0::/64 you could ask from the ISP router a prefix for delegation by dhcp6 client and let's say it assigns you 2001:aaaa:bbbb:ccc1::/64 , that can be assigned to the wg.

Sorry, I still don't quite understand. If I take the subnet I get from using

Code: Select all

ip addr

on the dietpi, am I not in a different subnet than the LAN? (My ISP delegates a /59 network, of which LAN uses the /64 of the prefix (again, not sure if I understand this IPv6 stuff correctly) which again is narrowed down as - following my understanding -

Code: Select all

ip addr

shows.

I get the feeling that I should relearn subnetting, after rereading what I just wrote something feels off. Please tell me, so I can try to read up subnetting again.