Virtual Private Networks using L2TP (Layer 2 Tunneling Protocol) atop IPsec are common in enterprise deployments because they combine simplicity with broad OS support. However, administrators frequently encounter routing conflicts when clients connect: traffic that should flow over the tunnel goes out the local network, or remote subnet routes collide with local LAN addresses. This article digs into the technical causes behind L2TP routing conflicts and provides practical, tested fixes for Windows, Linux, and macOS endpoints as well as server-side configurations.

Why L2TP routing conflicts occur: core mechanisms

At a high level, routing conflicts with L2TP arise because the host operating system must decide how to forward packets: through the tunnel interface or via existing local interfaces. Several factors influence that decision:

  • Default gateway behavior — When a client adopts the VPN’s default route, all traffic is sent through the tunnel. Conversely, if the VPN doesn’t override the default gateway, some traffic stays local.
  • Route priorities and metrics — OS route tables use metrics (administrative distance) to pick the best route. Incorrect metrics can prefer local NICs over the tunnel interface.
  • Subnet overlap — If the remote VPN subnet overlaps a client’s local subnet (e.g., both use 192.168.1.0/24), the OS will route based on its table, often sending packets to the wrong next hop.
  • Policy vs. destination routing — Some environments require source-based (policy) routing rather than destination-only routing. L2TP and PPP usually push destination routes, which can be insufficient when multiple source networks exist.
  • PPP/L2TP negotiation flags — Options negotiated during PPP (e.g., replace default route) determine whether the VPN becomes the default path.

Common manifestations

  • Access to internal resources fails despite successful tunnel up.
  • Split tunnel misconfiguration exposes sensitive traffic to the local network.
  • DNS resolution still uses local DNS servers after connecting.
  • Intermittent connectivity depending on network adapter binding order or wireless vs wired.

Diagnosing the conflict: step-by-step

Before applying fixes, gather information to determine the root cause. Use these checks on the client and server.

  • On the client, list the route table and interface metrics:
    • Windows: run route print and Get-NetIPInterface in PowerShell.
    • Linux: check ip route show and ip rule show.
    • macOS: use netstat -rn or route get <destination>.
  • Inspect PPP/L2TP interface properties to see whether a default route was added and which DNS servers were pushed.
  • Check for overlapping subnets — verify LAN and VPN pools do not collide.
  • Capture traffic with tcpdump/Wireshark to see whether packets destined for an internal remote IP leave the machine via the local NIC or the ppp interface.
  • On servers, review L2TP/IPsec daemon logs (strongSwan, libreswan, xl2tpd, racoon) for route push events and errors.

Practical fixes by platform

The sections below provide concrete remedial steps with commands and configuration snippets. Always test changes in a lab or maintenance window first.

Windows clients

Windows is a common source of confusion because its VPN client has options that affect routing implicitly.

  • To force all traffic over VPN (full tunnel): In the VPN adapter properties → Networking → IPv4 → Advanced, enable Use default gateway on remote network. This sets the default route metric to the PPP interface.
  • To enable split tunneling manually: uncheck that option and add persistent static routes so only desired destination networks go through the tunnel: 
    route -p add 10.10.0.0 mask 255.255.0.0 192.168.100.1 metric 1

    Replace the gateway with the VPN interface gateway as seen in route print.

  • If Windows still prefers the local adapter, adjust the interface metric: 
    Set-NetIPInterface -InterfaceAlias "Ethernet" -InterfaceMetric 25
Set-NetIPInterface -InterfaceAlias "VPN Connection" -InterfaceMetric 5

    Lower metric wins.

  • For RAS-based clients, sometimes registry edits are required to prevent Windows from registering the PPP interface as the default DNS. Use caution with registry changes and back up first.

Linux clients (strongSwan / xl2tpd / NetworkManager)

