L2TP Disconnects After 8 Hours
L2TP Disconnects After 8 Hours
Section titled “L2TP Disconnects After 8 Hours”RouterOS L2TP sessions that terminate at a fixed, repeating interval — most commonly every 8 hours — are almost always caused by a PPP profile session-timeout setting. This is a hard wall-clock limit on session duration, enforced regardless of traffic activity. This guide explains how to identify and resolve the issue, and how to distinguish it from other causes of L2TP instability.
Overview
Section titled “Overview”L2TP in RouterOS is implemented as a PPP-based tunnel. All L2TP connections inherit properties from a PPP profile, including timeout values. The session-timeout property in /ppp profile sets the maximum duration of any single PPP session. When this limit is reached, RouterOS forcibly terminates the session. If the value is set to 8h (or 28800 seconds), every L2TP session will disconnect exactly 8 hours after connecting.
This behaviour is often mistaken for a software bug, keepalive failure, or ISP-imposed limit. In most cases it is a deliberate configuration value — sometimes inherited from the default profile without the administrator realising it was set.
Session-Timeout vs. Idle-Timeout
Section titled “Session-Timeout vs. Idle-Timeout”| Property | Trigger | Typical cause of 8h drops? |
|---|---|---|
session-timeout | Fixed wall-clock time from session start | Yes — causes exactly periodic drops |
idle-timeout | Period of no traffic activity | No — only drops idle sessions |
If your L2TP sessions disconnect on a precise schedule (within seconds of the same interval each time), session-timeout is the likely cause. Idle-timeout drops are traffic-dependent and will not occur on a strict schedule.
Prerequisites
Section titled “Prerequisites”- Access to the RouterOS device acting as the L2TP server (Winbox, SSH, or console)
/pppand/interface l2tp-serverread/write permission- If RADIUS authentication is in use: access to RADIUS server configuration
Diagnosing the Cause
Section titled “Diagnosing the Cause”Step 1 — Confirm the Disconnect Interval
Section titled “Step 1 — Confirm the Disconnect Interval”Check the uptime of active L2TP sessions and review log timestamps to confirm the interval is fixed.
# View active PPP sessions and their uptime/ppp active print
# View recent disconnect events/log print where topics~"l2tp"/log print where topics~"ppp"If sessions consistently terminate at the same elapsed time from connection, the cause is a configured timeout.
Step 2 — Identify the Active PPP Profile
Section titled “Step 2 — Identify the Active PPP Profile”Determine which PPP profile is applied to the L2TP server.
/interface l2tp-server server print detailNote the default-profile field. If no profile is explicitly set, the default profile is used.
Step 3 — Inspect PPP Profile Timeout Settings
Section titled “Step 3 — Inspect PPP Profile Timeout Settings”/ppp profile print detailLook for the session-timeout field in the profile identified above. A value of 8h, 28800, or 08:00:00 confirms this is the cause.
Also check individual PPP secrets (users), which can override the profile timeout:
/ppp secret print detailStep 4 — Check for RADIUS-Supplied Timeout
Section titled “Step 4 — Check for RADIUS-Supplied Timeout”If the L2TP server uses RADIUS authentication, the RADIUS server may be supplying a Session-Timeout attribute (RADIUS attribute 27) that overrides the local PPP profile setting. Check your RADIUS server policy for any Session-Timeout value of 28800 seconds.
Configuration
Section titled “Configuration”Remove or Extend the Session Timeout
Section titled “Remove or Extend the Session Timeout”To allow L2TP sessions to run indefinitely, set session-timeout to 0 (unlimited) on the relevant profile:
# On the default profile (used if no other profile is assigned)/ppp profile set default session-timeout=0
# On a named profile/ppp profile set [find name=my-l2tp-profile] session-timeout=0To set a specific limit instead of removing it entirely:
# Allow sessions up to 24 hours/ppp profile set default session-timeout=24hAdjust Keepalive Timeouts (for Non-Periodic Drops)
Section titled “Adjust Keepalive Timeouts (for Non-Periodic Drops)”If sessions drop unpredictably rather than on a fixed schedule, the cause may be keepalive timeout — RouterOS terminates a session when keepalive probes go unanswered. Default values are conservative; increasing them reduces false drops on unstable paths.
# L2TP client side/interface l2tp-client set [find] keepalive-timeout=120
# L2TP server side/interface l2tp-server server set keepalive-timeout=60Enable Verbose Logging for Diagnosis
Section titled “Enable Verbose Logging for Diagnosis”If the cause is unclear, enable detailed logging before the next expected disconnect:
/system logging add topics=l2tp action=memory/system logging add topics=ppp action=memoryAfter the disconnect occurs, review the logs:
/log print where topics~"l2tp"/log print where topics~"ppp"Verification
Section titled “Verification”After applying the fix, verify the change took effect and monitor session uptime past the previous disconnect interval.
# Confirm session-timeout is now 0 (unlimited)/ppp profile print where name=default
# Monitor active sessions — uptime should exceed 8h/ppp active printIf sessions now persist beyond 8 hours, the session-timeout was the cause. If disconnects continue, re-enable verbose logging and examine the log entries immediately before the disconnect for clues.
Troubleshooting
Section titled “Troubleshooting”Sessions still disconnect at 8-hour intervals after setting session-timeout=0
Section titled “Sessions still disconnect at 8-hour intervals after setting session-timeout=0”- Verify the profile that is actually applied to the L2TP server:
/interface l2tp-server server print detail— confirmdefault-profilematches the profile you modified. - Check PPP secrets for per-user profile overrides:
/ppp secret print detail. - If RADIUS is in use, verify the RADIUS server is not sending a
Session-Timeout(attribute 27) in its Access-Accept response.
Sessions disconnect but not at a fixed interval
Section titled “Sessions disconnect but not at a fixed interval”Fixed-interval drops point to session-timeout. Non-fixed drops indicate a different cause:
| Symptom | Likely Cause |
|---|---|
| Drops only when idle | idle-timeout is set |
| Drops on NAT-heavy networks | Connection tracking timeout on UDP 1701 |
Drops with IPsec (use-ipsec=yes) | IPsec proposal mismatch or re-key failure |
| Drops with log message “LCP timeout” | Keepalive failure — increase keepalive-timeout |
| Drops with fragmented traffic | MTU/MRU mismatch — reduce mru/mtu to 1460 or lower |
MTU/MRU Adjustment
Section titled “MTU/MRU Adjustment”L2TP adds encapsulation overhead. If fragmentation causes drops, reduce the interface MTU/MRU:
# On the L2TP client/interface l2tp-client set [find] mtu=1460 mru=1460
# On the PPP profile used by the L2TP server/ppp profile set default-encryption mtu=1460 mru=1460Firewall — Required Ports
Section titled “Firewall — Required Ports”Ensure the firewall permits traffic required for L2TP:
# L2TP without IPsec/ip firewall filter add chain=input protocol=udp dst-port=1701 action=accept comment="L2TP"
# L2TP with IPsec (IKEv1)/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept comment="IPsec IKE/NAT-T"/ip firewall filter add chain=input protocol=ipsec-esp action=accept comment="IPsec ESP"