Split-tunneling remains one of the most powerful techniques to balance security, performance, and cost when deploying VPN clients for remote staff, contractors, or edge systems. This guide walks through practical configuration patterns, platform-specific examples, security considerations, and troubleshooting tips so site owners, engineers, and developers can implement a controlled split-tunnel policy that minimizes risks while maximizing throughput and usability.

Why use selective routing?

Full-tunnel VPNs route all client traffic through a centrally managed gateway. That approach simplifies logging, inspection, and centralized policy enforcement, but it introduces higher bandwidth usage, increased latency for internet-bound traffic, and greater load on gateway infrastructure. Split-tunneling lets you direct only sensitive or corporate destinations over the VPN while sending other traffic (e.g., CDN, video streaming, large downloads) directly to the internet, improving user experience and reducing gateway costs.

Split-tunneling is not a one-size-fits-all feature—it’s a policy decision that must balance:

  • Security: Which destinations must be protected and inspected?
  • Performance: Which flows benefit from direct routing?
  • Compliance: Are there regulatory constraints requiring inspection or egress via a specific jurisdiction?
  • Manageability: How will you push and enforce route/policy updates?

Approaches to split routing

There are three common implementation approaches, each with pros and cons:

  • Server-pushed route-based: The VPN server pushes specific subnets to the client. Easy to manage centrally and ensures corporate destinations go through the tunnel.
  • Client-side route exclusion: The client configures local routes to exclude certain destinations from the VPN (e.g., 0.0.0.0/1 and 128.0.0.0/1 technique). Useful when the default is full tunnel and you want to exempt large CIDR ranges.
  • Application-based split-tunnel: Only selected applications use the VPN (OS or third-party client-level routing). Highest granularity but more complex to enforce across diverse endpoints.

Policy considerations

Decide whether your policy will be:

  • Destination-based — route by IP/CIDR or FQDN to/from the tunnel.
  • Application-based — route traffic originated by certain processes through the tunnel.
  • Port/service based — rare, but possible (e.g., route SMTP or RDP via VPN).

OpenVPN: practical server and client configurations

OpenVPN supports pushed routes (server side) and client-side controls like route-nopull. Example patterns:

Server-pushed destination routes

On the OpenVPN server config (server.conf / server.ovpn), push specific networks:

push "route 10.10.0.0 255.255.0.0"

This ensures 10.10.0.0/16 is routed via the VPN for connected clients. If you need to force DNS through the tunnel: push "dhcp-option DNS 10.10.0.5".

Client-side exclusion

If the server pushes a default route but a client should bypass the tunnel for internet, use route-nopull in the client config then selectively add back corporate routes:

route-nopull
route 10.10.0.0 255.255.0.0

On Windows, OpenVPN GUI also supports per-profile route overrides. Remember that Windows route metrics can influence which gateway is chosen; verify metrics with route print.

WireGuard: using AllowedIPs for selective routing

WireGuard’s split-tunneling model is both simple and powerful: the AllowedIPs field on a peer defines which destination IPs are routed through that peer. For example, to route only corporate subnets:

[Peer]PublicKey = <server-key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.10.0.0/16, 10.20.0.0/24

To emulate a default route (full tunnel): include 0.0.0.0/0 and ::/0. To implement split-tunnel, do not include those. For multi-homed clients, use Linux policy routing or route metrics to prefer the corporate peer for AllowedIPs while keeping internet direct for other traffic.

Platform specifics: Windows, macOS, Linux, iOS, Android

Windows

Windows treats VPN connections as network interfaces and updates system routing tables. Key tips:

  • Check “Use default gateway on remote network” to enable full tunnel; uncheck to keep split-tunnel. For OpenVPN, this corresponds to presence/absence of pushed default route.
  • For DNS, use netsh interface ip set dns and confirm resolver order. Windows uses a per-interface DNS resolver strategy which can cause leaks—use conditional forwarders or DNS over HTTPS (DoH) for critical queries.
  • Control WebRTC leaks in browsers by disabling peer-to-peer or configuring browser settings/extensions.

macOS

macOS supports route-based and app-based VPNs (via Network Extension). When using OpenVPN or WireGuard clients, confirm the routing table with netstat -nr or route -n get. App-based splits are often enforced by the client and require kernel extensions or Network Extension APIs for per-app control.

