Tailscale Subnet Routers vs Port Forwarding: The Failure Mode That Looks Like a Firewall

You advertise 192.168.1.0/24 from a Tailscale subnet router, accept the route on your laptop, and ping the NAS. Nothing. Traceroute dies somewhere that looks like a policy drop. You open the home firewall, add a temporary allow, disable Windows Firewall on the NAS, even poke a hole on the WAN “just to test.” The test works. You conclude Tailscale is fighting you and that port forwarding is simpler. Then a scanner finds that hole in three days and you get to learn what your camera vendor puts in a default password field.

Most of the time the mesh was fine. The failure was a local route, a missing forward sysctl, an ACL that allows tailnet IPs but not the advertised LAN, or a hotel that also uses 192.168.1.0/24. Those all present as “the firewall ate it.” They are not the same as a WAN port map, and treating them like one makes both designs worse.

What each tool is actually for

A port forward is a bargain with the public internet. You publish a destination on your WAN address, or you try to, and you hope your ISP still gives you an inbound path. CGNAT, a second router in the closet, and “security” firmware that resets UPnP overnight are why this bargain keeps failing in apartments. When it works, it works for anyone who can reach the port. That is the feature and the incident.

A Tailscale subnet router is a bargain with your tailnet. One machine on the LAN forwards packets for prefixes you advertise. Clients that accept the route send 192.168.1.50 through the mesh instead of through the coffee shop. The NAS does not need Tailscale installed. The camera does not need a cloud. You did not publish a WAN socket. You published a route to people who already have your tailnet keys.

Those are different products. Subnet routing is how you reach a printer that will never run a client. Port forwarding is how you run a game server for friends who will not install Tailscale, or a webhook that must be on the public internet. If you are still deciding whether Tailscale replaces a privacy VPN at all, that is a different comparison. Using either as a synonym for “remote access” is how the debugging goes in circles.

The failure that looks like a firewall

I keep a short list. Every item has wasted an evening that ended with iptables being innocent.

Overlapping RFC1918

Your house is 192.168.1.0/24. The hotel, the in-laws, the shop LTE router, and half the VPNs on earth are too. Your laptop already has a connected route to 192.168.1.0/24. Tailscale’s accepted subnet is less specific or loses the tie. Packets for the NAS go to the hotel TV. The hotel does not answer like a firewall. It answers like a black hole or the wrong host. You add WAN forwards to “make sure the NAS is reachable” and now you have two bugs.

The fix is not a hole. Renumber the house to something ugly: 10.42.0.0/24, 172.20.10.0/24, anything that hotels do not ship. Or do not use a subnet router for those prefixes; install Tailscale on the few hosts that matter and use 100.x addresses. If you refuse to renumber, at least stop debugging from networks that collide. Debug from a phone on LTE that is not 192.168.1.0/24. The number of “firewall” tickets that die on LTE is embarrassing.

Forwarding is off

The subnet router is a Linux box. net.ipv4.ip_forward is 0. Tailscale says the route is advertised. Clients send packets. The box receives them and drops them because it is not a router. Some distros also have firewalls that allow INPUT and forget FORWARD. From the laptop this is indistinguishable from a REJECT on the NAS. Counters on the FORWARD chain tell the truth. A WAN port forward “test” tells you nothing except that you can still open a socket on the internet.

Enable forwarding. Allow FORWARD for the tailscale0 interface to the LAN, and the return path. Do not disable the NAS firewall because you were impatient. You will forget to turn it back on.

The route was advertised, not accepted

Tailscale requires an admin to accept a subnet route, and some clients need it approved per device. You did it on your desktop. You did not do it on your phone. The phone fails. You blame the home firewall because the desktop works. Check the client route table. If 192.168.1.0/24 is not there, no amount of WAN policy will teach the phone to use the mesh for that prefix.

ACLs that only name tailnet IPs

You wrote a grant for 100.64.0.0/10 or for tags. The packet that arrives at the NAS after the subnet router NATs or forwards may still be sourced in a way your ACL did not imagine, or the reverse path may not match. More commonly, HA rules on the NAS allow the subnet router’s LAN IP and deny the original client. Depending on SNAT, the NAS sees either the laptop’s tailnet IP or the router’s LAN IP. One of those is in your allow list. The other looks like a scan. This is a firewall, just not the one on the WAN.

