L2TP Disconnects Every 8 Hours

L2TP Disconnects Every 8 Hours

L2TP tunnels that drop on a repeating ~8-hour cycle have three distinct root causes: IPsec SA lifetime mismatch, PPP profile session timeout, or ISP-forced WAN session reset. This guide explains how to identify which cause applies and how to fix it.

Overview

L2TP itself has no built-in session timer — it relies on PPP keepalives and, when use-ipsec=yes, on IPsec SA lifetimes for tunnel continuity. An 8-hour (28800-second) disconnection cycle almost always points to one of:

Cause	Indicator
IPsec Phase 1 SA lifetime set to 8h on one peer	IPsec SA expiry in log, no PPPoE event
PPP profile session-timeout set to 8h	PPP session teardown in log
ISP-forced WAN (PPPoE) session reset	PPPoE disconnect and L2TP drop share same timestamp
NAT-T UDP mapping expiry on CGNAT	Periodic drops under low-traffic conditions

RouterOS IPsec defaults are Phase 1 = 1d, Phase 2 = 30m. The 8-hour (28800-second) value is not a RouterOS default — it is the built-in IKEv1 SA lifetime used by Windows, iOS, Android, and many Cisco/Juniper devices. RouterOS accepts whatever lifetime the initiator proposes, so a Windows or iOS client connecting with its default 28800-second proposal will produce an 8-hour drop even though RouterOS’s own setting is 24h. If 8-hour drops occur with RouterOS factory defaults, the remote peer or ISP is enforcing an 8-hour policy.

Prerequisites

• RouterOS v6.45 or later (v7.x recommended for IPsec stability improvements)
• Admin access to both L2TP client and server (or knowledge of the remote peer’s IPsec configuration)
• Log access to correlate event timestamps

Configuration

Step 1 — Identify the cause from logs

/log print where topics~"pppoe|ppp|l2tp|ipsec|ike"

• If a pppoe disconnect and l2tp teardown share the same second → ISP WAN reset (see Step 5)
• If ike shows SA expired or rekey failed with PPPoE stable → IPsec lifetime issue (Step 2)
• If ppp shows session timeout → PPP profile timeout (Step 3)

Step 2 — Align IPsec SA lifetimes on both peers

Mismatched lifetimes cause the short-lifetime side to initiate rekey. If rekey fails (credentials mismatch, NAT change, DPD failure), the tunnel drops.

# Check current lifetimes
/ip ipsec profile print detail
/ip ipsec proposal print detail

# Set explicit lifetimes — match these values on the remote peer
/ip ipsec profile set [find name=default] lifetime=1d
/ip ipsec proposal set [find name=default] lifetime=1h pfs-group=none

# Enable DPD so dead peers are detected before the SA expires
/ip ipsec peer set [find] dpd-interval=120 dpd-maximum-failures=5

If the remote peer is a third-party device (Cisco, Windows, Juniper), check its Phase 1/Phase 2 defaults and match the RouterOS values to them, not the other way around.

Step 3 — Disable PPP profile session timeout

A PPP profile with session-timeout=8h (28800 seconds) will tear down the L2TP session regardless of tunnel health.

# Check all profiles
/ppp profile print detail
# Look for: session-timeout, idle-timeout

# Disable forced timeouts on the profile used by L2TP
/ppp profile set [find name=default-encryption] session-timeout=0 idle-timeout=0

session-timeout=0 means no forced timeout. idle-timeout=0 disables idle disconnection.

Step 4 — Configure L2TP client for persistent connection

/interface l2tp-client add \
  name=l2tp-out1 \
  connect-to=<server-ip> \
  user=<username> \
  password=<password> \
  disabled=no \
  dial-on-demand=no \
  keepalive-timeout=60 \
  profile=default-encryption \
  use-ipsec=yes \
  ipsec-secret=<shared-secret>

Key parameters:

Parameter	Recommended value	Reason
dial-on-demand	no	Maintain persistent connection; do not wait for traffic
keepalive-timeout	60 (increase to 120 on unstable links)	Detect dead peer without premature teardown
use-ipsec	yes	Encrypt L2TP traffic

On the server side:

/interface l2tp-server server set \
  enabled=yes \
  keepalive-timeout=30 \
  use-ipsec=required \
  ipsec-secret=<shared-secret>

Step 5 — ISP-forced WAN session reset

If logs show PPPoE dropping and L2TP dropping at the same instant, the ISP is forcing a session reset. RouterOS reconnects automatically, but the L2TP tunnel must also reconnect. Ensure:

# PPPoE client reconnects automatically (dial-on-demand=no)
/interface pppoe-client set [find] dial-on-demand=no

# L2TP client reconnects automatically (dial-on-demand=no already set above)
# No additional config needed — RouterOS retries the tunnel after WAN recovers

To reduce reconnect time after an ISP reset, lower the PPPoE client reconnect-delay or ensure IPsec DPD is enabled so stale SAs are cleared quickly.

