Implementing static routes within an L2TP VPN deployment is an essential skill for network engineers, system administrators, and developers who need predictable, secure connectivity between remote sites and centralized resources. This article walks through the practical steps to plan, configure, and verify static routes in L2TP VPN networks. It covers topology considerations, IP planning, server and client configuration samples, common pitfalls, and troubleshooting tips. The goal is to give you an actionable, detailed guide you can apply to production environments.

Why use static routes with L2TP?

L2TP (Layer 2 Tunneling Protocol) is commonly used together with IPsec for forming site-to-site or remote-access VPNs. While dynamic routing protocols (OSPF, BGP) are used in larger, complex networks, there are many cases where static routes are preferable:

  • Simplicity: Small-to-medium deployments require fewer moving parts and predictable behavior.
  • Security: Static routes reduce the attack surface associated with dynamic routing protocol vulnerabilities.
  • Control: Administrators explicitly manage path selection and failover logic.
  • Performance: No control-plane overhead from routing protocol advertisements.

Key design considerations before you configure

Proper planning avoids conflicts and ensures stable routing when you deploy static routes:

  • IP addressing plan: Define unique subnets for each remote site and for the VPN pool to avoid overlapping IP space.
  • Routing ownership: Decide whether the L2TP server (VPN concentrator) or the remote gateway will own the routes to remote subnets.
  • Split tunneling vs full tunneling: Determine which traffic should traverse the VPN and which should go directly to the Internet.
  • Security policies: Ensure firewall rules and IPsec policies allow the routed traffic.
  • MTU considerations: L2TP-over-IPsec introduces overhead; plan MTU and TCP MSS clamping appropriately.

Typical topologies

Two common topologies will affect how you configure static routes:

Remote-access topology

Clients connect to a central L2TP server and obtain addresses from a VPN pool. Static routes on the server push specific destination networks to clients (e.g., internal subnets) or the client OS configures routes locally.

Site-to-site topology (L2TP between gateways)

Two or more gateways establish tunnels. Each gateway must have static routes pointing to remote subnets via the tunnel interface so that traffic destined for a remote site is forwarded over the proper L2TP/IPsec connection.

Example environment and assumptions

For concrete examples below, assume this environment:

  • Central L2TP server public IP: 203.0.113.10
  • Remote site A gateway public IP: 198.51.100.20
  • Central LAN subnet: 10.10.0.0/16
  • Remote site A LAN subnet: 10.20.0.0/16
  • L2TP client VPN pool: 10.8.0.0/24 (for remote-access)
  • IPsec uses IKEv1 or IKEv2 depending on vendor; examples will focus on Linux strongSwan + xl2tpd and common router CLIs.

Step-by-step: Configure static routes on Linux L2TP/IPsec server (strongSwan + xl2tpd)

Below are concise, practical steps for a typical Ubuntu/Debian server running strongSwan and xl2tpd. Adjust paths and package names for your distro.

1. Install and prepare

  • Install packages:
    • sudo apt update && sudo apt install strongswan xl2tpd ppp
  • Enable IP forwarding:
    • echo “net.ipv4.ip_forward=1” | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

2. Configure IPsec (strongSwan)

Example /etc/ipsec.conf (simplified):

Note: This is illustrative; use secure auth methods in production.

conn L2TP-PSK
left=203.0.113.10
leftsubnet=10.10.0.0/16
right=%any
rightsubnet=10.8.0.0/24
auto=add
authby=secret
keyexchange=ikev1

And in /etc/ipsec.secrets:

203.0.113.10 : PSK “YourPreSharedKey”

3. Configure xl2tpd and PPP

In /etc/xl2tpd/xl2tpd.conf define the ip range and local IP for the server side of the L2TP session.

In /etc/ppp/options.xl2tpd add PPP options and a script to run on connection up (ip-up) to add routes for the client’s access. Example ip-up script will be used to add static routes pushed to the client.

4. Pushing static routes to clients

For remote-access clients, you can push routes via PPP’s ip-up script or use Windows-specific route commands in ppp options e.g. “ms-dns”. Example ip-up script snippet:

#!/bin/sh
# $1: tty, $2: link speed, $3: local IP, $4: remote IP (client)
/sbin/ip route add 10.10.0.0/16 via 10.8.0.1 dev ppp0 || true

This installs a route on the server to direct client-bound packets into the PPP interface. To push routes onto the client itself, use ‘ip-up’ to use pppd option ‘sendeap’, or for Windows clients use RADIUS or scripting on client machines to install routes post-connect. For cross-platform deployments, consider distributing client-side configuration that installs static routes upon connection.

5. Static routes for site-to-site

