Why the Linux Tailscale client ignores advertised subnet routes

You are on a Linux laptop, tailscale status lists the other machines, and the NAS at 10.80.0.25 still times out. The tailnet is healthy, the subnet router is online, and nothing in the client's output says why the LAN behind it is unreachable. The walkthrough below moves outward from that symptom: the flag on this client, then the advertisement on the router, then approval, then policy, and only then the destination itself. Each gate fails with the same timeout, so the order matters more than the commands.

What the Linux client is refusing to install

Tailscale clients on Linux do not accept advertised subnet routes unless you ask them to. Without that setting the client joins the tailnet and reaches peer addresses, while every prefix the router advertises stays unused. The default is deliberate, and it is why the symptom looks like a broken router rather than a local decision.

Two separate things are called routing here, and only one of them is yours. The router advertises a prefix into the tailnet; your machine decides whether to install it. A failure in either produces the same timeout, which is why guessing wastes an afternoon. Find which side is refusing before you edit anything.

Turn route acceptance on for this machine

Set the preference on the client, then look at what changed instead of assuming the command took effect. The current form applies the setting without repeating the login flow, which matters when you are mid-session.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale installs accepted routes in its own table on Linux, so a prefix appearing in table 52 is direct evidence that this client installed the advertisement. If your range is absent from that table, stop: the problem is local and no amount of work on the router will change it.

Older clients expose the same preference as a flag on the login command, so sudo tailscale up --accept-routes is the fallback when tailscale set is missing. Use it rather than hand-editing routes, because the daemon rewrites its own table and your edit disappears at the next reconnect. Check the version before you copy a command from an older post.

Check the advertisement and the approval separately

On the subnet router the prefix has to be advertised, and the kernel has to forward packets between interfaces. Advertising without forwarding gives you an approved route that silently drops traffic, which is the most common half-finished setup.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

Compare the advertised prefix with the address you are actually trying to reach, character by character. A router announcing 10.70.0.0/24 says nothing about a NAS at 10.80.0.25, and the mismatch is invisible in every status output because both numbers look equally plausible. Most reports of a broken route end here. Fix the advertisement before you touch anything downstream.

Approval is the next gate, and it is easy to skip when the router was configured from a shell. The advertisement has to be enabled for that device in the admin console before other machines may use it. Accepting routes on the client approves nothing and overrides no access rule.

Probe the private address before the hostname

A successful connection to the router's own tailnet address proves the tailnet works, which you already knew. The useful test is the service you actually need, against the private address first, so a DNS failure cannot masquerade as a routing failure.

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

If the address answers and the hostname does not, you have a name resolution problem and should stop treating it as a route problem. If neither answers, go back a section and confirm the advertisement covers the address. The two failures look identical from the application and are fixed in different places.

One local check is worth doing before you blame the tailnet. When your current LAN uses the same prefix as the remote subnet, the kernel prefers the directly connected route and the traffic never leaves the machine, which is what happens when a home and an office both chose 192.168.1.0/24.

Why a client flag is not a router setting

These are different roles with different requirements, and copying a client flag onto a router is how a working tailnet acquires a loop. A machine that advertises routes needs forwarding, firewall rules that permit the forwarded traffic, and a decision about which prefixes it announces. None of that is implied by --accept-routes.

The subnet router documentation warns against enabling route acceptance on redundant routers that announce one prefix, since a standby node can push traffic that is already local out through the active one. If you run an HA pair, treat that as a design constraint rather than a footnote, and decide which node owns the prefix before you approve it on both. On a single router the same warning reads as a reminder that acceptance belongs on clients, not on the machine doing the advertising. Write down which gate was closed.

For an ordinary client the sequence ends with the application test that failed at the start. For the router, review forwarding, advertisement, approval and firewall in that order, because the first one that is missing produces exactly the timeout you began with.