{"slug":"troubleshoot-hard-nat-issues","title":"Troubleshoot hard NAT issues","tags":["tailscale","networking"],"agent_summary":"Last validated: Mar 16, 2026","trigger_phrases":[],"runnable":false,"markdown":"\r\n# Troubleshoot hard NAT issues\r\n\r\nLast validated: Mar 16, 2026\r\n\r\nIn a scenario with three contingent conditions, you may experience network performance issues. This affects latency-sensitive traffic through connectors (exit nodes, subnet routers, and app connectors). One possible visible symptom is DNS resolution timing out. Perform network tests to diagnose your configuration and traffic and ascertain if the following are applicable.\r\n\r\n1. [Hard NAT](https://tailscale.com/docs/reference/connection-types#hard-nat) makes establishing direct connections difficult (if not impossible). Tailscale will fall back to DERP relay servers based around the world.\r\n\r\n2. If heavy packets per second or bits per second of traffic are relaying over these DERP TCP connections, there is a higher potential for [head-of-line blocking](https://en.wikipedia.org/wiki/Head-of-line_blocking)—and in the extreme case: a [TCP meltdown](https://en.wikipedia.org/wiki/Tunneling_protocol#TCP_meltdown_problem).\r\n\r\n3. This packet blocking can occur with greater likelihood and impact on a network that consists of nodes with traffic aggregation and forwarding like subnet routers and exit nodes.\r\n\r\n\r\nThe preferred and recommended approach is to use direct peer-to peer connections rather than DERP relay connections for these key nodes. Removing the Hard NAT will address the underlying and contributing factors. Change it to a no NAT (directly accessible) or [easy NAT](https://tailscale.com/docs/reference/device-connectivity#easy-nat) configuration.\r\n\r\nHowever, if removing the Hard NAT on the connector is not an option, you can attempt to minimize the contributing factor of packets blocked by shared traffic. One approach is to isolate latency-sensitive services behind separate subnet routers. Another approach would be to host latency-sensitive services on their own nodes without a subnet router in front of them.\r\n\r\n![Project Logo](https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed)\r\n\r\nAsk AI\r\n\r\nreCAPTCHA\r\n\r\nRecaptcha requires verification.\r\n\r\nprotected by **reCAPTCHA**\r\n","html":"<h1>Troubleshoot hard NAT issues</h1>\n<p>Last validated: Mar 16, 2026</p>\n<p>In a scenario with three contingent conditions, you may experience network performance issues. This affects latency-sensitive traffic through connectors (exit nodes, subnet routers, and app connectors). One possible visible symptom is DNS resolution timing out. Perform network tests to diagnose your configuration and traffic and ascertain if the following are applicable.</p>\n<ol>\n<li>\n<p><a href=\"https://tailscale.com/docs/reference/connection-types#hard-nat\">Hard NAT</a> makes establishing direct connections difficult (if not impossible). Tailscale will fall back to DERP relay servers based around the world.</p>\n</li>\n<li>\n<p>If heavy packets per second or bits per second of traffic are relaying over these DERP TCP connections, there is a higher potential for <a href=\"https://en.wikipedia.org/wiki/Head-of-line_blocking\">head-of-line blocking</a>—and in the extreme case: a <a href=\"https://en.wikipedia.org/wiki/Tunneling_protocol#TCP_meltdown_problem\">TCP meltdown</a>.</p>\n</li>\n<li>\n<p>This packet blocking can occur with greater likelihood and impact on a network that consists of nodes with traffic aggregation and forwarding like subnet routers and exit nodes.</p>\n</li>\n</ol>\n<p>The preferred and recommended approach is to use direct peer-to peer connections rather than DERP relay connections for these key nodes. Removing the Hard NAT will address the underlying and contributing factors. Change it to a no NAT (directly accessible) or <a href=\"https://tailscale.com/docs/reference/device-connectivity#easy-nat\">easy NAT</a> configuration.</p>\n<p>However, if removing the Hard NAT on the connector is not an option, you can attempt to minimize the contributing factor of packets blocked by shared traffic. One approach is to isolate latency-sensitive services behind separate subnet routers. Another approach would be to host latency-sensitive services on their own nodes without a subnet router in front of them.</p>\n<p><img src=\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\" alt=\"Project Logo\"></p>\n<p>Ask AI</p>\n<p>reCAPTCHA</p>\n<p>Recaptcha requires verification.</p>\n<p>protected by <strong>reCAPTCHA</strong></p>\n"}