Packet info: len 74 port 30 interface 30 vsys 1 The below pan_packet_diag logs explain how the TCP reassebly failures caused the packet drops >debug dataplane packet-diag show setting
> debug dataplane packet-diag set log feature tcp
The reason for the failure in TCP reassembly can be understood by enabling "tcp reass", along with the regular filters, captures and flow basic. Tcp_drop_packet 2 0 warn tcp pktproc packets dropped because of failure in tcp reassembly The firewall receives these SYN-ACKs and drops them with the below counter: Ideally a change in seq# in the Syn-Ack will not matter to the client, because the client doesnt know of the seq# yet of the server ( Client's Syn packet has an ack# 0 ).Īs shown in the snapshots, the server retransmits SYN-ACKs with the below IP and TCP values:
This doesnt mean that the packet is malformed.Īfter the first 4 failed attempts, the Server continues to retransmits the SYN-ACKs, but now on a different sequence#. It is expected to see Ip.Id 0 for SYN-ACKs. Similar to SYN, the SYN-ACKs too have the same source IP, destination IP, source port, destination port, seq# and Ack#. The server receives all these SYNs and responds back to all these SYNs with their SYN-ACKs. S IP: 192.16.31.62, D IP: 172.22.136.50, Ip.id 0, src port 80, dest port 44912, Seq# 743112262, Ack# 2033466734īecause the client never received the SYN-ACK, it retries 4 more times on the same source IP, destination IP, source port, destination port, seq# and Ack# before eventually giving up, and then attempting to connect again on a new port number. The SYN-ACK when received on the firewall have the below IP and TCP values: The second snapshot shows SYN-ACKs from the server to the client, again on the receive, transmit, firewall and the drop stages of the firewall.Ī) The client first attempts to connect to the server with a SYN packet with the below IP and TCP values: The first snapshot shows SYNs from the client to the server, on the receive, firewall, transmit and the drop stages ( although drop stage has no packets ) of the firewall. The SYN-ACK never makes it to the client from the firewall, and hence the client retries to connect 4 more times on the same port number, before attempting to make a connection on a new port number. The firewall receives the SYN-ACK, de-nats it and transmits the packet back to the client. The server receives the SYN and responds with a SYN-ACK. The firewall receives the SYN, performs NAT and transmits the SYN. The firewall is configured with dynamic address and port translation, because of which the SYN on the receive and the transmit stage show different IP and port numbers, although the IP ID remains the same. Here is a case study where, a client, 172.22.136.50 attempts to connect to a server 192.16.31.62 on destination port 80. This document discusses one common scenario while troubleshooting TCP reassembly packet drops
0 kommentar(er)
