![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")
Last validated: Feb 13, 2026
\nWhen you set up subnet routers, exit nodes, or app connectors, Tailscale injects routes into client routing tables so traffic reaches the correct destination. This topic explains the complete route injection process, including when routes appear in client routing tables, how access controls interact with routing, and how router selection works.
\nRoutes and access controls operate at different layers and serve different purposes:
\nA common misconception is that grants or ACLs control route injection. They do not. Grants control packet filtering, while routes are injected based on what subnet routers advertise and what the control plane approves.
\nFor traffic to flow successfully, you need both:
\nYou can have a route without ACL access (packets enter the tunnel but are dropped by the filter), or ACL access without a route (packets never enter the tunnel). Both conditions must be satisfied for end-to-end connectivity.
\nRoutes are injected into a client's routing table when all following conditions are met:
\nA subnet router advertises the route. The subnet router uses --advertise-routes to announce which subnets it can reach.
An admin approves the route. Routes must be approved in the admin console or through autoApprovers in the tailnet policy file.
The control plane distributes the route. After approval, the control plane includes the route in the network map sent to clients.
\nThe client accepts subnet routes. The client must have route acceptance enabled:
\ntailscale set --accept-routesRoutes appear because clients receive them in the network map after they're advertised and approved; clients don't probe a router with pings before installing routes.
\nIf a router is offline or access controls don't permit traffic to flow, the route may still be present but traffic won't successfully traverse it.
\nA common question is whether a grant allowing a CIDR range (like 0.0.0.0/0) causes all advertised routes within that range to be injected. The answer is no. Grants and routes are evaluated independently:
Route injection: The client receives exactly the routes that subnet routers advertise and admins approve. If a router advertises 10.1.0.0/24, clients get a route to 10.1.0.0/24. A grant allowing 10.0.0.0/8 does not cause additional routes to be injected.
ACL evaluation: When traffic flows through an injected route, the packet filter checks if a grant permits that specific traffic. A grant allowing 10.0.0.0/8 permits traffic to any IP within that range, regardless of how many or how few routes exist within it.
When multiple subnet routers advertise routes, only exact prefix matches are grouped for high availability. For example:
\n10.0.0.0/24 are failover candidates for each other10.0.0.0/24 and another advertising 10.0.0.0/16 are not failover candidates, even though the /16 contains the /24The operating system's routing table handles longest-prefix matching as usual. If routes exist to both 10.0.0.0/8 and 10.1.0.0/16, traffic to 10.1.0.5 uses the more specific /16 route.
When multiple subnet routers advertise the same route, the control plane distributes the available routers in the network map and clients choose an active route based on availability and preferences (for example, high-availability or regional routing settings).
\nThe choice depends on factors such as:
\nvia routingWhen using the via field in grants to specify which routers can handle traffic, only \"accessible\" routers are candidates. A router is accessible when:
via routing is policy-aware: a router must be eligible for the user and traffic in question, and tailnet policy can limit which routers may be used.
If policy prevents a user from using a router, that router won't be a usable via candidate for that user.
Consider this example grant:
\n{\r\n \"grants\": [\\\r\n {\\\r\n \"src\": [\"group:engineering\"],\\\r\n \"dst\": [\"192.168.0.0/16\"],\\\r\n \"ip\": [\"*\"]\\\r\n }\\\r\n ]\r\n}\nThis grant permits group:engineering to send traffic to 192.168.0.0/16. However, the grant does not inject any routes. For traffic to actually reach 192.168.0.0/16:
If a subnet router advertises 192.168.1.0/24, clients receive that specific route. Traffic to 192.168.1.50 works (route exists, ACL permits). Traffic to 192.168.2.50 fails because no route covers it, even though the grant would permit the traffic.
Conversely, if a subnet router advertises 10.0.0.0/8 but no grant covers it, clients receive the route but traffic is dropped by the packet filter.
If expected routes don't appear on a client:
\ntailscale status --json on the router.tailscale debug prefs and check if RouteAll is true. If false, run tailscale set --accept-routes.ip route on Linux, netstat -rn on macOS).If routes exist but traffic is blocked:
\ntailscale debug netmap and examine the PacketFilter section to check effective rules.If failover between subnet routers isn't working:
\nAsk AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}