Tailscale / Troubleshooting
Tailscale Exit Node Is Connected but There Is No Internet
Separate exit-node approval and policy, Linux forwarding, the exit node's own upstream connectivity, client numeric-IP reachability, firewall/NAT evidence, and DNS on Tailscale 1.102.3.
An exit node must be advertised, allowed for the tailnet, selected by the client, and able to forward traffic. On Linux, Tailscale documents IP forwarding as a prerequisite for exit-node routing.[1][2]
A custom tailnet policy can also block Internet routing through an otherwise reachable exit node. Tailscale documents autogroup:internet for policy rules that permit traffic to the public Internet through an exit node, so policy should be checked before blaming NAT or the host firewall.[1]
Applicability
- Products
- Tailscale
- Scope
- For Tailscale v1.102.3 when a client can connect to the tailnet and select an exit node, but Internet traffic through that exit node fails. This page is not for an exit node that is absent from the client list, a generic Tailscale connection failure, a subnet-router-only problem, or a DNS-only problem once external numeric-IP connectivity is proven.[4][1]
- Last verified
Symptoms
Quick diagnosis
Prove policy, forwarding, the exit node's own upstream path, client numeric-IP reachability, and DNS in that order.
Capture client and exit-node state without changing it
Record the selected exit node, current Tailscale status, and whether the node is advertised and approved. Do not toggle routing or firewall state merely to see whether the symptom changes.[1][2]
tailscale statustailscale status --jsonRead the Linux forwarding state
On a Linux exit-node host, inspect IPv4 forwarding before any sysctl change. A disabled value is actionable evidence; an enabled value means the tree should continue to upstream and client-path checks.[1]
sysctl net.ipv4.ip_forwardUse numeric-IP tests to separate routing from DNS
Test an external numeric IP from the exit-node host and then from the client while the exit node is selected. Numeric success on the client moves the diagnosis to DNS rather than firewall or NAT changes.[1][3]
Interactive troubleshooter
Your answers stay in this browser tab. The tool does not connect to your systems or send diagnostic results.
Guided check / step 1
Safe diagnostic guidanceIs the intended exit node selected on the client?
Selection is the scope gate; it does not prove that routing works.[1][2]
Read the complete diagnostic tree without using the controls
- Is the intended exit node selected on the client?
Selection is the scope gate; it does not prove that routing works.[1][2]
- Yes — intended exit node is selected → Is the node approved for exit-node use in the tailnet?
- No — node is not selected or unavailable → Different diagnosis: exit node is not selected or available
- Is the node approved for exit-node use in the tailnet?
The advertised node must be allowed for exit-node use before the client path can succeed.[1]
- Yes — approved → Does the active policy allow this source to use autogroup:internet?
- No — not approved → Exit-node approval is missing
- Does the active policy allow this source to use autogroup:internet?
Check the policy read-only; device reachability is not the same permission as public-Internet routing.[1]
- Yes — default or explicit Internet grant allows it → Is Linux IP forwarding enabled on the exit-node host?
- No — custom policy lacks the required grant → Tailnet policy blocks Internet routing through the exit node
- Unsure → Evidence is not yet specific enough for a safe change
- Is Linux IP forwarding enabled on the exit-node host?
Read the current forwarding value before any sysctl change.[1]
- Yes — forwarding enabled → Can the exit-node host reach an external numeric IP?
- No — forwarding disabled → Linux IP forwarding is disabled
- Can the exit-node host reach an external numeric IP?
Prove the host's own upstream path before diagnosing client forwarding.[1]
- Yes — host Internet works → Can the client reach an external numeric IP through the selected exit node?
- No — host itself has no numeric Internet → The exit-node host's own upstream path is broken
- Can the client reach an external numeric IP through the selected exit node?
Numeric-IP failure keeps the problem in forwarding/firewall/NAT; success moves to DNS.[1][3]
- Yes — numeric Internet works → Does DNS resolution also work through the exit-node path?
- No — numeric Internet fails → Client traffic fails in the forwarding/firewall/NAT boundary
- Does DNS resolution also work through the exit-node path?
Run DNS troubleshooting only after numeric connectivity is proven.[1]
- Yes — DNS works → Evidence is not yet specific enough for a safe change
- No — numeric works but names fail → Routing works; the remaining problem is DNS
- Different diagnosis: exit node is not selected or available
Resolve advertisement, approval, or client selection before this no-Internet tree applies.[1][2]
- Exit-node approval is missing
Approve only the intended node for exit-node use, then retest before changing host networking.[1]
- Tailnet policy blocks Internet routing through the exit node
Correct only the proven source-to-autogroup:internet policy boundary.[1]
- Linux IP forwarding is disabled
Preserve the current value and use the forwarding fix boundary before any firewall rewrite.[1]
- The exit-node host's own upstream path is broken
Repair the host's default route or upstream connectivity before changing Tailscale client state.[1]
- Client traffic fails in the forwarding/firewall/NAT boundary
Keep DNS out of this branch and inspect host forwarding/firewall/NAT evidence without flushing rules.[1][3]
- Routing works; the remaining problem is DNS
Preserve working exit-node routing and continue with DNS-specific troubleshooting.[1]
- Evidence is not yet specific enough for a safe change
Capture the policy, forwarding value, host numeric-IP test, client numeric-IP test, and DNS result before making another change.[1]
Detailed diagnosis
1. Verify that the client really selected the intended exit node
Confirm the intended node is selected on the client and that the node is allowed as an exit node in the tailnet. Do not infer successful routing from the UI selection alone.[1][2]
2. Check the tailnet policy before host-network changes
If the default policy has been replaced, inspect whether the relevant source can reach autogroup:internet. Allowing access to the exit-node device itself is not the same as authorizing public-Internet routing through it.[1]
3. Check Linux IP forwarding
Read the host forwarding state. If it is disabled, stop and preserve the current value before any persistent sysctl change. If enabled, continue rather than changing firewall rules preemptively.[1]
sysctl net.ipv4.ip_forward4. Prove the exit node's own upstream path
Test whether the exit-node host itself can reach an external numeric IP using its normal upstream route. Failure here is an upstream/default-route problem, not evidence that the Tailscale client or DNS is broken.[1][3]
5. Compare client numeric-IP reachability, then inspect forwarding/NAT evidence
If the host has Internet but the client cannot reach an external numeric IP through the selected exit node, inspect forwarding and firewall/NAT evidence without flushing rules. If numeric IPs work, continue only with DNS-specific troubleshooting.[1][3]
Supported scenarios
These observations narrow the next investigation; they do not establish a unique cause.
The tailnet policy does not permit Internet routing through the exit node
With a custom policy, the relevant source may be connected to the tailnet yet lack permission to use autogroup:internet through the exit node.[1]
How to check: Read the active policy and verify the intended source-to-autogroup:internet grant without broadening any rule.[1]
IP forwarding is disabled on the Linux exit node
Linux exit-node routing requires IP forwarding, so a disabled forwarding state prevents the host from carrying client traffic onward.[1]
How to check: Read net.ipv4.ip_forward and record the value before considering a persistent change.[1]
The exit-node host itself has no working upstream route
An exit node cannot provide Internet access when the host itself cannot reach the public Internet over its normal route.[1][3]
How to check: Test an external numeric IP from the exit-node host before inspecting client DNS or changing Tailscale state.[1]
The host can reach the Internet but client traffic is not forwarded successfully
When the host has upstream connectivity and the client still cannot reach an external numeric IP, the remaining boundary is forwarding/firewall/NAT behavior on the exit-node host rather than DNS.[1][3]
How to check: Inspect firewall and forwarding state read-only and correlate the client flow before changing any rules.[1]
Next actions and procedure boundaries
Correct only a proven missing Internet-routing policy grant
If the active custom policy is the proven blocker, add only the least-privilege rule required for the intended source to use autogroup:internet. Do not replace the policy with an allow-all rule and do not confuse exit-node device access with Internet-routing permission.[1]
Before changing anything
- Risk
- Tailnet policy changes can alter access for multiple devices and users, not only the failing client.[1]
- Safer check
- Record the current policy, the intended source identity, and the exact missing grant before editing.[1]
- Expected result
- Only the intended source gains the required exit-node Internet path while unrelated policy behavior remains unchanged.[1]
- Backup / recovery access
- Preserve the previous policy text or version so it can be restored exactly.[1]
- Rollback
- Restore the previous policy if Internet routing does not recover or unrelated tailnet access changes.[1]
Enable Linux forwarding only after the disabled state is proven
If the exit node is approved and policy is correct but net.ipv4.ip_forward is disabled, enable forwarding using the host's normal persistent configuration method. Do not combine this with unrelated firewall rewrites.[1]
Before changing anything
- Risk
- Enabling forwarding changes how the host can route packets between interfaces and can interact with existing firewall policy.[1]
- Safer check
- Record the current forwarding value, host firewall state, and recovery access before changing it.[1]
- Expected result
- The host forwards exit-node traffic and the client can proceed to the numeric-IP connectivity check.[1]
- Backup / recovery access
- Record the previous sysctl value and the file or service that provides the persistent setting.[1]
- Rollback
- Restore the previous forwarding value if routing behavior becomes unsafe or the expected client path does not recover.[1]
If host Internet works but client numeric IP fails, preserve state and inspect firewall/NAT evidence
Do not flush iptables or nftables and do not disable the host firewall. Record the failing client flow, current rules, and Tailscale routing mode, then correct only a proven host forwarding or masquerading boundary under the host's firewall procedure.[1][3]
If numeric IP works, exit to DNS troubleshooting
Preserve routing and firewall state when the client can reach an external numeric IP through the exit node. Continue with DNS-specific evidence instead of changing NAT or forwarding.[1]
Warnings and boundaries
Sources
Links were reviewed on 2026-09-08. Reachability and automated validation do not replace editorial verification of each claim.
- Exit nodes (route all traffic)
Tailscale Inc. · Tier A · accessed 2026-09-08 - tailscale set CLI reference
Tailscale Inc. · Tier A · accessed 2026-09-08 - Kernel versus userspace routers
Tailscale Inc. · Tier A · accessed 2026-09-08 - Tailscale changelog
Tailscale Inc. · Tier A · accessed 2026-09-08