Multiple Road Warrior L2TP/IPsec Clients Behind NAT

Multiple Road Warrior L2TP/IPsec Clients Behind NAT

Overview

When two or more L2TP/IPsec road warrior clients connect from behind the same NAT device (same public IP address), the standard use-ipsec=yes automatic mode fails. Automatic mode creates IPsec Security Associations (SAs) in transport mode, which keys the SA on the outer (post-NAT) IP address. A second client from the same public IP produces an identical SA selector, causing a collision: the second client fails to connect or the first is knocked offline.

Official RouterOS documentation explicitly states that use-ipsec=yes does not support multiple clients behind the same NAT. The solution is to disable use-ipsec and configure manual IPsec policies with tunnel=yes and level=unique.

Why tunnel mode solves the problem

Client A (192.168.0.5)  ─┐
Client B (192.168.0.6)  ─┤── Office NAT (203.0.113.10) ──► RouterOS VPN Server (198.51.100.1)

Mode	SA selector	Result
Transport mode (use-ipsec=yes)	203.0.113.10 ↔ 198.51.100.1	Identical for both clients — collision
Tunnel mode (manual)	192.168.0.5 ↔ 198.51.100.1 / 192.168.0.6 ↔ 198.51.100.1	Unique per client

In tunnel mode, IPsec encapsulates the entire inner IP packet. IKE Phase 2 negotiates the inner (pre-NAT) addresses as SA selectors, so each client gets a distinct SA even when they share a public IP. The level=unique policy setting prevents SA reuse across separate client connections.

This guide covers the server side. Client-side L2TP/IPsec is configured by the client OS (Windows, macOS, iOS, Android) using the server’s public IP and the shared secret.

---

Prerequisites

• RouterOS v6.49+ or v7.x
• A public IP address (static or DDNS) on the server WAN interface
• UDP 500, UDP 4500, and IP protocol 50 (ESP) reachable at the server
• PPP user accounts for each road warrior client

---

Configuration

1. L2TP Server — disable automatic IPsec

/interface l2tp-server server
set enabled=yes \
    use-ipsec=no \
    default-profile=vpn-profile

use-ipsec=no is intentional. Manual IPsec policies (steps 4–5) replace the automatic mode that cannot handle multiple NAT’d clients.

2. PPP Profile and IP Pool

/ip pool
add name=vpn-pool ranges=10.0.0.2-10.0.0.254

/ppp profile
add name=vpn-profile \
    local-address=10.0.0.1 \
    remote-address=vpn-pool \
    dns-server=8.8.8.8 \
    use-encryption=yes

3. PPP Secrets (per user)

/ppp secret
add name=alice password=AliceSecret service=l2tp profile=vpn-profile
add name=bob   password=BobSecret   service=l2tp profile=vpn-profile

4. Manual IPsec — Phase 1 and peer

# Phase 1 profile: enable NAT-T and set strong algorithms
/ip ipsec profile
set [find default=yes] \
    nat-traversal=yes \
    dh-group=modp2048 \
    enc-algorithm=aes-256,aes-128 \
    hash-algorithm=sha256

# Passive peer: accepts connections from any address
/ip ipsec peer
add name=rw-peer \
    address=0.0.0.0/0 \
    passive=yes \
    send-initial-contact=no

# Identity: preshared key authentication
/ip ipsec identity
add peer=rw-peer \
    auth-method=pre-shared-key \
    secret=StrongSharedSecret

send-initial-contact=no is critical. The default (yes) causes RouterOS to send an IKE Initial Contact notification when a new Phase 1 begins from a known peer IP — this tears down all existing SAs for that IP, disconnecting the first client when a second connects from the same NAT address.

5. IPsec Policy — tunnel mode with level=unique

/ip ipsec policy
add src-address=0.0.0.0/0 \
    dst-address=0.0.0.0/0 \
    protocol=udp \
    dst-port=1701 \
    action=encrypt \
    level=unique \
    tunnel=yes \
    peer=rw-peer \
    proposal=default

• tunnel=yes — encapsulates the full inner IP packet; SA selectors are the clients’ real (pre-NAT) IP addresses, which are unique per client
• level=unique — forces a distinct SA per client connection; prevents SA sharing when multiple clients negotiate from the same public IP

6. Firewall Rules (Input Chain)

Place before any default-drop rule:

/ip firewall filter
add chain=input protocol=udp dst-port=1701 action=accept comment="L2TP"
add chain=input protocol=udp dst-port=500  action=accept comment="IKE"
add chain=input protocol=udp dst-port=4500 action=accept comment="IPsec NAT-T"
add chain=input protocol=50                action=accept comment="IPsec ESP"

UDP 4500 (NAT-T) carries encapsulated ESP when clients are behind NAT. All four rules are required.

7. NAT Bypass Rule

Prevents masquerading of IPsec-encrypted traffic, which would break VPN tunnels:

/ip firewall nat
add chain=srcnat action=accept ipsec-policy=out,ipsec \
    comment="IPsec bypass — do not masquerade encrypted traffic"

If VPN clients need internet access through the server, add a masquerade rule after the bypass:

/ip firewall nat
add chain=srcnat src-address=10.0.0.0/24 out-interface-list=WAN action=masquerade \
    comment="VPN client internet access"

