Wireguard with IPv6 not working as expected

Have some feedback, questions, suggestions, or just fancy a chat? Pop it in here.
User avatar
Joulinar
Posts: 4802
Joined: Sat Nov 16, 2019 12:49 am

Re: Wireguard with IPv6 not working as expected

Post by Joulinar »

are you using same IP range for VPN as for the local network?
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Sibbefufzich
Posts: 17
Joined: Mon Jan 18, 2021 6:12 pm

Re: Wireguard with IPv6 not working as expected

Post by Sibbefufzich »

Joulinar wrote: Tue Jan 19, 2021 9:22 pm are you using same IP range for VPN as for the local network?
As I now am getting more and more confused: yes? :D

My LAN is 192.168.0.0/24. DietPi wg server is static 192.168.0.3 and I assign in wireguard 192.168.0.5/32 for the client.
User avatar
Joulinar
Posts: 4802
Joined: Sat Nov 16, 2019 12:49 am

Re: Wireguard with IPv6 not working as expected

Post by Joulinar »

can you share ip a
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Sibbefufzich
Posts: 17
Joined: Mon Jan 18, 2021 6:12 pm

Re: Wireguard with IPv6 not working as expected

Post by Sibbefufzich »

Result of ip a

Code: Select all

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:33:85:cb brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.3/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 **ipv6**:85cb/64 scope global dynamic mngtmpaddr
       valid_lft 172799sec preferred_lft 86399sec
    inet6 fe80::dea6:32ff:fe33:85cb/64 scope link
       valid_lft forever preferred_lft forever
12: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 192.168.0.3/24 scope global wg0
       valid_lft forever preferred_lft forever
User avatar
Joulinar
Posts: 4802
Joined: Sat Nov 16, 2019 12:49 am

Re: Wireguard with IPv6 not working as expected

Post by Joulinar »

you have assigned same ip 192.168.0.3/24 to eth0 as well as wg0. That's very bad idea. ;)

Usually VPN should have an own IP range. Use 10.9.0.1/24 as server address and 10.9.0.2/24 for first client
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
User avatar
trendy
Posts: 309
Joined: Tue Feb 25, 2020 2:54 pm

Re: Wireguard with IPv6 not working as expected

Post by trendy »

First of all the wireguard doesn't bridge, you must use a different subnet for the tunnel than the one you use in your lan.
The second thing is that this subnet must be advertised in the lan, as only the dietpi knows about it. Either a static route on the ISP router or SNAT on the dietpi (but this means only wg->lan communication). With some DNATs on dietpi you can achieve a few ports forwarded from lan to wg clients, if needed.
Sibbefufzich wrote: Tue Jan 19, 2021 9:20 pm Sorry, I still don't quite understand. If I take the subnet I get from using 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 -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.
The lan and the wg must be different subnets, not the same. Just like with IPv4. And since the smallest prefix in IPv6 is /64, you need to use a different /64 than the one you have in lan.
Sibbefufzich
Posts: 17
Joined: Mon Jan 18, 2021 6:12 pm

Re: Wireguard with IPv6 not working as expected

Post by Sibbefufzich »

Sorry guys, was very busy today. Just had the time to test your suggestions.
Joulinar wrote: Tue Jan 19, 2021 10:03 pm you have assigned same ip 192.168.0.3/24 to eth0 as well as wg0. That's very bad idea. ;)

Usually VPN should have an own IP range. Use 10.9.0.1/24 as server address and 10.9.0.2/24 for first client
Okay, that seems logical. Don't know what I thought, setting it up like that. Unfortunately changing it to the IPs suggested by you doesn't solve the problem. A connection is still established, I still see queries in PiHole and can still ssh into the Pi from my client.

However, things changed when I try to ping the client.

Trying to ping from the DietPi:

Code: Select all

PING 10.9.0.2 (10.9.0.2) 56(84) bytes of data.
64 bytes from 10.9.0.2: icmp_seq=1 ttl=64 time=318 ms
64 bytes from 10.9.0.2: icmp_seq=2 ttl=64 time=21.1 ms
64 bytes from 10.9.0.2: icmp_seq=3 ttl=64 time=4.00 ms
64 bytes from 10.9.0.2: icmp_seq=4 ttl=64 time=4.23 ms
64 bytes from 10.9.0.2: icmp_seq=5 ttl=64 time=4.06 ms
--> Great success! :D

Trying to ping from machine in lan:

Code: Select all

PING 10.9.0.2 (10.9.0.2): 56 data bytes
92 bytes from 84.116.198.94: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 c2f9   0 0000  3f  01 edb3 192.168.0.73  10.9.0.2

Request timeout for icmp_seq 0
92 bytes from 84.116.198.94: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 05a6   0 0000  3f  01 ab07 192.168.0.73  10.9.0.2

Request timeout for icmp_seq 1
92 bytes from 84.116.198.94: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 1a88   0 0000  3f  01 9625 192.168.0.73  10.9.0.2

Request timeout for icmp_seq 2
92 bytes from 84.116.198.94: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 53a6   0 0000  3f  01 5d07 192.168.0.73  10.9.0.2

Request timeout for icmp_seq 3
92 bytes from 84.116.198.94: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 f9b4   0 0000  3f  01 b6f8 192.168.0.73  10.9.0.2
I guess that's because I'm on another subnet?(I REALLY have to read up subnetting again)

....aaaaand as I wrote I simultaneously tried to load a website again and it worked. Don't know why it first did nothing but it seems, ditching the assignment of internal IPv6 and choosing the right IPv4 subnet was the solution. Classic case of thinking too complicated.

Big thanks to @trendy and @Joulinar, you guys rock!

One additional question regarding choosing the right subnet: When I first played with a Raspi/Wireguard setup, I had an ISP with IPv4. The LAN was 192.168.2.0/24. The Raspi had static 192.168.2.111 and I assigned 192.168.2.180/24 for wg0, with clients going from 192.168.2.181/32 counting up. This worked flawless.....why? If overlapping eth0 and wg0 subnets is such a big deal (as we saw in my problem here), why did it work then?
User avatar
Joulinar
Posts: 4802
Joined: Sat Nov 16, 2019 12:49 am

Re: Wireguard with IPv6 not working as expected

Post by Joulinar »

basically it's 2 different networks with 2 different interfaces. where does the system should know to which interface to sent packages as the ip range is the same? In fact the VPN server is doing a routing between networks and not a bridging :)

And if you use dietpi-software to setup WireGuard, you would get correct implementation already ;)

And doing a ping from your local network towards the VPN will work only if you tell your local network where to sent packages for the VPN to. Usually all packages are sent to your router and the router will most probably sent it to the internet. But you would need to setup a route inside the router to push packages to your VPN server for the VPN IP range.

This is how it looks on my privat network if I try to ping my WireGuard server locally.

Code: Select all

>ping 10.9.0.1

Pinging 10.9.0.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.9.0.1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
It's failing same way as on you network, because my router simply doesn't know what to do.

But it change if I setup a static route like this.

picture.PNG

Now, success ;)

Code: Select all

>ping 10.9.0.1

Pinging 10.9.0.1 with 32 bytes of data:
Reply from 10.9.0.1: bytes=32 time=21ms TTL=64
Reply from 10.9.0.1: bytes=32 time=7ms TTL=64
Reply from 10.9.0.1: bytes=32 time=10ms TTL=64
Reply from 10.9.0.1: bytes=32 time=13ms TTL=64

Ping statistics for 10.9.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 7ms, Maximum = 21ms, Average = 12ms
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Post Reply