How can I resolve drop code "Cache Add Cleanup"?

This article provides troubleshooting steps to resolve packets being dropped on the SonicWall firewall due to drop code "Cache Add Cleanup".

The Drop Code "Cache Add Cleanup" may be legitimate since the firewall will drop everything that comes out of order.

NOTE: If an ACK Packet of a TCP conversation arrives after the connection was closed by a ACK/FIN or a RST Packet, the ACK packet will be dropped as "Cache Add Cleanup": this error message states that the firewall has no active connections regarding the received packet so the packet can't be accepted.

Resolution for SonicOS 7.X

This release includes significant user interface changes and many new features that are different from the SonicOS 6.5 and earlier firmware. The below resolution is for customers using SonicOS 7.X firmware.

You may want to check the following :

• Review the TCP conversation using the packet monitor. If the dropped packet is received after the connection was closed (FIN or RST Packet), the drop is legitimate. If so, you will need to find out why the connection was closed/reset before the end of it by checking the machine that is sending the FIN/RST packet.
• Try by disabling Enforce strict TCP compliance with RFC 793 and RFC 1122 in Network | Firewall | Flood Protection.
  CAUTION: This will reduce the security of your network.
•  Make sure that the TCP Connection Timeout on the specific Access Rule or on Network | Firewall | Flood Protection is not too low (by default it is set to 15 minutes).
• Try to disable "Enable TCP sequence number randomization" from the diag page of the firewall (https://IP of the SonicWall/sonicui/7/m/mgmt/settings/diag).
• If the dropped traffic is VPN, make sure that you have a public IP set on the WAN Interface: a double NAT condition may cause the firewall to drop the traffic as "Cache Add Cleanup" due to the change in the packet header.

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.

You may want to check the following :

• Review the TCP conversation using the packet monitor. If the dropped packet is received after the connection was closed (FIN or RST Packet), the drop is legitimate. If so, you will need to find out why the connection was closed/reset before the end of it by checking the machine that is sending the FIN/RST packet.
• Try by disabling Enforce strict TCP compliance with RFC 793 and RFC 1122 in Firewall Settings | Flood Protection.
  CAUTION: This will reduce the security of your network.
•  Make sure that the TCP Connection Timeout on the specific Access Rule or on Manage | Firewall Settings | Flood Protection is not too low (by default it is set to 15 minutes).
• Try to disable "Enable TCP sequence number randomization" from the diag page of the firewall (https://IP of the SonicWall/diag.html).
• If the dropped traffic is VPN, make sure that you have a public IP set on the WAN Interface: a double NAT condition may cause the firewall to drop the traffic as "Cache Add Cleanup" due to the change in the packet header.

NOTE: Drop code numbers may change based on the firmware version, however, the drop code message (description) remains the same.

Additional drop code articles:

• How do I resolve drop code "Enforced Firewall Rule"?
• How do I resolve drop code "Cache Add Cleanup"?
• How do I resolve drop code "Packet Dropped - Policy Drop"?
• How do I resolve drop code "IP Spoof"?
• How do I resolve drop code "IDP Detection"?