WireGuard on a Raspberry Pi often fails after network changes because the server’s Address or ListenPort settings conflict with local subnet routing. The address 192.168.2.0/24 is a private LAN range, not a public external IP, causing routing loops if assigned to the WAN interface. Correcting this requires aligning the WireGuard configuration with your actual router-assigned public IP and ensuring proper NAT masquerading.
Clarifying Private vs Public IP Addresses
The most common source of confusion in these troubleshooting scenarios is the distinction between internal (private) and external (public) IP addresses. The address range192.168.x.x belongs to RFC 1918 private space. These addresses are used within your local home or office network and are not routable on the public internet. When you see "static external IP" mentioned alongside 192.168.2.0/24, it usually indicates one of two things: either the Raspberry Pi has been assigned a static IP within its local LAN by the DHCP server, or there is a misunderstanding about which interface holds the public-facing address.
If your Raspberry Pi is behind a standard residential router, it likely has a private IP like 192.168.2.50. Your router, in turn, has a public IP provided by your ISP. WireGuard must listen on the interface that connects to the internet, but its internal Address field should typically remain within the private range defined for the VPN tunnel itself (e.g., 10.0.0.2/32), not the LAN subnet. Assigning a LAN subnet address to the WireGuard virtual adapter can cause the OS to try to route VPN traffic through the local Ethernet port instead of the internet gateway, breaking connectivity.
For more details on distinguishing between connection types and subnet issues, you might find Troubleshooting OpenVPN Connection on Raspberry Pi for Specific Device Subnet helpful, as the underlying networking principles regarding subnet conflicts are identical across VPN protocols.
Verifying Network Interface Configuration
Before adjusting WireGuard, you must identify which IP address is actually reachable from the outside world. On your Raspberry Pi, open a terminal and run the commandip addr show. Look for your primary network interface, which is usually eth0 for wired connections or wlan0 for wireless.
You will see two main types of addresses listed:
1. inet: This is your IPv4 address. If it starts with 192.168., 10., or 172.16-31., it is a private IP.
2. inet6: You may also see an IPv6 address, which could be global and publicly routable depending on your ISP.
If you are using IPv4, you need to know your router's public IP. You can check this by visiting a site like whatismyipaddress.com from a device on the same network, or by checking your router’s admin panel. The WireGuard server on the Raspberry Pi does not need to know its own public IP explicitly in the config file; rather, it needs to bind to the correct local interface so that incoming packets from the internet are accepted.
Ensure that your Raspberry Pi’s local IP (e.g., 192.168.2.50) is static. If it changes frequently due to DHCP renewals, your port forwarding rules will break. Set this static IP in your router’s DHCP reservation table, not inside the WireGuard configuration.
Correcting the WireGuard Server Configuration
Once you have clarified your network topology, update the WireGuard server configuration file, typically located at/etc/wireguard/wg0.conf. Pay close attention to the [Interface] section.
The Address line defines the IP pool for the VPN tunnel, not the physical network. It should look something like this:
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = YOUR_PRIVATE_KEY_HERE
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE192.168.2.0/24, use 10.0.0.0/24 or 192.168.10.0/24. Never use 192.168.2.0/24 here if that is your physical LAN.
- ListenPort: Ensure port 51820 (UDP) is open.
- PostUp/PostDown: These commands enable NAT masquerading, allowing clients to access the internet through the Pi. Replace eth0 with your actual internet-facing interface name if it differs.
After saving the file, restart the service with sudo systemctl restart wg-quick@wg0. Check the status with sudo systemctl status wg-quick@wg0 to ensure there are no errors.
For additional context on handling peer connectivity issues when the server is not responding, refer to Peers Connect: VPN Server Not Responding with WireGuard.
Configuring Port Forwarding and Firewall
Even with a correct configuration, external peers cannot reach the Raspberry Pi unless your router forwards UDP port 51820 to the Pi’s local IP address. Log into your router’s administration interface and locate the Port Forwarding or Virtual Server section. Create a new rule: - Service Name: WireGuard - Protocol: UDP - External Port: 51820 - Internal Port: 51820 - Internal IP: The static local IP of your Raspberry Pi (e.g.,192.168.2.50)
Additionally, ensure your Raspberry Pi’s firewall allows inbound UDP traffic on port 51820. If you are using ufw (Uncomplicated Firewall), allow the port with:
sudo ufw allow 51820/udp
If you recently changed your network setup, existing connections may be stale. Disconnect all peers and reconnect them. If the issue persists, check if your ISP blocks incoming ports (common with CGNAT). In such cases, you may need to use IPv6 or a dynamic DNS service if your public IP changes, though a static public IP from your ISP resolves this.
See Troubleshooting No Internet with Self Hosted Wireguard VPN on Raspberry Pi Behind the Router for deeper insights into NAT and routing problems specific to self-hosted setups.
Frequently Asked Questions
Why did my WireGuard stop working after setting a static IP?
It likely stopped working because the static IP was assigned to the wrong interface or conflicted with the VPN subnet. If you assigned a LAN IP to the WireGuardAddress field, it creates a routing conflict where the Pi tries to send VPN traffic locally instead of out to the internet. Always keep the WireGuard virtual subnet separate from your physical LAN subnet.
Can I use my public IP address in the WireGuard Address field?
No, you should never put your public ISP-assigned IP in the WireGuardAddress field. That field defines the internal IP addresses given to VPN clients. The server binds to the interface automatically; it does not need to know its own public IP in the config file. Using a public IP there will break the tunnel establishment.
How do I check if my ISP is blocking port 51820?
Try connecting from a mobile data network (not your home Wi-Fi) to see if the connection succeeds. If it works on mobile but not on other networks, your ISP or local router might be blocking the port. You can also use an online port checker tool to scan your public IP on port 51820 to see if it appears closed.What if I am behind Carrier Grade NAT (CGNAT)?
If your router shows a public IP that is actually in the100.64.0.0/10 range, you are behind CGNAT. Standard port forwarding will not work because you do not have a true public IP. In this case, consider using IPv6 if your ISP supports it, or use a tunneling service like Tailscale or ZeroTier which can traverse CGNAT environments.
Does WireGuard require a specific kernel version on Raspberry Pi?
Modern versions of Raspberry Pi OS (Bookworm and later) include WireGuard kernel modules by default. However, older versions (Buster or early Bullseye) required manual installation of thewireguard-tools and kernel headers. Ensure your system is updated with sudo apt update && sudo apt upgrade to guarantee compatibility with current configurations.