PuTTY keepalive limits: SSH null packets vs TCP keepalives for idle sessions behind NAT

Direct Resolution

1. SSH-level null packets reliably reset most NAT and firewall idle timers, whereas TCP keepalives often do not. This is because SSH keepalives contain application-layer payload (encrypted data), which stateful NATs treat as active traffic. TCP keepalives are typically empty ACK probes that some middleboxes ignore when calculating idle timeouts.
2. Enabling both is not harmful, but is generally redundant. SSH keepalives are usually sufficient. TCP keepalives provide OS-level dead-peer detection, but on Windows, the default first probe often occurs after two hours, making it useless for preventing short NAT timeouts unless you manually modify the Windows Registry.
3. A reasonable lower bound is 60 to 300 seconds. Most home NATs timeout between 5 and 30 minutes. An interval of 60–120 seconds is typically safe. Intervals below 30 seconds can increase overhead on metered links and may mask genuine network partitions by keeping a "ghost" socket open.

Technical Explanation

SSH Null Packets (Application Layer)

When you configure Seconds between keepalives, PuTTY sends SSH-level messages (such as SSH_MSG_IGNORE) only when the session is idle. Because these are encrypted payloads wrapped in TCP segments, the NAT router sees a data transfer and resets its session timer.

TCP Keepalives (Transport Layer)

The Enable TCP keepalives option sets the SO_KEEPALIVE socket option. This delegates the keepalive logic to the Windows TCP/IP stack. Because PuTTY cannot control the timing of these probes, they rely on system-wide defaults. Without registry tuning, these probes fire too infrequently to prevent NAT drops.

Verification and Implementation

To implement and verify this without registry changes:

• Navigate to Connection in the PuTTY configuration and set Seconds between keepalives to 60.
• To verify activity, right-click the PuTTY title bar and select Event Log. Look for Sending SSH keepalive message entries appearing at your defined interval.
• For deep verification, use a packet capture tool to confirm that keepalive packets contain a payload (SSH) rather than being empty ACK packets (TCP).

Assumptions and Uncertainties

• OS Defaults: This assumes standard Windows TCP keepalive defaults. Modern Windows versions may vary, but the multi-hour delay for the initial probe remains common.
• NAT Behavior: It is assumed the NAT router is stateful and treats any payload-bearing packet as a timer reset. Some highly aggressive corporate firewalls may behave differently.
• Metered Links: SSH keepalives are small (approx. 60–100 bytes), but aggressive intervals (e.g., every 10 seconds) can add up on extremely restricted data plans.

Missing Diagnostic Detail

If sessions still drop with SSH keepalives enabled at 60 seconds, please specify if you are using a VPN or SSH Proxy/Jump host; in those cases, the timeout may be occurring at the proxy level rather than the local NAT.