NAT Templates - SecureXL

[Don_Paterson]

Is it recommended to turn NAT Templates on?

Why is it not on by default?

[Expert@GW:0]# fwaccel stat
Accelerator Status : on
Accept Templates : enabled
Drop Templates : disabled
NAT Templates : enabled
NMR Templates : enabled
NMT Templates : enabled

[Timothy_Hall]

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 SecureXL
randomly disabling itself (Edit: NAT Templates are enabled by default starting in R80.30 regardless of kernel version).

sk113398: Dynamic Dispatcher 'instance mismatch' drops on ports 80 and 443

sk100467: "Accelerator Status : off by Firewall (too many general errors (N) (caller: ...))" in the output of "fwaccel stat" command

sk106709 - SecureXL instability when SecureXL NAT Templates are enabled and Hide NAT is configured on VSX

sk111015 - Traffic outage on ClusterXL after enabling both CoreXL Dynamic Dispatcher and SecureXL NAT Templates

sk117332 - Cluster member with enabled SecureXL crashes during policy installation due to issues in SecureXL NAT Templates

[Don_Paterson]

Thanks Tim.

I am hoping for an internal response (from Tel Aviv).

Why is this not available in the SmartConsole? Optimized drop is.

The cli output message could perhaps be changed from saying disabled by user to something else, for example 'disabled', like the rest of the disabled-by-default options.

Regards,

Don

[PhoneBoy]

Tim's answer is pretty accurate, though.

Enabling SecureXL Templates for NAT is not something that can be done on the fly currently.

As a result, having a GUI option to do it doesn't make as much sense.

[Don_Paterson]

Thanks Dameon,

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.

Regards,

Don

[PhoneBoy]

Some of the problems that CAN occur are listed in the SK's that Tim mentioned.

The only reasons I would see to enable SecureXL NAT Templates are you're running firewall only and you need to achieve a high session establishment rate with NAT.

(IPS uses PXL/Medium Path)

Otherwise, best to leave it off as is the default.

[Timothy_Hall]

What Dameon Welch Abernathy‌ said.

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. 

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Don_Paterson]

Thanks very much both!

Regards,

Don

[HeikoAnkenbrand]

Here you can find a flowchart of how NAT is implemented:

R80.x Security Gateway Architecture (Logical Packet Flow) 

Regards,

Heiko

[Jaisingh_rathor]

Hi Tim,

Thanks for the explanation.

I am still confused about what templates are and how traffic is being accelerated.

Please help

[Don_Paterson · Accepted solution]

Hi Jaisingh,

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).

Look here for the official explanation:

https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_NextGenSecurityGateway_Guide...

Snippet:

"About SecureXL

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) 

Don

[Jaisingh_rathor]

Good info Sir, Appreciate your response 😊

[Martin_Raska]

Why NAT templates are enabled by default in R80.20 GA?

[_Val_]

By design 🙂

[Don_Paterson]

Care to elaborate? 

Asking because there is a another thread I started on this (with Tim and Dameon contributing).

[Don_Paterson]

Hang on! It's this thread! 🙂

Good question Martin. Lets see how they respond... 😉

[_Val_]

In brief, NAT templates require lots of memory to work with, so before R80.20 they were disabled by default, as SecureXL could only use part of kernel memory.

With R80.20, SecureXL is completely re-done, and some of the magic happens in User Mode now, where memory is plenty. Hence there is no need to disable NAT templates by default anymore.

This is my take on it, but I will ask someone from R&D to comment as well

[Don_Paterson]

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.

Otherwise all is good... 😉

Thanks,

Don

[PhoneBoy]

We plan to support the newer kernel in the gateway in the coming weeks.

I believe we are still looking for EA candidates if you're interested

You only get xfs on R80.20 if you do a fresh install as it requires a complete reformat of the drive.

You don't get xfs if you do an in-place upgrade to R80.20.

[Don_Paterson]

Thanks Dameon. From what I see even a fresh install has xfs and ext3 on different partitions.

Will advertise where possible for EA candidates. 🙂 

OEM/open server customers are likely to be more interested I guess.

[PhoneBoy]

Now of course the new version of R80.20 with the new kernel is released

Not all the possible Open Servers are supported yet, but you can give it a try: https://community.checkpoint.com/community/infinity-general/appliances-and-gaia/blog/2018/12/06/r802...‌

[Don_Paterson]

Thank you for the prompt update 😄

Will have a play and dissendissethid information further. 

[Don_Paterson]

I invented a new word there (dissendissethid). 😁

Maybe I wanted to say 'digest and test this'.

So, logic dictates that dissendissethid means digest and test but how does one actually pronounce the word, (and does it go on the fast path)?

🙄

[Judd_Miller · Accepted solution]

😀