Wireguard VPN handshake successful but no traffic/ ping

Support Network
,
1

Disclosure: I have posted the same question already on StackExchange, but since I am not getting any answers there and using Manjaro, I post it here as well. Hope that it’s okay-ish.

I have set up WireGuard VPN on my router (FritzBox) and added the VPN config to my Manjaro Gnome notebook.
My router in the LAN at home is available on 192.168.0.1.

[Interface]
PrivateKey = xxxx
Address = 192.168.0.201/24
DNS = 192.168.0.1
DNS = fritz.box

[Peer]
PublicKey = xxx
PresharedKey = xxx
AllowedIPs = 192.168.0.0/24,0.0.0.0/0
Endpoint = xxx.myfritz.net:58130
PersistentKeepalive = 25

From the WireGuard logs that I found in the kernel, it seems like the handshake was successful.

sudo dmesg -wT | grep wireguard
[Mo, 16. Okt 2023, 00:43:25] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[Mo, 16. Okt 2023, 00:43:25] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[Mo, 16. Okt 2023, 00:55:29] wireguard: wg_config: Interface created
[Mo, 16. Okt 2023, 00:55:29] wireguard: wg_config: Peer 5 created
[Mo, 16. Okt 2023, 00:55:29] wireguard: wg_config: Sending keepalive packet to peer 5 ((einval))
[Mo, 16. Okt 2023, 00:55:29] wireguard: wg_config: Sending handshake initiation to peer 5 ((einval))
[Mo, 16. Okt 2023, 00:55:34] wireguard: wg_config: Peer 5 ((einval)) destroyed
[Mo, 16. Okt 2023, 00:55:34] wireguard: wg_config: Peer 6 created
[Mo, 16. Okt 2023, 00:55:34] wireguard: wg_config: Sending keepalive packet to peer 6 (remote-ip:58130)
[Mo, 16. Okt 2023, 00:55:34] wireguard: wg_config: Sending handshake initiation to peer 6 (remote-ip:58130)
[Mo, 16. Okt 2023, 00:55:35] wireguard: wg_config: Receiving handshake response from peer 6 (remote-ip:58130)
[Mo, 16. Okt 2023, 00:55:35] wireguard: wg_config: Keypair 2 created for peer 6
[Mo, 16. Okt 2023, 00:55:35] wireguard: wg_config: Receiving keepalive packet from peer 6 (remote-ip:58130)
[Mo, 16. Okt 2023, 00:55:45] wireguard: wg_config: Receiving keepalive packet from peer 6 (remote-ip:58130)
[Mo, 16. Okt 2023, 00:55:56] wireguard: wg_config: Receiving keepalive packet from peer 6 (remote-ip:58130)

But still I cannot access the page of my router or any other service in my LAN at home or even do a ping.
The request just time-out.

I’ve read that I need to check if there is a route to my router at 192.168.0.1 over the WireGuard interface, but to me, it seems like there is one:

ip route get 192.168.0.1                                         ✔ 
192.168.0.1 dev wg_config src 192.168.0.201 uid 1000 
    cache

Any idea what is going on there? Are there any additional logs / info that I can provide?
I know that this config works on a different PC.

Edit: Here is the output of sudo wg show while the VPN is active, but i think it doesn’t show anything surprising.

sudo wg show                                                     ✔ 
interface: wg_config
  public key: xxxx
  private key: (hidden)
  listening port: 51820
  fwmark: 0xcaed

peer: xxxx
  preshared key: (hidden)
  endpoint: public-ip:58130
  allowed ips: 192.168.0.0/24, 0.0.0.0/0
  latest handshake: 2 seconds ago
  transfer: 124 B received, 19.25 KiB sent
  persistent keepalive: every 25 seconds

Edit #2: Additional information

