Internet traffic stops every time XG has an IPS or ATP update

I've looked into this further but it doesn't seem to be limited to that one site. I checked our own site and that dropped all traffic for about 40s during an ATP update (I presume it was for a shorter period because it is an XG 230 and the update would have completed quicker).

Hi JasP,

After a talk with the support, I've found out anything that makes the IPS (Snort) service restarts will make your firewall drop packets.

Well, I've been facing a issue where creating a custom IPS signature, Snort would restart bringing a lot of packets down with it, after a while I've saw the same thing happens over IPS/ATP updates. This issue is a lot more noticeable on low-end CPUs since It takes a while to restart Snort.

In v17.5 It would primarily drop only the traffic that had IPS within a policy, now on v18 It's even worse because if your doing TLS Decryption half of the decrypted traffic gets dropped and you have to refresh the entire page over the browser.

The answer by them has - some traffic will get dropped while restarting Snort, so they will add this information at the Docs.

Thanks!

Thanks for the info Prism

So, in summary, the way they handle updates is crap and their solution to the problem is to document the fact it is crap!

If that is the behaviour then an obvious solution is to be able to specify a time period to check for IPS and ATP updates, then it can be scheduled out of hours. All you can do ATM is turn automatic updates on or off.

JasP said:

If that is the behaviour then an obvious solution is to be able to specify a time period to check for IPS and ATP updates, then it can be scheduled out of hours.

Well, don't hold your breath.

People have been asking this since 2016, by the rate that things are moving we will see this really advanced feature by the year 2026.

I believe this is the current expected behaviour when the IPS patterns are updated, I will confirm with Engineering. 

Scheduled updates of firmware are available today using Central. Scheduled updates of patterns are coming, I hope in 18.5 but please do not take this as commitment, we are doing our best to catch up on some of these long requested features, but the Engineering teams also have other priorities to balance.

Stuart

Hi Jasp,

you can change the update frequency from rvry 15 minutes out to every 2 days or as you said by manually starting the process.

A question which PMStuart has not addressed or maybe even been asked is this not an issue with the UTM?

Ian

Hi ian

Thanks, I'm aware of this but this but it still doesn't when they run. I assume it is also applies to all the updates, including anti-virus updates, that don't cause and issue and I would like to update asap.

I hope this is granular and not a one size fits all option. Anti-virus updates take place multiple times a day, don't cause an issue, and I would like applied ASAP. Those that stop internet connectivity I want to be able to schedule outside of working hours. Better still would be code that didn't stop internet connectivity when it was updating!

It really is time that you employed someone with some business acumen in your design team. I appreciate that this is a security device but anything that regularly stops it passing genuine internet traffic is a design failure and should not make it in to production. What do you say to a customer that loses all their VOIP calls several times a week? - "Sorry, its designed to do that!!!"

BTW, my 'high' priority support case has now been open 8 days and I haven't had a single response yet!

JasP said:

I hope this is granular and not a one size fits all option. Anti-virus updates take place multiple times a day, don't cause an issue, and I would like applied ASAP. Those that stop internet connectivity I want to be able to schedule outside of working hours. Better still would be code that didn't stop internet connectivity when it was updating!

It really is time that you employed someone with some business acumen in your design team. I appreciate that this is a security device but anything that regularly stops it passing genuine internet traffic is a design failure and should not make it in to production. What do you say to a customer that loses all their VOIP calls several times a week? - "Sorry, its designed to do that!!!"

BTW, my 'high' priority support case has now been open 8 days and I haven't had a single response yet!

I'd second the "business acumen" comment.  They'd also quickly discover how futile the logging in this product is whenever they had to try and track down why something wasn't working.  

Can you try to disable virtual fastpath? 

console> system firewall-acceleration disable