Tailscale Subnet Routing

Guide to publishing LAN subnets into a Tailscale tailnet with subnet routers

created: Sat Mar 14 2026 00:00:00 GMT+0000 (Coordinated Universal Time) updated: Sat Mar 14 2026 00:00:00 GMT+0000 (Coordinated Universal Time) #networking#tailscale#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.

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:

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:

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:

sudo tailscale up --advertise-routes=192.168.10.0/24

Multiple routes can be advertised as a comma-separated list:

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:

sudo tailscale up \
  --advertise-routes=192.168.10.0/24 \
  --advertise-tags=tag:subnet-router

Example policy idea:

{
  "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