Tailscale Subnet Router for Home Lab Remote Access: Windows and Android Setup Without Port Forwarding

What a subnet router does​

Abidi's home lab has a Home Assistant VM, 3D printers with their own web interfaces, and ESP32 boards. None of these can run a Tailscale client. Installing Tailscale on the server would only give him that one machine.

Tailscale's docs describe subnet routers as gateways that extend a tailnet to devices that can't run the client. One tailnet machine advertises a private network range. Authorized tailnet devices can then reach everything in that range.

This is not an exit node. Tailscale says an exit node routes a device's internet traffic through another machine. A subnet router only gives access to specific private subnets and, per the docs, doesn't affect internet routing. Abidi wanted only home-bound traffic to go home, and ordinary browsing stays on the remote device's own connection.

Why no port forwarding is needed​

Tailscale uses WireGuard for device-to-device encryption and NAT traversal to set up connections. According to Tailscale's DERP documentation, most traffic uses relay servers only to establish a direct connection. When hard NAT or firewalls rule that out, devices can fall back to a DERP relay. Tailscale says the relay forwards already-encrypted traffic and can't decrypt it.

So "no port forwarding" is accurate. "No dependency on anything" is not. Tailscale's coordination and relay infrastructure is still involved. Performance over a relay can differ from a direct path, and Tailscale suggests peer relays if relayed connections are frequent and slow.

The setup, step by step​

The sequence below follows Abidi's account and Tailscale's guide.

1. Install Tailscale on the always-on machine and sign in. Abidi used the distribution-aware install script (curl -fsSL [!/bin/sh](https://tailscale.com/install.sh) | sh, then sudo tailscale up). He notes that manual package instructions exist if you don't want to pipe a script into a shell.
2. Enable IP forwarding persistently. Abidi's commands set net.ipv4.ip_forward = 1 in /etc/sysctl.d/99-tailscale.conf and reload with sysctl -p. Tailscale's example also sets net.ipv6.conf.all.forwarding = 1. Abidi's setup only covers IPv4, which suits his IPv4 LAN. Add the IPv6 line if you advertise IPv6 ranges.
3. Advertise your real LAN range. His command is sudo tailscale set --advertise-routes=192.168.0.0/24. That is his subnet, not a universal default. Replace it with your own. One guide found in search suggests running ip route to see your local network.
4. Approve the route in the admin console. Advertising is only a request. In the admin console, open the Machines page, find the device with the Subnets badge, and approve the route. Tailscale says approval isn't needed if an autoApprovers policy covers the device.
5. Check access rules. Tailscale separates route approval from access control. Approval decides whether the route reaches client routing tables. Grants or ACLs decide whether packets are allowed through. Tailscale's route-injection page says you can have a route that your policy then blocks. You can also have a grant with no route behind it. Both must be in place.
6. Connect from your devices. Tailscale says Windows, macOS, Android, iOS and tvOS accept subnet routes by default. Linux clients don't, and need sudo tailscale set --accept-routes. Its CLI reference confirms that the default depends on the host OS.

Once that's done, Abidi reached services at their normal LAN addresses over mobile data or public Wi-Fi. His examples were Home Assistant and an AFFiNE instance at 192.168.0.123:3010. Those addresses are specific to his network.

Troubleshooting​

Tailscale's route-injection page lists the common failure points.

• Routes missing on a client: Check that the router is advertising the route and that you approved it. On Linux, confirm route acceptance is enabled. Also look for a more specific local route taking precedence.
• Route present but traffic blocked: Check that a grant or ACL permits the traffic. Confirm the destination is reachable from the subnet router itself. Check firewalls on the router and the destination.
• Sanity check: Tailscale suggests pinging the router's Tailscale address (tailscale ip -4 shows it) from another tailnet device.
• Linux routers and firewalls: Tailscale advises making sure the firewall denies forwarding by default, as ufw and firewalld do. That keeps forwarding from opening unintended paths.

One more issue is key expiry. Tailscale's docs warn that if a subnet router's key expires, its routes stay in place on other devices but become unreachable. They recommend disabling key expiry on the router or setting up high availability. A guide found in search also suggests disabling key expiry on the router. For a machine you rely on remotely, that is easy to forget.

The security boundary​

Abidi flags the main caveat himself. The WireGuard tunnel ends at the subnet router. From there to the final device, traffic runs over the local network under whatever protection the service provides.

Tailscale's documentation says the same about subnet routers in general. It says installing the client on each device gives the best security and performance through end-to-end encryption, and that subnet routers are a practical compromise. On a trusted home LAN that's reasonable. Even so, you still want HTTPS where available, strong credentials, updates, and segmentation for anything sensitive.

By default the router also applies source NAT, so LAN devices see traffic as coming from the router, not the remote client. Tailscale documents a Linux-only option to turn this off, but then you must add return routes yourself. Leave the default unless you have a reason to change it.

Availability and redundancy​

The router is now a single point of failure. If it sleeps, loses power or drops off the network, the path home disappears. Abidi disabled automatic sleep while plugged in and set a DHCP reservation for a stable LAN address. These are sensible choices of his own, not Tailscale requirements. A reservation keeps the address predictable but doesn't keep the machine online.

He also plans a second router advertising the same prefix. Tailscale's high-availability guide says to advertise the exact same route prefixes on each router and approve them. It also warns against --accept-routes on HA routers. A standby router could accept the primary's route to a network it is already directly attached to, which creates an inefficient path.

Cost​

Abidi says the Personal plan is free for non-commercial use, with up to six users and unlimited user devices. Tailscale's pricing FAQ says the Personal plan is free forever and meant for non-commercial use such as homelabs and home VPNs. It also says user devices are unlimited on every plan. The subnet-router docs say devices behind a subnet router don't count toward a plan's device limit. Pricing and limits can change, so check the current plans page before relying on this.

Verdict​

This is a well-matched fix for a common problem. It is a small, understandable design that keeps services off the public internet and works from Windows and Android without touching router port settings. It isn't magic. The router must stay up, access policy still needs thought, and the last hop on your LAN isn't covered by the tunnel. It's also one writer's setup, not independent testing of Tailscale's security or performance. Used with those limits in mind, it beats a pile of forwarded ports.