Split tunneling remains one of the most practical techniques for balancing privacy, performance, and access to local network resources when using a VPN. For organizations and developers relying on L2TP/IPsec VPNs — still common for legacy systems and built-in OS support — enabling split tunneling requires a careful mix of VPN server configuration, client routing rules, and security controls. This guide provides a concise yet technically detailed walkthrough to enable split tunneling in L2TP setups while minimizing risk.

Understanding split tunneling and L2TP/IPsec

Split tunneling means only specified traffic flows through the VPN tunnel while other traffic goes directly to the internet. There are two common approaches:

  • Policy-based split tunneling: traffic is selected by IP prefixes, destination ports, or application policies and routed via the tunnel.
  • Route-based split tunneling: the VPN creates a virtual interface and uses routing tables to determine which subnets go through the tunnel.

L2TP is a layer 2 tunneling protocol usually paired with IPsec for encryption. Typical Linux server stacks use xl2tpd for the L2TP daemon and strongSwan/Libreswan for IPsec. Windows, macOS, iOS, and Android have built-in L2TP clients. Split tunneling can be applied either at the server side (pushing routes to the client) or at the client side (local route adjustments).

Server-side vs client-side split tunneling: pros and cons

Server-side (pushing routes)

  • Advantages: Central control, consistent routing policies, easier to audit and log.
  • Disadvantages: Requires configuring VPN server and possible client compatibility issues; may not work with all OS L2TP clients (some clients accept “local network access” only).

Client-side (manual routes)

  • Advantages: More flexible for end-user control, useful when server cannot push routes.
  • Disadvantages: Harder to manage at scale and prone to user misconfiguration.

Key security considerations

When enabling split tunneling with L2TP/IPsec, keep these points in mind:

  • DNS leaks: Ensure the DNS for tunneled destinations is using secure resolvers (or a DNS resolver inside the tunnel). Consider pushing DNS server addresses via the VPN or configuring clients to use conditional DNS.
  • Policy enforcement: Critical traffic (e.g., AD, SSO endpoints, monitoring) should always be forced through the tunnel.
  • Network segmentation: Restrict what tunneled clients can access on the private network using firewall rules and access control lists.
  • Logging and monitoring: Maintain logs for tunnels and critical route changes to detect anomalies.
  • Crypto settings: Use strong IPsec ciphers (e.g., AES-GCM, SHA2, and modern key exchange) and avoid legacy settings.

Example server-side configuration (Linux: strongSwan + xl2tpd)

Below is a high-level approach to push routes to clients so only certain subnets use the VPN. On an L2TP/IPsec server you typically configure IPsec connection profiles to allow traffic selectors that limit which remote networks are encrypted. For modern strongSwan setups, use the “leftsubnet” and “rightsubnet” or use virtual IPs with specific policy. With L2TP, PPP assigns an IP to the client; you can then route specific private subnets to the PPP interface.

Steps:

  • Enable IP forwarding on the server: echo 1 > /proc/sys/net/ipv4/ip_forward.
  • Configure strongSwan to accept connections but do not set a 0.0.0.0/0 route in the IPsec policy; instead specify only the internal networks that should traverse the tunnel.
  • In xl2tpd’s PPP options, ensure the server pushes only required routes using pppd options like ms-dns and ipparam to tag sessions for per-user routing.
  • On connection, create ip rule/ip route entries that route only specified subnets via the client’s pppX interface.

For example, to route 10.0.0.0/8 and 172.16.0.0/12 across the ppp interface when a client connects, a server-side script (invoked by pppd’s ip-up) could add:

ip route add 10.0.0.0/8 dev ppp0

ip route add 172.16.0.0/12 dev ppp0

And remove them on disconnection with ip-down. This results in route-based split tunneling enforced by the server’s routing tables rather than by pushing a full-tunnel default route.

Client-side setup — Windows

Windows L2TP clients typically set the “Use default gateway on remote network” option to control full vs split tunneling. To enable split tunneling:

  • Open the VPN connection properties → Networking → Internet Protocol Version 4 (TCP/IPv4) → Properties → Advanced.
  • Uncheck “Use default gateway on remote network”. This disables the default route via VPN and keeps local internet traffic out of the tunnel.
  • Manually add routes for private subnets that must go through the VPN using route add or persistent routes with route -p add 10.0.0.0 mask 255.0.0.0 . Note the gateway is typically the VPN-assigned address or the PPP interface index.

