This machine is misconfigured and cannot relay traffic

Not specified by the original author.

Fix "This machine is misconfigured and cannot relay traffic" (false positive)

TL;DR: The console is lying: your exit node is fine, but it reported its forwarding state before you enabled IP forwarding. Restart Tailscale (or toggle the advertised routes) so it re-reports, and the badge clears.

The error

This machine is misconfigured and cannot relay traffic.
This machine has IP forwarding disabled and cannot relay traffic.

Shown in the admin console machines list and in Edit route settings, with an Exit Node ! badge, even though traffic relays fine.

Fix it

1. Confirm it is the false positive

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
tailscale status

Expected: both sysctls are 1, and a client test through the exit node works. If forwarding is actually 0, just enable it persistently and skip to step 3.

2. Restart Tailscale so it re-reports

sudo systemctl restart tailscaled

Expected: on the next MapRequest the client reports forwarding correctly and the console clears the badge within a few minutes.

3. If the badge sticks, toggle the advertised routes

In the admin console, open the machine's Edit route settings, uncheck "Use as exit node", save, then re-check it and save again. Or from the CLI:

sudo tailscale up --advertise-exit-node=false
sudo tailscale up --advertise-exit-node

Expected: the route state refreshes and the warning disappears.

4. Or just wait

The forwarding state also refreshes on disco key rotation. If nothing is actually broken, the badge can clear on its own.

When this applies

• Console says misconfigured / IP forwarding disabled
• sysctl shows forwarding enabled
• Real exit-node traffic works
• You enabled the exit-node flag before enabling IP forwarding

When it does not apply

• Forwarding is actually disabled (enable it: sysctl -w net.ipv4.ip_forward=1 plus persistent config)
• Clients genuinely cannot reach the internet through the node (real misconfiguration)
• The node never advertised exit routes at all

Tool compatibility

Tailscale 1.9x on Linux. The control-side fix was merged; the client-side refresh behavior ships in later 1.9x.

Variant phrasings

Exit Node ! badge with "Unable to relay traffic" in route settings

Same false positive, seen in the Edit route settings panel. Same fix.

Why it happens

The client detects IP forwarding once, when it sends its MapRequest to the control server. If you flipped the exit-node flag first and enabled forwarding after, the control plane kept the stale "disabled" reading until something forced a fresh report.

Edge cases

• Order matters on new builds: enable IP forwarding BEFORE first advertising the exit node to avoid this entirely.
• Persistent sysctl: set net.ipv4.ip_forward=1 in /etc/sysctl.conf or a drop-in so a reboot does not reintroduce the real version of this warning.
• API says fine, UI says broken: trust the API route state plus a live traffic test over the console badge.

Thread ref gh:tailscale/tailscale#18976 (closed). Three Linux exit nodes were flagged in the admin console with 'This machine is misconfigured and cannot relay traffic' and 'This machine has IP forwarding disabled and cannot relay traffic', yet kernel forwarding was enabled (net.ipv4.ip_forward=1), the admin API showed advertised and enabled routes correct, and real client traffic relayed fine: a control-plane/UI false positive. Tailscale maintainer mikeodr gave the immediate workarounds: restart Tailscale, reboot the machine, wait for the disco key rotation, or change the advertised routes; the root cause was enabling the exit-node flag before enabling IP forwarding, since forwarding detection happens when the client sends its MapRequest. A control-side fix was merged. Source: https://github.com/tailscale/tailscale/issues/18976

Not specified by the original author.

TL;DR

The CRM allowlists login IPs and the agent's egress IP is not on it, so every connection is refused regardless of credentials. Find the agent's egress IPs, add them to the allowlist (or route the agent through an approved egress), and verify. This is network policy, not auth.

Error

Access error: login from unrecognized IP; the IP allowlist blocked the connection.

Steps

1. Determine the agent's egress IP (check what the CRM sees, not what the host thinks). Expected: the real public egress IP.
2. Add it to the CRM's trusted IP ranges or login IP allowlist. Expected: the policy permits the agent.
3. If egress IPs are dynamic, route the agent through a static egress (NAT gateway or proxy). Expected: a stable IP to allowlist.
4. Verify with a login from the agent. Expected: success.
5. Document the egress path; cloud egress IPs change, and the allowlist needs maintenance. Expected: no surprise re-blocks.

When to use

• Connections refused from the agent's network with correct credentials.
• An agent works from one network but not another.
• After migrating agent hosting.

When not to use

• Wrong credentials (fix auth).
• 403s after successful login (permissions).

Tool compatibility

• Salesforce login IP ranges and trusted IPs; HubSpot IP allowlisting.
• NAT gateways and egress proxies.

Variant phrasings

ip allowlist blocked egress

Allowlist the egress IP or fix the route.

unrecognized ip on login

Same policy block.

Why it happens

Allowlisting trusts networks, not just credentials. Agents on dynamic cloud egress present a different IP than expected, and the policy blocks them.

Edge cases

• IPv6 egress needs its own allowlist entries; check both families.
• VPNs change the egress IP; allowlist the VPN egress, not the office.
• Overly broad allowlists defeat the purpose; keep them tight.

Provenance

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

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

Thread query: agent failed to access the crm: ip allowlist blocked its egress error

TL;DR: The CRM allowlists login IPs and the agent's egress IP is not on it, so every connection is refused regardless of credentials. Find the agent's egress IPs, add them to the allowlist (or route the agent through an approved egress), and verify. This is network policy, not auth.

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.