L2TP/IPsec: Multiple Road Warriors Behind NAT

L2TP/IPsec: Multiple Road Warriors Behind NAT

A common scenario: several users in the same office, or on the same home network, all connect to your RouterOS L2TP/IPsec server. The first client connects fine. The second client fails — IKE completes but the L2TP tunnel never comes up, or the tunnel drops seconds after establishing.

This is a NAT and IPsec policy problem, not a user credentials problem. This guide explains the root cause and provides the complete firewall and IPsec configuration to fix it.

---

Overview

Standard IPsec uses ESP (protocol 50), which has no port numbers. A NAT device tracks TCP and UDP sessions by source/destination port pairs, but it has no port-based mechanism to distinguish two ESP streams from the same public IP.

NAT Traversal (NAT-T) solves this by encapsulating ESP inside UDP port 4500. Each client behind the NAT gets a distinct UDP source port, giving both the NAT device and the RouterOS server a way to keep sessions separate.

RouterOS enables nat-traversal=yes by default on the IPsec profile, but one additional setting is required:

Setting	Object	Effect
generate-policy=port-strict	/ip ipsec identity	Generates a unique Phase 2 policy per client keyed by UDP port, not just IP

Without this setting, RouterOS generates policies keyed only by IP address and tries to reuse an existing SA for new connections from the same public IP. The second client collides with the first client’s SA and the tunnel fails.

When use-ipsec=require is set on the L2TP server, RouterOS auto-generates the IPsec identity with generate-policy=port-strict already enabled. No manual command is needed — but verifying it is set is recommended.

---

Prerequisites

• RouterOS 7.x on the VPN server
• A public IP on the RouterOS router, or upstream NAT that forwards the following to the router:
  • UDP 500 (IKE)
  • UDP 4500 (IKE NAT-T / ESP encapsulated)
  • ESP (protocol 50) — only needed if NAT-T is not in use
• Firewall input chain open for UDP 500 and UDP 4500 before any drop rules

---

Configuration

Step 1 — IP Pool and PPP Profile

/ip pool
add name=l2tp-pool ranges=10.10.10.10-10.10.10.200

/ppp profile
add name=l2tp-prof \
    local-address=10.10.10.1 \
    remote-address=l2tp-pool \
    use-encryption=yes \
    dns-server=8.8.8.8,8.8.4.4

Step 2 — Enable the L2TP Server

/interface l2tp-server server set \
    enabled=yes \
    use-ipsec=require \
    ipsec-secret=YourStrongPSK \
    default-profile=l2tp-prof \
    authentication=mschap2

ipsec-secret is a single shared PSK for all clients. Per-user authentication is provided by the PPP credentials added in the next step. Do not attempt to differentiate users by PSK — that is the wrong layer.

Step 3 — Add PPP Users

/ppp secret
add name=user1 password=Pass1 service=l2tp profile=l2tp-prof
add name=user2 password=Pass2 service=l2tp profile=l2tp-prof
add name=user3 password=Pass3 service=l2tp profile=l2tp-prof

Step 4 — Verify IPsec Settings for Multiple NAT Clients

RouterOS auto-generates IPsec objects when use-ipsec=require is set on the L2TP server. Verify the auto-generated settings are correct:

# Confirm NAT traversal is on (it is by default, but verify)
/ip ipsec profile
set [find default=yes] nat-traversal=yes

# Verify port-strict is set — use-ipsec=require sets this automatically
/ip ipsec identity print detail
# Expected: generate-policy=port-strict

If generate-policy shows anything other than port-strict, set it manually:

/ip ipsec identity set [find] generate-policy=port-strict

Note on level=unique: The level property applies to dynamic and manually created non-template policies only. It is silently ignored on the policy template (the entry marked T in /ip ipsec policy print). When using use-ipsec=require with generate-policy=port-strict, the port-based traffic selectors are sufficient to prevent SA collisions — level=unique on the template is not required and has no effect.

Named objects: If you created named IPsec peers or identities instead of using auto-generation, apply generate-policy=port-strict to those named identities rather than using [find].

Step 5 — Firewall Rules

These rules must appear before any drop rules in the input chain.

The examples below use an interface list named WAN. If you do not already have one, create it and add your WAN interface to it:

/interface list add name=WAN
/interface list member add list=WAN interface=ether1

Replace ether1 with the actual name of your WAN interface. Then add the firewall rules:

/ip firewall filter
add chain=input \
    action=accept \
    protocol=udp \
    dst-port=500,4500 \
    in-interface-list=WAN \
    comment="L2TP/IPsec: IKE and NAT-T"

add chain=input \
    action=accept \
    protocol=ipsec-esp \
    in-interface-list=WAN \
    comment="L2TP/IPsec: ESP (fallback when NAT-T not active)"

If you prefer to target the interface directly rather than using a list:

/ip firewall filter
add chain=input action=accept protocol=udp dst-port=500,4500 \
    in-interface=ether1 comment="L2TP/IPsec: IKE and NAT-T"