Decide whether the subnet router SNATs. Then write the NAS allow list for the source you actually chose. Document it. The next restore will reset the NAS firewall to default deny and this bug will return wearing the same costume.

The destination never heard of you

Windows host firewall, IoT devices that only accept the same /24, cameras that drop anything not in their “local” notion. The subnet router got the packet there. The endpoint spat it out. A port forward from WAN sometimes works here because the camera vendor expected NAT from the router and treats the router as local. That is a vendor bug you should not solve by publishing the camera.

Put the camera on a VLAN the subnet router can reach, or put a client on a jump host that is actually local. Do not celebrate a WAN 8080 that happens to make the vendor stack happy.

When port forwarding still wins

Friends who will not join a tailnet. A game server, a Minecraft weekend, a random webhook from a vendor that only stores one URL. Let’s Encrypt HTTP-01 if you have not moved to DNS-01. A device you are willing to treat as public and keep patched.

Even then, prefer a single published reverse proxy with a name and a certificate, not a scatter of high ports on the WAN. Prefer IPv6 if you have a real prefix and a firewall you understand. Prefer not publishing at all if the users can install Tailscale in four minutes.

CGNAT is the usual reason people say “I have to use Tailscale.” That is correct for inbound. It is not a reason to advertise the entire LAN if you only needed SSH to one box. Install the client on that box. Subnet routers are for the stubborn leftovers.

When a subnet router is the smaller hazard

IoT that cannot run a client. A printer. A handful of http-only admin pages you refuse to put on 443/WAN. A lab VLAN you want reachable from a travel laptop without giving the laptop a second VPN profile.

Keep the advertised prefixes tight. 192.168.1.0/24 is lazy. 10.42.10.0/28 for the NAS VLAN is adult. The blast radius of a stolen tailnet device is the prefixes you advertised, plus whatever those hosts trust. That is still better than a WAN camera, and it is not free.

Run the subnet router on a box that is not your daily desktop. Desktops sleep. Sleeping routers look like firewalls. A used mini PC or the router itself, if it can run Tailscale, is the right kind of boring. Monitor it. When it dies, the failure mode is “whole LAN vanished from the tailnet,” which at least is obvious. When a desktop subnet router dies, you get intermittent reaches that look like policy.

A debug order that avoids new holes

From a network that does not collide, check that the client has the accepted route. Ping the subnet router’s tailnet IP. Ping its LAN IP. Then ping the target. If the first works and the third does not, you are in forwarding, SNAT, or host firewall. Stay there. Do not open WAN 443 as a control experiment unless you like leftover rules.

On the subnet router, watch FORWARD counters and tcpdump on tailscale0 and the LAN NIC. If packets arrive and do not leave, it is this box. If they leave and the NAS does not answer, it is the NAS or L2. If they never arrive, it is ACL, route accept, or overlap.

Only after that, consider whether you wanted a subnet router at all. One Tailscale client on the NAS would have skipped this class of bugs. People advertise /24 because it feels complete. Complete is how you inherit every IoT firewall personality on the segment.

Site-to-site is a third design

Two houses, two subnet routers, both advertising their LANs, both accepting each other, is a site-to-site VPN with extra logos. It works until both sides use 192.168.1.0/24 or until a printer loop appears. Renumber one site. Do not “fix” it with port forwards between houses. I have seen that sentence in a ticket. The diagram is still in my head and I would like it to leave.

If you need two sites, write the prefixes down as if they were public ASNs you cannot overlap. Treat the tailnet as the transit. Keep WAN closed. The failure that looks like a firewall is usually a route you already had, closer than the mesh.

The close

Port forwarding publishes a socket. A subnet router publishes a prefix to people you already trust. When reachability dies, the costume is a firewall. The usual actor is overlap, forwarding, unaccepted routes, or a host that never wanted remote sources.

Renumber lazy 192.168.1.0/24 if you can. Advertise less than a /24 if you cannot. Debug from a non-colliding network. Leave the WAN closed while you watch FORWARD counters. Install Tailscale on the one box you actually needed before you make the whole LAN look like a remote network.

If you still need a published port after that, you needed a published port. Open that one, watch it, and do not pretend it is the same as a mesh route. The scanner can tell the difference even when your evening cannot.