alexfray Zscaler

Zscaler – Forwarding Choices

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.

PAC File

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.

SD-WAN

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.

 

alexfray Checkpoint

Checkpoint R77.30 to R80.10 Upgrade in Azure

Ok, if you are reading this, you already know that it is not as simple as running CPUSE to upgrade from Checkpoint R77.30 to R80.10 in Microsoft Azure. In fact, its not even supported in Microsoft Azure (or any public cloud). Checkpoint’s preferred approach is an in-parallel upgrade and migration of services across. Wow, ok so while this reduces risk considerably it really depends how complex your Azure and Checkpoint deployment is. In the recent in-parallel upgrade we did for a client this change was almost a mini project.

Things to consider:

Azure complexities, the client had 10 VNETs with over 20 different routing tables. This meant ensuring that the Checkpoint cluster SPN had contributor rights to all resource groups containing routes to the Cluster. Checkpoint’s new test script is very useful to ensure you have all this covered

Checkpoint functionality used, in this instance, FW, VPN, URL and APP Control were used. You can clone policies, assuming your old and new cluster are managed by the same Security Manager which makes this process a lot simpler, however the VPN functionality needs to be carefully considered. When we cutover to the new firewall cluster in a change window, the VPN from On-Prem to the Azure hosted Checkpoint cluster had issues, ranging from SA’s timing out and the VPN being completely down to not all subnets being encrypted, the classic and unhelpful “no valid SA error”. Essentially after hours of troubleshooting this turned out to be issues with the interface and link selection causing IKE negotiation issues. Even though this was configured as per the Checkpoint reference architecture (i’m not mad, i’m just very disappointed). We reverted to using a link selection profile we had deployed on another R77.30 Azure deployment successfully, reset the IKE and IPSec SAs using vpn tu and hey presto a successful in-parallel upgrade.

What we took away from this experience was a very detailed runbook and test plan to ensure we captured all the VNETs and user defined routes that required changing and testing services hosted in different VNETs and subnets to ensure all subnets were routable across the VPN.

The only benefit of this saga was the ease to rollback to the original checkpoint cluster if necessary as very few changes had been performed on it during cutover.

alexfray ADFS, Authentication, AzureAD, Zscaler

Zscaler – Authentication Choices

Zscaler is the market leading cloud proxy service. I have implemented Zscaler for a number of customers in the Transport and Government sector over the last 3 years and its adoption is rapidly increasing as customers look to migrate services to the cloud, increased workforce mobility, a move to OPEX based services and away from traditional on-premise CAPEX heavy forward proxy solutions like Bluecoat. Note. Bluecoat do offer a cloud service but it is doesn’t have the maturity and cloud scale that Zscaler has built up as a pure cloud player over the last 10 years.

There are many ways to authenticate users of the Zscaler service, locally defined database, LDAP and SAML to name the main ones. However the problem comes in populating the user database. If you had a small organisation (sub 50 users) then a locally defined user database might work for you, however most organisation are way above this figure and want to leverage their existing Identity management system such as Active Directory or Azure AD. Now this is fine as we can integrate Zscaler into both of these IDPs using SAML. However populating the user database depends on your requirements. We can auto-populate (preferred) the Zscaler user database using the data from the SAML tokens, which is great as each time the user authenticates to Zscaler their information is updated! This works great when using Active Directory (ADFS) or Azure AD (see my other articles on how to integrate these). However when using AzureAD the user’s group membership cannot be added to the SAML token. You could define local groups in Zscaler if that meets your requirements however if like most organisations you are migrating from an on-premise forward proxy solution to Zscaler then chances are you will want to ease the pain by using the existing AD groups which are used to define your proxy policy. With ADFS we can insert the AD Groups that the user belongs to in the SAML token, it just puts a dependency on having an ADFS infrastructure in place or building one.

The other options are LDAP or Zscaler Authentication Bridge (ZAB). Where you could still carry out user authentication via SAML but populate the Zscaler user database using LDAP or the ZAB. I don’t like either of these solutions. Exposing your domain controllers to the Internet, albeit source IP restricted doesn’t feel right to me, it also puts a dependency on LDAPS being in place which a lot of organisations still don’t use. I guess you could use LDAP but i’m not even going to suggest exposing your IDP data unencrypted over the Internet. and the ZAB, what’s the point of a pure cloud proxy solution if you have to put a VM in your on-premise data centre to sync your user data. (Also Bluecoat’s and Cisco Umbrella’s solution) Also the ZAB is currently only supported on VMware so you couldn’t even host this is Azure or AWS!

I like the elegant solution of authentication and auto-populating the user database using SAML. I’ve spoken to Microsoft about being able to include Groups in the SAML token when using Azure AD as the IDP and it doesn’t seem to be supported for Zscaler. Note. You can modify app manifest files to populate User Groups in the SAML token for other apps so you maybe able to do this for Zscaler. Off topic, I don’t understand why Azure has App registrations and Enterprise Apps, this should be merged! Zscaler is deployed as an Enterprise App as such there is no Manifest file to modify, So you would have to manually register the app if this is even possible. I would hope, as this is not the only use case, that Groups will be possible using Azure AD at some point, Microsoft have got pretty good at listening to the community now that they have other options.

Links

https://support.zscaler.com/hc/en-us/articles/204455339-Choosing-Provisioning-and-Authentication-Methods