How to Fix Issue with Raspberry Pi that Can't Get Out to the Internet After Recent Changes Related to Wireguard/VPN

The Raspberry Pi loses internet connectivity after configuring WireGuard because the VPN client often installs a default route that directs all traffic through the tunnel interface. If the tunnel drops or misconfigures, this primary route prevents the device from reaching public IP addresses. You can resolve this by adjusting the routing table to ensure only specific traffic uses the VPN while general internet access remains via your standard gateway.

Understanding the Routing Conflict

When you start a WireGuard service, it typically adds a rule to the kernel’s routing table. By default, many configurations set AllowedIPs = 0.0.0.0/0, which tells the operating system to send every single packet destined for the internet through the virtual network interface, usually named wg0. This is known as "split tunneling" in reverse, or full tunneling. While useful for privacy, it creates a critical dependency: if the WireGuard connection fails, or if the local network interface changes its default gateway, the Pi no longer knows how to reach the outside world because it is still trying to send packets into the void of the disconnected tunnel. This issue is particularly common on Raspberry Pi OS, which relies on NetworkManager or systemd-networkd depending on the version. Unlike traditional desktop Linux setups, embedded systems often have less robust fallback mechanisms for dynamic interfaces. When the VPN link goes down, the static route pointing to the VPN peer persists until the service stops, leaving the system with a broken path to the internet. To fix this, we must either remove the default route or configure the system to use multiple routes intelligently.

Step 1: Verify Current Routing State

Before making changes, you need to see exactly what the kernel is doing with your network packets. Open a terminal on your Raspberry Pi and run the following command to display the current IPv4 routing table:

ip route show

You will likely see an output similar to this:

default via 192.168.1.1 dev eth0 proto dhcp
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.5
default via 10.0.0.1 dev wg0 proto static metric 202

Notice the two lines starting with default. The first one points to your local router (e.g., 192.168.1.1) via your Ethernet or Wi-Fi interface (eth0 or wlan0). The second line points to the WireGuard gateway (10.0.0.1) via the wg0 interface. In Linux, when there are multiple default routes, the system uses the one with the lowest metric (priority). If the WireGuard route has a lower or equal metric, it takes precedence. If the tunnel is down, packets sent to this route are dropped, causing the "no internet" symptom. For more detailed diagnostics on why a specific host might be unreachable during such failures, refer to Troubleshooting Linux Device Not Reachable During Network (Ping).

Step 2: Fix the WireGuard Configuration

The most effective long-term solution is to prevent WireGuard from taking over the entire internet route unless absolutely necessary. Edit your WireGuard configuration file, which is typically located at /etc/wireguard/wg0.conf. Look for the [Peer] section where your remote server is defined. Find the line that starts with AllowedIPs. If it currently says:

AllowedIPs = 0.0.0.0/0

Change it to specify only the private networks you actually want to access through the VPN. For example, if you only want to access a home LAN behind the VPN, you might use:

AllowedIPs = 192.168.100.0/24

By removing 0.0.0.0/0, WireGuard will no longer install a default route for all internet traffic. Instead, it will only route traffic destined for specific subnets through the tunnel. All other traffic will continue to flow through your normal ISP connection via the original default gateway. After editing the file, restart the service using:

sudo systemctl restart wg-quick@wg0

If you are experiencing issues with internal communication between clients behind the same VPN, check Troubleshooting WireGuard Client-to-Client Communication Issues to ensure your peer settings allow proper forwarding.

Step 3: Use Policy Routing for Advanced Control

If you require full tunneling but want to avoid losing internet access when the VPN disconnects, you should implement policy-based routing. This technique allows you to keep the default route intact for general use while directing specific applications or traffic types through the VPN. However, for most users simply wanting their Pi back online, the split-tunnel approach in Step 2 is sufficient. Another common point of failure is DNS resolution. Even if routing works, incorrect DNS settings can make it seem like there is no internet. Ensure your /etc/resolv.conf is managed correctly by your network manager rather than being manually overwritten. On modern Raspberry Pi OS, /etc/resolv.conf is often a symlink to a file managed by systemd-resolved or dhcpcd. Manually editing it can lead to conflicts where changes are wiped out on reboot or network restart. To verify your DNS is working, try pinging a public DNS server directly:

ping 8.8.8.8

If this succeeds but ping google.com fails, your routing is fine, but your DNS is broken. In this case, check your DHCP settings or ensure your WireGuard config includes valid DNS servers in the DNS = 1.1.1.1, 8.8.8.8 line within the [Interface] section. For broader guidance on diagnosing connection failures, see Troubleshooting: Cannot Connect to the Internet.

Step 4: Restore Connectivity Temporarily

If you are currently locked out and cannot edit files remotely, you may need to access the Pi locally via HDMI and keyboard. Once logged in, you can temporarily flush the problematic route to restore internet access without rebooting. Run:

sudo ip route del default dev wg0

This removes the default route associated with the WireGuard interface. Your Pi should immediately regain internet access via its primary interface. Note that this change is not persistent across reboots; you must still correct the configuration file as described in Step 2 to prevent recurrence.

Frequently Asked Questions

Why does my Pi lose internet even though Wi-Fi is connected?

The Wi-Fi connection itself is active, but the operating system is sending data packets to the wrong destination. A misconfigured default route forces traffic into the VPN tunnel instead of your local router. Since the tunnel is broken, the packets disappear, resulting in no internet despite a healthy physical link.

Is it safe to expose ports on my Raspberry Pi for testing?

Exposing ports directly to the internet carries significant security risks if not properly secured. Always ensure you understand the implications of opening firewalls and services. For context on port exposure safety, review Is it safe to expose a port opened from netcat?.

Can I use iptables to fix the routing issue?

While iptables can manipulate packet flow, it is generally more complex and error-prone than adjusting the routing table or WireGuard config. For simple routing fixes, modifying AllowedIPs or using ip route commands is safer and easier to maintain than writing custom firewall rules.

What happens if I delete the default route manually?

Deleting the default route temporarily restores connectivity by forcing the system to fall back to other available default gateways, such as your local Wi-Fi or Ethernet router. However, this is a temporary workaround. You must update the persistent configuration to prevent the issue from returning after a reboot.

How do I know if my DNS is failing versus routing?

Test connectivity by pinging an IP address like 8.8.8.8. If the ping succeeds, your routing is correct and the issue is likely DNS-related. If the ping fails, your routing table is blocking traffic, indicating a problem with your default gateway or VPN configuration.