LogOpenFails and no_new_conn_for_this_packet log events.

Frequently Asked Questions
Post Reply
Posts: 696
Joined: 10 Apr 2008, 14:14
Location: Clavister HQ - Örnsköldsvik

LogOpenFails and no_new_conn_for_this_packet log events.

Post by Peter » 24 Aug 2012, 12:08

This FAQ applies to:
  • Clavister CorePlus / cOS Core all versions

My logs contain many events regarding "LogOpenFails" and "no_new_conn_for_this_packet", what does this mean?


The log reference guide has the following to say about this particular message:
Can not open a new connection for this TCP packet since the combination of TCP flags is wrong. Only packets with the SYN TCP-flag set as the only TCP flag are allowed to open a new TCP connection.
Note: It can also be ICMP instead of TCP.

So what does this mean?

Simply put it means that a program or otherwise is trying to send data in a connection that the SGW has closed or has never existed. The reason why the SGW has closed it is either that the connection has timed out, that the program itself has sent a FIN packet telling the SGW that the connection can be taken down or the connection has never existed at all on the SGW (unusual, but could perhaps occur if the SGW was recently added in a network).

This is a fairly common log message when dealing with HTTP traffic. Many browsers open a large amount of connections and then fails (or perhaps ignores) to close them properly, or simply try to re-use connections it believes it has open. In the end it usually means that a program is behaving "badly".

Another example would be if an application idles for a very long time (3+ days) so that the SGW closes the connection due to the idle timeout value. If the application then at a later stage tries to use the connection it believe to be open, the SGW will drop the packet due to "No_new_conn_for_this_packet".

Log Message Examples:
2012-08-24 12:09:26 Warning CONN 600012 LogOpenFails TCP ge6 80 50771 no_new_conn_for_this_packet reject protocol=tcp pdatalen=20 ack=1 fin=1
2012-08-24 12:09:48 Warning CONN 600013 LogOpenFails ICMP ge6 80 no_new_conn_for_this_packet drop protocol=icmp pdatalen=141 icmptype=DEST_UNREACH unreach=HOST_UNREACH

As a security product, the SGW monitors traffic for irregular behavior and if such a behavior is detected, the irregular behavior is either taken care of (if possible) or the connection attempt terminated. In this case it is terminated as it is an incorrect behavior based on the settings specified in the SGW. Settings such as connection idle timeouts.

If an application is having trouble to function properly and this log message is the most likely suspect of that problem, an exception can be made in the rules to allow the incorrect packet flow. Basically this means that you need to use Stateless rules such as FwdFast in order to allow the communication between the client and the server. As Stateless rules does not care about the ordering of packets or which state they arrive in.

For information about Stateless rules (FwdFast) please see the following How-To.

The problem may also be related to timeouts of connections being formed. If a connection has not fully established after the 3 way handshake it may be necessary to increase the "Initial Timeout" of connections being formed (default value is 60 seconds). This can be done at two locations:
  • System->Advanced Settings->Conn Timeout Settings->TCP SYN Idle LifeTime.
    Objects->Services->YourService->Custom Timeouts->Initial Timeout.
It is highly recommended to use Custom Timeouts on the service that has the problem. The reason for this is because the Advanced setting causes a change globally, and that is not always something that you want to do for all traffic. The value to increase it to may vary depending on the behavior of the problematic application, but 240 seconds is good value to start testing with.

Note: Observant users may have noticed that there exists a setting called TCP_Allow_Reopen. Unfortunately that setting will not help in this scenario as the connection has already been closed by the SGW when if/when you see these log events. Log events containing "LogStateViolation" may be solved by enabling this setting though.

Additional example of when this can occur:
I was hitting these msg on my fwalls. After some investigations, I found someone added FwdFast rules in the midst of my Allow rules.
This caused incoming traffic to match the FwdFast rule, and returning traffic to hit an Allow rule.

Because of the FwdFast the state table was not populated and the returning allow rule would not pass the syn+ack
Thanks to Pieter Lambrecht for providing us with this example:

Post Reply