Hello Community,
We have been using CloudXR for some time now and we are extremely happy!
We have recently rolled out to a new client that uses Zscaler, a cloud security company, and have run into issues connecting via their network. The connection works fine on any wifi yet is being blocked on the Zscaler network.
Here is a link to their website: Zscaler FAQs | What does Zscaler do and more
Unfortunately, the Zscaler team has not been able to poinpoint the exact issue yet only able to give some suggestions.
Has anyone had any issues or success with Zscaler networks?
We are using Meta Quest 2, Amazon EC3 G5.2xlarge and nvidia Cloudxr. Again, we have no issues connecting with any wifi and everything works as expected, just not on this specific network secured with Zscaler.
Below is some correspondence that could be useful.
I think the issue is seen here.
I’m by no means an RTSP expert, but this is my educated guess:
Packet 217: Client wants to learn server capabilities on media format, codecs, etc.
Packet 218: Server responds with a 200 OK and some headers including Content-Length: 89510
Packet 219: Client ACKs that response
Packet 232: Client closes the connection
Client seems to close the session after 20 seconds. Looks like a timeout to me. Most probably the client was expecting more data from the server (I guess the actual media details) and was not receiving it.
I suspect this is the packet that was dropped at the Zscaler node due to the content-length of that header not matching the actual response this client is waiting for.
Thank you in advance for any assistance!
-Jeremy
Hi Jeremy, If you’re comfortable replying back with your client and server logs we can take a look at it. I’m assuming you’re off-network when transmitting traffic if it’s passing through an IDP/IPS or packet-shaper like Zscaler. Networks with these make it difficult (or impossible) to pinpoint a solution but a log would help.
Hello wcannady,
Thank you for the response! My apolagies, I missed this and did not see it…
I have attached a screenshot of the logs as well as a packet capture.
I had to rename the packet capture to .txt to upload. To view it, please rename the file to .pcap. I hope this data can provide some insight!
datapath.txt (134.0 KB)
Thank you!
-Jeremy
Thanks for the log – unfortunately it confirms a nearly 20 second delay from the server to the client for some reason. The good news is we’ve been investigating this from another partner who was able to provide some additional logs.
What we think is happening is a blank DESCRIBE payload within the RTSP signler for versions earlier than CloudXR 4.0. The reason is RTSP has a content-length requirement that requires you announce the payload size you plan to send to the server. If this is set as one size, but actually is a difference size sent, Zscaler devices see it as a risk and deletes the DESCRIBE payload required for an RTSP connection.
Version 4.0 (and all versions thereafter) have changed the signaling mechanism to use Websockets/WebRTC instead. Besides making the signaling handshake much simpler, it bypasses this issue and preserves compliance.
The suggestion is to upgrade to 4.0 and retest to see if you run into the same problem. Because the signaling is different, it should resolve the issue. Let us know how it goes.
