WireGuard blocks traffic to remote networks not listed in AllowedIPs by design. To access such destinations, you must explicitly add those IP ranges to the AllowedIPs field in your configuration file. This change ensures that packets destined for those networks are encapsulated and sent through the tunnel instead of being dropped or routed via the local network interface.
Understanding WireGuard’s Routing Model
Unlike traditional VPNs that often route all traffic through the tunnel, WireGuard operates on a per-peer basis with strict policy enforcement. TheAllowedIPs directive serves as both an access control list and a routing table entry for the virtual interface. When a packet arrives at the wg0 interface (or whichever peer is configured), the kernel checks if the destination IP matches any prefix in AllowedIPs. If it does not match, the packet is discarded immediately. This behavior prevents accidental leakage of traffic but also means that any new remote subnet you wish to reach must be explicitly declared.
This strict model is a security feature, not a bug. It ensures that even if a peer is compromised, it cannot sniff traffic intended for other subnets unless those subnets are explicitly allowed. However, this requires administrators to maintain accurate and up-to-date routing tables within the WireGuard configuration files. Misunderstanding this mechanism is the primary cause of connectivity issues when trying to reach devices outside the initially defined scope.
Modifying the Configuration File
To resolve the connectivity issue, you need to edit the configuration file for the specific peer on the client or server side. On Linux systems, this is typically located in/etc/wireguard/wg0.conf or a similar path depending on your setup. You will find a section under [Peer] that corresponds to the remote device you are trying to reach.
Look for the line starting with AllowedIPs. It may currently contain a single IP address, like 10.0.0.2/32, or a range like 192.168.1.0/24. To add a new remote network, simply append the new CIDR notation to the existing list, separated by a comma. For example, if you want to allow access to both the current subnet and a new remote office network at 172.16.0.0/24, the line should look like this:
AllowedIPs = 10.0.0.0/24, 172.16.0.0/24AllowedIPs field. After saving the file, you must reload the WireGuard service for the changes to take effect. Do not restart the entire system; use the following command to apply the new configuration dynamically:
sudo wg-quick down wg0
sudo wg-quick up wg0sudo wg syncconf wg0 /etc/wireguard/wg0.conf to apply changes without tearing down the connection, which minimizes downtime.
Verifying Route Installation
After updating the configuration, verify that the kernel has correctly installed the new routes. Use theip route show table main command to check the main routing table. You should see entries corresponding to the wireguard interface (usually named wg0) for the newly added subnets. If the routes are missing, it indicates that the configuration was not loaded correctly or there is a syntax error in the file.
You can also inspect the active peers using wg show. This command displays the current state of the tunnel, including the latest handshake times and data transfer statistics. Ensure that the handshake is successful and that the peer is marked as "allowed" for the new IPs. If the peer is not responding, check the firewall settings on both ends to ensure that UDP port 51820 is open and that no intermediate firewalls are dropping packets destined for the new subnets.
For more complex scenarios involving multiple interfaces, refer to our guide on Bypass/split tunnel wireguard to understand how to manage traffic distribution between the VPN and local network effectively.
Common Pitfalls and Solutions
One common mistake is forgetting to update theAllowedIPs on both ends of the connection. While WireGuard is asymmetric in its routing, ensuring that both peers have the correct policies helps avoid confusion during troubleshooting. Another issue arises when NAT is involved. If the remote network is behind a NAT gateway, ensure that the source IP of the packets leaving the WireGuard tunnel is correctly translated.
Additionally, check for overlapping IP ranges. If the new remote network overlaps with an existing one, WireGuard may prioritize the first matching rule, leading to unexpected routing behavior. Always use unique, non-overlapping subnets for each peer to maintain clarity and stability.
If you are experiencing issues with client-to-client communication across different peers, consider reading Troubleshooting WireGuard Client-to-Client Communication Issues for advanced routing tips.
Frequently Asked Questions
Can I use 0.0.0.0/0 to allow all traffic?
Yes, settingAllowedIPs = 0.0.0.0/0 will route all internet traffic through the WireGuard tunnel. This is useful for creating a full VPN proxy but should be used with caution due to privacy and performance implications.
Why did my connection drop after updating AllowedIPs?
The connection itself remains intact, but packets to previously allowed IPs might now be dropped if they were removed from the list. Ensure you retain all necessary subnets in the comma-separated list to maintain existing connectivity while adding new ones.Does WireGuard support dynamic IP updates?
No, WireGuard configurations are static files. You must manually edit the configuration and reload the service whenever IP ranges change. For dynamic environments, consider using automation scripts to regenerate the configuration file upon startup or change events.How do I troubleshoot if ping fails after adding a new IP?
First, verify that the new route exists in the kernel routing table usingip route. Second, check that the remote host is reachable from the WireGuard endpoint itself. Finally, ensure that no local firewall rules on the remote host are blocking ICMP or the specific application port.