DefaultRoute=false in the [Interface] section of your configuration file. This prevents the VPN from overriding your system's default gateway, allowing traffic to flow normally for non-routed destinations while only specific subnets are directed through the encrypted tunnel. Without this setting, all internet traffic is forced through the VPN regardless of your routing rules.
Split tunneling allows you to route only specific traffic through a VPN while letting other traffic use your regular internet connection. This is useful for accessing remote resources securely without slowing down general browsing or local network access. By carefully configuring both the client and server sides, you can achieve precise control over which packets traverse the encrypted tunnel.
Understanding DefaultRoute Behavior
The most common mistake when setting up split tunneling is assuming thatAllowedIPs alone controls routing behavior. In WireGuard, the AllowedIPs directive defines which incoming traffic is accepted and sets up corresponding routes on the interface. However, by default, WireGuard also sets the default route (0.0.0.0/0) to point through the VPN interface. This means that even if you specify only local subnets in AllowedIPs, your entire internet traffic will still be routed through the VPN peer.
To prevent this, you must explicitly disable the automatic default route. This is done by adding DefaultRoute=false to the [Interface] section. When this flag is false, WireGuard will not install a default gateway entry in the kernel routing table. Instead, it will only install routes for the networks specified in AllowedIPs. This leaves your existing default gateway intact, ensuring that traffic destined for addresses outside the allowed IP ranges continues to use your standard ISP connection.
Configuring the Client Interface
The client configuration requires careful attention to both the[Interface] and [Peer] sections. Start by defining your local network details in the interface section, including your private key and an IP address that does not conflict with your existing network. Then, add the DefaultRoute=false directive.
[Interface]
PrivateKey = your_client_private_key
Address = 192.168.41.2/32
DNS = 1.1.1.1
DefaultRoute = false
[Peer]
PublicKey = server_public_key
Endpoint = vpn.example.com:51820
AllowedIPs = 10.0.0.0/8, 192.168.1.0/24
PersistentKeepalive = 25
In this example, the AllowedIPs field includes two ranges: 10.0.0.0/8 for the main corporate network and 192.168.1.0/24 for a specific subnet. Any traffic destined for these networks will be sent through the WireGuard tunnel. Traffic for any other destination, such as 8.8.8.8 or your local router at 192.168.0.1, will bypass the VPN and use the normal network interface. Note that you should avoid adding 0.0.0.0/0 to AllowedIPs unless you intentionally want full tunneling.
Server-Side Configuration
On the server side, you need to ensure that theAllowedIPs for each client match the specific subnets they should access. If you leave AllowedIPs as 0.0.0.0/0 on the server, it might accept all traffic from the client, but the client's routing decisions are still governed by its own configuration. It is best practice to align the server's AllowedIPs with the client's needs to maintain security boundaries.
Additionally, ensure that IP forwarding is enabled on the server if it acts as a gateway for the tunneled traffic. You can check this by running sysctl net.ipv4.ip_forward. The value should be 1. If it is zero, enable it temporarily with sysctl -w net.ipv4.ip_forward=1 or make it permanent in /etc/sysctl.conf.
Verifying Routing Tables
After starting the WireGuard service, verify that the routing table reflects your split tunneling setup. Use theip route show command to inspect the current routes. You should see specific entries for the networks defined in AllowedIPs pointing to the wg0 (or your configured interface) device. Crucially, you should NOT see a default route (default via ... dev wg0). If a default route exists on the WireGuard interface, your split tunneling has failed, and all traffic is likely going through the VPN.
If you encounter issues where traffic is not reaching the intended destinations, check your firewall rules. Ensure that the necessary ports are open and that no intermediate firewalls are blocking the UDP traffic. For more details on managing default gateways, you might find How to Make a Server Not Use VPN as a Default Gateway helpful for understanding broader routing principles.
Troubleshooting Common Issues
One frequent problem is DNS leakage. Even with correct routing, your DNS queries might still go through the VPN provider if your system uses the VPN's DNS servers. To fix this, ensure yourDNS setting in the [Interface] section points to reliable resolvers that you trust, or configure your OS to use your local ISP's DNS for non-tunneled traffic. Another issue is connectivity loss if the VPN drops. Since DefaultRoute=false prevents automatic failover, you may need to implement a script or tool to monitor the VPN status and adjust routes manually if necessary.
For clients trying to communicate with each other through the VPN, refer to Troubleshooting WireGuard Client-to-Client Communication Issues if you face unexpected packet drops between peers.
Frequently Asked Questions
What happens if I forget to set DefaultRoute=false?
If you omit this setting, WireGuard will automatically install a default route through the VPN interface. This causes all internet traffic to be routed through the VPN, effectively creating a full tunnel instead of a split tunnel. Your local network access and non-tunneled websites will become inaccessible until the VPN connection is terminated.
Can I use split tunneling with IPv6?
Yes, but you must handle IPv6 separately. Add Address = fd00::2/128 (or similar) to your interface and include IPv6 prefixes in AllowedIPs. Ensure DefaultRoute=false applies to both address families, or explicitly manage IPv6 routes to prevent them from leaking through the tunnel unintentionally.
How do I allow my local printer to work while connected?
Add your local subnet to the AllowedIPs list on the client, for example, AllowedIPs = 192.168.1.0/24, 10.0.0.0/8. This ensures that traffic destined for your local network bypasses the VPN and uses the physical network interface directly.
Does DefaultRoute=false affect ping to the VPN server?
No, because the route to the VPN server itself is typically established via your default gateway before the WireGuard interface becomes active. However, if you cannot reach the server, check that your outbound UDP port is open and that no local firewall blocks the initial handshake.
Why is my split tunneling not working after a reboot?
This often occurs if the WireGuard service starts before your network manager has established the primary default route. Ensure that WireGuard dependencies are correctly ordered in your systemd unit file, or use a network manager hook to apply configurations after connectivity is established.