Linux

Linux gives the most control. Use ip route and ip rule for advanced policy routing. Example: create a routing table for VPN and direct only corporate subnets there.

Commands outline:

ip rule add from 10.0.0.0/24 lookup 200
ip route add default via 10.8.0.1 dev tun0 table 200
ip route add 10.10.0.0/16 dev tun0

iptables can be used to restrict which packets are allowed into the tunnel interface (e.g., only specific source ports or user IDs), and nftables provides more modern alternatives.

Mobile (iOS / Android)

Both platforms support split-tunnel but with OS-managed constraints. iOS Network Extension provides per-app VPN; Android’s VpnService API allows per-app routing on modern versions. Manage DNS carefully—mobile OSes can leak DNS queries to the system resolver if per-app tunnels are not properly configured.

DNS and leak prevention

DNS leaks are a common attack vector when split tunneling is misconfigured. Consider these practices:

  • Push corporate DNS servers via VPN and configure clients to use those for corporate domains (conditional DNS).
  • Use DNS forwarding on the VPN gateway for split-horizon resolution—return internal records only for internal queries.
  • Enable DNS over TLS/HTTPS where possible, especially for direct-to-internet flows.
  • Block outbound DNS queries to external resolvers from endpoints unless explicitly allowed.

IPv6: don’t forget it

Many environments ignore IPv6, causing accidental bypasses. Ensure your VPN handles IPv6 either by:

  • Routing IPv6 subnets via the tunnel (WireGuard: include ::/0 when you want a default route), or
  • Disabling IPv6 on endpoints where you cannot guarantee proper handling, or
  • Implementing firewall rules that drop unwanted IPv6 traffic at the host until the VPN is active.

Security controls and hardening

Split-tunneling increases the attack surface because some traffic bypasses the corporate inspection points. Mitigation strategies:

  • Enforce endpoint security: EDR, up-to-date OS patches, host firewall rules, and application allowlists.
  • Restrict split-tunnel to known safe services and IP ranges—avoid allowing arbitrary internet traffic to bypass controls for privileged users.
  • Combine split-tunnel with Zero Trust policies: require MFA, device compliance checks, and micro-segmentation for critical assets.
  • Log locally and centrally: ensure clients still report telemetry and security events even when traffic is direct-to-internet.

Testing and verification

After applying split-tunnel policies, validate routing and leak protection:

  • Check route tables: ip route (Linux), route print (Windows), netstat -nr (macOS).
  • Verify DNS: perform queries for internal hosts and internet domains; confirm which resolver answers.
  • Use traceroute/tracert to see the path for corporate and internet destinations.
  • Test WebRTC and browser-based leaks with specialized online tools, but also ensure these do not expose internal addresses.
  • Monitor logs on your VPN gateway for unexpected direct-to-internet patterns from users who should be full-tunnel.

Operational best practices

To operate split-tunnel at scale:

  • Standardize client configs in your deployment tooling (configuration management, MDM, or custom installers).
  • Use versioned, auditable server-side route pushes so changes can be rolled back quickly.
  • Maintain an approved CIDR list for corporate assets and update it via automation (e.g., CI/CD or API-driven push to VPN server).
  • Document exceptions and keep short-lived exemptions for contractors or special projects.

Troubleshooting checklist

  • Are routes present on the client for intended subnets? (If not, server push may be misconfigured or client rejected the routes.)
  • Is DNS resolving internal names correctly? If not, check pushed DNS options and interface metrics.
  • Are there duplicate default routes with conflicting metrics? Adjust interface metrics or remove pushed default route.
  • Any IPv6 traffic bypassing the tunnel? Either route IPv6 via VPN or disable it on the client.

Split-tunneling is a nuanced tool: when carefully designed and enforced, it reduces latency and cost without sacrificing control over sensitive traffic. Implement the right combination of server- and client-side routing rules, secure DNS, host hardening, and ongoing monitoring to keep the balance between usability and security.

For more in-depth guidance and managed Dedicated IP VPN solutions that support advanced split-tunneling policies, visit Dedicated-IP-VPN.