Troubleshooting No Internet with Self Hosted Wireguard VPN on Raspberry Pi Behind the Router

Restoring internet access for a self-hosted Wireguard VPN on a Raspberry Pi behind a router typically requires correcting the AllowedIPs configuration and enabling IP forwarding. Misconfigured routing rules often direct all traffic through the tunnel, causing connectivity loss when the peer cannot reach the internet. Verifying these settings ensures that only intended traffic is routed while general browsing remains unaffected.

Verifying AllowedIPs Configuration

The most common cause of lost internet connectivity in a Wireguard setup is an incorrect AllowedIPs entry. This parameter defines which traffic is encrypted and sent through the VPN tunnel. If you set this to 0.0.0.0/0, your device attempts to route all internet traffic through the VPN server. If the server does not have proper gateway configurations or if the client lacks a default route back to the local network, internet access will fail. To fix this, check your client configuration file. The AllowedIPs should usually be limited to the specific subnet of your home network or the private IP range assigned by the VPN. For example, if your local network is 192.168.1.0/24 and your VPN assigns addresses from 10.0.0.0/24, your client configuration should look like this:

[Interface]
PrivateKey = client_private_key
Address = 10.0.0.2/24

[Peer]
PublicKey = server_public_key
Endpoint = your_domain_or_ip:51820
AllowedIPs = 10.0.0.0/24, 192.168.1.0/24
PersistentKeepalive = 25

By excluding 0.0.0.0/0, you ensure that traffic destined for the wider internet bypasses the tunnel and uses your standard router connection. This is critical when the VPN server is primarily used for accessing internal resources rather than acting as a full proxy for all web traffic.

Enabling IP Forwarding on the Server

If your goal is to route all traffic through the VPN (split tunneling or full tunneling), the server must act as a gateway. On a Raspberry Pi running Linux, IP forwarding is disabled by default for security reasons. You must enable it to allow packets to move between the VPN interface and the physical network interface. Check if forwarding is currently enabled by running:

sysctl net.ipv4.ip_forward

If the output is 0, you need to enable it. Edit the sysctl configuration file:

sudo nano /etc/sysctl.conf

Find the line containing net.ipv4.ip_forward and uncomment it, changing the value to 1:

net.ipv4.ip_forward=1

Apply the changes immediately with:

sudo sysctl -p

Without this setting, even if the routing tables are correct, the kernel will drop packets attempting to traverse from the wireguard interface to the internet interface. This step is essential for any server-side configuration where the Raspberry Pi serves as the exit node for connected clients.

Configuring NAT Masquerading

Enabling forwarding is not enough; you must also configure Network Address Translation (NAT). When a packet leaves the VPN interface, it carries a private IP address (e.g., 10.0.0.2). Routers on the public internet do not know how to route packets from this private range back to your client. You must masquerade these packets so they appear to come from the Raspberry Pi's public IP. Use iptables to add a masquerade rule. Assuming your external interface is eth0 or wlan0 and your Wireguard interface is wg0, run:

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Or more dynamically, using the outgoing interface variable:

sudo iptables -t nat -A POSTROUTING -o $(ip -4 route show default | awk '{print $5}') -j MASQUERADE

This command tells the firewall to rewrite the source IP of outgoing packets from the VPN subnet to the public IP of the Pi. Without this, return traffic from websites will never find its way back to your client. Note that if you are using OpenWRT, this is often handled via the "Masquerade" checkbox in the Firewall Zone settings, but manual verification is still recommended. For more details on configuring the server side correctly, see Configure WireGuard OpenWRT Server and Client.

Checking Router Port Forwarding

Since your Raspberry Pi is behind a router, the external world cannot initiate connections to the Wireguard service unless port forwarding is configured. While this primarily affects incoming connections, some asymmetric routing issues can arise if the router's NAT table is confused about outbound traffic from the VPN interface. Ensure that UDP port 51820 (or your custom port) is forwarded from your router to the static local IP of your Raspberry Pi. Log into your router's admin panel, locate the Port Forwarding or Virtual Servers section, and create a new rule. Set the protocol to UDP, the external port to 51820, and the internal IP to the Pi's address. Additionally, verify that the Pi has a static local IP address. If the DHCP lease expires and the Pi receives a new IP, the port forward will break, and existing connections may hang. Assign a static IP via your router's DHCP reservation settings or configure it directly on the Pi's network interface.

Firewall Rules and Interface Binding

Linux firewalls like UFW or Firewalld might block traffic on the wireguard interface. By default, Wireguard creates a new interface (wg0) which might not be trusted by your firewall rules. If you use UFW, you may need to explicitly allow traffic on the wireguard interface or adjust the default policies. Check your firewall status:

sudo ufw status verbose

If you are restricting traffic, ensure that the wireguard interface is allowed to accept connections. Sometimes, simply allowing the UDP port on the main interface is insufficient because the traffic arrives on wg0. You can test this by temporarily disabling the firewall to see if connectivity returns. If it does, re-enable it and add specific rules for wg0. Also, ensure that the Wireguard service is listening on the correct interface. In your configuration, the ListenPort should be open. If you have multiple network interfaces, binding to 0.0.0.0 ensures it listens on all of them, preventing missed packets due to interface mismatch. For troubleshooting connection establishment issues, refer to Troubleshooting: Wireguard Home VPN Connection Not Established.

Frequently Asked Questions

Why can I ping the VPN server but not browse the web?

This indicates that the Layer 3 connectivity between the client and server is working, but routing or NAT is misconfigured. Check your AllowedIPs on the client to ensure it is not forcing all traffic through the tunnel without a valid exit route. Also, verify that NAT masquerading is active on the server's public interface.

Does Wireguard require port forwarding on the router?

Yes, for a self-hosted server, you must forward the UDP listen port (default 51820) to the Raspberry Pi's local IP. Without this, external peers cannot initiate the handshake required to establish the encrypted tunnel. Internal peers on the same LAN do not need this.

How do I make iptables NAT rules persistent after reboot?

Iptables rules are lost on reboot unless saved. Install iptables-persistent and run sudo dpkg-reconfigure iptables-persistent to save current rules. Alternatively, use a systemd service or add the commands to /etc/rc.local depending on your distribution.

Can I use Split DNS with Wireguard on Raspberry Pi?

Yes, but it requires additional configuration. You would need to run a local DNS resolver like Pi-hole or dnsmasq on the Pi and point the client's DNS setting in the Wireguard config to the VPN server's IP. Ensure the server forwards queries appropriately to maintain privacy and speed.

What happens if I set AllowedIPs to 0.0.0.0/0 incorrectly?

If the server cannot route traffic back to the client or lacks internet access itself, setting 0.0.0.0/0 will cause a complete internet blackout for the client. Always test with a specific subnet first to ensure the tunnel works before expanding to full traffic routing.