Throughout the event I will be speaking to employees and product managers from Zscaler to get information on the next big thing, hopefully some best practices and also push for some feature requests.
Keynote from Jay Chaudhry, CEO of Zscaler
Jay talked about the cloud journey that we are all on but also the move from network centric architectures to user centric and I think that is key for businesses and engineers to understand to succeed in cloud transformation.
Spoke to David Creedy, product manager for Zapp about current forwarding issues and roadmap for Zapp.
Roadmap – Zapp will be changing its tunnel mode from TCP to DTLS which will make it much more lightweight and improve user performance. No date on this yet.
Roadmap – Zapp user interface is being revamped and will provide the user more information. This looks more like a mobile app and shows ZIA and ZPA status in parallel which is really nice.
Roadmap – Currently if you are using Zapp on-premise with no GRE/IPSec tunnelling you are NATing all clients behind a single public IP address so all clients will hit the same ZEN node, no load balancing. Coming soon you will be able to modify the PAC file to distribute the load in this scenario to multiple ZENs.
Roadmap – Zapp will be able to forward all ports and protocols to the Zscaler cloud in Q1 2019 as opposed to currently where only HTTP and HTTPS traffic is forwarded. This is pretty cool for a split tunnel solution as we can now protect/restrict all ports from a device from any location. Would I want to retrospectively implement this? I’m not sure, it would take a lot of UAT to ensure we don’t break any existing connectivity. Think about it your localised SMB traffic gets thrown to the cloud, might cause some issues. Look forward to testing this though.
David talked about forwarding modes for Zapp. Zscaler seem to have changed their minds on best practice from ‘tunnel with local proxy mode’ to ‘tunnel using the packet based filter’ which is a new addition in version 1.3.1 of the Zapp. The key advantage is that all system context traffic is captured and only for HTTP and HTTPS so is more optimal. Where as ‘tunnel using routing mode’ captures all traffic and can cause issues, as I have experienced in the past. This best practice also depends on the customer’s environment and if they are using an existing VPN RAS solution like Cisco AnyConnect or PAN Global Protect when you would need to use Tunnel with Local Proxy mode for traffic when off-network or on VPN. Forwarding decision definitely take some testing.
Best practice tip – Forwarding PAC – By-pass URLs in the forwarding PAC as opposed to the App Profile PAC so the browser deals with the PAC and not the Zapp as browsers are better at handling this.
Best practice tip – Zscaler also saying you should disable Zapp on trusted network and let it route over your tunnel to the Zscaler cloud. This seems debatable as how would the authentication work without the Zapp? You would have to open a browser first before Outlook for example as Outlook is not cookie aware so would appear as unauthenticated traffic which in some environments may not be allowed. Can’t see users liking this experience. I’m still in favour of tunnelling within a tunnel, so Zapp on and via a tunnel, ok there is some additional overhead but the user experience is much better.
Feature Request – Zapp Pre-Login Gina. I asked David whether it was on the roadmap for Zapp to start pre-login. Zscaler are looking to develop this which is awesome as it makes ZPA a real contender against PAN Global Protect if users can reset password with AD, GPO updates etc via pre-login. They are looking to start development on this so don’t expect it anytime soon as they need to work on a machine context for Zapp as everything is currently in the user context.
Feature Request – Zapp for Citrix Session Based Compute. Currently I use PAC files on Citrix SBC which works ok but has limitations, such as websites using connect method strips the authentication cookie. Zscaler are also looking into Zapp for session based compute so multiple users on the same server have their own Zapp context/tunnel.
Zscaler Internet Access
I visited the ZIA user interface booth and gave a load of feedback for UI improvements such as referencing CVEs in their threat library, exclusion searches and more Office 365 statistics, hopefully some of these will make it into the next release. Some cool new reports and dashboards being rolled out across the Zscaler clouds, for example a quarterly business powerpoint which is cool for senior stakeholders and you can edit it so really nice feature.
Attended the keynote from Microsoft which was really interesting as most of my customers use Azure AD and Office 365. Microsoft demo’d the CASB integration with Zscaler which is a really nice feature whereby using the Microsoft App Security portal you can effectively block access to cloud apps like dropbox by just clicking on it and this updates your Zscaler policy via an API call. This is really useful for Information and Security officers who perhaps are not hands on but want to instantly block user traffic to file sharing apps or other.
Roadmap – I have issues with a customer who uses 3rd parties which permit access via Source IP, sigh. Using Zscaler, obviously your IP comes from a pool of shared IP addresses so often the 3rd party won’t allow you to use this. As a work around, if you are luck, you can do a proxy chain in the PAC file back to your existing on-premise Proxy, but if you’ve got rid of that then you’ve got a problem. Now, really you should talk to the business and the partner about changing this control to something a bit more modern and user based like SAML but if that’s not going to happen Microsoft are baking a new feature into Azure AD Conditional Access which will allow you expose your location IP address as opposed to the Zscaler IP address, this is going to really help in these scenarios.
What was also cool to see was the Microsoft network map and their peerings with Zscaler. Zscaler is peered with Microsoft in London, Paris and Amsterdam which is three data centres which I use the most which means very low latency.
Attended a session where the company SFK presented their Zscaler solution using regional Internet breakouts as opposed to local Internet breakouts, using key locations where Zscaler, Akamaii and Microsoft were located such as London and Paris in Europe. SFK also used Zapp when users are On-Network so they were doing tunnel (Zapp) within a tunnel (GRE), which is a solution i’m looking to deploy, so good to know its works and performance is good.
SFK also talked about routing out through the Great Chinese Firewall which was really interesting the issues you will have trying to egress out of china, especially around latency and packet loss as if the great firewall is overloaded, scary stuff.
Roadmap – The Cloud Firewall if you have the advanced license does IPS for all ports. Coming soon is SNORT integration and a bit later the ability to add your own SNORT rules which is handy if you get advanced notification of threats from people like NCSC. In the meanwhile you can send Zscaler the SNORT rules and they will implement them for you.
Tech note – Skype traffic was brought up regarding latency as Zscaler can add up to 100ms latency. This is obviously unacceptable from a voice/video perspective so is not as inspected as web traffic to provide better latency to this type of UDP traffic.
Tech note. sub locations and countries. So one customer I have wanted to preface the data centres that could be used by clients. So in the PAC file you can change the $gateway setting to a specific data centre like lon3.sme.zscalerone.net. The reasoning is to ensure traffic is traversing a DC in a trusted country. However you don’t get the geo-location so users working in a different country would have a poorer experience because of the increased latency. Now you could introduce rules in the PAC file to combat this but if their travel is dynamic then this is not scalable. A solution for this is for Zscaler to allocate you a sub-cloud. This is purely a whitelist of ZEN nodes you can use, so you can raise a ticket and say I want London, Paris and Amsterdam only and change your PAC to customerdomain_$gateway. That’s pretty cool. Another alternative is to use the following $gateway_country. This parameter doesn’t chose the ZEN via geo location or lowest latency but by what country you are in which gives you more control with very little config.
I got the PAC file information from Yogi at Zscaler, that guy knows his stuff, if you ever get to meet him you can get a lot of answers and put your requests to him.
Network Transformation – Hub and Spoke to a Hybrid network
When we talk about hybrid networks we are talking about local Internet break-out at branch sites and SD-WAN and how goliaths like Siemens have moved to the model of Internet as the Corporate Network. Why are we changing from hub and spoke to SD-WAN? Because workloads are moving to the cloud. in the 90s/00s all the apps were in the data centre but now companies are migrating apps to SaaS, Public Cloud and Private cloud, the traffic pattern has shifted to the Internet and the network needs to adapt to reflect this.
Some interesting points made at the network transformation session around the types of Internet circuits being procured at branch sites. Circuits ranging from carrier grade to broadband, how do you procure these internationally, who makes the decision on the grade of circuit. These are business decisions, but it is rare to get a customer to make these decisions. This needs to be driven technically and justified to the business.
Siemens and Orange Business Services presented their network transformation journey using Zscaler and SD-WAN. The project plan below is really good and could be applied to most customer deployments.