ip -br link; ip -br addr; ip route; ip rule                                                                        ✔ 
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
wlp0s20f3        UP             34:7d:f6:8e:6e:a3 <BROADCAST,MULTICAST,UP,LOWER_UP> 
virbr0           DOWN           52:54:00:1b:79:e3 <NO-CARRIER,BROADCAST,MULTICAST,UP> 
br-b70272889e99  DOWN           02:42:cf:67:52:3b <NO-CARRIER,BROADCAST,MULTICAST,UP> 
docker0          DOWN           02:42:cf:d9:9e:e6 <NO-CARRIER,BROADCAST,MULTICAST,UP> 
wg_config        UNKNOWN        <POINTOPOINT,NOARP,UP,LOWER_UP> 
lo               UNKNOWN        127.0.0.1/8 ::1/128 
wlp0s20f3        UP             192.168.0.62/24 fe80::a493:410e:53d0:9d48/64 
virbr0           DOWN           192.168.122.1/24 
br-b70272889e99  DOWN           172.26.1.1/24 
docker0          DOWN           172.26.0.1/24 
wg_config        UNKNOWN        192.168.0.201/24 
default via 192.168.0.1 dev wlp0s20f3 proto dhcp src 192.168.0.62 metric 600 
default via 192.168.0.1 dev wg_config proto static metric 20050 
172.26.0.0/24 dev docker0 proto kernel scope link src 172.26.0.1 linkdown 
172.26.1.0/24 dev br-b70272889e99 proto kernel scope link src 172.26.1.1 linkdown 
192.168.0.0/24 dev wg_config proto static scope link metric 50 
192.168.0.0/24 dev wg_config proto kernel scope link src 192.168.0.201 metric 50 
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.62 metric 600 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 
0:	from all lookup local
30960:	from all lookup main suppress_prefixlength 0
30961:	not from all fwmark 0xcaed lookup 51949
32766:	from all lookup main
32767:	from all lookup default

ip route show table 0                                                                                              ✔ 
default dev wg_config table 51949 proto static scope link metric 20050 
default via 192.168.0.1 dev wlp0s20f3 proto dhcp src 192.168.0.62 metric 600 
default via 192.168.0.1 dev wg_config proto static metric 20050 
172.26.0.0/24 dev docker0 proto kernel scope link src 172.26.0.1 linkdown 
172.26.1.0/24 dev br-b70272889e99 proto kernel scope link src 172.26.1.1 linkdown 
192.168.0.0/24 dev wg_config proto static scope link metric 50 
192.168.0.0/24 dev wg_config proto kernel scope link src 192.168.0.201 metric 50 
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.62 metric 600 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 172.26.0.1 dev docker0 table local proto kernel scope host src 172.26.0.1 
broadcast 172.26.0.255 dev docker0 table local proto kernel scope link src 172.26.0.1 linkdown 
local 172.26.1.1 dev br-b70272889e99 table local proto kernel scope host src 172.26.1.1 
broadcast 172.26.1.255 dev br-b70272889e99 table local proto kernel scope link src 172.26.1.1 linkdown 
local 192.168.0.62 dev wlp0s20f3 table local proto kernel scope host src 192.168.0.62 
local 192.168.0.201 dev wg_config table local proto kernel scope host src 192.168.0.201 
broadcast 192.168.0.255 dev wlp0s20f3 table local proto kernel scope link src 192.168.0.62 
broadcast 192.168.0.255 dev wg_config table local proto kernel scope link src 192.168.0.201 
local 192.168.122.1 dev virbr0 table local proto kernel scope host src 192.168.122.1 
broadcast 192.168.122.255 dev virbr0 table local proto kernel scope link src 192.168.122.1 linkdown 
fe80::/64 dev wlp0s20f3 proto kernel metric 1024 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::a493:410e:53d0:9d48 dev wlp0s20f3 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev wlp0s20f3 table local proto kernel metric 256 pref medium

Edit #3: I also tried changing the “remote” LAN subnet to 192.168.1.0/24 just in case that overlapping networks are somehow the problem, but this didn’t change the situation, unfortunately.

