SecureXL Process Details

SecureXL is a patented technology consisting of a software package with an API for the acceleration for multiple, intensive security operations. In addition to the IPS, SecureXL also accelerates operations carried out by a Stateful Inspection firewall from Check Point. Through the SecureXL API, this firewall can offload the handling of those operations to a special module, the "SecureXL device," which is a performance-optimized software module.

In a SecureXL-enabled gateway, the firewall first uses the SecureXL API to query the SecureXL device and discover its capabilities. The firewall then implements a policy that determines which parts of what sessions are to be handled by the firewall, and which should be offloaded to the SecureXL device. When new sessions attempt to get established across the gateway, the first packet of each new session is inspected by the firewall to ensure that the connection is allowed by the security policy. As the packet is inspected, the firewall determines the required behavior for the session, and based on its policy it may then offload some or all of the session handling to the SecureXL device. Thereafter, the appropriate packets belonging to that session are inspected directly by the SecureXL device. The SecureXL device implements the security logic required for further analysis and handling of the traffic. If it identifies anomalies it then consults back with the firewall software and IPS engine. In addition, SecureXL provides a mode that allows for connection setup to be done entirely in the SecureXL device, thus providing extremely high session rate.

SecureXL in Multi-core CPU Minimizes Performance Hits to Integrated IPS

Performance is achieved via optimized network interface drivers and multi-threaded code in software or in hardware devices that are SecureXL-capable. Together, this combination of features increases throughput by a factor of 3X when compared to un-accelerated solutions. The end result is the best price/performance combination on the market. In a multi-core system one or more processors can be assigned to do SecureXL processing and dispatch non-accelerated packets among IPS and firewall kernel instances running on separate cores. SecureXL enables the integrated IPS and firewall to adjust and attain the optimal balance between security and performance requirements.

That is from Checkpoint "Solving the Performance Hurdle for Integrated IPS"



More explain from https://www.cpug.org/forums/miscellaneous/10418-securexl-templates-rulebase.html

"People like to get all confused over templates. I explain it thus (and btw, this is a long version of what Jim and PhoneBoy said):
First of all you have to understand that SecureXL is either a hardware or software layer that can forward packets faster than the firewall kernel, either because it's optimised efficient code in the gateways operating system (i.e. perf pack, or Nokia IPSO) or because it's a network processor based hardware card.
SXL templates accelerate TCP connection setup by reducing the time it takes to forward the initial SYN, SYN-ACK, ACK packets. This gives you higher connection establishment rates which is important if your taking a large number of HTTP connections. It can do this by creating a 'template' within the SecureXL module that matches the accept rule in the rulebase.
When a TCP connection comes in, there is no need to send the three way hand shake packets via 'slow path' to the firewall kernel. It gets sent 'fast path' through the SXL device and so you get fast TCP session establishment and high connection setup rates.
Any protection, such as security server, or syn defender, that requires the three way handshake to be inspected by the firewall kernel (F2F - forward 2 firewall) will disable templates, hence we worry here about syndefender.
Once the three way handshake is complete, templates no longer have any bearing on the performance of the connection. SXL, accelerates the rest of the packets, providing that there is no need for the firewall kernel to inspect them. There are are smartdefense protections which selectively disable SXL acceleration. Examples of this would be the ASCII ONLY HTTP RESPONSES which disables acceleration of the the server to client (S2C) side of the TCP connection. You then have one side of the connection being forward by the SXL device, and the other side being forwarded by the firewall kernel. It seems weird, but it's normal.
Other protections are less specific, for example, TCP sequence verification. This protection requires that the firewall kernel inspect EVERY TCP packet, and so you have no SecureXL acceleration for ANY TCP connection (I should mention that I used that as an example, i believe that the TCP sequence verifier is implement in Performance Pack now as well).
So, to come back to your question, the list of supported features details the type of features that are compatible with regular SXL acceleration (that is forwarding the packets after connection setup).
The list of unsupported features lists those features that would disable SXL templates.
The only reason to make changes to your configuration to make templates work would be because you need a high connection setup rate.

Oh and for fun:
fwaccel ver
FireWall-1 version: NG with Application Intelligence (R55) HFA_08 for IPSO 3.8, Hotfix 833 - Build 004
Acceleration Device: Nokia IPSO
Accelerator Version 1.0
FireWall-1 API version: 2.12NG (16/10/2003)
Accelerator API version: 2.12NG (16/10/2003)
fwaccel stat
Accelerator Status : on
Templates : disabled by FireWall-1 starting from rule #855
Accelerator Features : Accounting, NAT, Cryptography, Routing,
HasClock, Templates, VirtualDefrag, GenerateIcmp,
IdleDetection, Sequencing, TcpStateDetect,
AutoExpire, DelayedNotif, McastRouting "

Understand Cisco NAT - Policy NAT-ing with overlap message - Order is important

There is a special situation came up today. When host 172.17.1.3 tried to access remote site 200.200.200.200 , it has to be nat-ed to a different ip address 200.147.90.83

There is an existing rule already on ASA :

static (dmz,outside) 200.147.90.89 172.17.1.3 netmask 255.255.255.255

So what I did :

Step 1. Add a new access-list PNAT-T:

access-list PNAT-T extended permit ip host 172.17.1.3 host 200.200.200.200 

Step 2. Add a new access-list

FW1/act/pri(config)# static (dmz,outside) 200.147.90.83 access-list PNAT-T

INFO: overlap with existing static

  Alphadmz:172.17.1.3 to outside:200.147.90.89 netmask 255.255.255.255

