We are deploying ZPA (only ZPA) to our userbase to replace Cisco Anyconnect. I’ve gotten feedback from a large number of users spread out across the US that it is terribly slow when accessing our Windows file shares as compared to Cisco Anyconnect. Right now we have a wide open ZPA config for testing. I’ve enabled Quick Ack, tried some private service edges, but nothing seems to matter. Any ideas?
It is slow if users load a lot of small files as SMB establishs a dedicated connection for each file, which makes connections slow with the encryption overhead.
Besides that, Zscaler recommends to use dedicated AppConnectors for fileshares. Have not seen any difference yet but we are currently in the phase to set these up, so we are still observing this
Are you using hostnames or FQDNs for the path? You’ll see an incredible difference in response times.
I think we talked previously about this on another thread. SMB is unfortunately extremely chatty and doesn’t play nice with most things. Even VPNs when googling have had issues over the years with performance. That being said this may be a good candidate for the newer ZPA legacy App stuff that is coming out.
This link talks about it a bit.
We had similar issues… whitelist all ads including pdcs even though they might not be directly interacting with end user machine in zscalar… connector will not hog up bandwidth with all the smb and ldap and other authentication/chatty traffic.
Oddly enough, speed, especially with file shares is our selling point. We saw an increase in speed. However, we are also on an Hitachi NAS. BTW, if anyone has users who can’t mount drives on a normal basis or it’s intermittent, then let me know. We uncovered a situation where Hitachi has an anti-DDoS feature that if anyone in your environment has an expired password in AD and they haven’t changed it, when they access Hitachi, it’s “auto-barr” feature will block their IP. Well guess which IP they’re coming from? The same IP everyone is – the app connectors. 
We’re fine tuning it now. It’s been interesting.
Under your ZPA portal, there’s the diagnostic log. What’s the setup time?
Throwing an idea on the table - what is your current setting for the segment’s Health Reporting? Could None make a difference in your case?
May be an obvious question, but are your app connectors built and sized properly (CPU, Memory, etc.)? Default specs can support up to 500 mbps per AC and should be deployed N+1.
So make sure all ADCs are accessible over an App Segment, this is a huge one as the client will contact all domain controllers at times because the client knows it’s not in a site.
Also, ZPA creates a tunnel for every connection, and with SMB this is a lot, I’ve seen two or three per file even. Every tunnel has a setup time involved, which is observable in the App Connector metrics. The first chart is the time it takes to establish a tunnel to different service edges and the second is the latency of the tunnel.
You need to use ZDX to find what Zscaler DC the user is connecting to, then look up the service edges for that DC in the metrics of the App Connector. That will give you a picture of what’s going on, and Zscaler should be walking you through that honestly. Sometimes the Zscaler DC is the issue.
With all that, because the way ZPA works, it will not be as fast as a VPN, and honestly it probably shouldn’t be due to the nature of its operations. The App Connector is a Linux vm and has limitations and sometimes you have to have a bunch of those suckers to spread the load. Sometimes, especially with SMB, it becomes a “it is what it is” situation because of the nature of the protocol. I will see if I can pull up the tuning guide I came across some time ago for things like SMB, it had me adjust a couple of sysctl setting on the App Connectors that helped, and IIRC it was around file handles and network port exhaustion tuning.
Join the club. File share access is stupid slow. We are in the process of moving user files to one drive so machines access via internet/ZIA rather than ZPA
With most companies moving to OneDrive, Google Drive, et cetera it doesn’t come up a ton. It will be slightly slower than VPN since you aren’t connecting directly to the network, but it shouldn’t be noticeable.
For customers that still use file shares for large transfers (like 100GB CAD files) usually you can use a private service edge, or have an App Connector dedicated just for the SMB traffic.
You could also look at where you have App Connectors placed, and if they are in optimal locations for the file shares.
Yes, they are, but only a few of our larger sites have DCs, about 5 out of 30.
I’ve tried both small and large file transfers and it’s the same for both. I’m not sure what they mean by dedicated App Connectors. How do you dedicate an app connector for file shares?
Unfortunately it is still a big issue and only about 15% of our remote users are using Zscaler. The majority are not using it because they say it’s too slow, even for things like RDP.
This is great, is this a new SKU? I can’t seem to find anything other than is “at a glance”
I am not blocking anything at this time. All TCP and UDP ports 1-52 and 54-65525 are open.
The file servers are at each location and are local to the server, no NAS or SAN, just a simple RAID 5 array on the file server.
The highest I saw was 0.78ms
It is reporting health on connection. I can try to turn it off.