Re: NAT Templates - SecureXL

Templates are used for acceleration purposes and are applied in the lowest possible layer (in the TCP/IP stack), on the interfaces (think about Layer 2).

Acceleration means that packets can move from the ingress port to the egress port and leave the firewall with as little as possible resource utilisation or software processing (rule matching or analysis for routing decisions). The packets are then on the Fast Path.

Templates are records of allow (accept), block or NAT decisions that the firewall has made and the template entry/record is created when a connection attempt is made (when a client tries to connect through the firewall to the server (C2S)) and a rule was matched because of the connection attempt.

For example if a client connects through the firewall to a web server.

The SYN packet that the client sends to the server is processed by the firewall and is allowed by a rule (that process sends the SYN packet on the Slow Path/Firewall Path which is slower and more resource intensive (the routing decision is also made after the FW decision process (the slow path)) .

The Connections table is updated with the record of the C2S and S2C (IPs and Ports, protocols and directions). The Templates are then updated (all but the client source port are recorded in the accept template).

The template entry (record) is made in order to apply acceleration for future new connections between the client and the server and is dependent on the initial C2S connection.

So, continuing with that example, if the client has an established connection to the web server and then the client makes a brand new connection to the web server (the only difference is the new source port) then the firewall can accelerate the first packet (the SYN packet) without having to send it on the Slow Path, and of course the rest of the packets between C&S are accelerated for the new connection.

In other words:

If the rule that was matched had the Accept action then the template records the C2S and S2C (for the responses from the server) in a similar way to the connections table records the connections state/details (for allowed (and therefor established) connections).

SecureXL is an acceleration solution that maximizes performance of the Firewall and does not compromise security. When SecureXL is enabled on a gateway, some CPU intensive operations are processed by virtualized software instead of the Firewall kernel. The Firewall can inspect and process connections more efficiently and accelerate throughput and connection rates. These are the SecureXL traffic flows:

Accelerated path- Packets and connections that are processed immediately by SecureXL and are not processed by the Firewall.

Medium path- Packets that require deeper inspection. It is not necessary for the Firewall to inspect these packets, they can be offloaded and do not use the slow path. For example, packets that are inspected by IPS cannot use the accelerated path and can be offloaded to the IPS PSL (Passive Streaming Library). SecureXL processes these packets more quickly than packets on the slow path.

Slow path- Packets and connections that are inspected by the Firewall Rule Base, and are not processed by SecureXL.

The goal of a SecureXL configuration is to minimize the connections that are processed on the slow path.

Throughput Acceleration"

Also see the attached PDF (if it is uploaded and attached successfully)

Re: NAT Templates - SecureXL

NAT Templates can keep the first packet of a new connection from having to be evaluated in the Firewall Path (F2F) for finding a NAT policy rule match (Edit: R80.10 and earlier - in R80.20+ the first packet of a new connection always goes F2F). Can be most advantageous when a large percentage of traffic can be both templated by SecureXL and fully handled in the Accelerated Path. However this situation is not likely these days since the most commonly-used blades (i.e. APCL, URLF, Threat Prevention) will cause the majority of traffic to be handled in the Medium Path (PXL), and also the SecureXL templating rate will drop to zero if Anti-bot is enabled or a blade other than "Firewall" is enabled in the first Access Control layer of a policy package. Quoted from (Edit: the second edition of) my book:

However unless at least 50% of connections are able to be templated (Accelerated conns/Total conns) AND at least 50% of traffic is being handled in the Accelerated Path (Accelerated pkts/Total pkts) as shown by fwaccel stats -s, there is little to gain by enabling NAT Templates and potentially a lot to lose. NAT Templates can only be enabled and disabled via the fwkern.conf file and a firewall reboot, so if problems start to occur after enabling NAT Templates an outage will be required to turn them back off unless you have a firewall cluster. Enabling NAT Templates also seems to increase the likelihood of problems with other parts of the firewall, including SecureXLrandomly disabling itself (Edit: NAT Templates are enabled by default starting in R80.30 regardless of kernel version).

Re: NAT Templates - SecureXL

It still doesn't make sense to me. Statements like "if problems occur...". What problems?

I still unfortunately see the majority of customer not using much more than the IPS blade, and even that it not that frequently used. Maybe it is a UK thing or the types of customers I am exposed to.

Would still like to know if this is something that FW only customers might be recommended to be using by default (turned on), especially if it is the NAT FW, or if it is a feature that will otherwise possibly be removed, which makes sense if it is something to be weary of, as seems to be the message here.

Just trying to get answers here to be able to answer the questions in the field.

Re: NAT Templates - SecureXL

To provide some further insight, NAT templates are still off by default in R80.20 EA (always possibly subject to change for GA of course):

I'm assuming some kind of risk/reward analysis took place inside Check Point when deciding whether NAT templates would be enabled by default. If there were substantial performance gains available, low perceived risk, or both present NAT templates would be enabled by default.

NAT has its own caching mechanism (fwx_cache) in the Firewall Path to help avoid excessive NAT rulebase lookup overhead. In addition SecureXL Accept (connection) templates are not nearly as important as they used to be due to the new Column-based matching mechanism, and also because enabling certain features and policy layer configurations instantly drops the SecureXL templating rate to zero. In my opinion I'd lump NAT templates with Accept templates in this case as "not nearly as important as they used to be", at least on an R80.10+ gateway.

Re: NAT Templates - SecureXL

Templates are used for acceleration purposes and are applied in the lowest possible layer (in the TCP/IP stack), on the interfaces (think about Layer 2).

Acceleration means that packets can move from the ingress port to the egress port and leave the firewall with as little as possible resource utilisation or software processing (rule matching or analysis for routing decisions). The packets are then on the Fast Path.

Templates are records of allow (accept), block or NAT decisions that the firewall has made and the template entry/record is created when a connection attempt is made (when a client tries to connect through the firewall to the server (C2S)) and a rule was matched because of the connection attempt.

For example if a client connects through the firewall to a web server.

The SYN packet that the client sends to the server is processed by the firewall and is allowed by a rule (that process sends the SYN packet on the Slow Path/Firewall Path which is slower and more resource intensive (the routing decision is also made after the FW decision process (the slow path)) .

The Connections table is updated with the record of the C2S and S2C (IPs and Ports, protocols and directions). The Templates are then updated (all but the client source port are recorded in the accept template).

The template entry (record) is made in order to apply acceleration for future new connections between the client and the server and is dependent on the initial C2S connection.

So, continuing with that example, if the client has an established connection to the web server and then the client makes a brand new connection to the web server (the only difference is the new source port) then the firewall can accelerate the first packet (the SYN packet) without having to send it on the Slow Path, and of course the rest of the packets between C&S are accelerated for the new connection.

In other words:

If the rule that was matched had the Accept action then the template records the C2S and S2C (for the responses from the server) in a similar way to the connections table records the connections state/details (for allowed (and therefor established) connections).

SecureXL is an acceleration solution that maximizes performance of the Firewall and does not compromise security. When SecureXL is enabled on a gateway, some CPU intensive operations are processed by virtualized software instead of the Firewall kernel. The Firewall can inspect and process connections more efficiently and accelerate throughput and connection rates. These are the SecureXL traffic flows:

Accelerated path- Packets and connections that are processed immediately by SecureXL and are not processed by the Firewall.

Medium path- Packets that require deeper inspection. It is not necessary for the Firewall to inspect these packets, they can be offloaded and do not use the slow path. For example, packets that are inspected by IPS cannot use the accelerated path and can be offloaded to the IPS PSL (Passive Streaming Library). SecureXL processes these packets more quickly than packets on the slow path.

Slow path- Packets and connections that are inspected by the Firewall Rule Base, and are not processed by SecureXL.

The goal of a SecureXL configuration is to minimize the connections that are processed on the slow path.

Throughput Acceleration"

Also see the attached PDF (if it is uploaded and attached successfully)

Re: NAT Templates - SecureXL

Thank you sir. While we have your attention 🙂 please can you clarify the Linux Kernel version in R80.20?

I seem to have 3.10.0693cpx86_64 in my new build MDS and the old 2.6.18-92cpx86_64 in a new build gateway (VSX in my case). What's the plan and how is this going to affect (if at all) new open server technology (or maybe not so new anymore).

Had some fun with the new xfs (on the log partition only) and ext3 partitions when resizing an R80.20 server (for more space in /opt). Have already fed back on the relevant SKs (they need more details since the R80.20 deployment uses a mix of the two (xfs and ext2)) and hopefully they will be clarified.