When the tunnel is gateway-to-gateway, configure kernel routes on each gateway so traffic to the remote subnet uses the tunnel interface. Example:

On central gateway:
sudo ip route add 10.20.0.0/16 via 198.51.100.20 dev ipsec0

On remote gateway:
sudo ip route add 10.10.0.0/16 via 203.0.113.10 dev ipsec0

Replace ipsec0 with the actual virtual interface name created by your IPsec stack (e.g., vti0 or a specific device on your router OS).

Examples for common router vendors

Vendor CLI differs. Here are concise examples for typical appliances.

Cisco IOS

  • Define static route on Router A:
    • ip route 10.20.0.0 255.255.0.0 Tunnel0
  • Ensure Tunnel0 (or L2TP pseudowire) is up and IPsec ACLs allow 10.10.0.0/16 ↔ 10.20.0.0/16.

MikroTik RouterOS

  • Add route:
    • /ip route add dst-address=10.20.0.0/16 gateway=198.51.100.20%ipsec
  • Use ipsec policy templates and ensure ‘src-address’/’dst-address’ reflect routed subnets if using policy-based IPsec.

pfSense

  • Web GUI: VPN → L2TP → Server settings for pool and client routing, then System → Routing → Static Routes to add entries for remote subnets via the VPN gateway.

Firewall, NAT, and IPsec policy tips

Static routes alone aren’t enough — make sure traffic is permitted and correctly translated:

  • IP forwarding: Enabled on the VPN server/gateway.
  • Firewall rules: Allow ESP (protocol 50), AH (protocol 51 if used), UDP 500/4500, and the L2TP control port (UDP 1701) only when protected by IPsec. Also allow the routed subnets to exchange traffic.
  • Policy vs route-based IPsec: Policy-based IPsec matches traffic selectors (src/dst) — update selectors to include remote subnets. For route-based, bind routes to the virtual interface (VTI) and let kernel routing handle it.
  • NAT: Avoid NATting traffic between routed subnets. If NAT is required, be explicit and document the changes.
  • MTU/MSS: Set lower MTU (e.g., 1400) or use TCP MSS clamping to avoid fragmentation across L2TP/IPsec tunnels.

Testing and verification

Follow these steps to validate your configuration:

  • Verify the L2TP/IPsec session: check strongSwan logs (/var/log/syslog or journalctl) and xl2tpd status.
  • Check interfaces and routes:
    • ip link show; ip addr show
    • ip route show
  • Ping across subnets:
    • From central server/gateway: ping 10.20.0.1
    • From remote host: ping 10.10.0.1
  • Tracepath/traceroute to observe hop path and MTU behavior.
  • tcpdump or Wireshark to confirm packets traverse the tunnel and match IPsec policies. Capture on both ends if necessary:
    • sudo tcpdump -i any host 10.20.0.1 or host 10.10.0.1

Common issues and troubleshooting

Below are frequent problems and recommended diagnostics:

  • No connectivity after tunnel up: Check IP forwarding, firewall rules, and whether routes are installed on each gateway.
  • Asymmetric routing: Ensure the return path uses the tunnel and not the public Internet. Validate routing tables and policy selectors.
  • IP conflicts: Overlapping subnets cause dropped traffic. Replan addressing to avoid overlap or use NAT where unavoidable.
  • MTU/fragmentation issues: Reduce MTU or enable MSS clamping on the tunnel interface.
  • IPsec policy mismatch: Check strongSwan or vendor IPsec logs for negotiation errors; verify lifetimes, algorithms, and traffic selectors.
  • Routes not pushed to clients: For L2TP remote-access, many clients (especially Windows/macOS) will require client-side route scripts or VPN client configuration to accept routes. Consider using RADIUS to deliver VPN attributes where supported.

Operational recommendations

To maintain a stable L2TP + static route deployment:

  • Document all static routes and IPsec traffic selectors in version-controlled configuration files.
  • Automate route deployment if you manage many gateways (Ansible, Salt, or vendor APIs can help).
  • Monitor tunnel status, latency, and packet loss with SNMP, Prometheus exporters, or the vendor’s telemetry.
  • Periodically audit firewall and IPsec policies to ensure least privilege and compliance.
  • Test failover scenarios and backup connectivity for critical sites.

Implementing static routes in L2TP VPN networks provides clear control and predictability for site interconnects and remote-access services. By combining robust IP planning, proper firewall/IPsec policies, and thoughtful route management, you can create reliable VPN topologies appropriate for many enterprise and developer needs.

For additional resources, configuration examples, and managed L2TP/IPsec services, visit Dedicated-IP-VPN.