We've been running Zscaler's ZIA (Internet Access) for about 18 months now, primarily to secure our remote and branch users across APAC. The sales deck and their public-facing map show fantastic coverage in Southeast Asia, with multiple nodes in Singapore, Thailand, Vietnam, etc.
Our real-world latency tells a different story. Users in Vietnam and the Philippines, even when manually connected to the suggested Singapore POP, often see 200ms+ added latency for simple web apps like Google Workspace or Salesforce. It's like their traffic is taking a detour before hitting the local node.
We dug into the packet captures and did some traceroutes. It looks like some of the "coverage" is actually a partnership or peered connection, not a true Zscaler-owned POP. The traffic gets routed to the partner's infrastructure, which sometimes adds hops and congestion.
Has anyone else in the community faced this? We're trying to decide if we need to:
* Push our account team for a clearer "actual architecture" map
* Implement a more aggressive PAC file to steer certain geo traffic differently
* Consider a complementary SD-WAN solution just for these regions to optimize the path
It's frustrating when the integration promise (seamless, fast security everywhere) bumps against the physical reality of cables and routers. Would love to hear your data points or how you've tuned around this.
That's a frustrating discovery, and I think a lot of us have been burned by the difference between a coverage map and actual routing performance. The partner vs. owned POP distinction is a real blind spot in vendor marketing. I've seen similar with other SSE providers where they claim a PoP in a city but it's really just a peered edge with a local ISP, which means the traffic still has to hairpin through a central hub before hitting the internet.
On the actionable side, I'd push back a little on the "aggressive PAC file" idea. That can work for specific destinations, but if your users in Vietnam are hitting a partner node that's causing the detour, a PAC file won't fix the underlying routing to that node. You'd be better off asking Zscaler for the actual BGP path data for those countries and comparing it to a direct internet break-out from a local ISP. The real question is: are they meeting the latency SLAs they promised in the contract? If not, that's a vendor management issue, not just a technical one.
Have you asked your account team for a formal architecture review with the network engineers, not the sales engineers? Sometimes that forces them to admit the difference between "coverage" and "presence."
Stay curious, stay critical.
Your packet captures are the only proof you need. I ran into this exact issue with a client in Jakarta. Zscaler's map showed a local POP, but the traffic was bouncing through Hong Kong before hitting the partner node in-country. Adding 180ms for internal apps.
Pushing for an "actual architecture" map is a waste of time. They'll just give you a prettier PDF. Demand the specific ASN and IP prefixes for the nodes in Vietnam and the Philippines, then validate the routes yourself. If it's a partner colo, their internal routing is often a black box and you'll never get the performance of an owned POP.
Forget the aggressive PAC file. That's a band-aid for a routing problem. Your third option, a complementary SD-WAN, is probably the only real fix if latency is critical. It adds cost and complexity, but it gives you control over the first hop.
-- bb