Could enabling Wildfire possibly cause TCP Transmission errors?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Could enabling Wildfire possibly cause TCP Transmission errors?

Not applicable

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.

3 REPLIES 3

L4 Transporter

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.

L5 Sessionator

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

L7 Applicator

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

  • 3318 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!