Respond to Not a Valid SYN Packet log messages

Logs that contain “Not a Valid SYN Packet” messages indicate that packets were discarded due to connection tracking.

Problem description: The “Not a Valid SYN Packet” message appears in logs with entries on discarded packets.

Reason: “Not a Valid SYN Packet” is a TCP packet that is not the first packet of a TCP connection (the packet does not have the SYN flag set), but is not part of an existing connection either (there is no connection tracking entry on the Firewall matching this packet). The policy would allow this packet if the packet was part of an existing tracked connection.

The message usually also contains a code inside square brackets that indicates the flags set in the discarded packet (A=Ack, F=FIN, R=RST, P=Push, S=SYN).

Some examples of situations, where “Not a Valid SYN packet” messages can be seen:

  • Asymmetric routing, which means that the opening packet does not go through the Firewall, but the reply (the SYN/ACK) does. If so, there is a configuration error in the routing of the surrounding network that must be fixed.
  • Connections that are idle for more than the defined connection timeout (connection has been erased from the Firewall records). This happens from time to time, but if necessary, the timeout can be increased or you can use the TCP Proxy Protocol Agent, which can reset the connection at the host and server when the connection is left idle (if the application in question does not properly close connections).
  • Connections that have been made to look like TCP connections while they are not. If necessary, these connections can be allowed as individual packets without connection tracking.
  • Network scans or attacks that use ACK packets.
  • Heavily loaded server or client that sends a packet after the host at the other end of the connection has already timed out and closed the connection.

It is normal to see some messages like this in the logs. If a certain type of communication that you want to allow is always prevented because of connection tracking, check these troubleshooting steps.

Steps

  1. If there are connections that are left idle for a long time, you can change the idle timeout value for the Access rule that allows that specific traffic. There are also default values that you can set globally for different TCP connection states in the Firewall element’s properties (Advanced settings). This solution does not usually apply to non-TCP connections, so take care that the rule only matches the specific connections involved.
    CAUTION:
    Setting long idle timeouts for a high number of connections considerably increases the resource consumption of the Firewall and can even lead to performance problems. Especially, non-TCP protocols do not include connection closing messages, so such virtual connections are never closed before the timeout is reached.
  2. You might have to disable connection tracking in the rule allowing the connection. We recommend that you deactivate logging in rules that have connection tracking off. These rules create a separate log entry for each packet transmitted, which increases the number of log entries generated. NAT cannot be applied to traffic that is allowed without connection tracking, and both communication directions must be explicitly allowed in the Access rules (replies are not automatically allowed).
  3. For some types of connections, problems can be solved by using a Service that includes a special Protocol Agent for that traffic.