WireGuard peers on different network interfaces communicate by configuring static routes in the
AllowedIPs field of each peer’s configuration. This setting tells the kernel routing table which traffic to encapsulate and send through the tunnel, ensuring that packets destined for remote subnets are correctly routed over the WireGuard interface rather than the default gateway.
Understanding AllowedIPs and Routing
A common misconception among administrators is that
AllowedIPs acts as a firewall rule or an access control list that restricts what can be sent out. In reality, it serves two primary purposes: it defines the destination IP ranges for outbound traffic from the local host into the tunnel, and it sets up reverse routing so that replies from the remote peer are accepted. When peers reside on different physical interfaces or distinct subnet segments, this distinction becomes critical for proper connectivity.
The
AllowedIPs directive does not inherently enable client-to-client communication between two endpoints unless specific routing conditions are met. If Peer A wants to talk to Peer B, and both are connected to the same WireGuard server (Peer C), Peer A must have a route pointing to Peer B’s subnet via Peer C’s tunnel interface. Without this explicit route, Peer A will attempt to reach Peer B via its default gateway, which likely fails because Peer B is behind the VPN.
Configuring Static Routes
To establish communication between peers on different interfaces, you must explicitly define the remote subnets in the
AllowedIPs field. Consider a scenario where Server S has an internal network 192.168.1.0/24 and a WireGuard subnet 10.0.0.0/24. Client C1 connects with IP 10.0.0.2 and needs to access resources on 192.168.1.0/24.
In the configuration file for Client C1, the
[Peer] section for Server S should include:
[Peer]
PublicKey = ...
Endpoint = ...
AllowedIPs = 192.168.1.0/24
This tells the Linux kernel that any packet destined for 192.168.1.x should be pushed through the WireGuard interface associated with Server S. The server itself must also know how to route traffic back to Client C1, which is typically handled automatically if the server’s
AllowedIPs includes the client’s specific IP address (e.g., 10.0.0.2/32).
For multi-peer environments, such as when you need to connect two clients directly without routing all traffic through the server, refer to our guide on
Troubleshooting WireGuard Client-to-Client Communication Issues. This approach requires careful management of routing tables to prevent asymmetric routing problems.
Handling Multiple Interfaces and Subnets
When dealing with complex topologies involving multiple network interfaces, such as a machine with both Wi-Fi and Ethernet connections, WireGuard operates independently of the underlying physical layer. However, the operating system’s main routing table must prioritize the WireGuard interface for specific destinations.
If a client has multiple WireGuard peers, you can specify multiple subnets in the
AllowedIPs field separated by commas. For example:
AllowedIPs = 10.0.0.0/24, 172.16.0.0/16
This configuration ensures that traffic for both subnets is tunneled appropriately. It is crucial to avoid overlapping routes that could cause ambiguity. If you intend to route all internet traffic through the VPN, you would use
0.0.0.0/0, but this is generally discouraged for multi-interface setups unless specifically intended for privacy reasons. For mobile clients requiring full traffic redirection, see
Wireguard with VPS for Mobile Clients: Routing All Traffic.
Asymmetric Routing Risks
One of the most frequent causes of failure in multi-interface setups is asymmetric routing. This occurs when outgoing packets take one path (through the VPN) but incoming packets return via a different path (the public internet or another interface). To mitigate this, ensure that the source IP of the outgoing packet matches the expected return path.
You can enforce symmetric routing using policy-based routing rules. On Linux, this involves creating separate routing tables and using
ip rule to direct traffic based on its source address. For instance, packets originating from the WireGuard subnet (10.0.0.0/24) should always use the WireGuard routing table, while packets from the local LAN (192.168.1.0/24) use the main table.
Diagnostics and Verification
Verifying connectivity requires checking both the WireGuard status and the kernel routing table. Use
wg show to confirm that the handshake is established and that data packets are being transmitted. Look for non-zero values in the
TxBytes and
RxBytes columns.
Next, inspect the routing table with
ip route. You should see entries like:
192.168.1.0/24 dev wg0 proto kernel scope link src 10.0.0.2
This entry confirms that the kernel knows to send traffic for 192.168.1.0/24 through the
wg0 interface. If this entry is missing, the
AllowedIPs configuration may be incorrect or the service has not reloaded properly.
If you encounter issues where peers are visible but unreachable, check for firewall interference. Many users struggle with basic connectivity errors; for more general troubleshooting steps, consult
Troubleshooting WireGuard No Access to Remote. Ensure that UDP ports are open on all intermediate firewalls and that the
PostUp and
PreDown scripts in your configuration do not inadvertently block necessary traffic.
Frequently Asked Questions
Does AllowedIPs filter inbound traffic?
Yes,
AllowedIPs effectively filters inbound traffic by only accepting packets that appear to come from the specified IP ranges. This prevents spoofed packets from other peers or external sources from being processed by the WireGuard interface, enhancing security.
Can I route all traffic through WireGuard on a multi-homed device?
You can set
AllowedIPs = 0.0.0.0/0 to route all traffic, but this often breaks connectivity on other interfaces. It is safer to specify only the required subnets to maintain access to local resources while protecting sensitive data.
Why do I get ping timeouts despite correct keys?
Timeouts usually indicate a routing issue rather than an authentication problem. Verify that the target subnet is listed in
AllowedIPs and that intermediate firewalls allow UDP traffic on the configured port.
How do I troubleshoot peer accessibility issues?
Check the
LastHandshake timestamp in
wg show to ensure recent activity. If it is stale, verify endpoint reachability and NAT traversal settings. For detailed diagnostics, review our
Wireguard Peer Not Accessible Troubleshooting Guide.
Is client-to-client communication supported natively?
WireGuard supports client-to-client communication if both peers are aware of each other’s subnets and routes are configured accordingly. This requires explicit peer definitions in each client’s configuration file.