3

This is not going to work. Are you trying your wiregard connection from inside your own network or a network that uses the same address space as your Home network?

4

Yes indeed my remote network was also using 192.168.0.0/24.
I didn’t know that it is a requirement for WireGuard to work, that those networks don’t overlap.
Luckily i was able to change the network config, so that it’s now 192.168.1.0/24 and ip route returns this:

default dev wg_config table 51949 proto static scope link metric 20050 
default via 192.168.1.1 dev wlp0s20f3 proto dhcp src 192.168.1.58 metric 600 
default via 192.168.0.1 dev wg_config proto static metric 20050 
172.26.0.0/24 dev docker0 proto kernel scope link src 172.26.0.1 linkdown 
172.26.1.0/24 dev br-b70272889e99 proto kernel scope link src 172.26.1.1 linkdown 
192.168.0.0/24 dev wg_config proto static scope link metric 50 
192.168.0.0/24 dev wg_config proto kernel scope link src 192.168.0.201 metric 50 
192.168.1.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.1.58 metric 600 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 172.26.0.1 dev docker0 table local proto kernel scope host src 172.26.0.1 
broadcast 172.26.0.255 dev docker0 table local proto kernel scope link src 172.26.0.1 linkdown 
local 172.26.1.1 dev br-b70272889e99 table local proto kernel scope host src 172.26.1.1 
broadcast 172.26.1.255 dev br-b70272889e99 table local proto kernel scope link src 172.26.1.1 linkdown 
local 192.168.0.201 dev wg_config table local proto kernel scope host src 192.168.0.201 
broadcast 192.168.0.255 dev wg_config table local proto kernel scope link src 192.168.0.201 
local 192.168.1.58 dev wlp0s20f3 table local proto kernel scope host src 192.168.1.58 
broadcast 192.168.1.255 dev wlp0s20f3 table local proto kernel scope link src 192.168.1.58 
local 192.168.122.1 dev virbr0 table local proto kernel scope host src 192.168.122.1 
broadcast 192.168.122.255 dev virbr0 table local proto kernel scope link src 192.168.122.1 linkdown 
fe80::/64 dev wlp0s20f3 proto kernel metric 1024 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::a493:410e:53d0:9d48 dev wlp0s20f3 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev wlp0s20f3 table local proto kernel metric 256 pref medium

However, I have still no access to the internet or my home LAN.

Edit: Yeah maybe I should read the documentation from FritzBox more precisly. It says :

Set up an IP address to your FRITZ!Box that differs from the IP addresses of the routers you use to connect to the FRITZ!Box, for example 192.168.10.1 (subnet mask 255.255.255.0):

5

Your output does not look like a normal ip route . Which command did you really used? Or did you configured an alias for ip route .

Also which software do you use to set up the wiregurad tunnel on your Manjaro system? (The wg-quick Script, NM, …)

The first line looks unusual, but depending on the software to set it up, it might be correct. The second line is what I would expect.

6

Yeah you’re right, i was using ip route show table 0, sorry.
When I just do ip route the following appears:

ip route                                                                                  ✔ 
default via 163.13.62.254 dev wlp0s20f3 proto dhcp src 163.13.62.204 metric 600 
163.13.62.0/24 dev wlp0s20f3 proto kernel scope link src 163.13.62.204 metric 600 
172.26.0.0/24 dev docker0 proto kernel scope link src 172.26.0.1 linkdown 
172.26.1.0/24 dev br-b70272889e99 proto kernel scope link src 172.26.1.1 linkdown 
192.168.0.0/24 dev wg_config proto static scope link metric 50 
192.168.0.0/24 dev wg_config proto kernel scope link src 192.168.0.201 metric 50 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

I added the WireGuard configuration using Gnome settings, but I will try to do the same using wg-quick.

Edit:
Here is how it looks when I do the same using wg-quick:

