I’m running multiple instances of infra across multiple cloud accounts: (Dev, qa, prod, etc.) I was previously using wireguard as a VPN entrypoint to my private network. This was nice as the wireguard client allows the selective enabling/disabling of various tunnels.
The key thing to know here is that all my subnets are the same across accounts. This is fine if only one relay is enabled per client. Traffic flows to the private network through the single active relay and my users can easily access their machines with private IP’s.
With Tailscale, if I create multiple relay nodes, one for each environment, and then try to access them, I’m running into a problem where my subnet CIDR ranges are competing for the same address space. Essentially colliding and preventing reliable access to a specific environment.
Looks like selecting relays in the client is not an option. So I tried to limit things using ACL lists. This seems like it should work but does not do what I want.
I’m using groups and host rules to attempt to prevent some users from accessing some relay nodes. It appears that the subnet rules override the group rules and if I allow a group to have access to a specific subnet CIDR range, this will allow them to see all the relays supporting this range. (leading to the collision issue)
Has anyone else run into this specific issue? I’m starting to think that Tailscale may not have the features I need here. Namely, the ability for a client to manually select and enable / disable relay nodes without interacting with the ACL list. I can’t change my subnet CIDR ranges to avoid this as they’re all tied into my existing infra.
Any ideas on how to resolve this while still using Tailscale?
Right, tailscale currently assumes that if there are multiple relays offering up the same subnets, that they are for load balancing and failover, not that they are conflicting subnets. The only exception is with exit nodes and the magic 0.0.0.0/0 subnet, where you can explicitly choose which exit node you want.
It would be possible to allow a client to select which subnet relay to connect through, but so far the demand for that is low, and it would significantly complicate the UI.
Can you renumber your various subnets so that you don’t have a conflict? That’s by far the option that will cause the least overhead.
ᐧ
I can re-number them because my infra isn’t yet in production, otherwise this would be a major pain, almost a deal breaker.
I can certainly understand a desire to avoid making the UI more complicated, low priority request etc, but the ability to switch on / off relay nodes would make Tailscale a feature complete migration from Wireguard. Without this feature, it’s a lot more difficult (especially assuming multiple environments with matching subnets, a common pattern I’m sure)
If I had audited Tailscale harder before implementing it, I may have decided against using it for this reason. 
Regarding UI, the devices menu (on mac) shows a little black circle next to the relay you’re currently using. This looks deceptively like Wireguard’s checkmark tunnel enable feature. So much that I assumed this was the intended functionality. (For other readers: It appears to be a marker to show which tunnel is handling traffic, but is not a manual selection indicator)
Only after booting a second instance in QA (with matching subnets) did I break the integration and realize what was going on.
Anyways, just a little bit of dev feedback. Otherwise loving the product!