To route internet-bound traffic between two WireGuard peers, you must configure the client's default gateway to point through the VPN interface while ensuring the server does not forward packets for non-local subnets. This setup requires careful manipulation of IP forwarding rules and routing tables on both endpoints to prevent traffic loops and ensure that data destined for the public internet exits via the correct upstream provider rather than being dropped or misrouted within the private tunnel.
Understanding the Traffic Flow
In a standard WireGuard configuration, traffic between two clients (Peer A and Peer B) flows directly if they are in the same subnet or if the server acts as a router between different subnets. However, when one peer attempts to access the internet, the traffic must traverse the server node. The core challenge lies in distinguishing between traffic intended for the other VPN peer and traffic intended for the global internet. If the server's kernel routing table is not configured correctly, it may attempt to send internet-bound packets back into the WireGuard tunnel, creating an infinite loop or dropping them entirely because the destination IP is not part of the local VPN subnet.
To solve this, the server must act as a transparent bridge for inter-peer traffic while functioning as a standard router for external traffic. This involves enabling IP forwarding on the Linux host running the WireGuard server. Without this kernel parameter set to
1, the operating system will reject any packet that arrives on one interface and needs to be sent out another, effectively isolating the peers from each other regardless of the WireGuard configuration. You can verify this setting by checking the value of
net.ipv4.ip_forward in the system's network configuration files.
Configuring Server-Side Routing
The most critical step is defining which destinations should remain inside the VPN and which should exit to the public internet. In your
wg0.conf file on the server, the
AllowedIPs field for each peer dictates what traffic the server will accept and process. For Peer A, you might specify
10.0.0.2/32 if you only want direct peer-to-peer communication. However, to allow Peer A to reach the internet through the server, you typically need to include the broader subnet or use a specific routing strategy.
If you are using a single WireGuard instance to connect multiple clients, you often define the entire private range (e.g.,
10.0.0.0/24) in the
AllowedIPs. This tells the server to handle all traffic from these IPs. To differentiate internet traffic, the server relies on its main routing table. When a packet arrives from Peer A destined for
8.8.8.8, the server checks its routes. If there is no specific route for
8.8.8.8 via the WireGuard interface, the default route (
0.0.0.0/0) will catch it and send it out via the physical network interface (like
eth0). This is the desired behavior for internet traffic.
However, problems arise if the server itself uses the VPN as its default gateway, or if the client tries to push its own default route through the VPN. See
How to Make a Server Not Use VPN as a Default Gateway for details on preventing the server from routing its own management traffic incorrectly.
Client Configuration for Internet Access
On the client side, specifically Peer A, you need to ensure that its default gateway is set to the WireGuard interface. In the
[Interface] section of the client's configuration, set
PrivateKey and generate a new
PublicKey. Under the
[Peer] pointing to the server, set AllowedIPs to 0.0.0.0/0. This directive instructs the client's kernel to send all non-local traffic (which includes the internet) through the encrypted tunnel to the server.
It is crucial to understand that setting AllowedIPs = 0.0.0.0/0 on the client does not mean the server will route everything to the internet; it only means the client sends it there. The server still applies its own routing logic. If the server has multiple network interfaces or complex routing rules, you may need to add static routes to ensure return traffic works correctly. For example, if the server is behind NAT, the source IP of the packet will be translated, but the routing decision remains based on the destination IP.
For more complex setups involving multiple VPNs on the same VPS, isolation becomes key. Refer to How to Isolate WireGuard Networks on a Small Linux VPS Host with Multiple VPNs to learn how to prevent cross-contamination between different tunnel configurations.
Troubleshooting Common Issues
Even with correct configurations, internet traffic may fail due to firewall restrictions or MTU mismatches. First, check the server's firewall (iptables, nftables, or ufw). Ensure that forwarding is allowed between the WireGuard interface (usually wg0) and the physical interface. A common mistake is allowing incoming connections but forgetting to permit forwarded traffic. You can test connectivity by pinging a public DNS server from the client. If the ping fails, check the server's logs using journalctl -u wg-quick@wg0 to see if packets are being received and where they are being dropped.
Another frequent issue is asymmetric routing. If the client sends traffic out via the VPN, but the response comes back via a different path, the connection will drop. This often happens if the server has multiple default routes. Use ip route get 8.8.8.8 on the server to verify which interface is used for outbound internet traffic. Additionally, consider adjusting the MTU size. WireGuard adds overhead, so reducing the client's MTU to 1420 or lower can prevent fragmentation issues that manifest as slow or broken internet access. For deeper diagnostics on why peers cannot communicate directly, review Troubleshooting WireGuard Client-to-Client Communication Issues.
Frequently Asked Questions
Why can my peer reach the other peer but not the internet?
This usually indicates that the server's default route is not handling the traffic correctly or that the client's AllowedIPs are too restrictive. Ensure the client sets AllowedIPs = 0.0.0.0/0 to send all external traffic to the server, and verify that the server's kernel is forwarding packets out to its primary network interface.
Do I need to enable NAT on the WireGuard server?
Standard WireGuard does not perform NAT by itself. If your clients are on private subnets and you want them to appear as the server's IP to the internet, you must configure SNAT (Source Network Address Translation) using iptables or nftables on the server's outgoing interface. Without this, return traffic may not know how to route back to the private client IP.
Can I have multiple WireGuard servers route traffic?
Yes, but you must carefully manage the routing tables to avoid loops. Each server needs distinct private subnets to prevent IP conflicts. See Connecting Another WireGuard Server to an Existing One: VPS Open Ports and NAT Solutions for guidance on linking multiple infrastructure nodes securely.
What causes high latency when routing through a WireGuard peer?
Latency is primarily caused by the additional encryption overhead and the physical distance to the server. Additionally, if the server is doing heavy CPU work for encryption or if the MTU is mismatched causing packet fragmentation, performance will degrade. Monitor CPU usage during transfers to identify bottlenecks.
Is it safe to route all internet traffic through a WireGuard peer?
It depends on trust. If you control the server, it is generally safe, but the server owner can potentially inspect unencrypted traffic before it leaves their machine unless you are using end-to-end encryption applications. Always assume the VPN provider can see your traffic metadata.