Split-tunneling has become a pivotal feature for organizations and developers who want to balance privacy, compliance, and network performance when using VPNs. Rather than sending all traffic through a VPN tunnel, split-tunneling allows selective routing—sending specified IP ranges or application traffic over the VPN while allowing other traffic to use the direct internet path. This article dives into configuration approaches, platform-specific examples, routing mechanisms, security trade-offs, and operational best practices that help optimize VPN performance without sacrificing security.

Why split-tunneling matters for enterprises and developers

Traditional full-tunnel VPNs ensure that all client traffic traverses the corporate network or a VPN exit node. While this model simplifies security controls and monitoring, it introduces several drawbacks for modern use cases:

  • Increased bandwidth and latency: Routing non-business traffic (e.g., large software updates or cloud services) through a central VPN gateway consumes bandwidth and increases round-trip time.
  • Scalability limits: Centralized gateways can become bottlenecks as remote workforces grow.
  • Unnecessary egress: Accessing local resources or geolocated services can be inefficient when exiting via a distant VPN endpoint.

Split-tunneling addresses these issues by allowing granular traffic selection, improving performance and reducing infrastructure costs—provided it is implemented with secure policies and controls.

Split-tunneling models and policies

There are several split-tunneling models to choose from, each with different operational implications:

  • Network-based split-tunneling (route-based): Configure IP routing so that specific destination networks are sent over the VPN while other destinations use the local default gateway.
  • Application-based split-tunneling: Only traffic generated by particular applications is routed through the VPN (e.g., corporate apps), with other applications using the LAN/Wi-Fi.
  • Per-host or per-service split-tunneling: Individual hosts or services’ IPs/subnets are routed via the VPN (useful for hybrid cloud access).
  • Inverse split-tunneling: Only corporate traffic is allowed via VPN, everything else is blocked or sent locally depending on policy.

Choice of model depends on security posture: application-based controls are often safer than broad route-based split-tunneling because they minimize exposure of the corporate network to unmanaged traffic.

Routing fundamentals and key terms

Understanding IP routing and policy-based routing is essential when configuring split-tunneling.

  • Default gateway: The route used when no specific route exists for a destination (0.0.0.0/0).
  • Static routes: Manually added routes telling the OS to send traffic for certain prefixes to a specified gateway.
  • Policy-based routing (PBR): Routing decisions based on packet attributes (source IP, source port, or application) rather than just destination.
  • Routing table priority: More specific routes (longer prefix) take precedence over less specific ones.

Platform-specific configuration examples

OpenVPN (route-based split tunneling)

OpenVPN commonly uses route directives to implement split-tunneling. The server can push specific routes to clients, or clients can add local routes.

Server-side push example (server.conf):

push "route 10.10.0.0 255.255.255.0"

This instructs clients to route 10.10.0.0/24 via the VPN tunnel. On the client, prevent default-route push by using:

pull-filter ignore "redirect-gateway"

Client-side static routes (Linux):

ip route add 10.10.0.0/24 via 10.8.0.1 dev tun0

Windows (OpenVPN GUI) can use route-up scripts or the –route directive in client config.

WireGuard (simple and fast routing)

WireGuard uses simple routing with interface-based configuration. You declare AllowedIPs per peer which serves both as routing and access control.

Example peer block for split tunneling:

[Peer] PublicKey = <server-key>
AllowedIPs = 10.10.0.0/24, 203.0.113.50/32

Only packets destined for the listed AllowedIPs will be routed over WireGuard; the rest follow the host’s default route.

Windows: App-based split tunneling (Microsoft Endpoint Manager / Intune)

Windows 10/11 with modern VPN clients or Intune allows configuring app-triggered VPNs (per-app VPN). Administrators can define which UWP or Win32 apps launch the VPN connection and route only their traffic through the tunnel.

For traditional VPN clients, you can disable “Use default gateway on remote network” in the adapter’s IPv4 settings to prevent full-tunnel behavior, then add static routes via route add.

macOS and iOS: Network Extensions and per-app VPN

Apple platforms support per-app VPN through MDM solutions and the Network Extension framework. Administrators can push a per-app VPN profile that automatically routes only managed app traffic into the VPN tunnel.

Firewall and NAT considerations

