I have deployed a 5506x with FirePOWER at the edge of one my networks for the first time thinking it would be a relaitlvey cheap way to add some IPS functionality to small client networks. I've been trying to get the thing to behave correctly with mostly default settings (get signature and geo updates finally work as of November), but I've noticed that there are certain types of completely legitimate traffic that it will just block almost no matter what I do. It seems to ignore some of the policies I put in place, and doesn't really log all of its own actions, which is pretty annoying. It also seems to frequently false on legitimate traffic when in the "balanced security and connectivity" mode, and even in the "connectivity over security" it will sometimes block completely legitimate traffic (for example, it will partially block legitimate browser traffic to blogs that use wp.com hosting for desktop browsers but it will allow it for mobile device browsers - this causes attempts to load these pages on a browser to stall and eventually work after a reload attempt or two).
Some examples of things I've tried to get it to allow:
There is an email client running on a host that opens say 5 simultaneous TLS connections to a POP email server just to grab archive copies of incoming email for some shared accounts. In balanced mode, the ASA will pseudo randomly decide to block one or more of these connection attempts. In the ASA logs it shows in debug that the FirePOWER is instructing the ASA to drop SYN packets with the implication that the rapid-fire simultaneous connections to the same IP are a SYN flood. 5 SYNs is not a flood no matter how close together they are. The FirePOWER does not show any events in its logs for this, so figuring out what is going on is an exercise in frustration until you find out that the ASA logs this by stating that the FirePOWER requested it drop the packet. I tried creating a policy in the FirePOWER to explicitly trust traffic to and from that server and it still instructs the thing to drop one or more of the outbound SYN packets when in "balanced" mode. In connectivity over security, it seems to allow it, but it is frustrating that this completely normal behavior triggers a rule that is invisible in the FirePOWER configuration and is not logged by the FirePOWER itself.
The network environment for this initial deployment is mostly Macs and iOS devices with just a handful of Windows boxes, so there are a lot of things building connections to Apple's IP space for receiving push notifications etc, including a couple Mini's that are used to do some lightweight MDM with Apple's server tools (so they try to maintain persistent connections to Apple's IP space). The FirePOWER randomly blocks traffic in balanced mode, even if I create a policy that explicitly trusts all traffic to or from Apple's entire class A. This causes erratic delays in delivery of things like iMessage traffic.
What finally prompted me to post and ask about this behavior was that my frustration with the erratic behavior hit a boil when it became clear that on the balanced setting, the FirePOWER will sometimes block the traffic for auto configure of an Exchange account when Outlook tries to perform its autoconfiguration on initial setup for Exchange hosted on Office 365. Between Apple and Microsoft, it is randomly blocking completely legitimate traffic that occurs all the time on networks everywhere, so its "balanced" setting is useless without the ability to make some tweaks.
And this is where my question comes in, the FirePOWER seems to be quite willing and able to ignore pretty straightforward policies. For example, to try to narrow down the problem, I created an access control policy in the FirePOWER that trusts all traffic to and from the 17.x.x.x class A that Apple owns. Normally I wouldn't be too happy with a rule that broad and open, but even with that policy deployed, the FirePOWER still randomly decides to instruct the ASA to drop outbound SYN traffic to Apple's IP space in "balanced" mode, and it does so without logging it as an event. The fact that it is doing it can only be found in the ASA's logs, where it simply states that the FirePOWER requested it drop the packet. I must be missing something obvious, because otherwise I'm going to take it out of inline mode at this first site, and not bother with buying FirePOWER licenses for any other sites that would get a bigger ASA at the edge than this first deployment site.
