I have been using Zscaler Internet Access (ZIA) for nearly two years and the product still impresses me with its simplicity yet feature full platform. I am currently working on my third ZIA design and whilst a lot can be replicated each customer environment makes the design different. One of the main decisions is how you forward the user traffic to the Zscaler cloud.
Zscaler has a range of forwarding options but the decision really depends on your customer’s requirements, current environment, end user devices and user behaviour. Fortunately you can use combinations of options to try and suit the customer’s needs. Now I always opt for simplicity in my designs as while complex is cool to design its not cool to support.
Zscaler App (Zapp)
My preferred method of forwarding is the Zscaler App (Zapp). Whilst I am a big fan of clientless methods of forwarding like PAC files, the Zapp is really good. Its a lightweight app that is supported on Windows, Mac, Android and Apple which if your customer has a big mobile device presence makes this a no brainer. The Zapp is managed via the admin portal so you can push policy updates and software updates centrally. The zap client checks in every 20 seconds so updates are quick. The software update process is particularly slick and you get a report of what devices are running which version so you can gauge the process over time with no additional management tooling like Microsoft SCCM. The Zapp handles the authentication which I have used both Microsoft ADFS and Azure AD successfully. The app installs a virtual adapter which forwards all (unless specified not to) web traffic to the Zscaler cloud. This means that all user and system traffic is captured and forwarded which is a lot better than a pure PAC file solution.
The simplest way of forwarding is using a PAC file which is pushed out via group policy. If you have a large static device estate or want an easy migration then this maybe the easiest option and also there is no real minimum operating system spec, so again it depends on the customer. I deploy a PAC file forwarding method to a Citrix environment because it is session based computing the Zapp wouldn’t work correctly with authenticating the correct user so PAC had to be used. Whilst this works fine and integrates easily with Microsoft ADFS for authentication there are limitations. Often the user credentials get stripped because they are carried in a cookie e.g. a CONNECT strips this out so we get logs showing unauthenticated user which is not ideal. Zscaler recommend using PAC in combination with GRE and IPSec tunnels to capture all the traffic. Again you don’t have to and in some environments I haven’t, for example Zscaler doesn’t play well with Checkpoint firewalls which meant an IPSec tunnel couldn’t be used. Also using a tunnel means implementing policy based routing or having a default route to the Zscaler cloud, two options not to be taken lightly, this is major change territory so think carefully considering this in complex customer networks.
GRE / IPSec Tunnelling
If you need to tunnel all your traffic, perhaps a Guest WIFI environment then GRE or IPSec tunnelling is a good option when you can’t control your clients. However Zscaler isn’t cheap so I wouldn’t imagine you would buy it just for Guest Wifi so it is likely you would use a combination of forwarding methods.
At the time of writing I am currently working on a VeloCloud SD-WAN design. The customer already uses Zscaler and VeloCloud is a Zscaler partner so integrates nicely. I am deploying the Zapp to all client devices but also having IPSec tunnels to the nearest Zscaler cloud to ensure all branch web traffic is captured e.g. client and non client devices, printers, Guest WiFi etc. SD-WAN and Security as a Service providers like Zscaler compliment each other nicely and I can see more customers going down this route as more services shift to the cloud and they want to manage less data centre infrastructure.