144 lines
4.1 KiB
Markdown
144 lines
4.1 KiB
Markdown
---
|
|
title: Tailscale Subnet Routing
|
|
description: Guide to publishing LAN subnets into a Tailscale tailnet with subnet routers
|
|
tags:
|
|
- networking
|
|
- tailscale
|
|
- routing
|
|
category: networking
|
|
created: 2026-03-14
|
|
updated: 2026-03-14
|
|
---
|
|
|
|
# Tailscale Subnet Routing
|
|
|
|
## Introduction
|
|
|
|
Subnet routing allows Tailscale clients to reach devices that are not running the Tailscale agent directly. This is useful for printers, storage appliances, hypervisors, IoT controllers, and legacy systems on a homelab LAN.
|
|
|
|
## Purpose
|
|
|
|
Use subnet routing when:
|
|
|
|
- A device cannot run the Tailscale client
|
|
- A full site-to-site VPN is unnecessary
|
|
- Remote users need access to one or more internal networks
|
|
- You want to publish access to a specific VLAN without exposing the entire environment
|
|
|
|
## Architecture Overview
|
|
|
|
A subnet router is a Tailscale node with IP forwarding enabled. It advertises one or more LAN prefixes to the tailnet.
|
|
|
|
```text
|
|
Remote client -> Tailscale tunnel -> Subnet router -> LAN target
|
|
```
|
|
|
|
Recommended placement:
|
|
|
|
- One router per routed network or security zone
|
|
- Prefer stable hosts such as small Linux VMs, routers, or dedicated utility nodes
|
|
- Apply restrictive ACLs so only approved identities can use the route
|
|
|
|
## Step-by-Step Guide
|
|
|
|
### 1. Prepare the router host
|
|
|
|
Install Tailscale on a Linux host that already has reachability to the target subnet.
|
|
|
|
Enable IPv4 forwarding:
|
|
|
|
```bash
|
|
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
|
|
sudo sysctl --system
|
|
```
|
|
|
|
If the subnet is IPv6-enabled, also enable IPv6 forwarding:
|
|
|
|
```bash
|
|
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
|
|
sudo sysctl --system
|
|
```
|
|
|
|
### 2. Advertise the subnet
|
|
|
|
Start Tailscale and advertise the route:
|
|
|
|
```bash
|
|
sudo tailscale up --advertise-routes=192.168.10.0/24
|
|
```
|
|
|
|
Multiple routes can be advertised as a comma-separated list:
|
|
|
|
```bash
|
|
sudo tailscale up --advertise-routes=192.168.10.0/24,192.168.20.0/24
|
|
```
|
|
|
|
### 3. Approve the route
|
|
|
|
Approve the advertised route in the Tailscale admin console, or pre-authorize it with `autoApprovers` if that matches your policy model.
|
|
|
|
### 4. Restrict access
|
|
|
|
Use ACLs or grants so only the necessary users or tagged devices can reach the routed subnet.
|
|
|
|
Example policy intent:
|
|
|
|
- `group:admins` can reach `192.168.10.0/24`
|
|
- `group:developers` can only reach specific hosts or ports
|
|
- IoT and management subnets require separate approval
|
|
|
|
## Configuration Example
|
|
|
|
Example server-side command for a dedicated subnet router:
|
|
|
|
```bash
|
|
sudo tailscale up \
|
|
--advertise-routes=192.168.10.0/24 \
|
|
--advertise-tags=tag:subnet-router
|
|
```
|
|
|
|
Example policy idea:
|
|
|
|
```json
|
|
{
|
|
"tagOwners": {
|
|
"tag:subnet-router": ["group:admins"]
|
|
}
|
|
}
|
|
```
|
|
|
|
## Troubleshooting Tips
|
|
|
|
### Clients can see the route but cannot reach hosts
|
|
|
|
- Verify IP forwarding is enabled on the router
|
|
- Confirm local firewall rules permit forwarding traffic
|
|
- Make sure the router has normal LAN connectivity to the destination hosts
|
|
- Check whether the destination host has a host firewall blocking the source
|
|
|
|
### Route does not appear in the tailnet
|
|
|
|
- Confirm the router is online in `tailscale status`
|
|
- Check that the route was approved in the admin console
|
|
- Review whether policy requires a specific tag owner or auto-approval
|
|
|
|
### Asymmetric routing or reply failures
|
|
|
|
- Make sure the subnet router is in the normal return path for the destination subnet
|
|
- Avoid overlapping subnets across multiple sites unless routing precedence is intentional
|
|
- Do not advertise broad prefixes when a narrower one is sufficient
|
|
|
|
## Best Practices
|
|
|
|
- Advertise the smallest subnet that solves the use case
|
|
- Run subnet routers on stable infrastructure, not laptops
|
|
- Use separate routers for management and user-facing networks where possible
|
|
- Combine routing with ACLs; route advertisement alone is not authorization
|
|
- Monitor route health and document ownership of every advertised prefix
|
|
|
|
## References
|
|
|
|
- [Tailscale: Subnet routers](https://tailscale.com/kb/1019/subnets)
|
|
- [Tailscale: Access controls](https://tailscale.com/kb/1018/acls)
|
|
- [Tailscale: Policy file syntax](https://tailscale.com/kb/1337/policy-syntax)
|