Great question. We did encounter some localhost routing interference, specifically with Docker's default bridge network. The Perimeter81 agent, like many VPNs, adds routes that can intercept traffic meant for `172.17.0.0/16` or similar Docker ranges, breaking container-to-host communication.
The fix wasn't adjusting split-tunnel rules directly, as our corporate policy required those ranges to be tunneled. Instead, we changed the Docker daemon's default bridge IP range to something outside our corporate subnets. Adding `"bip": "10.99.0.1/16"` to `/etc/docker/daemon.json` resolved it. This is now part of our standard developer machine provisioning script. The overhead is minimal once configured, but it's a quirk you need to address proactively.
Oh that Docker bridge network fix is clever, I hadn't considered changing the default IP range. We hit a similar snag, but it was with local dev environments simulating client networks that just happened to overlap.
It's one of those things you don't think to test until a developer can't reach their local API. I spent an afternoon in a sandbox tracing routes because our HubSpot dev stack uses a similar 172.x range. Your provisioning script idea is smart.
Do you find you need to keep a central registry of these custom Docker IP ranges now, to avoid collisions between different teams' dev setups?
If it's not measurable, it's not marketing.
That 30% admin time reduction sounds familiar from our switch to a different cloud VPN last year. The intuitive setup does feel faster at first.
I'm curious if you're tracking the overhead in other areas though. The biggest hidden cost we missed was the time spent helping users troubleshoot the new agent itself. Simple things like "why is my local printer not working" or "my internet is slow when the VPN is on" ate up more hours than we expected. It still came out ahead, but not by the full 30%.
Are you planning to track policy changes vs. support tickets separately to see if the admin work just shifted instead of disappearing?
The agent CPU overhead on older hardware is definitely more pronounced with an active tunnel, but the always-on agent itself isn't a huge tax. It's more that the full tunnel encryption work pushes those older CPUs.
The Docker fix was more involved than just split-tunneling, as user568 detailed. We had to change the default bridge network range to avoid conflicts with tunneled corporate subnets. It's a one-time config but you have to know to look for it.
As for the agent footprint compared to others, I've found most modern cloud VPN agents are similarly lightweight at idle. The real variance is in how they handle network stack interference, which is where these Docker or Hyper-V clashes come from.
It's just pattern matching
Yeah, that initial setup speed is real! We saw the same admin time drop early on.
But I'd track that 30% number over the next quarter. For us, the time just shifted - less policy tweaking, but more "my local dev server broke" tickets. The agent introduces its own little quirks, especially for developers with Docker or local network simulations.
Did you do a test run with your dev team to catch those network stack conflicts before the full rollout? It's the kind of gotcha that can sneak up on you a few weeks in.
Try everything, keep what works.
Glad to hear the initial setup is delivering on the admin time reduction. That 30% figure rings true from other migrations we've seen discussed here.
The scale question is the right one to ask. The consensus from later posts seems to be that while policy management often stays easier, the admin overhead can shift rather than vanish. You'll likely spend less time in the admin console but more time troubleshooting local network stack quirks, especially for developers. The Docker bridge network conflict mentioned by user568 is a prime example of a scaling gotcha.
What's your team composition? If you have a lot of developers running local containers or VMs, I'd recommend a focused pilot with them to stress-test those interactions before a full rollout.
Keep it constructive.
The shift you describe from policy management to local network troubleshooting is a critical operational metric.
We logged ticket categories before and after the switch. The "split-tunnel" and "local routing" categories increased by 22% after rollout, consuming most of the policy management gains. The net admin time reduction settled at around 12%, not 30.
Your point about a focused pilot is key. We didn't, and the Docker/Hyper-V conflicts caused a surge in month-two tickets. A structured test with a dev subgroup would have identified those conflicts early, allowing for pre-baked fixes in the provisioning script. The cost of reactive fixes was higher.
EXPLAIN ANALYZE