SecureXL and URL filtering

[Luis_Miguel_Mig]

I have a number of clusters with SecureXL. I get more than 85% of packets accelerated in most of them

I have one with about 65% of packets accelerated though. The main difference is that I have URL filtering enabled in this last one.

The URL configuration I have at the moment is simple just a few rules to block some categories, however I have one rule at the end that allows and logs all the traffic.

To be honest, I don’t need to log and track all the traffic so I was thinking in disabling the last line of the URL filtering blade.

I believe that there is an implied rule at the end that will allow all the http traffic at the URL filtering blade, so if I disable the last explicit rule I won’t block my users traffic, correct?

[Timothy_Hall]

Correct, removing that last rule will help make more traffic potentially eligible for acceleration, assuming there is not another blade active that needs to pull that traffic into the Medium Path for Active Streaming.  The default cleanup rule for APCL/URLF policies is accept.

However in your other APCL/URLF rules, make sure you are not using "Any" in the Source and Destination fields of any rule.  You should only be using specific networks or object "Internet" for destination, which needs to have your firewall's topology correctly and completely defined to be applied properly.  In the Source field call out the specific internal networks you need, negations can sometimes be helpful here as well.  Avoid using "Any" at all costs!

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

[Luis_Miguel_Mig]

Thanks Tim,

I was wondering is there is any way to change/check the status of   the default implied rule ?  If I select View -> Implied Rules at the smartdashboard I don't see anything.

[Timothy_Hall]

You must be using R77.30 management, so the answer is no you can't see the default implied rule at the end of the rulebase.

In R80+ management this default rule can be viewed (and changed!).

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

[Luis_Miguel_Mig]

Thanks

[Vladimir]

Tim, can you elaborate on how and why logging impacts acceleration?

[Timothy_Hall]

After thinking about your question for a few minutes, I'm pretty sure the logging config doesn't impact acceleration directly.  For connections it is handling itself, SecureXL can send logging and accounting notifications up into the INSPECT driver running on the Firewall Worker cores.   So specifying a certain type of logging does not cause traffic to get punted out of the SXL path into a higher one as far as I know. 

Obviously a very high logging rate or high amounts of detail (i.e. log types Detailed & Extended) will cause general firewall overhead, particularly generating the logs themselves in the kernel and sending them up to process space for transfer to the SMS.  The log transport mechanism between the gateways and SMS/Log Server is handled completely in process space, so if the kernel needs CPU resources to keep moving live traffic expeditiously, the log transfer process will always have lower priority and will just have to wait.

Alerts such as emails and SNMP traps are fired from the SMS, not the gateway so those don't have an effect either.

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

[Vladimir]

Does this "For connections it is handling itself, SecureXL can send logging and accounting notifications up into the INSPECT driver running on the Firewall Worker cores." imply that the log traffic is subjected to inspection by the rule base before it is forwarded to the log servers?

[Timothy_Hall]

The log notifications coming up from SecureXL to INSPECT all happen inside the system, and it is not treated as network traffic by the various policies.  It is two trusted pieces of code talking to each other on the same system so I wouldn't be too worried about it from a security perspective.

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

[Vladimir]

It is not a security related concern, but rather question about performance impact and the attempt to visualize the workflow involved in getting events logged by the system components. 

[John_Tammaro1]

To take a step back from getting too wrapped up in the logging elements, have you considered from SK98722 the general limitations of SecureXL on an R77.XX and below platform ?

• For limitations of traffic acceleration and templates, refer to sk32578 - SecureXL Mechanism.

• SIM Affinity is applicable only to physical interfaces (VLAN / Bond interfaces are influenced by the "physical" decision).
  Note: Some systems may require BIOS update to enable IRQ Swizzling and EIRQ technologies. To determine whether a specific system supports the required technology, contact your hardware vendor.

• On VSX Gateway, WARP interfaces can not be assigned to a CPU core.

• SecureXL NAT Templates are supported only in R75.40 and above (refer to sk71200).

• SecureXL Drop Templates are supported only in R76 and above (refer to sk66402).

• SecureXL Drop Template acceleration is performed only on connections with the same destination port (does not use wildcards for source ports).

• SecureXL NMR Templates ("No Match Ranges") are supported only in R80.10 and above (refer to sk117755).

• SecureXL NMT Templates ("No Match Time") are supported only in R80.10 and above (refer to sk117755).

• SecureXL Optimized Drops feature (used for DoS/DDoS protection) is supported only in R76 and above (refer to sk90861).

• SecureXL Penalty box feature (used for DoS/DDoS protection) is supported only in R75.40VS and above (on VSX Gateway, the penalty box would only be enforced on Virtual System 0) (refer to sk74520).

• SecureXL does not support Point-to-Point interfaces (PPP, PPTP, PPPoE).
  Note: In case a PPP-interface is detected, SecureXL disables itself on that interface (refer to sk79880).

• ClusterXL Sticky Decision Function (SDF) disables SecureXL.

• QoS disables SecureXL (to enable both QoS and SecureXL on R77.10 and above, refer to sk98229).

• Delayed Synchronization in cluster:

  • Applies only to TCP services whose 'Protocol Type' is set to 'HTTP' or 'None'.
  • Delayed Synchronization is disabled if the 'Track' option in the rule is set to 'Log' or 'Account'.
  • Delayed Synchronization is performed only for connections matching a SecureXL Connection Template.

• It is possible that a connection will exist in the Firewall Connections Table, but not in the SecureXL Connections Table (partial connection).
  This situation can occur:

  • After policy installation
  • After cluster failover
  • If user turned off ('fwaccel off' command) and turned on ('fwaccel on' command) acceleration

If your policy or configuration on the gateway with URLF configured also contains any of the above listed features then this could be the cause of fewer packets being accelerated.

Moving to R80.10 would resolve some of the more basic issues such as Dynamic and Time based objects for example. Im pretty sure there are other SecureXL limitations that are removed after upgrade as well if in deed these are the root cause of the problem.

The only final question I have is that you have identified less traffic being accelerated. but ... is that actually causing you any problems ? If it is causing high resource usage because of this 20% difference in accelerated packets then I would suggest you need to upgrade the hardware rather spend too much time troubleshooting SecureXL.