Wireguard connection successful, but hangs when accessing anything

I have successful connected to the wireguard, and it seems like it’s transporting traffic.

transfer: 5.61 KiB received, 2.89 KiB sent

However, I could not access any websites. It just hangs trying to connect. ping works fine with 1.1.1.1. What may be a root issue and how can I find it? I also tried to setup it via network manager, but result is the same. Configurations files are okay, they work fine on
my mac.

UPD: It looks like it’s DNS issue, because all websites are accessible by direct IP. Is there anything I can do about it?

Hi @iillexial, and welcome!

To make sure it is that, check your DNS server(s) with:

cat /etc/resolv.conf

…before and after connecting, for any differences.

They are indeed different, but just in order. Before connecting:

nameserver 192.168.0.1
nameserver 2001:730:3ed2::53
nameserver 2001:730:3ed2:1000::53
# Too many DNS servers configured, the following entries may be ignored.
nameserver xxx.xx.0.1
search .

After:

nameserver xxx.xx.0.1
nameserver 192.168.0.1
nameserver 2001:730:3ed2::53
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2001:730:3ed2:1000::5
search .

My MacOS uses the same server xxx.xx.0.1

That looks like a local IP. You on a network?

I think that’s my router’s IP address.

That’s what I figured, yes.

OK, so maybe this works, I’m not sure. Leet’'s try making the file immutable:

sudo chattr +i /etc/recolv.conf

…before connecting next time and testing.

If it doesn’t you should be able to just disconnect again. if that doesn’t work, remove the immutable flag and reboot.

sudo chattr -i /etc/resolv.conf

It didn’t work. The file wasn’t modified, but the problem with connection stayed

Then it’s a routine issue. Which I’ve never done anything with, but I know how you can get the routing tables. So remove the immutable flag:

sudo chattr -i /etc/resolv.conf

And run and following before connecting, after connecting, and again on disconnecting:

ip route

And

route

…and provide the output here.

Edit:

Also, there seem to be a section dedicated to this in the Arch wiki:

https://wiki.archlinux.org/title/WireGuard#Broken_DNS_resolution

Check your network configuration as this happens frequently when using VPN.

My personal solution is to enable systemd-resolved and remove openresolv.

1 Like

Before:

$ ip route

default via 192.168.0.1 dev wlo1 proto dhcp src 192.168.0.194 metric 600
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-c1b7041ba63c proto kernel scope link src 172.18.0.1 linkdown
172.19.0.0/16 dev br-8d4bb2e36deb proto kernel scope link src 172.19.0.1 linkdown
172.20.0.0/16 dev br-1af474e41be2 proto kernel scope link src 172.20.0.1 linkdown
172.21.0.0/16 dev br-0b7dd881cf37 proto kernel scope link src 172.21.0.1 linkdown
172.22.0.0/16 dev br-2beb254c9d5b proto kernel scope link src 172.22.0.1 linkdown
172.24.0.0/16 dev br-fd2a368731eb proto kernel scope link src 172.24.0.1 linkdown
192.168.0.0/24 dev wlo1 proto kernel scope link src 192.168.0.194 metric 600

$ route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

default         _gateway        0.0.0.0         UG    600    0        0 wlo1
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-c1b7041ba63c
172.19.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-8d4bb2e36deb
172.20.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-1af474e41be2
172.21.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-0b7dd881cf37
172.22.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-2beb254c9d5b
172.24.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-fd2a368731eb
192.168.0.0     0.0.0.0         255.255.255.0   U     600    0        0 wlo1

After:

$ ip route

default via 192.168.0.1 dev wlo1 proto dhcp src 192.168.0.194 metric 600
xx.xx.0.0/16 dev wg scope link
xx.xx.0.0/16 dev wg scope link
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-c1b7041ba63c proto kernel scope link src 172.18.0.1 linkdown
172.19.0.0/16 dev br-8d4bb2e36deb proto kernel scope link src 172.19.0.1 linkdown
172.20.0.0/16 dev br-1af474e41be2 proto kernel scope link src 172.20.0.1 linkdown
172.20.0.1 dev gitlab scope link
172.21.0.0/16 dev br-0b7dd881cf37 proto kernel scope link src 172.21.0.1 linkdown
172.22.0.0/16 dev br-2beb254c9d5b proto kernel scope link src 172.22.0.1 linkdown
172.24.0.0/16 dev br-fd2a368731eb proto kernel scope link src 172.24.0.1 linkdown
192.168.0.0/24 dev wlo1 proto kernel scope link src 192.168.0.194 metric 600

$ route # this command is slow

default         _gateway        0.0.0.0         UG    600    0        0 wlo1
xx.xx.0.0       0.0.0.0         255.255.0.0     U     0      0        0 wg
xx.xx.0.0       0.0.0.0         255.255.0.0     U     0      0        0 wg
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-c1b7041ba63c
172.19.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-8d4bb2e36deb
172.20.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-1af474e41be2
pcpcpc          0.0.0.0         255.255.255.255 UH    0      0        0 wg
172.21.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-0b7dd881cf37
172.22.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-2beb254c9d5b
172.24.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-fd2a368731eb
192.168.0.0     0.0.0.0         255.255.255.0   U     600    0        0 wlo1

Check that :point_up_2: , it might help.

Thanks. I have already skimmed and tried to even ignore the wireguard interface in the NM, but didn’t help.

My personal solution is to enable systemd-resolved and remove openresolv.

Also tried this, didn’t work too

Did you install systemd-resolvconf ?

Yes, and the service enabled as well:

 Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)

That is not the same as systemd-resolved - it is - in lack of better word a replacement for those apps relying on resolvconf

sudo pacman -Syu systemd-resolvconf

Yes, I have installed it before. (1/1) reinstalling systemd-resolvconf

And is your /etc/resolv.conf a symlink?

 $ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 37 okt  3 13:09 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
lrwxrwxrwx 1 root root 39 Dec 18 12:48 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

You marked the wiki entry as the solution.

What exactly … ?

Sorry, it was a missclick