Packet drops due to TCP Sequence numbers ("tcp_seqno_too_high" or "tcp_seqno_too_low")

Last modified on 6 Jul, 2021. Revision 11
The reasons for incoming packet drops due to anomalous TCP Sequence numbers (causing either the log message "tcp_seqno_too_high" or "tcp_seqno_too_low"). This article is applicable to both NetWall (cOS Core) and NetShield (cOS Stream). The log message examples are taken from cOS Core.
Up to date for
cOS Core 13.00.10
Supported since
cOS Core 10.xx
cOS Stream any version
Status OK
Author
Peter Nilsson

Question:

I am seeing that the firewall drops packets and generates the log message “tcp_seqno_too_high” or “tcp_seqno_too_low”. What is the cause of this?

Answer:

Problems related to TCPSequence numbers can be fairly easily determined by looking at the log messages generated by the firewall. The log message will, in normal cases, also contain the sequence number “window” that is allowed.

Each packet has its own sequence number and this can be used to track the order of when packets arrive at a firewall interface. The firewall will look for irregularities in consecutive sequence numbers and will drop packets if it detects anomalous behavior.

Drops due to  the TCP sequence number being too high

An example of such anomalous behavior would be if we have packets sequences looking like this:

Packet Sequence 500
Packet Sequence 501
Packet Sequence 502
Packet Sequence 69818747

It would be very strange that the last packet sequence was so different from the previous one. The acceptable range can be found in the log message. The previous example would generate a TCP SequenceToHigh log message and the packet would be dropped by the firewall.


Here is a cOS Core log message example:

TCP_FLAG: id=03300019 event=tcp_seqno_too_high action=drop seqno=557601248 accstart=552014597 accend=552014599 rule=TCPSequenceNumbers connipproto=TCP connrecvif=G3 connsrcip=192.168.101.132 connsrcport=59292 conndestif=G6 conndestip=55.55.55.55 conndestport=443 origsent=304 termsent=0 recvif=G3 srcip=192.168.101.132 destip=55.55.55.55 ipproto=TCP ipdatalen=28 srcport=59292 destport=443 tcphdrlen=28 syn=1

In the above example, the firewall is accepting that the next packet is in the range 552014597 to 552014599. The system will therefore only accept a number difference of 2. But the client or server is sending a sequence number that is more than 5.5 million higher than the previous packet, so the firewall finds this suspicious and drops the packet.

Drops due to  the TCP sequence number being too low

An example on when you can get the TCPSequencetooLow would be if you have a packet sequence numbering order that looks like this:

Packet Sequence 500
Packet Sequence 501
Packet Sequence 502
Packet Sequence 499

The last packet in the above has a lower number than the expected and it could be an indicator of a problem or that packets are arriving in the wrong order.

Log message example:

TCP_FLAG: id=03300016 rev=2 event=tcp_seqno_too_low action=drop seqno=3547934071 accstart=3547938065 accend=3548002305 rule=TCPSequenceNumbers connipproto=TCP connrecvif=if2 connsrcip=55.55.55.55 connsrcport=37395 conndestif=VLAN500 conndestip=77.77.77.77 conndestport=443 origsent=268665712 termsent=2302311781 recvif=if2 srcip=55.55.55.55 destip=77.77.77.77 ipproto=TCP ipdatalen=1480 srcport=37395 destport=443 ack=1 psh=

Similar to the “too_high” log message, the problem here is the opposite. The firewall accepts a sequence number in the range of 3547938065 to 3548002305 (a total of 64 240) while the packet received was 3994 numbers below the acceptable start range. The firewall finds this suspicious and drops the packet.

Troubleshooting approaches

Here are some approaches to troubleshooting a sequence number problem:

1. Try to examine the problematic hosts. Are they either doing something strange or are they going through some special router/switch that modifies the sequence numbers+ Try to see if if you can narrow down what it is that is generating this strange behavior. Could it be due to problematic software? Network latency? An issue in the operating system? Incorrectly configured router? Incorrectly configured load balancer?


2. If the problematic hosts are both trusted internal hosts, you can configure/use Stateless (also known as “Forward Fast”) IP rule set entries for the communication between them. Such rules are not state tracked so the firewall does not care if the sequence number is in the wrong order.


3. Disable the TCPSequence check altogether. In the cOS Core WebUI, this option can be found under: Advanced Settings > TCP > TCPSequenceNumbers


Caution: Changing this setting means that you are disabling sequence checking for the entire firewall.



Related articles

No related articles found.