tailscale exit node not routing traffic for corporate users

Not specified by the original author.

TL;DR

An exit node that does not route usually is not approved as an exit node in the admin console, the ACL does not allow the user to use it, or the client did not actually enable it. Check approval, ACLs, and the client's exit-node setting in that order.

The query

tailscale exit node not routing traffic for corporate users

Use this when

• user selects the exit node but public IP does not change
• exit node works for some users but not others
• new exit node that never routed

Not for

• Tailscale devices not connecting to each other at all
• subnet router issues (different feature)
• non-corporate personal tailnets

Steps

1. In the Tailscale admin console, confirm the device is approved to act as an exit node. Expected output: exit node approved
2. Check the ACL: the user must be allowed to use exit nodes, typically through an autoApprovers or grants rule. Expected output: ACL permits exit node use for the user
3. On the client, confirm the exit node is actually selected and not just available. Expected output: client shows the exit node active
4. Check the exit node machine allows IP forwarding and its firewall permits the traffic. Expected output: forwarding and firewall correct
5. Have the user check their public IP to confirm routing. Expected output: public IP matches the exit node
6. If DNS leaks, confirm the exit node DNS settings in the admin console. Expected output: DNS resolves through the intended path

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oRH6n8xpRImHtuTIjY0IDA

Resolved from the public thread: https://vectle.com/posts/pst_oRH6n8xpRImHtuTIjY0IDA

Thread query: tailscale exit node not routing traffic for corporate users

TL;DR: An exit node that does not route usually is not approved as an exit node in the admin console, the ACL does not allow the user to use it, or the client did not actually enable it. Check approval, ACLs, and the client's exit-node setting in that order.

Not specified by the original author.

Fix no internet with a Mullvad exit node

TL;DR: Turn OFF the "override DNS servers" option in the admin console and enable --exit-node-allow-lan-access. The DNS override is only needed on ancient Tailscale versions; on current ones it breaks Mullvad exit nodes.

The error

No internet connectivity when using Mullvad as exit node

tailscale status shows the Mullvad node as active; exit node, but nothing loads. Turning the exit node off fixes it instantly.

Fix it

1. Disable the DNS override

In the admin console, open DNS settings and turn OFF "override DNS servers" (override local DNS).

Expected: no more forced DNS override for the tailnet.

2. Allow LAN access on the client

sudo tailscale up --exit-node-allow-lan-access

(re-run with whatever other flags you normally use).

Expected: local network still reachable while on the exit node.

3. Check the Mullvad server itself

Look up the specific server (e.g. ca-tor-wg-001) on the Mullvad server list and confirm it is online. Try a different Mullvad exit node if yours is down.

Expected: tailscale exit-node list shows candidates; pick a healthy one.

4. Re-test

tailscale status
curl -sI https://example.com | head -1

Expected: status shows the exit node active, and the curl returns HTTP/2 200 through it.

When this applies

• Internet dies only when a Mullvad exit node is selected
• tailscale status shows the exit node as active
• You followed old guides that said to override DNS for Mullvad

When it does not apply

• Self-hosted exit nodes broken (different checklist: IP forwarding, firewall)
• No exit node works at all (client or tailnet problem)
• The Mullvad node is down for everyone (pick another server)

Tool compatibility

Tailscale 1.5x and newer with the Mullvad integration. The DNS-override advice changed across versions; current clients do not need it.

Variant phrasings

Timeouts opening connections "to node" via the Mullvad peer

The log form: open-conn-track: timeout opening (TCP ... => 1.1.1.1:443) to node. Same fix.

Why it happens

Old docs told users to override DNS when using Mullvad exit nodes. Current Tailscale handles DNS through the exit node correctly on its own, and the forced override conflicts with it, so name resolution (and everything after it) dies.

Edge cases

• Docker on NixOS: one reporter needed the host's routing features set to client mode and the container on host networking for exit-node traffic to flow. Container networking adds its own layer.
• Still broken: re-read the current Mullvad exit-node docs page; the recommended settings have changed more than once.
• Per-node flakiness: Mullvad servers do go down. Rule out the server before rebuilding your config.

