Skip to content

L2TP Client: Reconnecting After ISP Session Resets

L2TP Client: Reconnecting After ISP Session Resets

Section titled “L2TP Client: Reconnecting After ISP Session Resets”

Some ISPs use L2TP as the WAN bearer protocol and enforce a maximum session lifetime — commonly 8 hours (28800 seconds). When the limit expires the ISP’s LNS terminates the session, leaving the RouterOS client offline until it reconnects. Because the timeout is imposed server-side, adjusting PPP profile settings on the router has no effect. The solution is to configure the L2TP client to reconnect automatically.

This guide applies when RouterOS is acting as an L2TP client connecting outbound to an ISP or remote L2TP server — not when RouterOS is the L2TP server.

A typical deployment affected by this issue looks like:

[ RouterOS 750GR2 ]
├── ether1 ← bridged with ether2 as WAN bridge
└── ether2 ← public IP assigned by ISP
└── L2TP client (l2tp-out1) → ISP LNS

The router receives a public IP on a bridged WAN interface and establishes an L2TP tunnel to the ISP’s LNS for authentication and routing. The ISP enforces an 8-hour session limit; at expiry it sends a Call-Disconnect-Notify and the tunnel drops.

  • RouterOS 6.x or 7.x
  • A configured L2TP client interface (/interface l2tp-client)
  • Admin access via Winbox, SSH, or console

Step 1 — Confirm the disconnect is ISP-imposed

Section titled “Step 1 — Confirm the disconnect is ISP-imposed”

Enable L2TP and PPP logging before the next expected disconnect:

/system logging add topics=l2tp action=memory
/system logging add topics=ppp action=memory

After the drop, inspect the log:

/log print where topics~"l2tp|ppp"

An ISP-side disconnect typically produces one of these log messages:

Log messageMeaning
l2tp-out1: disconnected, call disconnect notify receivedISP sent CDN — session limit enforced
l2tp-out1: session timed outsession-timeout enforced (could be local or remote)
l2tp-out1: LCP timeoutkeepalive failure — see Keepalive tuning below

If the message is call disconnect notify received, the ISP is terminating the session. The router cannot prevent this; configure auto-reconnect.

Step 2 — Confirm local session-timeout is not set

Section titled “Step 2 — Confirm local session-timeout is not set”

Verify the PPP profile assigned to the L2TP client has no local timeout:

/interface l2tp-client print detail

Note the profile field, then check it:

/ppp profile print detail where name=<profile-name>

Ensure session-timeout=0 and idle-timeout=0. If either is set to 28800 (8h), that is a local cause — set both to 0:

/ppp profile set [find name=<profile-name>] session-timeout=0 idle-timeout=0

If local timeouts are already 0 and disconnects continue, the cause is ISP-side. Proceed with auto-reconnect configuration.

RouterOS L2TP client interfaces have a dial-on-demand option. For a persistent ISP connection, dial-on-demand should be off and the interface should be set to reconnect automatically after disconnection. Verify:

/interface l2tp-client print detail

Confirm dial-on-demand=no. If it is yes, change it:

/interface l2tp-client set [find name=l2tp-out1] dial-on-demand=no

RouterOS will reconnect the L2TP client automatically after any disconnect when dial-on-demand=no. In most cases this is sufficient — no script is required.

If the client reconnects but takes several minutes to detect the disconnect, the keepalive interval may be too long. Reduce it so the client detects the ISP drop faster:

/interface l2tp-client set [find name=l2tp-out1] keepalive-timeout=60

keepalive-timeout is in seconds. The default is 60. Lower values (e.g. 30) cause faster reconnects but generate more traffic. Values below 10 are not recommended on cellular or unstable WAN links.

Netwatch-Triggered Reconnect (Optional Belt-and-Suspenders)

Section titled “Netwatch-Triggered Reconnect (Optional Belt-and-Suspenders)”

If the client occasionally fails to auto-reconnect — common on older RouterOS versions or when the ISP’s CDN is not delivered cleanly — add a Netwatch monitor that forces a reconnect when the tunnel endpoint is unreachable:

# Replace 10.0.0.1 with the ISP's LNS inner address or a known IP reachable through the tunnel
/tool netwatch add \
host=10.0.0.1 \
interval=00:00:30 \
timeout=00:00:10 \
down-script="/interface l2tp-client disable [find name=l2tp-out1]; :delay 2s; /interface l2tp-client enable [find name=l2tp-out1]"

Note: Disable this Netwatch rule if you change ISP or LNS address — the probe host must be reachable only through the L2TP tunnel, not the WAN interface directly, or it will trigger spurious reconnects.

Scheduler-Based Preventive Reconnect (Last Resort)

Section titled “Scheduler-Based Preventive Reconnect (Last Resort)”

If the ISP resets exactly at 8 hours and does not deliver a clean disconnect, the router may not detect the outage. A scheduler that proactively reconnects just before the 8-hour mark prevents the dead session from going undetected:

/system scheduler add \
name=l2tp-reconnect \
interval=07:50:00 \
on-event="/interface l2tp-client disable [find name=l2tp-out1]; :delay 3s; /interface l2tp-client enable [find name=l2tp-out1]" \
comment="Reconnect L2TP before ISP 8h session reset"

This forces a reconnect every 7 hours 50 minutes, dropping and re-establishing the tunnel 10 minutes before the ISP would reset it. Use this only if auto-reconnect via keepalive is insufficient.

After applying changes, confirm the client reconnects after a forced disconnect:

# Check current L2TP client state
/interface l2tp-client print detail
# Manually trigger a reconnect to test
/interface l2tp-client disable [find name=l2tp-out1]
:delay 5s
/interface l2tp-client enable [find name=l2tp-out1]
# Confirm it comes back up
/interface l2tp-client print detail
/ppp active print

The status field in /interface l2tp-client print detail should return to connected. Monitor the log across the 8-hour boundary to confirm automatic reconnection:

/log print where topics~"l2tp"

A successful reconnect shows l2tp-out1: connected in the log shortly after the disconnected event.

Client reconnects but gets no route

After reconnect, verify the default route through the L2TP interface is still present:

/ip route print where gateway=l2tp-out1

If the route is missing, it may have been added statically instead of via add-default-route=yes on the client. Set this on the L2TP client interface:

/interface l2tp-client set [find name=l2tp-out1] add-default-route=yes

Disconnect happens at irregular intervals, not exactly 8 hours

Irregular drops are not ISP session resets. Check:

SymptomLikely Cause
Drops with LCP timeout in logKeepalive failure — increase keepalive-timeout or check WAN stability
Drops only when traffic is idleidle-timeout is set in the PPP profile
Drops correlated with PPPoE reconnectsWAN (PPPoE) reconnecting changes IP, tearing down L2TP — fix PPPoE stability first
Drops with no reply to keepaliveNAT/firewall between router and LNS expiring UDP 1701 mapping

LNS rejects reconnect with authentication failure

Some ISPs lock credentials to the previous session and require a short delay before accepting a new one. Add a delay to the reconnect script:

/interface l2tp-client disable [find name=l2tp-out1]
:delay 10s
/interface l2tp-client enable [find name=l2tp-out1]