Why Full Tunneling is a Productivity Nightmare
You just turned on your VPN to SSH into a company server, and suddenly your Google Meet call freezes. Or worse, watching a YouTube tutorial becomes a luxury as the loading circle spins endlessly. This is the consequence of a default Full Tunnel configuration, where every bit of data from your computer is forced through the narrow VPN tunnel before reaching the internet.
I once managed infrastructure for an office of 50 employees. When I first deployed WireGuard, I used the default configuration for everyone. Within 15 minutes, the engineering department was complaining about lag. In reality, they only needed the VPN to access the datacenter’s 10.0.0.0/24 IP range. However, the VPN was also “swallowing” traffic destined for Facebook and Netflix. That’s when I realized I had to switch to Split Tunneling immediately.
Split Tunneling helps you intelligently separate data flows. Important and secure traffic goes through the VPN, while the remaining public data goes directly through your Internet Service Provider (ISP). This approach reduces VPN server load by up to 80% and ensures that latency for gaming or online meetings stays at a minimum.
Core Concept: AllowedIPs in WireGuard
The key to Split Tunneling lies in the AllowedIPs parameter. Unlike older protocols that use complex scripts, WireGuard uses this list for two purposes. First, it determines which destination IPs should be encrypted and sent through the tunnel. Second, it verifies if incoming packets from the tunnel have a valid source address.
If you set AllowedIPs = 0.0.0.0/0, you are using a Full Tunnel. To switch to Split Tunneling, you simply need to list the specific internal IP ranges you require.
Practice 1: Routing by IP Range (CIDR)
Suppose your office server is in the 192.168.10.0/24 range and Docker services are running at 172.16.0.0/16. You want to use the VPN only when accessing these two ranges.
Open the configuration file at /etc/wireguard/wg0.conf:
sudo nano /etc/wireguard/wg0.confEdit the [Peer] section as follows:
[Interface]
PrivateKey = <YOUR_PRIVATE_KEY>
Address = 10.0.0.2/24
DNS = 1.1.1.1
[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = vpn.company.com:51820
# Route only internal IP ranges and the VPN Server's own IP
AllowedIPs = 192.168.10.0/24, 172.16.0.0/16, 10.0.0.1/32
PersistentKeepalive = 25Quick Explanation:
192.168.10.0/24: For LAN servers.172.16.0.0/16: For internal container services.10.0.0.1/32: The VPN Server’s own IP for remote management.
After saving, restart the interface:
sudo wg-quick down wg0 && sudo wg-quick up wg0Now, the ip route command will show that the specified IP ranges are pointed through wg0, while default traffic still goes through your home router.
Practice 2: Routing by Domain Name
WireGuard does not natively support domains in AllowedIPs. If you enter a domain there, it only resolves the IP once at startup. If the server’s IP changes, the connection will break. The solution is to use a PostUp script combined with the dig command.
Update the wg0.conf file as follows:
[Interface]
PrivateKey = <YOUR_PRIVATE_KEY>
Address = 10.0.0.2/24
# Automatically fetch the domain IP and add it to the route table when the VPN starts
PostUp = ip route add $(dig +short internal.corp.com | tail -n1)/32 dev wg0
PostDown = ip route del $(dig +short internal.corp.com | tail -n1)/32 dev wg0
[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = vpn.company.com:51820
AllowedIPs = 10.0.0.0/24Don’t forget to install dnsutils using sudo apt install dnsutils to have the dig command available.
Fixing DNS Leaks Once and For All
Many users find that even with correct IP routing, they still cannot access internal websites. This is often because the computer is still querying the ISP’s DNS server, which knows nothing about your company’s private domains. If you are using Ubuntu 20.04 or later, systemd-resolved is an excellent lifesaver.
Add this smart configuration line to the [Interface] section:
DNS = 10.0.0.1, corp.comThis configuration forces the computer to query the VPN Server (10.0.0.1) only for domains ending in .corp.com. Other requests, like Google or Facebook, will still use the default DNS for optimal speed.
Testing the Results
Don’t just assume everything is working. Verify it with these 3 simple steps:
- Inspect the routing table: Type
ip route show. You should see the internal IP ranges pointing todev wg0. - Check your public IP: Run
curl ifconfig.me. The result should be your ISP’s IP (e.g., Comcast, AT&T), not the VPN’s IP. - Test internal connectivity:
ping 192.168.10.1. If it responds, you’ve succeeded.
Conclusion
Mastering Split Tunneling makes WireGuard much more refined. Instead of forcing the entire system to suffer from slow speeds, you only need 5 minutes to filter out what is truly necessary. This approach saves server resources and keeps your workflow smooth. Good luck with your configuration!
