- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Introducing Check Point Quantum Spark 2500:
Smarter Security, Faster Connectivity, and Simpler MSP Management!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
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
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.
Sounds an awful lot like the issue mentioned in this thread assuming that Zoom is using UDP for the audio/video transport:
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
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!
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:
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.
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:
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?
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.
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...
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
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:
Any "fix" for it?
Kind regards,
Hello,
I also received a report of slow zooming and disconnection at R80.30 GW.
Are there any new updates?
Thank you.
Same here. Did you find any solution without disabling SecureXL?? BR!
Please open a TAC case @iso667 @Jung_Patrick.
any updates about this issue?
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.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
10 | |
8 | |
6 | |
5 | |
5 | |
5 | |
5 | |
5 | |
5 | |
4 |
Wed 03 Sep 2025 @ 11:00 AM (SGT)
Deep Dive APAC: Troubleshooting 101 for Quantum Security GatewaysThu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (CEST)
Effortless Web Application & API Security with AI-Powered WAF, an intro to CloudGuard WAFWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksWed 03 Sep 2025 @ 11:00 AM (SGT)
Deep Dive APAC: Troubleshooting 101 for Quantum Security GatewaysThu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY