Could enabling Wildfire possibly cause TCP Transmission errors?

[tstores]

Having Intermittent failures when downloading files on 4.1.11 with Wildfire enabled. I am seeing the following errors in the packet capture, [TCP Previous segment lost] [TCP segment of a reassembled PDU],  [TCP Out-of-order] [TCP segment of a reassembled PDU],  [TCP Dup ACK 170#1]. When downloading files on a different PAN, with 4.1.7, no wildfire enabled, there are no issues.

[Phoenix]

I would not general see an issue with wildfire enabled having the tcp packet errors. Are the Tcp packet errors seen from the management interface on pan firewall to the wildfire cloud servers ?

Or were these errors seen for data traffic passing through the Untrust interface.

[kprakash]

TCP Previous segment lost] [TCP segment of a reassembled PDU],  [TCP Out-of-order] [TCP segment of a a reassembled PDU],  [TCP Dup ACK 170#1, 

This is what I got from wireshark wiki:

The hint "TCP segment of a reassembled PDU" indicates that the workstation is sending a large message to the server. In fact the message is so large that it is split over several frames. As soon as Wireshark sees the last frame it pieces the segments together and decodes the whole message

I usually see these messages when there is a latency for the TCP traffic. And in order to determine the file that is being downloaded, and take necessary action, its always recommended to have SSL decryption enabled ( without SSL decryption, the PANFW skips the file check for its encrypted ). SSL decryption introduces a relative delay becuase the firewall has to decrypt the traffic, match the traffic against the signatures and encrypt it back. So I would expect this to be a normal behavior, if SSL decryption is enabled.

In addition, with wildfire in action, the firewall looks up at  the first few packets of the file, and then calculates the hash, and then looks up for the hash matching that of any threat. This also causes a small delay, relative to the other firewall where wildfire is not configured.

So the client and the server are expecting a steady TCP flow, and when there is a delay, they use these mechanisms to check that the stream is not dead

BR,

Karthik

[gwesson]

The "previous segment lost" indicates a packet was lost in the transmission. The "out-of-order" was likely that lost packet being resent. The "dup ack 170" is saying that the ACK in frame 170 was sent twice to tell the server about the lost frame.

As Karthik mentioned, this is part of the normal TCP flow in the event of any packet loss.

Enabling Wildfire should not introduce any latency as the files are sent out-of-band with the client. If you have a lot of files going up to the cloud in addition to your normal browsing, there could be a load issue causing packet loss. Knowing where you took the capture and what two endpoints are involved in the packet loss might help too (client-to-firewall, firewall-to-server, firewall-to-wildfire, etc.).

Hope this helps,

Greg