First packet isnt SYN-r80.20

[kobilevi]

hello 

recently we have installed 2 check points 15600 in cluster mode - active/passive

 since we moving the L3 of the vlans the performence of the network very slow - (bandwith is not fully )

i only see in the logs the massage :

CP packet out of state- First packet isn't SYN

TCP Flags -RST-ACK 

and some log showed me :

CP packet out of state- First packet isn't SYN

TCP Flags -FIN-ACK

i see many Documents here but no one linked me to the resolve ...

***

the problem occur in the same source and destnation vlan and diffrent source and destention vlan 

OS build 101
OS kernel version 2.6.18-92cpx86_64
OS edition 64-bi

[Daniel_Schlifka]

Hi,

normally there are three options why this happens.
1. Assymetric Routing. Incoming Packets comes on NIC-A , leaving Packet uses NIC-B. -> Fix Routing or define out of state exception.
2. The Traffic uses side-channel connections (X11 is a good example with an own sk entry). -> Check if there is a defined service object for the traffic and then use that. If it not exists you might want to get in touch with CheckPoint TAC.
3. Connection is a "idler" and has aged out of the connection table. Increase age timers for the service object so that according traffic is kept longer within the conntable. If the service object is used multiple times within the policy you might want to clone the object and use the clone in the specific rule to reduce conntable inflation.

[kobilevi]

Assymetric Routing.- if it happen me in the same vlan it cant be ..
(source 192.168.80.5 - dest : 192.168.80.250)
The Traffic uses side-channel connections- incrasing the session time out in the service its means ?
(in my case i see many services that showed the massge "First packet isn't SYN ")

Connection is a "idler" and has aged out of the connection table - is the same meaning like 2 statemant ?

[Daniel_Schlifka]

No, aging out means a connection doesn't send anything for quite some time and the checkpoint removes the connection from the table.
Sidechannel means the connection peers open a second tcp connection on another port which doesn't use classic tcp threeway handshake to establish. The checkpoint is stateful and expects an initial TCP-SYN for each TCP connection and therefore will consider this new side-connection as a new con for which it never received the proper handshake. It does not know that it belongs to the first connection.  Hence this the connection will be considered as out of state and the firewall will drop it.
So two different stories...

[Daniel_Schlifka]

You could also define out of state exception if it is really a side-channel.(like in option 1)
That should work around it.

[MartinTzvetanov]

Recently I had the following scheme: Side A (L3 switch) HQ (CheckPoint cluster) and Side B (CP device). L3 switch was replaced by a CP device and all the routing functions were move to the new CP device. Communication between Side A and Side B were directly (not passing through HQ) using static routes. This is something I figured out later when saw a lot of Out of states and so on packets and started checking all the surrounding devices and their routes. The problem here was that if the traffic initiates from Side A to Side B it passes through the default gateway (CP in HQ) and it works. If the traffic initiates from Side B to Side A, the traffic passes through a static route pointing to Side A address and the return traffic is passing through the HQ CP and here it comes to the assymetric route. 

In you case please check all the involved devices and their routing tables just to be sure that this is not the case. There are a lot of applications which are poorly written and not following any RFC and CheckPoint doesn't like this kind of traffic. There are some tricks to handle such traffic but make sure this is the case.