International company, most sites in Eastern North America, Germany, Austria and Finland. Thinking about getting away from our VPN and deploying ZPA. When we had Cisco ASA I could whittle everyone down to only see what I wanted them to see. We deployed Meraki firewalls and it’s basically a router/firewall on a stick with little ability to be granular. If you’re a vendor/employee you basically have access to my whole network.
We don’t currently use ZPA due to internal politics and $$$ - but we did do a POC for it and I was pretty impressed.
Stitching your locations together is as easy as deploying a new VM. It was incredibly easy and if you need to onboard new locations often, it’s great.
Since everything is NAT’d through the App Connector - you lose insight on the internal firewall level. This can be problematic depending on your company (this is why we’re currently doing a POC for Prisma Access instead - we have a separate firewall team, and they didn’t like having to jump to a different tool for this insight).
Their discovery segment makes whittling down traffic to only what people need absolutely amazing. Their API is robust, easy to work with, and allowed for deep integration with whatever tools you bring if you have the skillset. IE: In less than 6 months when we did the POC I had developed and integrated the ZPA Segments into our Service Now APM (new server gets onboarded into SNOW with our current standard process - the app segment gets created or updated for the application automatically).
Performance was roughly +60% over a traditional SSL VPN (we use Global Protect) for speed tests and general latency. Access policies based on device type, MFA status, etc. were also incredible and gave us a lot of flexiblity. IE: We created an access policy for most of our applications that needed Crowdstrike to be running, updated, and active - but created a lower tier for remediation so we’re not trapped in a chicken or egg situation like we currently have with GlobalProtect HIPS.
For us performance was much, much worse with ZPA than with Cisco VPN, probably because the nearest service edge was 500 km away from the head office.
Be prepared to deploy a private service edge if you have latency sensitive apps and dont have a public service edge nearby. My advise is to test it properly before rolling out and deploy PSEs if needed from the start, to avoid unhappy users.
We use ZPA but in a unique manner with SaaS apps and Okta especially.
The posture checks work great for compliance, which is probably our biggest win.
Zscaler outages of third party ISPs (Mexico most recently) is what’s painful. Needing to make a high priority ticket for them to change steering is a gap. Yes we can use PSEs but that’s another thing to manage.
Moved from Traditional VPN to always on ZPA. Works great with ZIA as well. One of the best decisions that our management made last year. If you are poor with your segmentation you really need ZPA.
I’m a potential customer looking at ZIA + ZPA, but have already deployed a competitor to ZPA–Twingate. Pricing and feature wise, the only reason i’m considering ZPA is for the unified endpoint client my ZIA users would already have; however, i’m still not sure if it’s worth the move off of our Twingate instance as the connectors are containers and can easily run on any container platform without requiring a full VM. We’re about to do a ZPA POC here shortly.
Zpa should work well if all your applications are web-based as in only client server… theres challenges with server to client traffic , as well as accessing local resources so you may need a private service edge. DR also gets interesting with DNS. You may also need to do SIPA if you need security inspection beyond the app protection
So three years ago switched from GlobalProtect to ZIA+ZPA. With anything there’s learning curves but so far been very good, much better than other solutions we’ve tried.
Performance is good, it’s better than IPSeC tunnels but not as good as no tunnel of course.
Server-to-Client doesn’t work for remote ZPA, but not difficult to get around and things like GPO are Client-to-Server so no issues there.
Using Machine Tunnels pre-login to allow for domain join if needed, password change, instant lockout of account, etc. Cached passwords aren’t used unless a network connection isn’t available, but Duo MFA closes that gap.
Overall, it’s worth the spend and time to implement because it just works, and the ZIA Sandbox alone has caught some nasty stuff that woulda gotten through.
Having the always on/always enforced firewall of ZIA is awesome and being cloud based it doesn’t matter where the machine is it works the same without requiring full backhaul.
While not part of your question, have you considered alternative solutions? For example, I work on for the company behind OpenZiti (https://openziti.io/), an open source zero trust networking solution (my company offer a commercial SaaS of it too) which is basically ZPA on steroids.
Happy to share some further details and comparisons if you are interested.
This is good info, thanks! I’m also researching ZPA. A good (but 3-year old) write-up I read said one of the downsides is that server-initiated connections are not supported, like a GP push or an application install push. Do you know if they’ve added that since then?
Server to Client isn’t supported but Client to Client is - so if your servers have the Zscaler Client Connector installed you could make it work.
Sometime in the near future they announced supporting IPSec Tunnels which should support Server to Client along with solving the lack of transparency caused by the NAT but other than the announcement, no other details have been released.
Something to bear in mind - it’s only the network level that’s problematic. I’m unaware of any actual “GP Push” - from my understanding, Group Policy is a pull only system. Same with SCCM for App Install pushes where the Client polls for updates and most systems work this way since poking a bunch of holes on the client Firewall isn’t great.
Thanks. I just did a quick demo with Axis. They seemed to solve the problem by the connector server being able to push an IP to the client from a pool temporarily to initiate a server>client connection and make it routable inside. Don’t know the technical details, but saw it in action.
We use PDQ, which is a server push, so it’s a big setback if zscaler has no workaround.