Understand subnet routers

Not every printer, database, appliance, or legacy server can install Tailscale. A subnet router connects an existing IP prefix to the tailnet.

Think of your home NAS, a managed switch’s admin page, or an office printer. No Tailscale client exists for them, or policy forbids installing one. Instead, one Linux machine on that network runs Tailscale and forwards traffic on behalf of its neighbors.

How the traffic flows

Tailnet clients send matching destination traffic to the router, which forwards it into the local subnet. Your laptop learns a route: “for 192.168.50.0/24, send to the subnet router.” Packets travel encrypted through the tailnet to the router, then hop onto the physical LAN as ordinary local traffic.

The devices behind the router never know Tailscale exists. By default the router applies source NAT, so the printer sees a connection coming from the router’s LAN address, a neighbor it already trusts.

Reachability is not permission

The route extends reachability, not permission: route approval controls whether clients learn the route, while access policy controls who may use it.

Two separate switches. An admin approves the advertised prefix, and a grant decides which users may send traffic into it. Approving the route while forgetting the grant, or the reverse, is the most common “it doesn’t work” in this module.

Pick your lab subnet carefully

Choose a disposable private subnet and identify one resource behind it. Then check your own local network before advertising anything:

ip -4 addr show

2: wlan0    inet 192.168.1.34/24 ...

Do not advertise a prefix that overlaps your current local network during the first test. If your laptop sits on 192.168.1.0/24 and a remote site advertises the same prefix, the client cannot tell local neighbors from routed destinations. The classic symptom: local printers vanish while the remote subnet “works”. Pick something like 192.168.50.0/24 that appears nowhere else in your life.