Have you ever set up a WireGuard VPN on a local machine and a remote VPS, only to find out that the local machine can’t access the Internet, even though the VPS can? On top of that, neither can ping each other’s IPs? It’s a frustrating issue, but the good news is that the fix is actually quite simple. This article will guide you through the surprisingly easy solution to this irritating problem, which turns out to be a minor setting misconfiguration.
In my setup, I’m using a Raspberry Pi as the local machine, configured to act as a WireGuard client. This Raspberry Pi is set up as a transparent proxy and is strategically placed between my Wi-Fi router and ISP modem. My remote VPS, located in Amsterdam, serves as the WireGuard server. The goal was to securely exit to the Internet from Amsterdam via a VPS. I went with DigitalOcean as my VPS provider, opting for their most budget-friendly option. Despite the WireGuard VPN connection being successfully established—confirmed by running the
sudo wg show command on both my Raspberry Pi and the VPS—Internet connectivity remained elusive for my Raspberry Pi, and neither device could ping each other’s IPs.
Disclaimer: I want to make it clear that I’m not promoting DigitalOcean, nor am I being compensated for writing this article or endorsing their services. I’ve been using DigitalOcean for five years and have found its services beneficial for my specific needs, which is why I’ve chosen to share this information.
Your setup might differ from mine. For instance, you might be using WireGuard to connect to your home network while you’re out at a coffee shop. Regardless of your specific environment, the core issue discussed in this article and its solution should be applicable to you.
Before diving into the process of fixing the WireGuard connectivity issues, ensure you meet the following prerequisites:
WireGuard Installed: Make sure WireGuard is installed and configured on both the WireGuard client and the WireGuard server.
Terminal Access on Both Devices: You’ll need terminal access on both the WireGuard client and the WireGuard server to run various commands. This guide includes Linux terminal commands for troubleshooting.
Root or Sudo Access: You’ll need root or sudo access on both the WireGuard client and the WireGuard server to execute commands required.
Basic Linux Skills: Familiarity with basic Linux terminal commands like
ipis beneficial as you’ll be using the terminal to execute these commands for troubleshooting.
Once you’ve checked off these prerequisites, you’re all set to proceed with resolving the WireGuard connectivity issues.
The solution is very simple. The problem lies in the mismatched MTU (Maximum Transmission Unit) settings. This solution needs to be applied on both machines: the WireGuard client and the WireGuard server.
Reminder: First three steps should be performed on both the WireGuard client and the WireGuard server to ensure consistent settings.
To understand the issue, the first step is to check the MTU setting on your WireGuard client using the following command:
ip addr | grep mtu
In my case the output is:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
Notice that the MTU for the WireGuard interface (
wg0) is set to 1420, while other interfaces are set to 1500.
To resolve the issue, change the MTU setting for the WireGuard interface to match the system MTU, which in my case is 1500. This can be done with the following command:
sudo ip link set dev wg0 mtu 1500
After applying the fix, confirm that the MTU setting have been updated:
ip addr | grep mtu
And the output is:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
You should now see that the MTU for
wg0 matches the system MTU.
Now that you’ve successfully completed the previous three steps for your WireGuard client, it’s time to repeat those exact steps but for your WireGuard server. This ensures that both ends of the VPN tunnel are properly configured.
The final step is to verify that your WireGuard client (Raspberry Pi in my case) can access the Internet and ping the WireGuard server (remote VPS in my case).
Run the following command to ping the internal IP address of you WireGuard server:
ping [Your WireGuard servers IP address]
Run the following command to check the Internet access by pinging the public DNS resolver from Cloudflare:
Run the following command to check the Internet access by pinging the Google.com domain name:
If you get a response from these pings, then congratulations! You’ve successfully fixed the WireGuard connectivity issue.
Resolving WireGuard connectivity issues between a WireGuard client (Raspberry Pi in my case) and WireGuard server (remote VPS in my case) might seem daunting at first, especially when you’re faced with no Internet access and an inability to ping internal IPs. However, with the right guidance and a few simple commands, you can easily troubleshoot and fix this problem. By following this guide, you should now have a fully functional WireGuard setup that allows your client machine to securely access the Internet via your VPS without any headaches.
I hope this article has helped you successfully resolve the WireGuard connectivity issues in your setup. If you found this guide beneficial, feel free to leave a comment
Thank you for taking the time to read this article. May your network remain secure and efficient, powered by your perfectly configured WireGuard VPN!