8. (Alternative) IKEv2 Road-Warrior Without L2TP

For modern deployments that do not require L2TP, IKEv2 native tunnel mode handles multiple NAT’d clients via generate-policy=port-strict, which keys dynamic policies on both IP address and UDP source port:

/ip ipsec profile
add name=rw-profile nat-traversal=yes dh-group=modp2048 \
    enc-algorithm=aes-256,aes-128 hash-algorithm=sha256

/ip ipsec peer
add name=rw-peer2 address=0.0.0.0/0 exchange-mode=ike2 profile=rw-profile

/ip pool
add name=ike2-pool ranges=10.0.1.2-10.0.1.254

/ip ipsec mode-config
add name=rw-cfg address-pool=ike2-pool

/ip ipsec policy group
add name=rw-group

/ip ipsec policy
add group=rw-group template=yes src-address=0.0.0.0/0 dst-address=10.0.1.0/24

/ip ipsec identity
add peer=rw-peer2 auth-method=pre-shared-key secret=StrongSharedSecret \
    generate-policy=port-strict mode-config=rw-cfg policy-template-group=rw-group

generate-policy=port-strict distinguishes clients by both IP and UDP source port, providing per-client policy isolation without manual tunnel-mode policies. This option is specific to the IKEv2 path; it does not apply to the L2TP/IKEv1 configuration above.

---

Verification

Check active L2TP sessions

/ppp active print detail

Expect one entry per connected client with a unique VPN pool address.

Check IPsec Security Associations

/ip ipsec active-peers print detail

Multiple clients behind the same NAT appear with the same remote-address but represent distinct Phase 1 SAs (distinguished by IKE cookies over NAT-T/UDP 4500).

/ip ipsec installed-sa print detail

Each client has its own Phase 2 SA. The src-address and dst-address fields show the inner (pre-NAT) IP addresses — confirming tunnel mode is active and selectors are unique per client.

Confirm tunnel mode is active

/ip ipsec installed-sa print where tunnel=yes

If no results appear, the SA was established in transport mode — verify the policy has tunnel=yes set.

Check policy hit counters

/ip ipsec policy print detail

The bytes counter on the tunnel policy should increment as clients send traffic. Zero bytes indicates no traffic is matching the policy — check selectors and routing.

Test simultaneous sessions

Connect two clients from behind the same NAT simultaneously. Both should receive VPN pool addresses and be able to ping 10.0.0.1 (the server L2TP local address) without dropping each other’s session.

---

Troubleshooting

First client disconnects when second client connects

Cause: send-initial-contact=yes (default) on the IPsec peer. RouterOS sends an IKE Initial Contact notification when a new Phase 1 is initiated from an already-known peer IP, clearing all existing SAs for that IP.

Fix: Verify the peer has send-initial-contact=no:

/ip ipsec peer print detail where name=rw-peer

If not set, update it:

/ip ipsec peer set rw-peer send-initial-contact=no

Clients connect but no traffic passes

Cause: Missing ESP accept rule in the input chain, or the IPsec policy is not matching L2TP traffic.

Fix: Confirm ESP is allowed and check the policy:

/ip firewall filter print where protocol=50
/ip ipsec policy print detail

Ensure tunnel=yes, level=unique, action=encrypt, and dst-port=1701 are all set. If the bytes counter is zero, traffic is not reaching the policy.

IKE negotiation fails

Enable detailed IPsec logging:

/system logging add topics=ipsec,!packet action=memory
/log print follow where topics~"ipsec"

Common causes: Phase 1 or Phase 2 proposal mismatch between client and server, incorrect shared secret, or firewall blocking UDP 500 or UDP 4500.

NAT-T not activating (ESP blocked mid-path)

Cause: An intermediate device (ISP or carrier NAT) drops IP protocol 50 (ESP).

Fix: nat-traversal=yes is already set in the profile (step 4). Confirm it is active:

/ip ipsec profile print

Once NAT-T is active, all ESP traffic is wrapped in UDP/4500. The established counter in /ip ipsec active-peers print detail should increment.

Clients use use-ipsec=yes config from a prior setup

If a previous use-ipsec=yes configuration was in place, dynamic IPsec peers and policies may still exist and interfere.

Remove any leftover dynamic objects:

/ip ipsec policy print dynamic
/ip ipsec policy remove [find dynamic=yes]
/ip ipsec peer print

Ensure no peer named l2tp-* (auto-created by use-ipsec=yes) remains.

Client fails to reconnect after sleep or roam

Cause: Stale dynamic SA entries remain after the client disconnects without clean teardown.

Fix: Flush stale SAs and reconnect the client:

/ip ipsec installed-sa flush
/ip ipsec policy remove [find dynamic=yes]

Set a reasonable SA lifetime on the proposal to limit stale entry accumulation:

/ip ipsec proposal set default lifetime=1h

Check installed SAs and policy hits

/ip ipsec installed-sa print detail
/ip ipsec statistics print

Zero bytes on an SA indicates the client is not sending matching traffic — check selectors, routing, and that the client’s L2TP session is actually up.

---

See Also

• RouterOS IPsec documentation
• RouterOS L2TP documentation
• GRE Tunnel and NAT