Just curious is anyone has gotten a windows client vpn to connect to zscaler using ikev2? ZIA via Zapp does not work well at all in mainland China. I previously used an ikev1 VPN connection but that seems to now be blocked. I was able to get an IKEv2 VPN to connect but no data would flow over the tunnel. I also get the same thing experience in the US but now that I am back home, my same IKEv1 connection works again. I am hoping that if I can get an IKEv2 VPN to work to Zscaler in the US that it will work in China. I have tried using forticlient and greenbow. Forticlient is the one that connects but doesn’t get any data returned when using IKEv2. Greenbow’s configuration manager crashes and burns after I save a VPN config.
We don’t really recommend using a third party VPN client to connect to Zscaler.
Are you aware that we have three DCs now inside China, and if you point your traffic to them, then you shouldn’t have any issues. The nodes in China are not in public rotation, and have an extra bandwidth surcharge associated with them. You account team can give you more information about that.
I did change my Zapp pac to use country detection. If in China, then it uses the Shanghai or Beijing ZEN, else it uses the GATEWAY variable. I will try it next time I am in mainland China. In general, it would be better if Zapp better encrypted the traffic as the traffic is quite easy to decipher and I have seen layer 7 firewalls that block http connects kill zapp tunnels. Running the proxy over 443 doesn’t fool but the most basic firewalls.
Understood your concern, but the zapp is actually not designed to help bypass any firewall, such as the one in China.
We have customers in China using zapp to connect to our China DCs, but those DCs are using local internet links within the coverage of China Great Firewall, and will not help to play any magic in terms of serving internet access inside China.
SE Manager, Greater China
This design can cause a DoS though. When Zapp users are behind a L7 firewall that blocks http proxy, they are basically unable to use the internet. I have personally had this happen at a hotel (not in china) and all I got was a fortigate http.proxy blocked message in the browser. Zapp did not handle that failure well and fail open did not work. Using an IPSec connection to the ZEN restored my internet. I don’t think most of my users would have known what that meant and how to deal with it. Even if it did fail open, then my user’s network is no longer protected. Hopefully it is on the roadmap to provide some better data privacy for my users and also prevent this DoS issue.
On a positive side, ZPA worked amazingly well in mainland China despite my issues with ZIA.
Having a very strong firewall background from my previous job, I understand your concern.
Unlike ZPA which is for handling customer internal traffic and requires strong encryption, the ZIA is designed to handle customer internet traffic, which is not encrypted from the network layer. So the ZIA Zapp tunnel is built to forward traffic to us with the least overhead, to offer the best performance of our services. IPSec is not a good choice as it will introduce too much overhead to both our cloud and the client PC- imagine how much traffic the client will need to encrypt when the 5G network is launched. And actually China Great Firewall does recognize IPSec and openvpn, so as long as as the traffic is sending to our overseas datacenter it will not work reliably.
I have helped a lot of customers in the hospitality industry to design the network and firewall in my previous job, and all of them will simply allow all port 80 and 443 traffic from the guest network in order to avoid unnecessary Impact to customer internet access. I am thinking the situation you had encountered is due to a misconfiguration of the FW, that the IT admin there had wrongly extend the internal office network policy to the guest network.
I also travel a lot, and when I hit the same issue I normally will request the hotel to fix it, but in the other hand, I totally agree that we should provide another alternative for the tunnel setup as backup/resiliency, and this is what our PM is evaluating.
May I suggest you to reach partner covering you to raise a feature request to us to provide a backup way to forward traffic to Zscaler, so that we can track it internally more easily?
Thanks for your feedback and sharing!
SE Manager, Greater China
OK. I will contact SHI and ask them to raise a RFE. Since we are having a good discussion on Zapp, is it on the roadmap to use actual latency measurements to select ZENs? This problem occurs much more often and has a much larger impact on the productivity of my user base. My home for instance has its traffic routed to WAS instead of CHI which is almost half the latency of WAS. Maxmind shows accurate geo info. It should not be necessary to contact support for every IP that needs the zen selection changed.
We do have an ER being tracked for latency based ZEN assignment for Z App, though this does not have a release version assigned yet. If you need a reference for any discussions you can use: ER-5998