[FW-1] Non-SYN problems with NG FP2 / Will CP support for Non-SYN in the future?

["Palmer, Kevin" <KPalmer@FW1-NOSPAMGSITE.COM>]

Hello,

 

I desperately need help configuring Check Point to work in asymmetric routing environments. I have followed the non-SYN KB article without success. The firewall logs packets as being accepted and then drops the packets.

 

Has anyone been able to get this working in any version of Check Point NG?

 

Does anyone else agree that Check Point should allow non-SYN packets by default? What about including a simple check box in global properties instead of objects_5_0.c? This is a big deal for a number of potential customers deciding between Check Point and PIX. Since Cisco PIX is not affected by this issue, PIX has the advantage.

 

Please advise.

 

 

Solution

What to do when receiving errors in Log Viewer: "th_flags ## message_info TCP packet out of state"
Solution ID: skI4308 Creation Date: 08/16/2001 Revised Date: 11/30/2001
Environment: Check Point NG, FireWall-1 NG, VPN-1 NG, Rule 0, Non SYN packet, Connections table, Kernel, TCP, Logging
Symptoms: Error in Log Viewer: "th_flags ## message_info TCP packet out of state"Drop logs on rule 0
Cause: This error means that VPN-1/FireWall-1 intercepted a non-Syn packet which does not have an entry in the FireWall's connections table. FireWall-1 will therefore drop the packet. This error is the equivalent to the VPN-1/FireWall-1 4.1 error message: "Unknown established TCP packet". In VPN-1/FireWall-1 NG the mechanism has been improved and the log may show more drops on rule 0 than were seen in FireWall-1 4.1. The error can be the result of several possible causes: 1. Dropping packets belonging to expired connections. Increasing the timeout of the related service can improve the situation. 2. Dropping packets after policy unload and load. In this case connections established when there is no policy are out of state, and cannot be matched to packets of already established connections. 3. Situations involving asymmetric routing, where all the TCP handshake packets were missed. 4. Direction enforcement for unidirectional connections, where packet flow is in the opposite direction to the connection direction. 5. TCP handshake direction enforcement, where some of the TCP handshake packets are in the wrong direction.
Solution: To allow non-Syn packets which do not have state information in the connections table to be matched against the Rule Base: On FireWall-1 NG FP1 and above ======================== Using dbedit, edit the following property to "1" in the objects_5_0.C: :fw_allow_out_of_state_tcp (0)

Kevin Palmer
Network Engineer - MCSE+I, CCSE, CCNA