Split-tunneling affects firewall rules and NAT:

  • If corporate resources expect a known source IP (e.g., for allowlisting), ensure traffic routed through VPN retains the expected source network—configure NAT on the VPN gateway if necessary.
  • Implement host-level firewall rules to restrict which processes can open sockets destined for the VPN interface (application-based split tunneling).
  • For route-based split tunneling, configure firewall policies on the gateway to enforce access controls for tunneled subnets, and consider reverse path filtering (rp_filter) on Linux to prevent spoofed traffic.

Preventing DNS leaks and ensuring name resolution

Splitting tunnels introduces a common pitfall: DNS leaks. If DNS queries bypass the VPN or go to an insecure resolver, it can reveal user activity and undermine privacy.

  • Use VPN-enforced DNS: Configure the VPN to push DNS servers to clients (OpenVPN push “dhcp-option DNS x.x.x.x”, WireGuard: set DNS under interface block for clients).
  • Application or per-domain DNS policies: Use DNS split-view or conditional forwarding so that corporate domains resolve via corporate DNS while public domains use public resolvers.
  • Local resolver hardening: On endpoints, lock down resolv.conf or use DNS over TLS/HTTPS for split-resolved domains to prevent tampering.

Security trade-offs and mitigations

Split-tunneling inherently increases the attack surface because endpoints can access both the corporate network and the public internet simultaneously. Key mitigations include:

  • Endpoint protection: Require EDR, next-gen AV, and host-based firewalls on clients. Use posture checks before allowing VPN connections.
  • Zero Trust and least privilege: Implement micro-segmentation, least-privilege access, and granular access controls on services—do not rely solely on network perimeter.
  • Multi-factor authentication and device attestation: Enforce strong auth for VPN connections and verify device compliance via device certificates or MDM signals.
  • Logging and detection: Centralize logs for tunneled traffic and endpoint events to detect lateral movement or data exfiltration attempts.
  • Conditional split-tunneling: Only enable split-tunneling for devices meeting compliance standards (e.g., patched OS, corporate-managed browsers).

Advanced techniques: Policy-based routing and containerized apps

Policy-based routing (PBR) lets you route traffic based on source address, mark, or firewall rule. On Linux, use iptables/ip rule/ip route configurations to implement PBR:

Example (Linux):

iptables -t mangle -A OUTPUT -p tcp --dport 443 -m owner --uid-owner 120 -j MARK --set-mark 0x1
ip rule add fwmark 0x1 table 200
ip route add default via 10.8.0.1 dev tun0 table 200

This routes traffic from a specific user (UID 120, e.g., a corporate app) over the VPN. Combined with containerization, you can run corporate apps inside containers or VMs and route only those containers’ traffic through the tunnel, simplifying policy enforcement.

Testing, validation, and monitoring

After configuring split-tunneling, validate both routing and security:

  • Verify routing tables: ip route (Linux), route print (Windows), or WireGuard’s wg show.
  • Check DNS: Use dig or nslookup to confirm which resolver is authoritative for corporate domains and ensure DNS queries for sensitive domains traverse the VPN.
  • Test for leaks: Use public leak-test services to ensure WebRTC, DNS, and IP leaks are not exposing private addresses when split-tunnel is active.
  • Monitor performance: Compare latency and throughput for tunneled vs non-tunneled flows; consider QoS for business-critical tunneled traffic.
  • Log correlation: Ensure your SIEM correlates endpoint logs, VPN logs, and network gateway logs to identify anomalous patterns.

Operational best practices

  • Document policies clearly: Maintain configuration guides, justification for split-tunnel rules, and an approval process for changes.
  • Limit scope: Prefer application-based or per-service split-tunneling over broad 0.0.0.0/0 exclusions.
  • Automate compliance checks: Integrate MDM and vulnerability scanners to automatically deny split-tunnel to non-compliant devices.
  • Plan for incident response: Include endpoint isolation procedures for devices that may be compromised while split-tunneled.
  • Periodic review: Regularly review routing rules and AllowedIPs to remove stale or overly permissive entries.

Conclusion

Split-tunneling is a powerful tool for optimizing VPN performance and reducing centralized load when implemented carefully. The right approach balances routing efficiency with security controls—favoring per-app or per-service split-tunneling when possible, enforcing strong endpoint posture checks, and using DNS and firewall policies to avoid leaks. For developers and system administrators, leveraging policy-based routing, containerization, and modern VPN technologies like WireGuard can make split-tunneling both performant and manageable.

For practical deployments, always validate your configuration in a controlled environment and incorporate monitoring and automated compliance gates before rolling out to production.

Dedicated-IP-VPN — https://dedicated-ip-vpn.com/