Connection Table

R80.x Performance Tuning – Connection Table

What is a connection kernel table

One of the most important tables in the Check Point firewall is the “connection kernel table”. Connections kernel table contains the specific information about the current connections (source, destination, protocol, timeout, etc etc etc). The direction of the connection is set by the first packet of the connection even though the connection may be bi-directional in reality.

In principle, the following keys are used:

Direction of the connection (0 = inbound, 1 = outbound)
Connection key
Connection type
Connection flags
Rule number in SmartDashboard, to which the connection was matched
An index of an INSPECT handler function that is executed on every packet that belong to the connection
Unique 128-bit connection identifier.
Anti-Spoofing cache
Set of per-connection bits
Connection modules’ kernel buffers
Time to Live / Timeout

The information in the connections table is stored in the following form:

<direction,5-tuple-key;r_ctype,r_cflags,rule,service_id,handler,uuid1,uuid2,uuid3,uuid4,ifncin,ifncout,ifnsin,ifnsout,bits1,bits2,connection_module_kbufs@ttl/timeout>

Detailed explanation about each parameter can you find in the following SK Connections Table Format.

# fw tab -t connections -f -u

It is possible to manually delete an entry from the connection table with the following command.

You can find more about the topic in the following SK “How to manually delete an entry from the Connections Table”. Delete the desired connection entry:

# fw tab -t connections -x -e DIRECTION,SOURCE_IP,SOURCE_PORT,DEST_IP,DEST_PORT,PROTOCOL

Attention!

All subsequent packets of the deleted connection will be dropped as Out-of-State. The connection should be re-established.
This procedure will not remove entries from NAT translation tables.

Intressant are also the installed connection modules. Attention these are often confused with the “fw monitor chain modules”. The modules have nothing to do with each other. These connection modules can be displayed with the following command:

# fw ctl conn -a

Tuning connection table

The goal is always to reduce the number of connections in the connection table. The following tips will give you some examples. First of all you have to see what your connetion table looks like at the moment. Everything else can be found in tip one.

What I don’t want to enter here are different paths through the firewall in conjunction with SecureXL. More informations see here “R80.x Security Gateway Architecture (Logical Packet Flow)“

Fast path (Accelerated Path)
Medium path (PXL)
Slow path (F2F)

Tip 1

From my point of view all systems should be set maximum concurrent connections to “automatically” (see picture).

Alternatively, you can toggle it to manually here. I wouldn’t advise it, though. In most cases this is also set as default by older versions. If you use this, then please use it described below.

This command shows the current and maximum number of connections.

# fw tab -t connections -s

This command shows the maximum number of possible connections:

# fw tab -t connections | grep limit | grep -v Kernel | grep -v connections | grep -oP ‘(?<=limit ).*’

In this example there are 23876 peek concurrent connections and 14056 concurrent connections while the default limit is 25000. The connection table limit should be increased to ensure uninterrupted operation. However, it should be noted here that the increase also uses resources (RAM). I would carefully double the connection limit in this case to 50000. Locate the maximum concurrent connections setting for the firewall (normally found in the object’s properties) and increase the value. The increase should be done gradually and with care as it will also increase the memory usage of the firewall.

Attention! This changes the behavior of the firewall. Therefore please handle with caution.

TIP 2

Packets are dropped on security gateway because maximal number of symbolic links for connections was reached in connection table. What is the consequence! Very low traffic on the security gateway. How do I analyze the problem? The output of ‘fw tab -t connections -s’ command shows that the ratio of #SLINKS / #VALS is greater than/equal to 5. What can I do? Follow sk65463

TIP 3

Turn on Aggressive Aging to have connections removed as quick as possible.

Aggressive aging is activated in IPS profile, or new connections may be dropped for the reason that the connections table is full when a given CoreXL firewall instance has far fewer connection entries than the connections table limit, or the 80% threshold to activate aggressive aging as seen in the output of ‘fw ctl multik stat’ command.

