Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save ironicbadger/798065be71f28f10ab2eadad70ee4a8e to your computer and use it in GitHub Desktop.
Save ironicbadger/798065be71f28f10ab2eadad70ee4a8e to your computer and use it in GitHub Desktop.
# Multiple Subnet Routers in the Same LAN with `--accept-routes`: Potential Issues and Solutions
When setting up multiple subnet routers in the same LAN environment with Tailscale, using the `--accept-routes` flag can cause significant connectivity issues. This document explains the problem, why it happens, and offers practical solutions.
## The Problem
Having two subnet routers in the same LAN with the `--accept-routes` flag enabled causes several networking issues:
1. **Local connectivity disruptions**: Nodes with `--accept-routes` enabled may lose the ability to communicate with other devices on the same LAN using their local IP addresses.
2. **Asymmetric routing**: Reply packets are often routed through another subnet router, causing the source address to change and breaking the connection.
3. **Persistent issues**: The problem affects accessibility even when Tailscale is disabled on a client, as long as subnet routes remain approved on a router in the LAN.
## Why This Happens
The root cause of these issues is the routing priority conflict:
- When a Linux device uses `--accept-routes`, it accepts all advertised subnet routes without considering whether some of those routes match its local network.
- If a subnet router on the same LAN advertises routes for that LAN's subnet (e.g., 192.168.1.0/24), other devices on the LAN that accept these routes will try to reach local devices through Tailscale instead of directly.
- This creates a routing loop or asymmetric routing situation where:
- The incoming packet arrives directly via the local interface
- The outgoing reply is sent through Tailscale (changing the source address)
- The connection fails because the reply packet doesn't match the expected source
As noted in issue #13958, "the subnet router is still interfering with [connectivity], even though Tailscale is no longer active on the client. If I disable the subnet routes on [the subnet router] again, it works."
## Current Workarounds
While Tailscale does not yet have an official solution, you can use these workarounds:
### 1. Selective Route Acceptance (Manual)
For Linux clients that need to access other subnets but maintain local connectivity:
```bash
# First, disable automatic route acceptance
sudo tailscale up
# Then manually add only the routes you need to specific non-local subnets
# Example: only accept routes to a remote 10.0.0.0/24 network
sudo ip route add 10.0.0.0/24 dev tailscale0
```
### 2. Use Tailscale IP Addresses
If both devices run Tailscale:
- Use Tailscale IP addresses (100.x.y.z) instead of LAN IP addresses
- This works even when subnet routes are enabled
### 3. Custom Routing Rules (Advanced)
For experienced administrators who can manage routing tables:
```bash
# Create a routing table with lower priority for Tailscale routes
sudo ip rule add from all lookup main pref 30000
sudo ip rule add from all lookup 200 pref 40000
# Add accepted routes to table 200 instead of main
# (Implementation details will vary)
```
This approach is similar to the feature requested in issue #7947, which proposes a `--accept-routes=lowpriority` option.
## Long-term Solutions
The Tailscale team is working on solutions that may include:
1. A new flag to accept routes at lower priority (proposed in issue #7947)
2. The ability to filter which routes to accept (proposed in issues #587 and #3607)
3. Automatic detection of LAN segment overlap with advertised routes
## Conclusion
Until an official solution is implemented, it's best to:
1. Avoid using `--accept-routes` on Linux clients in the same LAN as subnet routers advertising that LAN's subnet
2. If you need redundant subnet routers, use the manual workarounds described above
3. Use Tailscale IP addresses when possible for communication between Tailscale-enabled devices
Remember that routing conflicts are most likely to occur when subnet routers advertise routes that overlap with the local network subnet.
---
**References:**
- [Tailscale Subnet Routers Documentation](https://tailscale.com/kb/1019/subnets/)
- [Issue #13958: Subnet router affects access to nodes on the LAN](https://github.com/tailscale/tailscale/issues/13958)
- [Issue #7947: FR: new option to accept routes at lower priority on Linux](https://github.com/tailscale/tailscale/issues/7947)
- [Issue #1164: --accept-routes disables local eth0](https://github.com/tailscale/tailscale/issues/1164)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment