A standard full-tunnel pushes all user traffic, from Windows updates to YouTube streaming, through the corporate gateway. This overloads the channel and increases latency for critical applications.
In one project with 300 employees, the average RTT for ERP rose to 120 ms due to competition with P2P traffic. Split tunneling solves the problem: only traffic to corporate subnets goes through the tunnel, while everything else goes directly to the local internet.
Server bandwidth savings reach 60%, which at current cloud rates reduces the bill by cost calculated after audit per month (average across our projects). Contact us to evaluate your project.
Why does full-tunnel slow things down?
Full-tunnel means that all of a user's traffic is routed into the tunnel, including background syncs, streaming video, and messengers. The corporate VPN gateway is forced to process all of these packets, which leads to an increase in MTTR and reduced availability.
In our case with a distributed team of 300 people, switching to split tunneling reduced the server load by 2 times (from 2 Gbps to 800 Mbps) and reduced the ERP system response time from 120 ms to 15 ms. Split tunneling is 5 times faster than full-tunnel for the end user.
Full-tunnel vs split-tunnel comparison
| Parameter | Full-tunnel | Split-tunnel |
|---|---|---|
| Default route | All traffic through the tunnel | Only corporate subnets |
| Load on the VPN server | High | Low (up to –60% of traffic) |
| Access to local resources | Only through the VPN | Direct access |
| Latency for the user | +20–50 ms | No change |
| DNS requirements | Single DNS | Split DNS (mandatory) |
How to configure split tunneling in OpenVPN?
Configuring OpenVPN is a step-by-step process:
- Disable
redirect-gateway— do not include this directive in the client config. - Add routes to corporate subnets via
push "route". - Configure DNS via
push "dhcp-option DNS".
Example server configuration:
push "route 10.0.0.0 255.255.0.0"
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 10.0.0.53"
After restarting, the client will access corporate resources through the VPN, while the rest of the traffic (for example, YouTube) goes directly. More details in the OpenVPN documentation.
How to set up split tunneling in WireGuard?
WireGuard is configured via the AllowedIPs parameter on the client. Specify only the subnets that should be routed through the tunnel:
AllowedIPs = 10.0.0.0/16, 192.168.1.0/24, 10.100.0.0/24
If you need to exclude specific subnets (reverse split), use generation of all routes except the required ones — there are ready-made scripts for this. The official WireGuard website contains configuration examples.
Comparison of settings for different protocols
| Protocol | Parameter | Note |
|---|---|---|
| OpenVPN | Absence of redirect-gateway + push "route" |
Requires client restart |
| WireGuard | AllowedIPs |
Instant application |
| IPSec | Interface policies (split key) | Depends on implementation |
| Tailscale | accept-routes |
Automatic routing |
Split DNS — why is it a must?
Without split DNS, internal names (for example, db.internal) do not resolve. DNS queries go to the public resolver, and the user cannot connect to corporate services by name. Configuring DNS suffixes and servers for the VPN adapter solves the problem. Example for macOS/Linux via systemd-resolved:
[Resolve] DNS=10.0.0.53 Domains=~corp.company.com ~internal
On Windows — via PowerShell:
Set-DnsClientServerAddress -InterfaceAlias "VPN" -ServerAddresses 10.0.0.53
Common mistakes when configuring split DNS
- Forgetting to specify
~(tilde) before the domain in Linux — then it is not treated as a search suffix. - Specifying a DNS server without checking its availability from the VPN subnet.
- Not testing resolution on different OSes — iOS and Android have their own specifics.
What is included in split tunneling setup?
- Audit of the current VPN infrastructure: servers, protocol versions, client operating systems.
- Design of the routing scheme for corporate subnets.
- Configuration of OpenVPN, WireGuard, or other protocol servers.
- Split DNS setup for Windows, macOS, Linux, iOS, and Android.
- Testing on 5–10 pilot users.
- Operations documentation and a user guide.
- Administrator training (2 hours online).
Typical problems and their solutions
- Addressing conflict: the user's local network (for example, 192.168.1.0/24) overlaps with the corporate one. The solution is to use non-standard ranges for the VPN (172.16.x.x) or coordinate addressing with the owners of the local networks.
- Internal names do not resolve: DNS queries go to a public resolver. The solution is to configure split DNS, as described above.
- Traffic growth after enabling split tunneling: if some employees use P2P or streaming, the load on the local internet increases. The solution is to implement traffic restriction policies at the firewall level or use QoS.
Order split tunneling setup
We will handle the work turnkey within 1–2 days and provide a 30-day warranty on the configuration. We will assess your project — just write to us. Our experience — more than 50 projects implementing split tunneling in companies from 50 to 5,000 employees.
Certified specialists in OpenVPN and WireGuard. Get a consultation with a certified specialist today! The average savings on a project is about cost calculated after audit per year due to reduced load.