Why Turning Off Stateful Inspection on Your Check Point Firewall is Bad

Over the past few years of working with Check Point, I have seem some weird and crazy things. One of those crazy (and unsafe) things I have seen is someone turning off Stateful Inspection on their Check Point firewall. I have seen it turned off for TCP packets, UDP packets or even both. One of the main features of the Check Point firewall is Stateful Inspection, so why turn it off?

The reason why people turn it off hasn’t been formally answered yet, but I have a theory as to why. Let’s say you have a program that isn’t working after putting in a new Check Point installation. Then looking at the logs, you see drops for packets that are out of state relating to your application. You look around a bit to see if you can find anything that might be causing it but you can’t seem to find the cause. One way to fix that after some searching around is to turn off Stateful Inspection in the Global Properties, right? …. Wrong! This is the worst thing you can do. You may have “fixed” the problem you were having, but you have now opened yourself up to more problems.

A stateful firewall inspects the packets in a connection to make sure they belong to that connection. With this feature disabled, anyone that can craft a packet can start an unsolicited connection with a protected host and access sensitive material. It will also prevent the state table from filling up by timing out connections that have been open for a certain amount of time with no traffic going through the connection.

Check Point’s Stateful Inspection will also look into the application layers of the packets and maintains information in dynamic state tables for evaluating subsequent connection attempts. One example of this is FTP session data. A client will request that the server generate a back-connection (FTP PORT command) and FW-1 will extract the port number from this request. FW-1 will then keep track of the IP addresses involved as well as these port numbers. Then when the FTP data connection is attempted, it will use the data it has recorded and verify that the attempt is in response to a valid request. Since the list of connections is dynamic, only the required FTP ports are opened for that connection. Once the connection is closed (either by the client/server or a timeout), the ports are closed and the client/server will have to make a new connection for any further transfer.

There are a few common problems that can cause those “out of state” drop messages in the logs that led you to disabling Stateful Inspection in the first place. One of the first things you should look at is if there is any asymmetric routing going on. This is most common in a Cisco environment. Asymmetric routing and Check Point do not get along well. The next thing you can look at is if the connection is timing out. Certain services defined in Check Point’s policy have a connection timeout associated with them. If the connection reaches that specific time with no sort of keep-alive packet received, it will close the connection and drop it for out of state. This is common with persistent SQL connections. When this happens, you can try increasing the timeout property for the specific service in the Dashboard. The proper way to fix it though is to somehow make the application send a keep-alive if possible. Most out of state traffic is caused by software not being made RFC compliant. If a TCP-based application does not perform a proper three-way handshake, Stateful Inspection will ignore the connection.

Hopefully this information is useful to some of you Check Point firewall administrators. This is also helpful to any kind of administrator of a stateful firewall. Stateful inspect while annoying at times, can help keep your network safe and traffic flow optimized for performance. It can also help you identify any problems with your network or the applications that run on it.

Was this article helpful?

Related Articles

1 Comment

  1. netudo

    I almost cried when I read this.

    My network team has been dealing with this almost three months now.

    I tried to explain them about asymmetric routes but they ignored me.

    In our case the asymmetry comes from having a MPLS router in the same subnetwork as the firewall and the Cisco core.

    The firewall is the default gateway. If a packet goes to a network on the other side of the MPLS, it gets routed to the core which also is doing routing. And goes to the MPLS.

    When the packet return from the application it arrives to the core and it’s routed to the client which is on the same subnet. So it gets routed directly bypassing the firewall.

    They ended up turning off packet inspection.

    The setup is exactly as you describe it. Cisco + checkpoint

    I’m tired of being treated disrespectfully.

Leave A Comment?

You must be logged in to post a comment.