Question

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

Answer

The log reference guide contains the following information 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: This log can also be generated for ICMP/ping and not just 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 firewall has closed it is either that the connection has timed out, that the program itself has sent a FIN packet telling the firewall that the connection can be taken down or the connection has never existed at all on the firewall (unusual, but could perhaps occur if the firewall was recently added to the 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 firewall closes the connection due to the idle time-out 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

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

Note: The log format has changed in new versions and will look different but the general content/message is still the same.

Troubleshooting

As a security product, the firewall 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 firewall. Settings such as connection idle time-outs.

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 Stateless rules (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 receiving these messages on my firewalls. After some investigations, I found out that someone had added Stateless rules (also known as FwdFast) in the midst of my Allow rules.
This caused incoming traffic to match the stateless rule, and the returning traffic to hit an Allow rule (stateful).
Because of the stateless rule 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.

Related articles