← All Guides
intermediate

Tailscale Subnet Routing: Access Your Entire Home Network Remotely

Set up Tailscale subnet routing to expose your full home network to all your tailnet devices. No VPN server required, no port forwarding.

Budget Homelab ·
networkingtailscaleremote-accessvpn

Tailscale’s default behavior is useful on its own: devices on the same tailnet can reach each other directly. But it only covers the devices that have Tailscale installed. Your NAS, your router admin page, the Proxmox web UI on a server that can’t run Tailscale — those are out of reach by default.

Subnet routing changes that. One device on your network (the subnet router) advertises your home subnet to the rest of the tailnet, and every device on the tailnet can reach everything on that subnet as if it were local.

This is the complete guide to setting it up, including split DNS so services are reachable by hostname and not just IP.

Before you start: You need Tailscale installed and working on the machine that will be the subnet router. If that’s not done yet, start with the Tailscale homelab setup guide.

How subnet routing works

Without subnet routing, Tailscale peers can only talk to each other directly. If your homelab server is on the tailnet at 100.x.x.x, you can reach it from your laptop at 100.y.y.y, but you can’t reach anything else on the 192.168.1.0/24 subnet.

With subnet routing:

  1. Your homelab server runs tailscale up --advertise-routes=192.168.1.0/24
  2. You approve the advertised routes in the Tailscale admin console
  3. Client devices run tailscale up --accept-routes
  4. Your laptop can now reach 192.168.1.100 (NPM), 192.168.1.101 (Proxmox), 192.168.1.102 (NAS) — anything on the home subnet

The subnet router is the device that bridges the two networks. It needs to stay online for routed connections to work. For a homelab, this is usually the same server that runs your core services.

Step 1: Enable IP forwarding on the subnet router

Tailscale subnet routing requires IP forwarding to be enabled in the Linux kernel. The server needs to be able to forward packets between its Tailscale interface and the local network interface.

# Enable IP forwarding for IPv4 and IPv6
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf

# Apply immediately without rebooting
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Verify it took effect:

cat /proc/sys/net/ipv4/ip_forward
# Should output: 1

Step 2: Advertise your subnet

Find your home subnet. On the server, run:

ip route | grep -v tailscale

Look for the local network route — something like 192.168.1.0/24 dev eth0 or 10.0.0.0/24 dev eth0. That’s your subnet.

Now advertise it:

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

Replace 192.168.1.0/24 with your actual subnet. If you’re on multiple subnets (common with VLANs), you can advertise multiple:

sudo tailscale up --advertise-routes=192.168.1.0/24,192.168.10.0/24,192.168.20.0/24

Verify it’s advertised:

tailscale status

You should see the server listed as a subnet router.

Step 3: Approve the routes in Tailscale admin

Tailscale requires manual approval for subnet routes. This is intentional — it prevents a compromised device from silently exposing a network.

  1. Go to the Tailscale admin console
  2. Find your server in the machine list
  3. Click the three dots → Edit route settings
  4. Enable the subnet you advertised
  5. Save

Without this approval step, clients won’t receive the routes even if the server is advertising them.

Step 4: Accept routes on client devices

Client devices need to opt in to accepting subnet routes. On Linux or macOS:

sudo tailscale up --accept-routes

On Windows, this is a toggle in the system tray menu: right-click the Tailscale icon → Use Tailscale Subnets.

On iOS and Android, subnet routes are accepted automatically if the admin console has approved them.

After this, test it:

# From your laptop on a different network (mobile hotspot, etc.)
ping 192.168.1.100

# Or try accessing a service by IP
curl http://192.168.1.100:81

If it works, subnet routing is active. You can reach anything on your home network from anywhere.

Step 5: Set up split DNS so hostnames work

IP addresses are functional but not how you actually use the homelab. You want mealie.domain.com to resolve to the right internal IP when you’re on Tailscale, just like it does at home.

This requires split DNS: tell Tailscale to route DNS queries for your internal domain through your internal DNS server.

In the Tailscale admin console:

  1. Go to DNS
  2. Under Nameservers, click Add nameserver → Custom
  3. Enter your internal DNS server IP (Technitium, Pi-hole, or AdGuard Home)
  4. Under Restrict to domain, enter your internal domain (e.g., homelab.lan, yourdomain.com, or whatever you use)
  5. Save

Now when you’re on Tailscale, DNS queries for your internal domain go to your home DNS server, which resolves them to internal IPs. Everything else resolves normally through public DNS.

If you’re running Technitium, see the Technitium DNS setup guide for configuring your internal zones correctly.

Using MagicDNS alongside subnet routing

Tailscale’s MagicDNS lets you reach tailnet devices by hostname instead of IP. With subnet routing AND MagicDNS enabled, you get two things:

  1. Reach anything on your home subnet by IP from anywhere
  2. Reach tailnet machines by hostname (e.g., pve, homelab-server)

Enable MagicDNS in the admin console under DNS → Enable MagicDNS. Machine names come from the hostname set in Tailscale.

The two features work together — MagicDNS handles tailnet peers, split DNS handles your internal domain’s hostnames, and subnet routing handles direct IP access to everything else.

Locking down who can access the subnet

By default, any device on your tailnet can use the advertised subnet routes. If you share your tailnet with family members or other people, you may want to restrict subnet access to specific users.

Tailscale ACLs (access control lists) in the admin console handle this. A basic policy that restricts subnet access to admin users only:

{
  "acls": [
    {
      "action": "accept",
      "src": ["group:admin"],
      "dst": ["192.168.1.0/24:*"]
    },
    {
      "action": "accept",
      "src": ["*"],
      "dst": ["*:*"]
    }
  ],
  "groups": {
    "group:admin": ["[email protected]"]
  }
}

The more permissive second rule allows normal tailnet peer-to-peer traffic. The first rule specifically allows admin users to access the subnet. Users not in group:admin can still use Tailscale normally but won’t be able to route through to your home network.

Troubleshooting

Ping works but services don’t respond

Check that your firewall isn’t blocking traffic coming from the Tailscale subnet (100.64.0.0/10) or from the subnet router’s Tailscale IP. On Ubuntu with ufw:

sudo ufw allow in on tailscale0

Routes disappear after reboot

The --advertise-routes flag only applies to the current Tailscale session on some setups. Make sure it’s persisted in your Tailscale configuration, or add a post-boot script. On systemd systems, check:

sudo tailscale up --advertise-routes=192.168.1.0/24 --reset

Split DNS not resolving internal hostnames

Confirm the nameserver is set correctly in the admin console and the domain restriction matches exactly what your DNS zone is authoritative for. A mismatch (e.g., homelab.lan in Tailscale but your zones are local.domain.com) means queries go to the wrong resolver.

Routes approved but clients still can’t reach subnet

Verify --accept-routes is active on the client:

tailscale status --peers=false

Look for acceptRoutes: true in the output.

Subnet routing is one of the features that makes Tailscale the right choice for homelab remote access over traditional VPN setups. No VPN server to maintain, no certificates to manage, and the routing just works after a one-time setup. Combined with split DNS, the experience from a remote device is essentially identical to being at home.

For the full picture of how this fits into the homelab network stack, see /stack/.