add chain=input action=accept protocol=ipsec-esp \
    in-interface=ether1 comment="L2TP/IPsec: ESP (fallback when NAT-T not active)"

Once NAT-T is working correctly, ESP traffic from NATed clients arrives encapsulated in UDP 4500 and is covered by the first rule. The ESP rule handles clients that are not behind NAT (direct connection, public IP).

---

Client-Side Requirements

Windows Registry Fix

Windows blocks L2TP/IPsec through NAT by default. Each Windows client must apply this registry change before connecting:

1. Open regedit
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
3. Create a DWORD value named AssumeUDPEncapsulationContextOnSendRule
4. Set the value to 2 (both client and server may be behind NAT)
5. Reboot

Without this, Windows refuses to send L2TP/IPsec packets when it detects it is behind NAT.

Client-Side NAT Device

The NAT router or firewall in front of the clients must:

• Not have IPsec passthrough, SIP ALG, or VPN passthrough features enabled — these intercept IKE packets and break NAT-T. Disable them.
• Track UDP 4500 state long enough for DPD keepalives to maintain sessions. Most consumer routers expire UDP state after 30–120 seconds of inactivity. See Troubleshooting below if sessions drop.
• Allow outbound UDP 500, UDP 4500, and ESP (protocol 50) from clients.

---

Verification

After multiple clients connect, verify each has its own security associations:

# One SA pair per connected client (inbound + outbound = 2 per client)
/ip ipsec installed-sa print

# One active PPP session per connected user
/ppp active print

# Dynamic policies: each entry should show unique source/destination ports
/ip ipsec policy print

Expected result for three connected clients: six SA entries (two per client), three PPP active sessions, and three or more dynamically generated policies with distinct port-based selectors.

---

Troubleshooting

Second client fails immediately after the first connects

Classic symptom of missing generate-policy=port-strict. Apply the setting and flush stale SAs:

/ip ipsec identity set [find] generate-policy=port-strict
/ip ipsec installed-sa flush

Have both clients reconnect. Check /ip ipsec installed-sa print to confirm two distinct SA pairs appear.

Connections drop after a few minutes

The client-side NAT device is expiring its UDP 4500 mapping. Shorten the DPD interval on the RouterOS server so keepalives fire before the mapping expires:

/ip ipsec profile
set [find default=yes] dpd-interval=30s dpd-maximum-failures=5

If you can configure the client-side NAT device, set its UDP state timeout to at least 120 seconds.

no Phase 2 policy found in server logs

The Phase 2 policy was not created or is stale. Flush SAs and have the client reconnect:

/ip ipsec installed-sa flush
/ip ipsec policy print

If no dynamic policies appear after reconnect, confirm generate-policy=port-strict is active:

/ip ipsec identity print detail

The generate-policy column must show port-strict, not no or yes.

IKE completes but L2TP does not start

The IPsec tunnel is up but UDP 1701 (L2TP) is not reaching the server. Causes:

1. Missing firewall rule for the L2TP interface — when IPsec is used, L2TP traffic arrives on the decapsulated L2TP interface, not the WAN interface. Ensure your input chain does not drop traffic from l2tp interfaces.
2. IPsec policy does not cover UDP 1701 — check that the dynamic policy generated by RouterOS includes UDP port 1701.
3. Client-side NAT is blocking UDP 1701 — some NAT devices block L2TP outbound. Test by temporarily allowing all UDP outbound.

Enable verbose logging

/system logging
add topics=ipsec,!debug action=memory
add topics=l2tp,!debug action=memory

/log print follow where topics~"ipsec|l2tp"

Remove after debugging:

/system logging remove [find topics~"ipsec"]
/system logging remove [find topics~"l2tp"]

Stale SAs blocking reconnect

Stale SAs from a previous session can block a new connection from the same IP:

/ip ipsec installed-sa flush

---

Alternative: IKEv2 for Road Warriors

L2TP/IPsec (IKEv1, transport mode) was not designed for large numbers of roaming clients behind NAT. If you need more than a handful of simultaneous NATed clients, or if you encounter persistent instability, consider migrating to IKEv2 with RSA certificates:

• IKEv2 handles NAT-T natively and has cleaner identity handling for multiple clients behind the same IP.
• Certificate-based auth (RSA signature) avoids the PSK-reuse problem inherent in L2TP/IPsec with a shared secret.
• IKEv2 supports EAP for per-user credentials without requiring L2TP at all.

See IPsec IKEv2 Road Warrior for IKEv2 configuration.

---

See Also

• L2TP/IPsec — Core L2TP/IPsec server setup and the port-strict solution overview
• IPsec — Full IPsec reference including IKEv2, site-to-site, and certificate auth
• NAT Helpers — How NAT helpers interact with IPsec and L2TP
• Firewall Filter Rules — Input chain ordering and rule placement