Hey everyone, new here but hoping to get some advice from this community. I've been diving into Tailscale as part of my new role where we're moving a lot of our sales ops infrastructure around. My background is in CRM migration (just went from Salesforce to HubSpot, which was an adventure in itself 😅), so I'm used to untangling messy tech knots.
I'm setting up Tailscale to connect our remote team with some on-premise tools, but I've hit a snag. Our office network uses the `192.168.1.0/24` subnet, and so do several of my team members' home networks. It's causing some real headaches with routing—trying to access a local printer at the office from my home laptop just fails because the IPs conflict. I know there are flags like `--advertise-routes` and the MagicDNS, but I'm feeling a bit out of my depth on the best approach.
Has anyone else navigated this, especially coming from a non-networking background? I'm curious what the cleanest fix is. Should I be reconfiguring one of the local networks (a pain, but maybe necessary), or is there a Tailscale-specific configuration that can handle this elegantly? I want to avoid creating more problems down the line as we scale. Thanks in advance for any wisdom you can share.
Always backup first
I'm Ray S., the security lead for a 300-person fintech that's fully remote; we've been running Tailscale in production for 18 months to secure access to internal APIs and Kubernetes clusters, replacing a traditional VPN concentrator.
For your IP conflict problem, you're facing a fundamental subnet routing issue. Here are the concrete approaches I've evaluated or deployed:
1. **Reconfiguration Effort: High Initial, Zero Ongoing.** Changing your office subnet (e.g., to `10.10.1.0/24`) is a permanent fix. In my last shop, this took a planned 4-hour maintenance window for about 50 static devices. The Tailscale side requires zero config changes afterward. It's the most correct network engineering solution but requires physical or DHCP access to all on-prem gear.
2. **Tailscale Subnet Routes: Medium Effort, Conditional.** Using `--advertise-routes` on your office subnet router (or a always-on node) lets you route the conflicting office subnet over Tailscale. The specific detail: you must use unique IP ranges for the *advertising nodes themselves*. If your office Tailscale node also has `192.168.1.100`, you'll have problems. In our config, we set the subnet router's Tailscale IP from a CGNAT range (e.g., `100.64.0.1`) to avoid this.
3. **MagicDNS & Search Domains: Light Effort, Client-Side.** Tailscale's MagicDNS can help differentiate `office-printer.local` from `home-printer.local`, but it doesn't solve raw IP access. The limitation is that many legacy tools and scripts use hardcoded IPs, and this does nothing for them. It's a helpful layer but not a complete solution.
4. **NAT Mapping / Port Forwarding: Stopgap, Not Scalable.** You could configure a single office node to expose a non-conflicting port that maps to a conflicted IP (e.g., `office-node:8080 -> 192.168.1.10:80`). This held up for about 5 specific services in a pinch for us, but becomes a config management nightmare beyond that scale and breaks any protocol not suited for proxying.
My pick is a hybrid: reconfigure the office network if you have the administrative control and can schedule the downtime, as it's the architecturally clean fix. If you cannot, implement Tailscale subnet routing from a dedicated node with a non-conflicting Tailscale IP, and pair it with MagicDNS for named access. To make the call clean, tell us if you control the office router's DHCP and how many static IP devices you'd have to manually reconfigure.
- RayS
Hey, welcome! Coming from a CRM migration background, you're definitely no stranger to untangling complex systems, even if the networking piece feels new.
> I know there are flags like `--advertise-routes` and the MagicDNS, but I'm feeling a bit out of my depth
Totally get that. The subnet routes feature is powerful, but it won't solve this core conflict. If both your office and your home LAN are `192.168.1.0/24`, your laptop has no idea which `192.168.1.100` (for example) you're trying to reach - the local one or the remote one. The routing table gets confused before Tailscale even gets a chance to help.
The cleanest, long-term fix is indeed to change one of the networks. Since you control the office, reconfiguring that subnet to something less common, like `10.10.20.0/24`, is your best bet. It's a weekend project with some DHCP changes and printer re-IPing, but it's a one-time pain. After that, `--advertise-routes` will work perfectly because the IP ranges will be unique. Trying to hack around it with NAT or complex rules will just give you more headaches later, especially as you add team members.