But during testing, it was not working. Lets take a look Cisco NAT Order:

Why? After google online, I found it is because of the order of NAT in ASA.

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_overview.html#wp1079279

"

1. NAT exemption (nat 0 access-list)—In order, until the first match. Identity NAT is not included in this category; it is included in the regular static NAT or regular NAT category. We do not recommend overlapping addresses in NAT exemption statements because unexpected results can occur.

2. Static NAT and Static PAT (regular and policy) (static)—In order, until the first match. Static identity NAT is included in this category.

3. Policy dynamic NAT (nat access-list)—In order, until the first match. Overlapping addresses are allowed.

4. Regular dynamic NAT (nat)—Best match. Regular identity NAT is included in this category. The order of the NAT commands does not matter; the NAT statement that best matches the real address is used. For example, you can create a general statement to translate all addresses (0.0.0.0) on an interface. If you want to translate a subset of your network (10.1.1.1) to a different address, then you can create a statement to translate only 10.1.1.1. When 10.1.1.1 makes a connection, the specific statement for 10.1.1.1 is used because it matches the real address best. We do not recommend using overlapping statements; they use more memory and can slow the performance of the adaptive security appliance.

The tricky part is #2 contains NAT and PAT as well as regular and policy. So there are 4 iterations in that one section. The go in the order they were entered into the config.
"


Last step, adjust the order of NAT, put Policy NAT before regular static NAT. Everything works like a charm!!


Note: To understand Cisco NAT better, the post  "彻底了解CISCO NAT的一些事"  will give more explanation.

Reference:

• 彻底了解CISCO NAT的一些事

Checkpoint Domain Object

Was thinking to use Domain Object as a source in our firewall rule. After consulted with checkpoint support, it seems impossible if your domain object represented multiple ip addresses.

SK42128

Symptoms

    Rules containing a Domain object will only resolve to one of the associated IP addresses, causing request for a site not to return a web page. 

Cause

A Domain object resolves a domain name by the first IP Address that appears when running the nslookup command.

Solution

Use domain objects for domains that, when the nslookup command is used, resolve only to one IP address.

It can not be used with domain names that are resolved to multiple IP addresses.

-----------------------------

Also SK41632 explained a little bit how Domain object works includes following best practice rules:

"Rules of thumb: 

• Avoid using domain objects, if you can.


• Place them as deep in the rulebase, as you can, to maximize the chance that a given packet will hit a rule that uses a network object, before falling to the domain object.


• Construct rules above the domain object, in such a way, as to catch as much traffic, as you can, before falling through to the domain object."

The most important one is put domain object as deep as you can to reduce latency caused by reverse name resolution.

Add static route in Smoothwall

Add static route in Smoothwall

Firstly, edit the file /etc/rc.d/rc.netaddress.up

Above the 'echo "setting up firewall ......."', add:

/sbin route add -net destination netmask subnetmask gw gateway devdeviceinterface

--------------------------------------

Edit /etc/rc.d/rc.firewall.up

After the section on "# Allow packets that we know about through ..."

Add:
# Allow packets from green to green
/sbin/iptables -A FORWARD -i $GREEN_DEV -o $GREEN_DEV -j ACCEPT

SecureXL Vs CoreXL Vs ClusterXL (Some Checkpoint Terms)

From Checkpoint Sites:

"SecureXL: Security acceleration

Patented SecureXL is a technology interface that accelerates multiple, intensive security operations, including operations that are carried out by Check Point's Stateful Inspection firewall. Using SecureXL, the firewall offloads operations to a performance-optimized software or hardware device, dramatically increasing throughput.

More details from this post.

CoreXL: Multicore acceleration
As the first security technology to fully leverage general-purpose multi-core processors, CoreXL introduces advanced core-level load balancing that increases throughput for the deep inspection required to achieve intrusion prevention and high throughput on the firewall. With CoreXL, high performance and high security can be achieved simultaneously.

Efficient Use Multiple CPU Cores—CoreXL

CoreXL is the first security technology to fully leverage general-purpose multi-core processors. It introduces advanced load balancing to boost throughput for the deep inspection required to achieve integrated IPS on the firewall. The increased processing capability in multiple cores allows networks to have high performance as well as a high level of security.

When CoreXL technology is activated, it immediately assigns one or more cores that are performing SecureXL acceleration to also act as directors for traffic. The other cores are designated to run instances of IPS and Firewall on each core. 

For example, if an appliance contains two quad-core processors, two cores will perform SecureXL acceleration and direct traffic to the other six cores that run IPS and Firewall instances. The cores acting as directors have two main functions. First, it makes the initial security decisions whether this traffic can be accelerated by SecureXL. Second, it assigns traffic to a core to handle additional security inspection if needed.

ClusterXL: Smart Load Balancing

ClusterXL provides high availability and load sharing that keeps businesses running without interruption. ClusterXL distributes traffic between clusters of redundant gateways, combining the computing capacity of multiple machines to increase total throughput. In the event of a gateway or network failure, connections are seamlessly redirected to a designated backup, maintaining business continuity.

"

-------

SPLAT Pro - Dynamic Routing support, Multicast support, Radius Authentication for SPLAT Admins.
Cluster XL Load Sharing - Allows Active | Active clustering out of the box. By default SPLAT only allows Active | Passive clustering. Active | Active (load sharing) mode needs a license.
CoreXL - SPLAT does not take advantage of multiple cores unless you add the CoreXL license, which is dependent upon the number of CPU's / cores you are running.
SecureXL - Packet acceleration