To configure a split WireGuard tunnel that grants access to the server itself, you must explicitly include the server's local IP address in the client configuration. By default, only traffic destined for specified peer subnets is routed through the tunnel. Adding the server's private interface IP to the
AllowedIPs list ensures that packets intended for administration or local services are correctly forwarded over the encrypted link rather than being dropped or sent via the default gateway.
Understanding Split Tunneling Behavior
WireGuard operates on a strict policy where traffic is only encapsulated if it matches the
AllowedIPs defined in the configuration. When you set up a standard tunnel, you typically specify a subnet such as
10.0.0.0/24. This tells the kernel module to route any traffic destined for that range through the virtual network interface. However, this does not automatically include the WireGuard server's own loopback or interface addresses unless they fall within that subnet.
If you attempt to SSH into the server or access a web service running directly on the WireGuard endpoint using its private IP, the connection will fail if that IP is not listed in
AllowedIPs. The operating system sees no route for that specific destination through the tunnel and may try to send it out via the physical network interface, which often results in connectivity issues because the return path is not symmetrically configured for the tunnel.
This behavior is distinct from full-tunnel VPNs where all traffic is forced through the provider. In a split tunnel setup, precision is key. You must manually define every IP range or host address that needs to traverse the encrypted channel. This includes not just the remote LAN subnets but also the immediate endpoints of the tunnel itself.
Configuring Multiple Allowed IPs
The core solution lies in modifying the
[Peer] section of your client configuration file. WireGuard allows multiple CIDR ranges to be specified for a single peer by separating them with commas. This feature enables you to create a comprehensive routing table that covers various destinations without requiring multiple peer entries.
For example, if your server has an IP address of
10.0.0.1 and your internal network uses the
192.168.1.0/24 subnet, you can combine these into a single line. The configuration should look like this:
[Peer]
PublicKey = ...
Endpoint = ...
AllowedIPs = 10.0.0.1/32, 192.168.1.0/24
Using
/32 for the server IP ensures that only traffic specifically targeting that single host is routed through the tunnel. If you used
10.0.0.0/24, you would route an entire block of addresses, which might inadvertently capture other devices on the same subnet that you do not wish to reach via the tunnel. It is crucial to use the most specific mask possible to avoid unintended routing leaks.
You can add as many comma-separated values as needed. Whether you need to reach a database at
10.0.0.5 or a DNS resolver at
10.0.0.2, listing them individually provides granular control. This approach prevents the "all-or-nothing" routing problem and keeps your tunnel efficient.
Verifying Routing Tables
After updating the configuration, you must ensure the Linux kernel recognizes the new routes. Use the
ip route command to inspect the current routing table associated with the WireGuard interface. Typically, the interface is named
wg0 or similar.
Run the following command to view relevant routes:
ip route show dev wg0
You should see entries corresponding to each IP or subnet listed in
AllowedIPs. If the server IP is missing from this output, the tunnel will not function for administrative access even if the configuration file appears correct. Restarting the WireGuard service after editing the config file is often necessary to flush old routes and apply the new ones:
sudo systemctl restart wg-quick@wg0
Always verify that the public key and endpoint remain unchanged during this process. Modifying unrelated fields can break the handshake. Focus solely on expanding the
AllowedIPs list to include the necessary server addresses.
Common Pitfalls and Troubleshooting
A frequent error is omitting the server IP entirely and assuming the tunnel handles all local traffic. Another mistake is using overlapping subnets that conflict with existing network routes. For instance, if your local machine is on
192.168.1.0/24 and you accidentally route that entire subnet through the tunnel, you may lose local internet access or cause routing loops.
Ensure that the server's firewall permits incoming connections on the ports you intend to use. Even with correct routing, iptables or ufw rules can block traffic. Check the server's logs for dropped packets if connectivity remains elusive. Additionally, confirm that the client's
PrivateKey matches the server's
PublicKey pair to avoid authentication failures that mimic routing issues.
For more details on handling complex routing scenarios, refer to our guide on
Bypass/split tunnel wireguard. If you encounter issues with clients communicating directly, check
Troubleshooting WireGuard Client-to-Client Communication Issues.
Frequently Asked Questions
Can I use a wildcard for AllowedIPs?
Yes, you can use
0.0.0.0/0 to route all traffic through the tunnel, but this defeats the purpose of split tunneling. It forces all internet traffic through the VPN, which may slow down speeds and expose non-sensitive data. Use specific subnets instead to maintain privacy and performance.
What happens if I forget the server IP in AllowedIPs?
You will lose direct access to the WireGuard server's management interface or services running on its private IP. Traffic destined for that IP will be sent via your default gateway, likely resulting in a connection timeout since the return path is not encrypted through the tunnel.
Does WireGuard support IPv6 in AllowedIPs?
Absolutely. You can mix IPv4 and IPv6 addresses in the
AllowedIPs field. For example,
fd00::1/128, 10.0.0.0/24 is valid. Ensure your server is also configured to handle IPv6 traffic if you plan to use this feature.
How do I remove a route from AllowedIPs?
Simply edit the
AllowedIPs line in the configuration file and delete the unwanted IP or subnet. Save the file and restart the WireGuard service to apply the changes. The kernel will automatically remove the corresponding route entry.
Is it safe to route my entire home network through the tunnel?
It is generally unsafe unless you fully trust the VPN provider. Routing your local network through a remote VPN can expose local devices to external attacks or cause latency issues. Stick to splitting only the necessary remote resources.