You are not logged in.
I'm experiencing connectivity issues with WireGuard on my Arch Linux system. While the VPN connection establishes successfully, access to websites is inconsistent:
Some websites detect my real IP address
Others recognize the VPN's IP address
Certain sites are completely inaccessible(The server at xxx is taking too long to respond.)
Interestingly, the same WireGuard configuration works flawlessly on my mobile device, suggesting a system-specific issue.
Last edited by c09e75 (2025-04-07 19:02:24)
Offline
Some VPN providers block ICMP packets for security reasons. This in turn breaks "Path MTU discovery" and you have to lower the MTU for yourself.
This website demonstrates one possibility (via ping):
https://networkdirection.net/articles/n … d-the-mtu/
Instead of dns.google you can take one of the servers you can't reach that answers to a ping.
After discovering the MTU you have to tell WireGuard to use it instead of it's default..
Last edited by -thc (2025-04-07 05:32:21)
Offline
It doesn't look like a block.
I tested the same config on my arch machine and on my phone. And there was no connection only on my computer
I tried changing the MTU and now I can access one resource but others are still unreachable.
Offline
Well - we need a lot of information then. While connected to the VPN please post the output of
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-45s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
ip address
ip -4 route
ip -6 route
ping 8.8.8.8
ping dns.googleOffline
1.
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.resolve1.service | system
dbus-org.freedesktop.timesync1.service | system
display-manager.service | system
getty@tty1.service | getty.target.wants
lactd.service | multi-user.target.wants
NetworkManager.service | multi-user.target.wants
NetworkManager-wait-online.service | network-online.target.wants
ollama.service | default.target.wants
p11-kit-server.socket | sockets.target.wants
pipewire-pulse.socket | sockets.target.wants
pipewire-session-manager.service | user
pipewire.socket | sockets.target.wants
remote-fs.target | multi-user.target.wants
systemd-resolved.service | sysinit.target.wants
systemd-timesyncd.service | sysinit.target.wants
systemd-userdbd.socket | sockets.target.wants
wakeup-disable_GPP0.service | multi-user.target.wants
wireplumber.service | pipewire.service.wants
xdg-user-dirs-update.service | default.target.wants2.
12: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.2.0.2/32 scope global wg0
valid_lft forever preferred_lft forever3.
default via 192.168.178.1 dev enp4s0 proto dhcp src 192.168.178.28 metric 101
192.168.178.0/24 dev enp4s0 proto kernel scope link src 192.168.178.28 metric 101 4.
2a02:8108:96b6:4000::/64 dev enp4s0 proto ra metric 100 pref medium
2a02:8108:96b6:4000::/64 via fe80::4a5d:35ff:fec5:d856 dev enp4s0 proto ra metric 105 pref medium
fe80::/64 dev enp4s0 proto kernel metric 1024 pref medium
default via fe80::4a5d:35ff:fec5:d856 dev enp4s0 proto ra metric 100 pref medium5.
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=20.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=19.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=23.2 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 19.860/21.233/23.245/1.453 msPING dns.google.com (2001:4860:4860::8844) 56 data bytes
64 bytes from dns.google (2001:4860:4860::8844): icmp_seq=1 ttl=116 time=13.2 ms
64 bytes from dns.google (2001:4860:4860::8844): icmp_seq=2 ttl=116 time=19.7 ms
64 bytes from dns.google (2001:4860:4860::8844): icmp_seq=3 ttl=116 time=12.4 ms
--- dns.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 12.357/15.092/19.722/3.291 msAlso, when pinging twitch.tv I received packets, but when trying to access twitch.tv from firefox I received an error:"The server at www.twitch.tv is taking too long to respond."
Offline
That reads like an IPv6 bypass. Your internet access (KabelD via Fritz!Box) is fully IPv6 capable and so is your arch box (you pinged dns.google via IPv6).
The VPN provides only IPv4. Either you add IPv6 to your WireGuard connection (if possible) or disable IPv6 on your baseline internet connection.
Additionally your WireGuard interface name suggests that you use "wireguard tools" for connecting to the VPN via "wg-quick". That needs special attention in regard to systemd-resolved.
Last edited by -thc (2025-04-07 17:41:55)
Offline
Ok. I think I have disabled ipv6 now, but connections still don't work. I checked how it works on windows, and it works fine.
PING dns.google.com (8.8.8.8) 56(84) bytes of data.
64 bytes from dns.google (8.8.8.8): icmp_seq=1 ttl=117 time=15.0 ms
64 bytes from dns.google (8.8.8.8): icmp_seq=2 ttl=117 time=12.4 ms
64 bytes from dns.google (8.8.8.8): icmp_seq=3 ttl=117 time=12.7 msOffline
What's the current MTU value on your WireGuard connection?
Offline
It equals 1420
Offline
Yeah - sorry for the question - it was already mentioned above.
Try reducing it to 1200 (just for testing & ruling out MTU problems).
Offline
Wow no way now it's works. Thank you a lot.
I was looking for a solution for half a year
Offline
Nice. You can re-increase the MTU value until the problems start to appear.
Offline