wg-quick up fritzbox                                                               ✔  7s  
[#] ip link add fritzbox type wireguard
[#] wg setconf fritzbox /dev/fd/63
[#] ip -4 address add 192.168.0.201/24 dev fritzbox
[#] ip link set mtu 1420 up dev fritzbox
[#] resolvconf -a fritzbox -m 0 -x
[#] wg set fritzbox fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev fritzbox table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] nft -f /dev/fd/63

default via 163.13.62.254 dev wlp0s20f3 proto dhcp src 163.13.62.204 metric 600 
163.13.62.0/24 dev wlp0s20f3 proto kernel scope link src 163.13.62.204 metric 600 
172.26.0.0/24 dev docker0 proto kernel scope link src 172.26.0.1 linkdown 
172.26.1.0/24 dev br-b70272889e99 proto kernel scope link src 172.26.1.1 linkdown 
192.168.0.0/24 dev fritzbox proto kernel scope link src 192.168.0.201 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
7

No worries about the ip route output, it just did not looked like a normal output, so I asked.

The wg-quick output looks normal. Now, you would need to start checking with the wg command, if the connection is established. Also check the Firtzbox Webinterface if you see a green dot infront the wireguard connection name. Then start pinging the local IP 192.168.0.201 and the Fritzbox IP 192.168.0.1 (might be a different one.)

The Problem with Wireguard is, it usually works, if not, there is not much to debug. You can enable debug logs, but it is sometimes not that helpful. You can also play with the MTU, it can help, but it depends on your ISP.

8

The output from sudo wg looks pretty similiar to the output from sudo wg show which I already posted:

sudo wg                                                   ✔  9s  
interface: wg_config
  public key: xxxx
  private key: (hidden)
  listening port: 51820
  fwmark: 0xcaed

peer: xxx
  preshared key: (hidden)
  endpoint: remote-ip:58130
  allowed ips: 192.168.0.0/24, 0.0.0.0/0
  latest handshake: 25 seconds ago
  transfer: 156 B received, 34.35 KiB sent
  persistent keepalive: every 25 seconds

I am able to in 192.168.0.201, but not 192.168.0.1.
The debug logs unfortunately also show nothing new in comparison to the original post.
I have already played around with the MTU setting, but I will try again.

Edit: No luck with the MTU settings again. I lowered them all the way down to 900 in steps of 100, but it didn’t change anything.
This MTU checker script also showed me a MTU of 1472 to the remote IP of my WireGuard server.

9

Does the fritzbox indicate a successful connection? Because

is basically nothing. Which often means the wireguard connection is never successfully established. The wg (which by default outputs the same as wg show) command on the “client” can’t show if a wireguard tunnel is successfully connected to a different peer. The only indication if a tunnel is working, is to check the traffic on the transfer line.

10

I would like to check, but the problem is, that I currently don’t have access to the FritzBox.
But yeah, 156B is really not too much…
I will see what I can do.

11

This would be important. Btw., did the old IPsec VPN worked in the past with this ISP connection? The reason I asked, are you sure this Fritzbox is reachable from the outside via IPv4. Many Provider stopped handing out publicly routable IPv4 addresses and started using a Carrier-grade NAT. In these cases, the Fritzbox VPN doesn’t work via IPv4 and you would need to use IPv6 for the outside tunnel. IPv4 will be only used inside the tunnel.

12

The FritzBox is definitely reachable from outside using IPv4.
We specifically selected an ISP that still provides (dynamic) IPv4 addresses and doesn’t make use of CG-NAT or DsLite.
In fact, I can even ping my FritzBox using just the public IP address and reach a few publicly available web-services, as long as i have not turned on my Wireguard VPN.

I didn’t use the old IPsec VPN, because I was using a self-hosted OpenVPN server before.

13

So I checked (or had it checked) if the FritzBox is indicating a successful connection, and in fact, that’s not the case.
The small icon/ light left to the connection didn’t turn green, even if my system indicated that the handshake was successful (Connection is “Laurenz-Laptop”).
I am very confused how this can happen…

grafik
grafik2224×966 153 KB

14

This is an explanation why there is no traffic and ping is not working.

This might be complicated to debug. For example you could try a different client system, like an Android Phone or Windows system to see if it is a local problem with your Manjaro system. Just make sure the connection is made from the same network as your Manjaro System would do, for example the same Wifi or mobile Network.
Also if possible, try a different ISP network for your client. Often this kind of problem appears because some network drops packages. Also if possible, try using IPv6 for the tunnel outside, if available it is often much more reliable than the legacy IPv4. Unfortunately some networks are stuck in the past and modern technologies are not available.

1 Like
15

I do not use this software but am interested in the things discussed, but since the thread seems to have come to a halt, maybe I have an idea.

It is stated you need to separate the networks.
Networks seems to be configured to 192.168.0.0/24 (192.168.0.1-192.168.0.255) and 192.168.1.0/24 (192.168.1.1-192.168.1.255)
But on the picture from the web interface it states 192.168.0.202/32 and 192.168.0.201/32 (a smaller span although overlapping).

I have no idea If this is relevant, but maybe it will give you guys new ideas to go on?

16

Actually on the second test that I did, there was a connection made to the FritzBox that the FritzBox UI also confirmed (the icon turned green), but traffic/ ping was still not possible.

I already tried Wireguard on a Windows laptop and Android phone, but the results were the same.
Even the IPSec VPN (FritzBox legacy VPN option) showed exactly the same behaviour, so VPN connection was seemingly established, but traffic not possible.
But I definitely need to try out other networks, I just haven’t had the chance yet.

It seems like my IPS for the remote network doesn’t support IPv6 :confused:
But in general, is there a way to force WireGuard to use IPv6 in favour of IPv4?

17

I am no expert on IP networks, but as far as I know a /32 network basically means a single address, right?
So what we can see in the screenshot is just the address, that my VPN client gets assigned to in the local network (192.168.0.201 which is in the range of 192.168.0.0/24).
I don’t see an error there…

Anyways, I’ve also contacted the support of AVM to see if they can come up with an explanation.

18

Not directly. But if the DynDNS sub domain includes a AAAA (IPv6) record and the system has IPv6 connectivity, IPv6 is used. If the domain has just a A (IPv4) record, this one is used.
And of course for testing, you can put the IPv4 or IPv6 address directly in the wireguard config file. (The IPv6 address in the Endpoint line needs to be in square brackets , and only in this line.)

This is correct. This is used to indicate that only packages for this specific address are send thru the wireguard tunnel and not for example every package.

19

I don’t know about wireguard - so there is that.

In general terms of routing between network - the network adress ranges must be separate.

e.g. 172.16.16.0/24 and 172.16.17.0/24

For a VPN the route must be specified as the public IP address in front of the network

sampling

172.16.16.0/24 has public IP 88.88.88.1
172.16.17.0/24 has public IP 77.77.77.1

then you need to declare a route VIA the remote networks router address - commenly the .1

172.16.16.0/24 via 172.16.17.1
172.16.17.0/24 via 172.16.16.1

This should make it possible to reach ips within the remote network.

You won’t be able to reach a service by name - for that you need a dns service.

20

Can I ask why do you need separate routing table? What are you trying to achieve with this wg tunnel? Connect from outside to reach your LAN only or something else?

After you answer these questions we should probably go back to your wireguard settings on both sides and also your network settings in general, ie. iptables rules, etc.

Also using 192.168.0.0/24 (or similar, widely used subnets) as virtual wg network is confusing and in general a bad idea. Rather use something unconventional like 192.168.33.12/24 or 10.0.109.4/24 or similar.

1 Like
23

So i found out that my remote ISP doesn’t support IPv6 at all, but the remote mobile ISP does.
So I connected my laptop to the mobile phone, and it finally got an IPv6 address and the “ipv6-test.com” site reported IPv6 support :slight_smile:
The DynDNS domain did indeed include a AAAA record, so it used this value and put it into the Wireguard config file, but unfortunately the handshake was then not successful anymore.

Nov 12 15:04:18 laurenz-Yoga kernel: wireguard: wg_config: Handshake for peer 8 ([2003:my-ipv6-adddress:2318]:58130/0%0) did not complete after 5 seconds, retrying (try 2)
Nov 12 15:04:18 laurenz-Yoga kernel: wireguard: wg_config: Sending handshake initiation to peer 8 ([2003:my-ipv6-adddress:2318]:58130/0%0)
Nov 12 15:04:23 laurenz-Yoga kernel: wireguard: wg_config: Handshake for peer 8 ([2003:my-ipv6-adddress:2318]:58130/0%0) did not complete after 5 seconds, retrying (try 2)
Nov 12 15:04:23 laurenz-Yoga kernel: wireguard: wg_config: Sending handshake initiation to peer 8 ([2003:my-ipv6-adddress:2318]:58130/0%0)
Nov 12 15:04:28 laurenz-Yoga kernel: wireguard: wg_config: Sending handshake initiation to peer 8 ([2003:my-ipv6-adddress:2318]:58130/0%0)
Nov 12 15:04:33 laurenz-Yoga kernel: wireguard: wg_config: Handshake for peer 8 ([2003:my-ipv6-adddress:2318]:58130/0%0) did not complete after 5 seconds, retrying (try 2)
Nov 12 15:04:33 laurenz-Yoga kernel: wireguard: wg_config: Sending handshake initiation to peer 8 ([2003:my-ipv6-adddress:2318]:58130/0%0)
Nov 12 15:04:34 laurenz-Yoga kernel: wireguard: wg_config: Peer 8 ([2003:my-ipv6-adddress:2318]:58130/0%0) destroyed
Nov 12 15:04:34 laurenz-Yoga kernel: wireguard: wg_config: Interface destroyed
Nov 12 15:04:48 laurenz-Yoga kernel: capability: warning: `gvfsd-admin' uses 32-bit capabilities (legacy support in use)
Nov 12 15:05:57 laurenz-Yoga kernel: wireguard: fritzbox: Interface created
Nov 12 15:05:57 laurenz-Yoga kernel: wireguard: fritzbox: Peer 9 created
Nov 12 15:05:57 laurenz-Yoga kernel: wireguard: fritzbox: Sending keepalive packet to peer 9 ([2003:my-ipv6-adddress:2318]:58130/0%0)
Nov 12 15:05:57 laurenz-Yoga kernel: wireguard: fritzbox: Sending handshake initiation to peer 9 ([2003:my-ipv6-adddress:2318]:58130/0%0)
Nov 12 15:06:02 laurenz-Yoga kernel: wireguard: fritzbox: Sending handshake initiation to peer 9 ([2003:my-ipv6-adddress:2318]:58130/0%0)
Nov 12 15:06:07 laurenz-Yoga kernel: wireguard: fritzbox: Sending handshake initiation to peer 9 ([2003:my-ipv6-adddress:2318]:58130/0%0)
Nov 12 15:06:12 laurenz-Yoga kernel: wireguard: fritzbox: Sending handshake initiation to peer 9 ([2003:my-ipv6-adddress:2318]:58130/0%0)

(Sorry the logs are a bit of a mess)

Sounds correct than :+1:

Okay makes sense to me, but I assumed that Wireguard does this sort of network configuration for me, whenever I enable the VPN with the config file.
For example here:

I know that this network is by far not ideal, and during the process of debugging, I learned about the problems that it can create, but that’s just the default configuration of the network and unfortunately I can’t change it right now.

I’m not 100% sure what you mean by that.
The “wg_config” / “fritzbox” network (/ routing table?) was created by Wireguard itself, as soon as i enable the VPN connection using wg-quick or the Gnome settings.