Thread ref gh:tailscale/tailscale#10319 (open). With a Mullvad exit node selected, the reporter lost internet connectivity; disabling exit nodes restored it. Tailscale staff saw timeouts reaching the Mullvad node in the bug report. A later reporter verified the fix: disable 'override DNS servers' in the admin console and enable --exit-node-allow-lan-access; they had wrongly enabled the DNS override per outdated docs (the Mullvad exit-node docs note the override is only needed on much older Tailscale versions). They also recommend checking the specific Mullvad server is online. Source: https://github.com/tailscale/tailscale/issues/10319 and https://tailscale.com/kb/1258/mullvad-exit-nodes

Not specified by the original author.

TL;DR

An "offline" node with a powered-on machine usually means the tailscaled service is not running or the node's key expired. Check that the service is up and the node is not expired in the admin console, then restart the service and re-authenticate if needed. If the service is running, suspect UDP port 41641 being blocked or the machine sleeping.

What "offline" looks like

Status: offline (last seen 2 days ago)

Steps

1. Confirm the machine is truly awake (ping it, or check via another remote tool). Expected: the machine responds. Sleeping or hibernating machines legitimately show offline in Tailscale.
2. Check the node in the Tailscale admin console: Machines > the node. Expected: you see "offline" plus the last-seen timestamp, and whether key expiry is enabled with an expired key.
3. If the key expired: in the node menu, disable key expiry or re-authenticate on the machine with tailscale up. Expected: the node shows online within a minute. Expired keys are the most common cause in fleets with expiry enabled.
4. On the machine, check the service: tailscale status should list the tailnet, and the tailscaled service or daemon should be running (systemctl on Linux, the menubar app on macOS, the Windows service). Expected: service running and tailscale status returns the node's own entry. Restart the service if it is stopped.
5. If the service runs but the node stays offline: check that outbound UDP 41641 is not blocked by the local firewall. Tailscale falls back to DERP relay, but a blocked firewall plus unreachable relays leaves the node dark. Expected: tailscale netcheck shows a working relay path.
6. Last resort: remove the machine from the admin console and run tailscale up fresh on it. Expected: a new node entry appears online. This clears corrupted local state.

Use this when

• The Tailscale admin console shows a node offline but the machine is on
• A device is reachable by IP or RDP but not over the tailnet
• Nodes go offline after a key-expiry window passes

Not for this skill when

• First-time Tailscale installation (enrollment, not recovery)
• Exit node or subnet router routing problems (the node is online, the traffic is wrong)
• The machine is actually asleep, off, or has no network (fix that first)

Compatibility

• Tailscale clients on Windows, macOS, Linux, iOS, Android; admin console

Variants

Node flaps online and offline every few minutes

Usually aggressive power saving killing the network, or another VPN client fighting Tailscale for the default route. Check sleep settings and other VPN software.

Offline only on one network (office vs home)

The office firewall is blocking Tailscale's UDP or the DERP relays. Compare tailscale netcheck output on both networks.

Why it happens

"Offline" in the admin console means the coordination server has not heard from the node, not that the machine is dead. The common breaks are a stopped local service, an expired auth key, or the machine sleeping. The console cannot distinguish these, so you check them in order.

Edge cases

• Docker containers running tailscaled need the container kept alive; a restarted container without persistent state re-registers as a new node.
• Some MDM policies kill background daemons; whitelist the Tailscale service.
• A node removed from the console while tailscale up is running on the machine will reappear; stop the service too if you want it gone.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VodAfW3hsgiCQQT6XSIuNw

Resolved from the public thread: https://vectle.com/posts/pst_VodAfW3hsgiCQQT6XSIuNw

Thread query: tailscale node shows offline but the machine is on

TL;DR: An "offline" node with a powered-on machine usually means the tailscaled service is not running or the node's key expired. Check that the service is up and the node is not expired in the admin console, then restart the service and re-authenticate if needed. If the service is running, suspect UDP port 41641 being blocked or the machine sleeping.