Dynamic ports TCP 32768=>65535 drops

[Lin]

Hello,

We're actually facing an issue on our infrastructure.

We have servers communicating through datacenter infrastructure (checkpoint firewalls).

Users faced latency on their applications. We saw the errors " First packet isn't ACK " . So we temporarily disactivate the packet filtering. 

There is no jitter issue on the links. But we can see on the firewalls some connections with the range port TCP 32768=>65535. 

Does someone face this issue or know how to troobleshoot ?

Thanks for your help.

Lina

[_Val_]

"First packet isn't ACK" - this does not any sense. Should be "First packet isn't SYN". Also, you say you disabled packet filtering. Do you mean out of state drops?

[HeikoAnkenbrand]

Normally there are this options why this happens  "First packet isn't SYN" and/or "TCP packet out of state' drop message in log":

A)  Assymetric routing! This message could appear in asymmetric networks, where the packet exit path of the network does not match the network entry path. Once the connection has been removed from the connection table, any packet other than a SYN will be dropped with a TCP packet out of state as this is the first packet needed to establish a new connection. Change your network configuration to resolve the asymmetry in order to fix this problem or follow workaround procedures.
   -> Fix Routing or in exceptional cases define out of state exception.

B)  Session has been expired of the connection table.
  -> Increase age timers for the service object.

C) Connection halt during ClusterXL failover - services that are not synchronized on the cluster
  -> To check and synchronize a service, double click it => Advanced => Sync on cluster.

D)  Aggressive aging kicking in on a highly loaded gateway / cluster
  -> If the memory usage of the gateway exceeds 80%, aggressive aging will also kick in to try and prevent the gateway from reaching 100% memory usage which ultimately crashes / freezes it.

E) The traffic is non TCP RFC compliant.
  -> refer to sk11088

F) Policy install.
  -> To check and keep connections after policy installation, double click the service => select 'Keep connections' or alternatively set the entire cluster to keep or rematch connections after policy install in the cluster object properties under advanced tab => connection persistence.

[the_rock]

I agree with all guys said here...personally, I would say asymmetric routing is definitely something you should check first.