first version of the knowledge base :)
This commit is contained in:
143
40 - Guides/networking/tailscale-subnet-routing.md
Normal file
143
40 - Guides/networking/tailscale-subnet-routing.md
Normal file
@@ -0,0 +1,143 @@
|
||||
---
|
||||
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)
|
||||
Reference in New Issue
Block a user