Created
April 21, 2025 15:30
-
-
Save ironicbadger/798065be71f28f10ab2eadad70ee4a8e to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# 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