![\"thumbnail-image\"](\"https://yt3.ggpht.com/K3B5Hdi7j4zy2y53nlQCQb9J0qHNuSXhD2hWysrwaiDvv19tPr5RY04QuQfFOvb9rDq9cugGjZU=s68-c-k-c0x00ffffff-no-rj\")
Last validated: Jan 12, 2026
\nSubnet routersare available for all plans.
\nSubnet routers let you extend your Tailscale network (known as a tailnet) to include devices that don't or can't run the Tailscale client. They act as gateways between your tailnet and physical subnets, enabling secure access to legacy devices, entire networks, or services without installing Tailscale everywhere. This capability maintains Tailscale's security model while providing flexibility for complex network environments.
\nWhen designing a secure network, installing the Tailscale client directly on each device provides the best security and performance through end-to-end encryption. However, network administrators frequently encounter situations where direct installation isn't feasible. Devices like printers often lack the capability to run Tailscale, and in large environments such as AWS VPCs or legacy networks undergoing gradual modernization, installing clients on every endpoint becomes impractical.
\nSubnet routers bridge this gap by functioning as gateways that relay traffic between your tailnet and conventional subnet-based networks. They maintain Tailscale's security model by respecting access control policies while extending connectivity to non-Tailscale devices. This approach offers a practical balance between security and connectivity requirements.
\nAn important consideration for organizations is that devices behind subnet routers don't count toward your pricing plan's device limit. Nevertheless, when possible, installing Tailscale directly on devices remains preferable for optimal performance, security, and configuration simplicity.
\nThe subnet router approach provides several important advantages for network administrators and organizations. Each benefit addresses specific challenges in modern network environments.
\nSubnet routers solve practical problems in various network environments by extending Tailscale's secure connectivity model. These use cases represent common deployment scenarios where subnet routers provide substantial value.
\nSubnet routers function as networking bridges that connect separate network environments under a unified access model. They operate at the network layer to facilitate communication between your Tailscale network and traditional subnet-based networks.
\nA subnet router connects subnets, which are parts of a larger network. In Tailscale, a subnet router is a device in your tailnet that you use as a gateway to advertise routes to other devices. This lets devices connect to your tailnet without installing the Tailscale client.
\nAny device that uses the subnet router as a gateway is considered behind the subnet router. Subnet routers use Source Network Address Translation (SNAT) by default. When SNAT is enabled, traffic from a device behind a subnet router appears to come from the router itself, not the original device. If preserving the original source IP address is important for your use case, you can disable SNAT to maintain the original device's IP address in the traffic packets.
\nSubnet Routers | Tailscale Explained - YouTube
\nTap to unmute
\nSubnet Routers | Tailscale Explained Tailscale
\nTailscale68.5K subscribers
\nSubnet routers and exit nodes serve different purposes in the Tailscale ecosystem, though they both involve routing traffic. Understanding the distinction helps you deploy the right solution for your networking needs.
\nExit nodes route outbound internet traffic from your tailnet devices, effectively functioning as VPN servers. When you connect to an exit node, your internet traffic appears to come from the exit node's location. This is useful for accessing geo-restricted content or improving privacy. In contrast, subnet routers provide access to specific private subnets. They enable tailnet devices to reach non-Tailscale devices within those subnets, but don't affect internet traffic routing. If you need to access private networks like office LANs or cloud VPCs, subnet routers are the appropriate solution.
\nSetting up a subnet router involves installing Tailscale on a device that will act as the gateway, configuring it to advertise routes, and ensuring proper access controls. This process requires administrative access to both the subnet router device and your Tailscale network.
\nYou can use almost any device that runs the Tailscale client as a subnet router. To configure a device to run as a subnet router, use the instructions below or refer to the quickstart guide.
\nThe first step in creating a subnet router is installing the Tailscale client on the device that will serve as your gateway. Installation procedures vary by platform, but the process is straightforward across supported operating systems.
\nLinux macOS tvOS Windows Android
\nDownload and install Tailscale onto the device you plan to use as a subnet router.
\nAfter installing Tailscale, you need to configure the device to function as a subnet router by enabling IP forwarding and advertising the subnet routes you want to make available. These steps transform a standard Tailscale node into a gateway for other networks.
\nLinux macOS tvOS Windows Android
\nTo use a Linux device as a subnet router, you need to complete two essential configurations: enabling IP forwarding and advertising subnet routes. Linux devices make particularly good subnet routers due to their stability and networking capabilities.
\nWhen enabling IP forwarding, ensure your firewall denies traffic forwarding by default. This is the default setting for standard firewalls like ufw and firewalld. Blocking traffic forwarding by default prevents unintended routing of traffic.
IP forwarding is required to use a Linux device as a subnet router. This kernel setting lets the system forward network packets between interfaces, essentially functioning as a router. The process for enabling IP forwarding varies between Linux distributions. However, the following instructions work in most cases.
\nIf your Linux system has a /etc/sysctl.d directory, use:
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf\r\necho 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf\r\nsudo sysctl -p /etc/sysctl.d/99-tailscale.conf\nOtherwise, use:
\necho 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf\r\necho 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf\r\nsudo sysctl -p /etc/sysctl.conf\nIf your Linux node uses firewalld, you might need to allow masquerading due to a known issue. As a workaround, you can allow masquerading with this command:
firewall-cmd --permanent --add-masquerade\nAfter you enable IP forwarding, run tailscale set with the --advertise-routes flag. It accepts a comma-separated list of subnet routes.
sudo tailscale set --advertise-routes=192.0.2.0/24,198.51.100.0/24\nMake sure to replace the subnets in the example above with the correct ones for your network. All platforms except Apple TV support both IPv4 and IPv6 subnets. Apple TV only supports IPv4 subnets.
\nIf the device is authenticated by a user who can advertise the specified route in autoApprovers, the subnet router's routes will automatically be approved. You can also advertise any subset of the routes allowed by autoApprovers in the tailnet policy file. If you'd like to expose default routes (0.0.0.0/0 and ::/0), consider using exit nodes instead.
The admin console provides a centralized interface for approving and managing subnet routes advertised by your devices. This step ensures that the routes you've configured on your subnet router become active in your tailnet.
\nYou can skip this step if you use autoApprovers.
property:subnet filter to list all devices advertising subnet routes.subnet property, then go to the Subnets section.You can disable key expiry on your server to avoid having to periodically reauthenticate. If you use tags, key expiry is disabled by default.
\nAccess controls determine which devices and users can access resources through your subnet router. Properly configured access rules are essential for maintaining security while enabling the connectivity you need.
\nAccess rules control which traffic is permitted, while route approval controls which routes are injected into client routing tables. These are separate mechanisms. For a complete explanation, refer to the route injection reference.
\nYou can skip this step if you already have rules that allow access to your advertised subnet routes.
\nThe following example tailnet policy configuration ensures members of group:dev can access devices in the subnets 192.0.2.0/24, 198.51.100.0/24 and 2001:db8::/32, and ensures the subnet 192.0.2.0/24 can access the subnet 198.51.100.0/24 and vice versa, if subnet route masquerading is disabled.
{\r\n \"groups\": {\r\n \"group:dev\": [\"alice@example.com\", \"bob@example.com\"]\r\n },\r\n \"grants\": [\\\r\n {\\\r\n \"src\": [\"group:dev\",\"192.0.2.0/24\", \"198.51.100.0/24\"],\\\r\n \"dst\": [\"192.0.2.0/24\", \"198.51.100.0/24\", \"2001:db8::/32\"],\\\r\n \"ip\": [\"*:*\"]\\\r\n }\\\r\n ]\r\n}\nYou can use the visual policy editor to manage your tailnet policy file. Refer to the visual editor reference for guidance on using the visual editor.
\nVerification ensures that your subnet router is properly configured and functioning as expected. This step confirms that your tailnet devices can communicate with the subnet router before attempting to access resources behind it.
\nCheck that you can ping the Tailscale IP address of your new subnet routers from a tailnet device (such as a Linux, macOS, or Windows device). You can find the Tailscale IP in the admin console or by running the following command on the subnet router.
\ntailscale ip -4\nOnce your subnet router is configured and verified, you need to ensure that other devices in your tailnet can discover and use the new routes. This process varies slightly by operating system.
\nAndroid, iOS, macOS, tvOS, and Windows automatically pick up your new subnet routes.
\nBy default, Linux devices only discover Tailscale IP addresses. To enable automatic discovery of new subnet routes on Linux devices, use the --accept-routes flag:
sudo tailscale set --accept-routes\nNetwork requirements evolve over time, and you may need to modify the subnet routes advertised by your subnet router. This process involves updating the route advertisements and ensuring that the changes are properly approved and accessible.
\nTo update subnet routes:
\nYou can exclude any routes to prevent the subnet router from advertising them.
\nAfter you set up a subnet router, you might consider:
\nDNS configuration lets your tailnet resolve names both for Tailscale devices and for resources on the advertised subnets. This capability enables seamless name resolution across your hybrid network environment.
\nYou can add Tailscale IP addresses to public DNS records because Tailscale IP addresses are only accessible to authenticated users of your network. You can use an internal DNS server on your subnet by configuring split DNS in the DNS page of the admin console.
\nFor critical environments, redundant subnet routers provide reliability by ensuring continued connectivity even if individual subnet router devices fail. This approach is essential for production networks where continuous availability is required.
\nYou can set up high availability to ensure your network is connectable even if one subnet router goes offline. For more information, refer to our topic on high availability failover.
\nWhen setting up subnet routers for high availability (HA), be careful with the --accept-routes flag. If you turn on --accept-routes for subnet routers that share the same routes in the same region, the standby router will accept its own advertised routes from the primary router.
This leads to an inefficient routing path. The standby router will send traffic for its directly connected subnet through the primary router instead. For example, if both subnet routers advertise and accept the same route, such as 192.168.1.0/24, the standby router will send all 192.168.1.0/24 traffic through the primary router, even though it is directly connected to that network.
For most HA subnet router setups, use the --advertise-routes flag alone. Avoid using --accept-routes unless you specifically need that routing behavior.
Tailscale supports advertising overlapping subnet routes with different prefix lengths from multiple subnet routers. When traffic is sent to a destination IP address, Tailscale uses longest prefix matching (LPM) to select the most specific route available.
\nFor example, if you configure:
\n10.0.0.0/1610.0.0.0/24Traffic is routed based on the most specific match:
\n10.0.0.1 routes through subnet router B (matched by the more specific /24 route)10.0.1.1 routes through subnet router A (only matched by the /16 route)This capability is useful for scenarios where you need granular control over routing within a larger address space, such as:
\nTailscale does not fall back to a less-specific route when the subnet router for a more-specific route goes offline. In the example above, if subnet router B (advertising 10.0.0.0/24) becomes unavailable, Tailscale drops traffic to 10.0.0.1 rather than falling back to subnet router A's 10.0.0.0/16 route.
Tailscale treats each advertised prefix independently using static route selection, not dynamic routing. An offline router cannot withdraw its route advertisement, so clients continue to prefer the more-specific prefix even when no healthy router serves it.
\nTo avoid this, configure all subnet routers that advertise a broader prefix to also advertise the more-specific prefix. For example, have subnet router A advertise both 10.0.0.0/16 and 10.0.0.0/24. This ensures the more-specific prefix has multiple candidate routers and can fail over if one goes offline.
For more information about this behavior and additional workarounds, refer to overlapping subnet route failover.
\nSource Network Address Translation (SNAT) affects how source IP addresses appear to devices in different parts of your network. By default, Tailscale performs SNAT on traffic passing through subnet routers, but this behavior can be modified when necessary.
\nBy default, when you advertise subnet routes, Tailscale uses source network address translation (SNAT) (also called masquerading). You can disable SNAT by using the --snat-subnet-routes=false flag (Linux only) with the tailscale up command. Disabling SNAT preserves the source IP addresses of the hosts behind the subnet router.
tailscale up --snat-subnet-routes=false\nThe --snat-subnet-routes flag only works with Linux subnet routers.
When you disable source NAT on a subnet router, devices behind it can access the Tailscale IP addresses of devices they connect to but don't automatically know how to route traffic back to those Tailscale IP addresses. To fix this, you must add a return route that tells the devices to send all Tailscale traffic through your subnet router. You can configure this route in one of three places:
\nThe route should include:
\n100.64.0.0/10 (the Tailscale IP address range, which includes reserved IP addresses)Currently setting --snat-subnet-routes=false on a node that's acting as both a subnet router and exit node can result in upstream drops. The recommended workaround for this is to sepearate the role of the subnet router and the exit node between two nodes if the subnet router must have SNAT disabled.
When a connector's (such as, app connector, subnet router, exit node) key expires, the connector's advertised routes remain configured on other devices but become unreachable (known as \"fail close\" policy). Tailscale keeps these routes in place intentionally because removing them could leak traffic to untrusted networks.
\nTo prevent disruption from this behavior, disable key expiry on the connector or configure high availability. If you prefer to withdraw routes when a key expires, you can use the admin console or API to enable and disable advertised routes when certain conditions are met.
\nAsk AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")