Zoom Meeting Issues with SecureXL

[jc332]

Hi there,

We're having issues with zoom meetings when SecureXL is turned on. The meeting connects and runs fine for ~15 mins before one end will appear to freeze (video and audio) and eventually disconnect (although users usually notice first and restart it themsleves before it disconnects. This will repeat itself until we turn SecureXL off.

The thing is, SecureXL can be turned on for a number of days or even weeks with multiple zoom meetings happening per day before we see any issues. We saw this issue in R77.30 and it remains even since we've migrated to R80.30. I suppose it could still be unrelated or there may of course be something else at play.

Hardware is a pair of 15400 applianes (ClusterXL).

I have a TAC case open but obviously they want logs etc. from the time the issue is occuring which are hard to provide as the focus was on turning off SecureXL at the time  to get the meeting running smoothly and we can't really turn it back on and risk breaking more meetings due to the nature of them.

I have been trying to reproduce the issue through a pair of 3100s running R80.30 with SecureXL turned on without success. But obviously there are many differences here (it could be speific to that hardware...).

Obviously we'd rather have it turned on, so I was just wondering if anyone had seen any similar issues and had any advice?

Many thanks in advance.

Josh

[Vladimir]

Actually, I have just experienced Zoom session quality deterioration yesterday, after upgrading pair of 13800s to R80.30.

Cannot yet ascertain if it is the same issue you are describing, but it very well may be.

[Timothy_Hall]

Sounds an awful lot like the issue mentioned in this thread assuming that Zoom is using UDP for the audio/video transport:

https://community.checkpoint.com/t5/Enterprise-Appliances-and-Gaia/Message-seen-on-var-log-messages-...

You aren't seeing anything like this in /var/log/messages are you:

simi_reorder_enqueue_packet: reached the limit of maximum enqueued packets for conn

[jc332]

It certainly is majority UDP traffic, and having read through the thread you linked it would make a lot of sense. It would also go some way to explaining why I wouldn't necessarily see the issue on an unused pair of 3100s.

Unfortunately the messages files don't go back to the last time we saw the issue so can't see any of those messages at present. I will have to think about the best way to test this on Monday. I will provide an update as soon as I have one!

[Timothy_Hall]

Since the syslog has rolled off on your gateway I assume you aren't using some kind of third-party log aggregation like Splunk for long-term syslog storage.  You may want to redirect firewall syslog messages into the main traffic logs stored on the SMS to avoid this situation in the future:

sk102995: How to export syslog messages from Gaia Security Gateway to a Log Server and view them in ...

Also might be interesting to revisit the last time period you had the problem (if it was less than 30 days ago) by firing up cpview in history mode with -t (timestamp).  There is a SecureXL menu on the Advanced screen; not sure if it would have anything that is related to your problem showing there but it might be worth a look during the problematic period.  

Would also be interesting to go through all the other cpview screens just before the problem started, then advance into the time period where the problem was known to be occurring and see if any dramatic differences jump out at you.

[jc332]

Yes we do actually ship the syslog off elsewhere, however it seems it hasn't been working since we upgraded. I still need to look into that. Having looked through older syslog though I cannot see any message containing simi_reorder from any of our gateways where we've had this issue...

Although we don't have an exact timestamp, we have a 1.5 hr window on Monday 8th July during which the issue occured. Having scrolled through cpview for this time  the figures are as follows from before and after the window, I don't know if those numbers are significant?

A couple of hours after this time the "Reorder" value jumped up to 1,025, then to 2,050 a few hours after that, then 3,075 and so on. Is this related to the reordering you mentioned?

The values today are as follows:

[jc332]

I replied to this already but can't see it anywhere... So here it is again.

I've now fixed the syslog issue we've had since the upgrade so the messages are once again being shipped off and stored. cpview shows the following from just before the issue window, just after, and currently:

The "Reorder" value there was zero throughout the window but in the hours following it began incrementing by 1,025 every few hours... Is this related to the reordering in the article you linked?

[PhoneBoy]

Your post was in the moderation queue--it got approved.
We do moderate posts for newer members as a default.
This shouldn't happen for you going forward.

[Timothy_Hall]

The "Reorder" counter getting incremented might be significant, tough to say.  I think you'll have to wait until the next problem period then check syslog...

[PhoneBoy]

Have to think we would have seen the issue internally given we make use of Zoom...
In any case, anytime disabling SecureXL is a solution, TAC should definitely be involved.
And yes, I am acutely aware the intermittent nature of this makes it hard to troubleshoot.

[jc332]

Yes, you'd have thought so. But I wonder if there's a difference between using zoom on the desktops and zoom on the video conferencing units we use? I.e. desktop stuff is predominantly via HTTPS/443 but VCs use UDP? In fact our firewall logs would certainly suggest that to the be the case having just checked

[bcibnkcpfw]

I have the same issue after upgrade from R80.20 to R80.30. But in my case All VPN based on UDP. Trying to solve:

• IPS Exception - Not solve;
• Update to Take 111 not solve;
• Disable SecureXL - SOLVED

Any "fix" for it?

Kind regards,

[PhoneBoy]

Please open a TAC case so we can troubleshoot this.

[Jung_Patrick]

Hello,

I also received a report of slow zooming and disconnection at R80.30 GW.

Are there any new updates?

Thank you.

[iso667]

Same here. Did you find any solution without disabling SecureXL?? BR!

[PhoneBoy]

Please open a TAC case @iso667 @Jung_Patrick.

[barakh]

any updates about this issue?

[PhoneBoy]

As noted previously, you should open a TAC case here so we can troubleshoot.
If you have SRs around this issue, please PM them to me.