Which keepalive mechanism should PuTTY prioritize for NAT traversal: TCP keepalives or application-level SSH keepalives

Answer the exact question first

When both options are enabled, PuTTY should prioritize application‑level SSH keepalives (null packets). They refresh NAT and stateful firewall mappings at the interval you set, while OS‑controlled TCP keepalives typically fire far too late to keep those mappings alive.

Why SSH keepalives win for NAT

• They are sent by the SSH client itself, so every NAT device that sees traffic on the SSH port receives a packet and resets its timeout counter.
• The interval can be tuned to match or be a fraction (e.g., 50%) of the known NAT timeout, ensuring the mapping never expires.
• They provide quick failure detection: if a null packet is not acknowledged, PuTTY will terminate the session.

Interaction when both are enabled

PuTTY treats the two mechanisms independently:

• The Seconds between keepalives setting sends null packets at the user‑defined interval.
• The Enable TCP keepalives checkbox simply sets the socket SO_KEEPALIVE flag; the kernel then sends its own keepalive packets based on the OS defaults (often 2–3 hours).
• Because the SSH keepalives are much more frequent, they will keep the NAT mapping alive long before any TCP keepalive would fire.

Recommended configuration for aggressive NATs

1. Determine the NAT timeout of the intermediate gateway (see Verification below).
2. Set Seconds between keepalives to a value that is less than half of that timeout. For example, if the NAT times out after 5 minutes, use 120–150 seconds.
3. Leave Enable TCP keepalives checked to keep the OS‑level fallback in case the SSH keepalive is disabled or the server drops the session silently.
4. Optionally, enable PuTTY’s Connection > Keepalives diagnostics to log when keepalives are sent.

Verification steps

• Use a packet sniffer (e.g., Wireshark) on the client side to confirm that SSH null packets appear at the configured interval.
• Check firewall or NAT logs to see that the mapping refreshes in sync with the null packets.
• If the session still drops, consider lowering the interval further or inspecting the server’s SSH configuration for idle timeouts.

Missing diagnostic detail needed to fine‑tune the recommendation

What is the exact NAT timeout value of the gateway between your client and the SSH server? Knowing that number lets you set the SSH keepalive interval precisely.