1 Reply Latest reply on Jul 31, 2013 9:18 AM by mtuma

    Stateful inspection on allow Any to Any rule causes packets to be dropped

    chriselize

      I discovered that when enabling stateful inspection in the Application Defence group on a rule where the source and destination endpoints are both specified as Any V4, some files will fail to be copied to a destination address (behind the firewall) and the following notification event is logged:

       

      information: Dropped a TCP packet with no matching session; flags=0x14<RST,ACK>

       

      However, when I create a rule and configure a specific network object as either sourc or destination endpoint, the problem does not occur.  It first came to my attention when I noticed that the McAfee ePO repository replication fails when a new product or new version of a product like Site Advisor or MOVE has been checked into the master repository.  Small files (2MB), specifically executables, failed to copy and stopped the replication process.  When attempting to copy the file manually, an error was generated and the frewall log confirmed that the packets are dropped.

       

      SAEHotfix809552-3.5.0.1021.1 (SiteAdvisor hotfix file) is an example of a file that cannot be copied to the site behind the firewall.  There is no problem with outbound connections, e.g. when establishing the connection from the site behind the firewall (site A) and copying it from a remote site without a firewall (Site B), to site A.

       

      How can I enable stateful inspection and still specificy Any V4 to Any V4 endpoints in the rule?  Why is it that only certain files (mostly executables, I think) cause this to happen?  Some executable files are copied successfully, and size does not seem to play a role.

        • 1. Re: Stateful inspection on allow Any to Any rule causes packets to be dropped

          Hello,

           

          Unfortunately the dropped packet message might be a red herring here. What that message is saying is that the firewall received a reset for a connection that does not exist in the firewall state table. What might have happened is the firewall recieved two reset packets, the first one closing the connection and removing it from the state table, then the second one coming in and triggering this message.

           

          I think taking a look at audit and tcpdumps with Support might be your best bet. There should be no reason that "Any v4" does not work, while specific objects for source/dest work just fine.

           

           

          -Matt