Enforce SecureXL template?

[Hugo_vd_Kooij]

Is there a way to enfocre SecureXLon TCP connections?

There is a way in sk104468 to do it the other way around. There you can enforce that SecureXL will not be applied.

But I am looking for a way to to it the other way around so I can make sure that additional blades are not causing me a big performance penalty on a high bandwidth connection.

[Timothy_Hall]

SecureXL has two separate but related components:

Packet/Throughput Acceleration: Ability to move packets more efficiently through the firewall via the four possible paths; they are in decreasing order of efficiency: SXL, PXL, F2F, and F2F with a process space trip.

Session Rate Acceleration/Templating: Ability to "cache" rulebase lookups in SecureXL and avoid lots of expensive full rulebase lookups, especially useful in environments with a high new connection rate.

My book covers how to optimize SecureXL for best operation, R80.10 is strongly recommended as there were many, many enhancements to firewall efficiency which invalidated some of the recommendations stated in the first edition of my book.  Bit too complicated to explain it all in a CheckMates post, but the best place to start are these "Super Seven" commands.  Posting the output of these should provide enough detail to make a few general recommendations:

netstat -ni

grep -c ^processor /proc/cpuinfo

fwaccel stat

fwaccel stats -s

fw ctl multik stat

fw ctl affinity -l -r

fw ctl multik get_mode (R77.30) or fw ctl multik dynamic_dispatching get_mode (R80.10+)

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Hugo_vd_Kooij]

It's in the works but will not be general available as I understand the current discussion. As it will have a security impact people may not understand.

[Timothy_Hall]

There is actually a way to whitelist a certain protocol & port number in SecureXL such that SecureXL will just handle it with passive streaming in the Accelerated path no matter what, and the Medium/Firewall paths will never even see it.  This is similar to the "application override" feature touted by a competitor's firewall.

It involves some hand-edits to the spii.def and table.def files on the SMS.  I'd rather not post the details since doing this negates almost all protections offered by the firewall, but the whitelisted traffic certainly does pass through the firewall at  ludicrous speed. If you really need this info, just mention the term "spii_dport_white_list" to Check Point TAC.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Hugo_vd_Kooij]

If TAC doesn't. I might have a look to get it through other channels. But from the looks of it it seems to be casting the net too wide to be comfortable. I got 1 SK back on the keyword that seems to indicate there is in fact a bug present.

[Hugo_vd_Kooij]

TAC just confirmed that the "spii_dport_white_list" trick does not work here. However we have a go on a more accurate fix that will have a better balance. to match the customer traffic without a big impact on security.