The aggressive aging timeout values must be lower than the stateful inspection default for TCP session timeout (3600). The stateful inspection default session timeout values can befound in: Global Properties > Stateful Inspection > TCP session timeout

Check Aggressive Aging status:

:# fw ctl pstat | grep Agg

TIP 4

When you decrease the start timeout and end timeout, the connections will removed as quick as possible if the connection is no longer used.

In the SmartDashboard go to „Policy->Global Properties“ and in the Stateful Inspection tab reduce the the following session timer (see picture):

TCP start timeout
TCP end timeout
UDP virtual session timeout
ICMP virtual session timeout
SCTP start timeout
SCTP end timeout
other IP protocols virtual session timeout

Please refer to the firewall’s user manual for more information on what the session timeout is.

Attention! This changes the behavior of the firewall. Therefore please handle with caution.

With the following command you can find the number of active sessions for „TCP start timeout“ in the connections table. If you change the value in “grep” you can also show other session timeouts!

# fw tab -t connections -u -f | grep “Expires:” |grep “/25;” |wc -l

Note: A high number of „TCP start timeout“ could also indicate a DDoS SYN flood attack. In the area of Distributed Denial of Service (DDoS), TCP SYN flooding was one of the first attack vectors that was encountered and it has remained significant even now. The TCP handshake process, which starts with a TCP [SYN] packet, requires that a server allocate a transmission control block (TCB) for incomplete and half-open connections. More see here “Best Practices – DDoS attacks on Check Point Security Gateway”.

TIP 5

Under R80.20 there is a new command that in conjunction with the “Dynamic Dispatcher” displays connections with a high load. That’s where I mention that CLI command here although it doesn’t quite match the theme. This command shows the table with heavy connections (that consume the most CPU resources) in the CoreXL Dynamic Dispatcher. For more information about the CoreXL Dynamic Dispatcher, see sk105261.

CoreXL suspects that a connection is “heavy” if it meets these conditions:

Security Gateway detected the suspected connection during the last 24 hours
The suspected connection lasts more than 10 seconds
CoreXL FW instance that processes this connection causes a CPU load of over 60%
The suspected connection utilizes more than 50% of the total work the applicable CoreXL FW instance does

Here is an example:

# fw ctl multik print_heavy_conn

TIP 6

An important point in tuning is the order of the rules. Normally the “rule counter” helps here. Rules that are often used should be at the beginning of the ruleset.

It can also be helpful to view certain connections in real time. For this I have published some useful commands here. The commands are for version R80.20.

1) Find all rules to an IP address in the connections table (Change the IP):

# fw tab -t connections -u -f | grep 10.1.2.81 | grep Rule | awk ‘{split($0,a,”;”); print a[14];}’ |sort -ng |uniq

2) Find all rules to an IP address in the connections table with IP and Port informations (Change the IP):

# fw tab -t connections -u -f | grep 10.1.2.81 | grep Rule | awk ‘{split($0,a,”;”); print a[14],” “,a[10],” “,a[6],” “,a[8],” “,a[9];}’ |sort -ng

TIP 7

Another important point is the session timeout for a service. For example, the default session timeout for UDP is set to 40 seconds (TCP to 3600 seconds). This means, for example, that each DNS request is kept open for a maximum of 40 seconds after the last package. That’s a bit much from my point of view! Therefore it is possible to change the virtuall session timeouts in the service. I always test here with about 20 seconds (see picture) and adjust it a little bit upwards or downwards. So the DNS requests do not remain so long in the connetion table. This can also be applied to other services.

References

Connections Table Format
How to manually delete an entry from the Connections Table
Packets are dropped on Security Gateway because maximal number of Symbolic Links for connections was reached in Connecti…
Best Practices – DDoS attacks on Check Point Security Gateway
How Connections Table limit capacity behaves in CoreXL
Performance Tuning R80.10 Administratio Guide
Performance Tuning R80.20 Administration Guide
Best Practices – Security Gateway Performance