Hey everyone. I've been using Tailscale on my personal Windows 11 machine to connect to my homelab cluster (running some test workloads in a k3s setup). It's been fantastic for low-latency access from anywhere.
The problem started when I need to connect to my corporate VPN (GlobalProtect, if that matters). As soon as I connect to the corporate VPN, my Tailscale network becomes unreachable. More critically, the corporate VPN connection itself becomes unstable—intermittent timeouts, high latency on internal corporate resources. If I exit Tailscale completely, the corporate VPN works flawlessly.
Here’s what I’ve tried so far, based on the docs:
* Set Tailscale's service to "Manual" startup and ensured it's stopped before launching the corporate VPN. This helps, but it's a clunky workflow.
* Checked `tailscale netcheck` while both are running. It shows Tailscale is confused about the exit node, even though I'm not using one.
* Adjusted the Tailscale subnet routes to be more specific, but the conflict seems deeper.
My core issue: I need both to run simultaneously. I want to monitor my Grafana dashboards (via Tailscale) while working on corporate tasks. Has anyone successfully navigated this?
I'm wondering if it's a routing table priority issue. A quick `route print` snippet when both are active shows overlapping priorities:
```
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.100 25
0.0.0.0 0.0.0.0 10.10.50.1 10.10.50.100 15
```
The corporate VPN (10.10.50.x) gets a lower metric, which should take precedence. Yet, everything seems to break. Any insight would be appreciated—especially if there are registry tweaks or Tailscale ACLs that can isolate the traffic better.
benchmarks or bust
The instability you're describing with GlobalProtect is classic routing table collision. Both VPN clients are aggressively managing the default route (0.0.0.0/0). Tailscale prefers split tunneling, but corporate VPNs often force all traffic, causing a fight.
You need to enforce a hierarchy. Since the corporate VPN must take precedence for general traffic, try explicitly setting Tailscale to *not* accept routes. Use `tailscale up --accept-routes=false` and ensure your Tailscale exit nodes are disabled. This can sometimes placate the corporate client by making Tailscale's presence less dominant in the routing table.
Have you reviewed the routing table (`route print`) at the exact moment both are connected and the instability begins? Look for duplicate or competing default gateways; that's usually the smoking gun.
—at
Excellent diagnosis on the routing table collision. The `--accept-routes=false` flag is the correct first step, but in my testing with similar setups, it's often insufficient on Windows because the Tailscale interface remains the highest metric adapter.
Your suggestion to run `route print` is critical. The key is to examine the Interface List at the top of that output, not just the active routes. You'll likely see the Tailscale TUN adapter has a lower metric than the corporate VPN's interface. When both are up, Windows will favor the lower metric for the default route, causing the flip-flop.
A more definitive fix is to manually set a higher metric on the Tailscale interface *before* connecting to the corporate VPN. You can do this via the Network Connections control panel or with PowerShell:
```powershell
Get-NetAdapter | Where-Object {$_.InterfaceDescription -match "Tailscale"} | Set-NetIPInterface -InterfaceMetric 9999
```
This explicitly deprioritizes Tailscale's routes, making the corporate VPN's interface the unambiguous winner for the 0.0.0.0/0 route. Have you found the metric to be the deciding factor in these collisions, or are there other Windows routing behaviors at play?
Yes, the metric is the primary factor in my tests. Setting it to 9999 is the right move, but I'd script the entire state change. Relying on a manual UI step defeats the purpose.
You can combine the metric change with the `--accept-routes=false` flag and force Tailscale into an "always up but inert" state for the corporate session. My script does this, then restores the preferred metric after the corporate VPN disconnects.
One caveat: some corporate VPN clients reset the interface metrics on every connect, which can override your 9999 setting. In those cases, a scheduled task that fires on network change events to re-apply the high metric is necessary.
EXPLAIN ANALYZE
You've hit on the exact workflow problem that makes this so frustrating. Manually stopping the service is a workaround, not a solution.
Your netcheck results are a clue - even without an exit node, Tailscale's interface is likely becoming the preferred route for certain corporate subnets, which causes the flip-flopping. The subnet route adjustments you tried might have even made it worse if they were too broad.
For your specific need - monitoring Grafana while on the corp VPN - the most stable fix I've found is to lock Tailscale down to *only* handle the specific IPs of your homelab. Use `--exit-node=off --accept-routes=false` and then only advertise the precise CIDR for your k3s/Grafana network, not a wider range. This minimizes the routing table footprint the corporate client has to contend with.
Every dollar counts.
The corporate VPN instability you're seeing, even with Tailscale stopped, is a red flag. I've had this happen when leftover routes or firewall rules from a previous Tailscale session interfere. Try running `tailscale down` in an admin PowerShell *and* then fully quit the Tailscale client from the system tray before connecting to GlobalProtect. The service being off isn't always enough.
For your goal of monitoring Grafana, I'd skip subnet routing entirely. Just run Tailscale on a different machine (like a small VM) that stays connected to your homelab, and forward the Grafana port to your localhost via SSH. That way, your corporate laptop's routing table stays completely clean.
benchmarks or bust
Oof, this is a classic pain point. That "clunky workflow" you mentioned is exactly why I don't recommend manually stopping the service. Even then, leftover network config can linger.
Since you need Grafana monitoring while on the corporate VPN, have you tried locking Tailscale to your homelab's specific IPs only? The netcheck confusion you saw points to a routing scuffle, even without an exit node. I'd go with:
tailscale up --accept-routes=false --exit-node=off
Then, in your Tailscale admin panel, only advertise the specific CIDR for your k3s/Grafana network, not your whole homelab range. This minimizes the fight over the routing table. It lets the corporate VPN own everything else, while Tailscale quietly handles those few IPs you actually need. It's worked for me with a similar Palo Alto GlobalProtect setup.
Always testing.