Configuring connection tracking

Connection tracking means that the engine keeps a record of all currently open connections (stateful inspection).

With connection tracking, the engine can verify that the connection proceeds according to the protocol standards. Connection tracking is also required for changing addresses using NAT and enforcing some other connection-related settings. By default, connection tracking is on.

However, it is not necessary to track the state of certain kinds of connections (for example, SNMP traps). Some applications can also communicate in a non-standard way that prevents them from being allowed through the engine when connection tracking is used. For those connections, you can disable connection tracking in the Access rules, which allows the engine to function as a simple packet filter for those connections. However, disabling connection tracking also prevents the use of some features that require connection tracking.

When connection tracking is off, each packet that you want to allow must match an Access rule that allows the packet. This means that even if two-way communications are always opened one way, both directions of communication must be explicitly allowed in Access rules. Reply packets are not recognized, so they are not automatically allowed through. If done carelessly, turning off connection tracking reduces the benefits you gain from your engine and might even weaken security. You might have other options: sometimes using the correct Protocol Agent helps.

Note: Before disabling connection tracking, always check if there is a Protocol Agent for the protocol in question. The Protocol Agents can pass connections that require special handling when connection tracking is on, which is always a more secure option.

When connection tracking is enabled in an Access rule, the Service cell of the rule must contain one of the protocols supported for connection tracking (ICMP, TCP, UDP, or another protocol that belongs to the IP protocol suite). ICMP and UDP are stateless protocols that do not contain any connection data. However, ICMP and UDP packets contain data that the engine can use to build virtual connections. The engine can also build virtual connections based on the IP address and IP protocol data in other types of IP packets.

You can choose between several connection tracking modes, depending on the traffic type and how strictly you want the connections to be tracked. The effect of the connection tracking setting in the Access rules depends on the traffic type.

If Connection Tracking is on, you can also set the Idle Timeout for connections. The timeout is meant for clearing the engine’s records of old connections that the communicating hosts leave hanging. The timeout concerns only idle connections, so connections are not cut because of timeouts while the hosts are still communicating. The timeout defined for an Access rule overrides the default idle timeout value that is set for the protocol in the engine’s properties.

CAUTION:

Setting excessively long timeouts for many connections can consume engine resources and degrade engine performance and stability. Be especially careful when defining timeouts for ICMP and UDP. The ICMP and UDP virtual connections do not have closing packets. The engine keeps the records for the ICMP and UDP connections until the end of the timeout.

Connection Tracking options in Access rules also allow you to override the limit for connections from a single source or destination IP address defined in the Traffic Handling settings for NGFW Engines and in the properties of some interface types. When the set number of connections is reached, the engine blocks the next connection attempts until a previously open connection is closed.

Changes in the Connection Tracking mode affect how existing connections are handled when you install or refresh the policy. When you install or refresh the policy on an engine, the engine checks if the existing connections are still allowed in the policy. If the connection tracking mode changes from Loose to Strict, existing virtual ICMP connections are only allowed if they began with a valid packet (for example, not with a response packet). In addition, if the mode changes from Normal to Strict, existing TCP connections are only allowed if all packets in the connection have been seen. In all other cases, changes in connection tracking mode do not affect existing ICMP, TCP, and UDP connections at policy installation.