Skip to content
Notifications
Clear all

Why is Cisco Umbrella so slow on VPN connect for remote users?

4 Posts
4 Users
0 Reactions
2 Views
(@crm_hopper)
Estimable Member
Joined: 4 months ago
Posts: 142
Topic starter   [#19353]

Just switched a client to Umbrella. Their remote team is crawling whenever the VPN kicks in.

We've tried the usual suspects: split tunneling, different DNS configs, policy tweaks. Still feels like routing everything through a straw. Is this just the price of "security" or is there a known config fix everyone misses?


CRM is a necessary evil


   
Quote
(@integrations_ivan)
Estimable Member
Joined: 4 months ago
Posts: 125
 

Your "routing everything through a straw" analogy is precisely correct, and it's usually a core architectural mismatch, not a config tweak. The typical culprit is forcing all VPN tunnel traffic through Umbrella's explicit proxy, which adds a full TLS decryption/re-encryption cycle for every single request.

You've tried split tunneling, but the critical detail is what's split. If your VPN is configured to only tunnel corporate subnets while sending everything else direct, but your DNS is still pointed to Umbrella, you're forcing remote users' personal traffic (streaming, social media) on a pointless round-trip to your data center proxy. Check the actual traffic logs in the Umbrella dashboard for a sample user; you'll likely see massive amounts of non-corporate domain requests consuming proxy sessions.

The known fix is to implement a local agent, like the Umbrella Roaming Client, for your remote users. It handles DNS and security policies directly on the endpoint, bypassing the VPN for enforcement. This decouples security from the network path. If you're tied to the VPN-integrated method, you must aggressively refine your proxy bypass lists for high-volume, low-risk SaaS platforms.


Single source of truth is a myth.


   
ReplyQuote
(@backend_latency_queen)
Reputable Member
Joined: 2 months ago
Posts: 159
 

The straw analogy is apt, but the bottleneck often sits between the VPN concentrator and Umbrella's proxy cluster. Even with proper split tunneling, you're likely hitting TCP meltdown due to latency and packet loss on that hop.

Check your VPN appliance's logs for retransmits and duplicate ACKs on the traffic destined for Umbrella's proxy IPs. I've seen cases where an MTU mismatch between the VPN tunnel and the proxy path causes persistent fragmentation, crushing throughput. Try forcing a lower MTU on the VPN client or adding the Umbrella proxy subnet to a path MTU discovery blackhole list.

It's not just the TLS overhead - it's the transport layer crumbling under suboptimal routing.


sub-100ms or bust


   
ReplyQuote
(@danielr)
Estimable Member
Joined: 7 days ago
Posts: 62
 

The real question is why you're using a VPN with Umbrella at all. Their entire security model is built on DNS-layer enforcement that doesn't require a tunnel. You're layering a legacy network design on top of a cloud service.

If you "need" the VPN for specific internal apps, then only tunnel those. But your description of trying split tunneling and DNS configs suggests you're still forcing all web traffic through your own infrastructure first, which defeats the main point of adopting a cloud proxy. You're paying for two things and getting the worst performance of both.

This isn't the price of security, it's the price of not picking an architecture.


Trust but verify.


   
ReplyQuote