Step 6 — Prevent NAT-T UDP mapping expiry

If the tunnel crosses NAT or CGNAT, intermediate devices may expire the UDP 4500 mapping. Keep the mapping alive with DPD (already set in Step 2) and optionally bypass connection tracking for IPsec traffic:

# Bypass conntrack for IKE and NAT-T traffic (prevents conntrack interference)
/ip firewall raw add chain=prerouting \
  protocol=udp dst-port=500,4500 \
  action=notrack comment="IPsec IKE/NAT-T bypass conntrack"

/ip firewall raw add chain=prerouting \
  protocol=ipsec-esp \
  action=notrack comment="IPsec ESP bypass conntrack"

Also verify that UDP 500, UDP 4500, and ESP (protocol 50) are not blocked by firewall filter rules on either end.

Verification

After applying fixes, monitor the tunnel across the expected 8-hour window:

# Check L2TP client state
/interface l2tp-client print detail

# Check active PPP sessions
/ppp active print detail

# Check IPsec SA state — should show active SAs, not expired
/ip ipsec installed-sa print detail
/ip ipsec active-peers print detail

# Watch for rekey events (should succeed, not drop)
/log print follow-only where topics~"ipsec|ike|l2tp"

A successful rekey looks like:

ike,info initiating IKEv1 Main Mode
ike,info peer responded
ike,info established IKE SA

A failed rekey (causing disconnect) looks like:

ike,error no proposal chosen
ike,error SA expired, no response from peer

Troubleshooting

Tunnel drops exactly at 8h despite session-timeout=0 Check the remote peer’s IPsec profile. If the remote enforces 8h and your RouterOS is set to 1d, the remote initiates rekey. If that rekey fails, the tunnel drops. Set your RouterOS lifetime to 8h to match, or negotiate a longer value with the remote administrator.

Tunnel drops at 8h and logs show no IPsec events The PPP profile is likely the cause. Run /ppp profile print detail and check session-timeout. Note that a RADIUS AAA server can inject a Session-Timeout=28800 attribute dynamically at session start — this overrides the local profile and is invisible in RouterOS config. If RADIUS is in use, check the server’s policy or inspect with:

/ppp active print detail
# Look for the "session-timeout" column — if it shows "8h" despite profile=0, RADIUS is the source

Tunnel drops at irregular intervals, not exactly 8h NAT-T mapping expiry under CGNAT is rarely perfectly periodic. Enable DPD and the conntrack bypass rules from Step 6.

dpd-interval is set but DPD packets are not keeping the tunnel up Verify that UDP 4500 is not being blocked by an upstream firewall. Run:

/ip firewall connection print where dst-port=4500

If NAT-T packets are being dropped, DPD cannot function.

After ISP reconnect, L2TP does not re-establish Check /interface l2tp-client print detail for status: disconnected. If dial-on-demand=no is set, RouterOS should retry automatically. If it does not, check for an authentication failure in the log — the ISP may have changed the WAN IP, invalidating the IPsec Phase 1 ID.

FastTrack is enabled and drops appear random The FastTrack connection accelerator bypasses firewall processing and can disrupt IPsec/L2TP traffic. Add an exclusion rule before the generic FastTrack rule:

/ip firewall filter add chain=forward \
  protocol=udp dst-port=500,4500 \
  action=accept comment="Allow IKE/NAT-T before FastTrack" \
  place-before=[find action=fasttrack-connection]

Multiple L2TP clients behind NAT see periodic disconnects that don’t align with any timer When several clients share a NAT exit IP, IPsec policy lookup conflicts can cause one client’s SA to be overwritten by another’s, producing apparent random drops. Set level=unique on the IPsec policy template so each client gets an isolated SA:

/ip ipsec policy set [find template=yes] level=unique

After ISP IP rotation, L2TP server tears down the session for the reconnecting client If the server has one-session-per-host=yes and the client’s WAN IP changes (ISP rotation or CGNAT), RouterOS treats the reconnect as a duplicate and drops both sessions. Set it to no (the default) unless duplicate-session enforcement is required:

/interface l2tp-server server set one-session-per-host=no

Drops occur on low-power hardware (hEX, hEX lite) and correlate with high CPU On RB750Gr2 and similar hEX-class routers, CPU saturation during the IPsec SA rekey window can prevent rekey from completing in time, causing the SA to expire and the tunnel to drop. Check CPU during the 8-hour window with:

/system resource print

If CPU peaks above 80% during rekey, consider reducing pfs-group to none (Phase 2) to reduce rekey computation, or upgrading to hardware with dedicated crypto acceleration.

See Also

• L2TP — MikroTik official docs
• IPsec — Phase 1/Phase 2 reference
• PPP AAA — PPP profile parameters
• VPN between home and cottage networks — L2TP/IPsec site-to-site example