For managed environments, push routes via Group Policy scripts or use an automatic post-connection script to add the necessary routes. Windows RRAS server administrators can also configure “Static Routes” per user/session.

Client-side setup — macOS and iOS

On macOS and iOS built-in L2TP clients, split tunneling behaviour is limited. macOS System Preferences → Network → VPN → Advanced has an option “Send all traffic over VPN.” Leave this unchecked to enable split tunneling by default. However, macOS may still alter DNS resolution. To reliably route specific subnets via tunnel:

  • Use networksetup or route commands on macOS to add static routes: sudo route -n add 10.0.0.0/8 .
  • On iOS you cannot add manual routes without MDM. For enterprises, use an MDM solution (like Apple Configurator/MDM) that can push per-app VPN or split tunneling policies.

Client-side setup — Linux

Linux gives full control over routing. With L2TP clients like NetworkManager-l2tp or xl2tpd, follow this pattern:

  • Disable automatic default route from PPP by passing nopcomp and noaccomp and using the pppd option defaultroute only when full-tunnel is desired.
  • After the ppp interface comes up (e.g., ppp0), add specific routes: ip route add 10.0.0.0/8 dev ppp0.
  • For policy routing per-user, create a separate routing table in /etc/iproute2/rt_tables and use ip rule to direct traffic from the VPN-assigned IP into that table.

Example for policy routing:

ip rule add from 10.10.10.100/32 table vpnclient

ip route add default dev ppp0 table vpnclient

This sends traffic originating from the client’s VPN IP through the ppp0 table while keeping other traffic on the regular table.

Mobile (Android) considerations

Android’s built-in L2TP client may not allow granular route control. Many enterprise Android devices use third-party VPN clients (OpenVPN, strongSwan) or an EMM that supports split tunneling. For Android 5+ with VPN Service API, apps can set allowed/disallowed lists. For standard L2TP clients:

  • Check device settings for “Use VPN for” or “Connect to network resources” options.
  • Use an MDM/Enterprise mobility management solution to push split tunneling policies where needed.

DNS handling and avoiding leaks

Split tunneling often leads to DNS leaks when the client uses local DNS for domain names that should resolve to private addresses. Best practices:

  • Push DNS server addresses for internal domains via the PPP options (ms-dns).
  • Use conditional DNS or split-horizon DNS so internal names resolve via internal servers while public names go to public resolvers.
  • On clients, configure per-domain DNS (e.g., systemd-resolved, dnsmasq) so that queries for internal domain names go to the tunnel’s DNS server.

Testing and verification

Validate configuration with these checks:

  • On the client, verify routing table entries (ip route, route print).
  • Use traceroute/tracert to confirm path for internal vs external destinations.
  • Check public IP and DNS (e.g., via a trusted site) for leak detection: tunneled traffic should show the VPN exit IP if you expect it to, while non-tunneled traffic should show local IP.
  • On the server, review firewall logs and pppd/strongSwan logs to ensure only intended subnets traverse the tunnel.

Operational tips for administrators

  • Inventory clients: Different OSes behave differently. Maintain a matrix of platforms and supported split tunneling mechanisms.
  • Automate scripts: Use connection up/down scripts to install/remove routes reliably and idempotently.
  • Enforce critical paths: Force traffic to critical systems through VPN by using server-side routing and firewall rules.
  • Review crypto policies: Periodically update IPsec settings to use modern algorithms and disable weak ones.

Split tunneling can significantly improve performance and user experience when done correctly, but it must be governed by policy and technical controls to avoid exposing sensitive resources. With L2TP/IPsec, the safest approach for enterprises is to manage split tunneling centrally when possible (server-side pushed routes or MDM-driven client policies). For unmanaged or BYOD environments, clear documentation and client automation are essential.

For an in-depth deployment tailored to your infrastructure (strongSwan, xl2tpd, Windows RRAS, macOS Server or mobile device management), consult the product-specific documentation and consider a staged rollout to monitor behavior before broad adoption.

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