Linux gives more control through iproute2, and often policy-based routing is the cleanest solution.

  • Check that the ppp interface (e.g., ppp0) gets a lower metric. If not, add explicit routes after the tunnel is up: 
    sudo ip route add 10.10.0.0/16 dev ppp0

    or specify the gateway:

    sudo ip route add 10.10.0.0/16 via 10.8.0.1 dev ppp0
  • For split tunneling, add permanent routes in NetworkManager connection configuration or use /etc/ppp/ip-up.d scripts to push routes at link-up time.
  • When multiple source addresses exist, use policy routing: 
    sudo ip rule add from 192.168.2.0/24 table vpn
sudo ip route add default dev ppp0 table vpn

    This ensures traffic from that source uses the VPN routing table.

  • To handle DNS, use resolvconf or systemd-resolved hooks to prefer remote DNS servers pushed by PPP.

macOS clients

macOS normally honors the “send all traffic” option per VPN. For finer control:

  • Use the “Set Service Order” in Network Preferences to prioritize the VPN adapter if you want it preferred.
  • To add persistent routes, use: 
    sudo route -n add -net 10.10.0.0/16 192.168.100.1
  • Consider AppleScript or launchd jobs to reapply routes when the VPN connects (no built-in per-VPN route push support in some versions).

Server-side and architecture mitigations

Fixes are not all client-side. Servers and network architects should design VPN route behavior intentionally.

Avoid overlapping address spaces

Non-overlapping address pools are the simplest mitigation. Reserve a dedicated address range for remote subnets and avoid using common home/LAN ranges (192.168.x.0/24, 10.0.0.0/8) where possible.

Push explicit routes from the server

Many L2TP/IPsec server implementations can push specific routes (via pppd options or RADIUS attributes). For pppd, use the ms-dns and ms-wins options and scripts to add routes on connect:

  • xl2tpd with pppd options in /etc/ppp/options.xl2tpd can include defaultroute or no-defaultroute depending on whether you want full tunnel.
  • Use /etc/ppp/ip-up scripts to run ip route add commands when the PPP link is established.

Use NAT or proxying on the server for overlapping cases

If you cannot avoid overlapping address spaces, implement NAT on the server to translate client addresses to a non-overlapping range, or expose services via a proxy so clients never need direct subnet routing.

Policy-based routing and VRFs

On more complex networks, deploy policy-based routing or VRFs on the server/edge to scope routing and prevent leaks between tenant networks.

Other practical considerations

  • MTU and fragmentation: L2TP/IPsec adds encapsulation overhead; if the MTU is too large, packets may be dropped or fragmented. Lower the PPP MTU (e.g., 1400) using pppd option mtu 1400 mru 1400.
  • Firewall rules: Ensure host and server firewalls allow traffic via the tunnel interfaces. On Linux, add appropriate iptables/nftables rules explicitly referencing the ppp interface.
  • DNS leaks: Even with correct routing, clients may still use local DNS. Push DNS via PPP negotiation and configure clients to accept or script the resolver update.
  • Multiple simultaneous connections: If a client has more than one VPN (or multiple NICs), ensure correct metrics and policy rules so the intended tunnel handles the expected traffic.

Troubleshooting checklist

  • Confirm tunnel is up and IP addresses assigned to ppp/L2TP interface.
  • Evaluate the client route table; confirm routes for remote subnets exist and point to the tunnel interface.
  • Check for overlapping networks; if present, change addressing or use NAT/proxy.
  • Adjust route metrics or add explicit static routes where appropriate.
  • Verify DNS settings and use resolvconf/systemd hooks or client configuration to prevent DNS leaks.
  • Test with packet capture from the client to see the actual egress interface for problem destination IPs.

By combining careful server-side route push behavior, non-overlapping addressing, and explicit client routing or policy-based rules, most L2TP routing conflicts can be eliminated. In enterprise environments, prioritize predictable routing (full tunnel for security-sensitive users or explicit split tunnel route lists for bandwidth-sensitive use cases) and document client configuration steps for each OS to avoid inconsistent behavior.

For additional configuration examples, scripts, and downloadable troubleshooting checklists tailored to L2TP/IPsec setups, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.