topic Re: SecureXL Templates 61000/64000 in Hyperscale Firewall (Maestro)

SecureXL Templates 61000/64000

Andre_K — Mon, 10 Sep 2018 06:29:31 GMT

Hi all,

Should the value in the ‘Conns’ column of a SecureXL template be counted as a concurrent connection or an indicator how many connections used the particular template?

For example; for a particular vs I have approx. 50.000 connections in the fw1 & SecureXL connections table (asg_conns). However according ‘asg perf’ output there are over 6.000.000 concurrent connections for that specific vs. This is caused by one particular connection which is accelerated and templated and has the value of 6.000.000 in the ‘Conns’ column. Each time the firewall policy is installed or SecureXL is enabled/disabled the template is cleared and after a week or so the concurrent connections is back around 6 million and increasing. As result SNMP and ‘asg alert’ send email alerts due to the high amount of concurrent of connections which causes noise for the firewall administrator since there is no high load. As workaround the firewall administrator pushes the firewall policy every few days to clear the templates.

Is this behavior expected or something cosmetic? According TAC (last year), it works as designed.

As a solution we can assign a inspect handler (i.e. SIP) to the service so that each connection is forced to F2F, but again this should not the be to way to solve this issue.

Anyone else experience this behavior?

Thank,

Andre

Re: SecureXL Templates 61000/64000

Lari_Luoma — Fri, 14 Sep 2018 14:48:50 GMT

I don't fully understand the problem. You said that there is one connection that causes 6M connections in the connections table. Sounds weird. Can you elaborate this or provide a screenshot? Which command did you use to get the "conns" value?

SecureXL is restarted in policy push, so it's normal that the templates get cleared.

Re: SecureXL Templates 61000/64000

Andre_K — Fri, 14 Sep 2018 15:09:46 GMT

Hi Lari,

Thank you for your reply. I was referring to 6M connections in the ‘Conns’ column for one particular connection when executing the command ‘g_fwaccel templates’ and there are approx 50K connections in the acceleration/fw connections table combined; when executing the command ‘asg_conns'. I am aware that the SecureXL templates are resetted each time a policy install is executed. As mentioned, that is the current workaround for the firewall administrators to get rid of the concurrent connections notifications generated by the chassis.

In a nutshell: each connection that passes the specific SecureXL template is added to the conns column and counted as an concurrent connection. The value of the Conns column keeps increasing and does not time out until a policy push. The chassis marks this somehow as an active connections and at the end of the week the template has 6M hits. When executing the command ‘asg perf -vs all -vv’ it shows that there are 6M concurrent connections for that particular VS with only 50K entries in the combined connections table. (and the throughput for that VS is less than a Mb)

Unfortunately I am not entitled to share any screenshots with the public.

Thanks again.

Re: SecureXL Templates 61000/64000

Lari_Luoma — Fri, 14 Sep 2018 18:02:29 GMT

g_fwaccell templates shows all connection templates. Sounds like the system creates 6M templates for this one connection. I would like to understand what kind of connection that might be. A template is created whenever a source port can be masked out (DIP, DPORT and SIP stay the same) and the system works as intended.

Re: SecureXL Templates 61000/64000

Andre_K — Mon, 17 Sep 2018 05:17:50 GMT

It’s a connection initiated by a 3prd party which performs remote monitoring by using endpoint monitoring agents. The SIP, DIP and DPORT are indeed the same and the template works as intended. However when that specific template is used and the connection passed through the firewall does this still count as a concurrent connection? I will see if the 3^rd party is able to adjust their tressholds and see if they can monitor less aggressive. On my next visit to Tel Aviv in the near future I will make sure I run this by the high-end team. Thanks again for your input Lari.