Subnet routing on-site often fails due to misconfigured ACLs, disabled IP forwarding, or local firewall rules blocking traffic. Verify your tailnet ACL permits the subnet, ensure the node has ip_forwarding enabled, and check that no local iptables or ufw rules drop forwarded packets. This guide walks through diagnosing these common issues step by step.
Understanding Subnet Routing vs Exit Nodes
It is crucial to distinguish between subnet routes and exit nodes before troubleshooting. A subnet route allows other devices in your tailnet to reach a specific local network range (e.g., 192.168.1.0/24) via this machine. An exit node routes all internet-bound traffic from your tailnet out through this machine’s public interface. Confusing these two concepts leads to incorrect configuration attempts. If you are trying to access internal resources like printers or servers, you need subnet routing, not an exit node. Exit nodes are generally used for privacy or bypassing geo-restrictions when accessing external services. Misidentifying the goal can cause you to configure the wrong flags or ACL rules.Verifying Access Control List (ACL) Permissions
The most common reason subnet routes do not work is that the tailnet ACL does not permit the target subnets. Tailscale requires explicit permission for each node to advertise and serve subnets. You must edit your ACL JSON file to include thesubnets field under the appropriate user or group. For example, if user "alice" should access the 192.168.1.0/24 subnet served by "server-node", the ACL must explicitly allow this. Without this entry, even if the node advertises the route, other users will receive "no route" errors. Check the ACL editor in the Tailscale admin console to ensure the syntax is correct. Remember that changes to ACLs require a reconnection of the affected nodes to take effect.
Enabling IP Forwarding on the Host
For a Linux machine to act as a subnet router, the kernel must be configured to forward packets between interfaces. By default, many distributions disable IP forwarding for security reasons. You can check the current status by runningsysctl net.ipv4.ip_forward. If the output is 0, forwarding is disabled. To enable it temporarily, run sudo sysctl net.ipv4.ip_forward=1. For persistence across reboots, add net.ipv4.ip_forward=1 to /etc/sysctl.conf or a file in /etc/sysctl.d/. On macOS and Windows, IP forwarding is typically handled automatically by the Tailscale service, but you must still ensure the subnet is advertised in the client settings. Failure to enable forwarding results in dropped packets at the OS level, making debugging difficult because the traffic never leaves the host.
Checking Local Firewall Rules
Even with forwarding enabled, local firewalls likeufw, iptables, or firewalld may block forwarded traffic. Tailscale uses a virtual interface (usually tailscale0) to handle tunnel traffic. Your firewall must allow traffic coming from this interface to be routed to the local LAN interface. For instance, if using ufw, ensure that forwarding is allowed. Some configurations might inadvertently drop all forwarded packets unless explicitly permitted. You can inspect active rules using sudo iptables -L -n -v to see if packets are being rejected. Look for chains handling FORWARD traffic. If you see drops or rejects, adjust the rules to accept traffic from tailscale0 destined for your local subnet. Always test connectivity after making firewall changes to isolate the issue.
Diagnosing Connectivity Issues
Once permissions and system settings are verified, use diagnostic tools to pinpoint where the connection breaks. Start by pinging the local gateway of the subnet from the subnet router itself. Then, ping the subnet router from another device in the tailnet. If the ping works locally but not over the tailnet, the issue is likely network-related or ACL-based. Usetailscale ping <machine-ip> to check reachability through the tailnet. This command provides detailed latency and packet loss information. If the ping fails, check the Tailscale dashboard for any reported errors or stale routes. Additionally, verify that the subnet router is online and connected. Sometimes, a simple restart of the Tailscale service on the router can clear stuck states. For more complex networking scenarios involving mixed physical and virtual environments, refer to our guide on [Networking Woes: Some Physical and Virtual Machines Are Reachable and Some Aren't](/news/1035065/networking-woes-reachability-issues-with-physical-and-virtual-machines).
IPv6 Considerations
Tailscale supports IPv6, but subnet routing for IPv6 requires additional configuration compared to IPv4. Ensure that your local network actually routes IPv6 traffic correctly. The subnet router must have an IPv6 address assigned and forwarding enabled for IPv6 (net.ipv6.conf.all.forwarding). In your ACL, specify the IPv6 subnet ranges explicitly. Many users overlook IPv6 support, assuming it works automatically. However, if your local ISP or router does not provide proper IPv6 routing, Tailscale cannot bridge it. Check your local router’s IPv6 settings to ensure it is not blocking necessary protocols. Also, verify that the Tailscale client version supports the required IPv6 features. Outdated clients may not advertise IPv6 subnets correctly.
Frequently Asked Questions
Why can I ping the subnet router but not devices behind it?
This usually indicates that IP forwarding is disabled on the router or a local firewall is blocking forwarded packets. Check sysctl net.ipv4.ip_forward and ensure it is set to 1. Also, verify that your local firewall allows traffic from the tailscale interface to be forwarded to the LAN interface.
Do I need to open ports on my home router for subnet routing?
No, subnet routing relies on the Tailscale overlay network, which runs over UDP. Your home router only needs to allow outbound connections for the Tailscale client. You do not need to port forward anything for other tailnet devices to access your local subnet via the router.
How do I verify if my subnet route is advertised correctly?
You can check the Tailscale admin console under the "Routes" tab to see if the subnet is listed as advertised. Additionally, running tailscale status on the router will show the advertised subnets. If the route is not visible, ensure the ACL permits it and the node is online.
Can I use subnet routing with IPv6 addresses?
Yes, Tailscale supports IPv6 subnet routing. You must enable IPv6 forwarding on the host and specify the IPv6 subnet ranges in your ACL. Ensure your local network infrastructure also supports IPv6 routing for this to function correctly.
What should I do if subnet routes appear in the admin console but don’t work?
If routes appear but connectivity fails, check for local firewall rules blocking forwarded traffic. Also, verify that the target devices on the local subnet have a valid route back to the Tailscale network, either via the subnet router or their own default gateway. Consult our article on [Troubleshooting Website Access Between Two Offices on Different Subnets](/news/1034042/troubleshooting-website-access-between-two-offices) for similar cross-subnet issues.