ASA/FirePower Access Control and NAT

[Matthew]

When implementing FirePower services on an ASA and managing it with FireSight in an enviroment with existing ACL's and NAT statement on the ASA, will creating access control policies and nat statements through FireSight take precedence over the local rules? For example, if there is a webserver on the inside interface of the firewall which has a static nat translation created via cli on the asa, would I want to create this rule (access control and NAT) in FireSight then simply remove the rule from the ASA?

[ArchiTech89]

It's my understanding that the "Access Control Policies" in FirePOWER are only there for the purpose of sifting traffic out for applying the Intrusion Policies to. Basically, it's so the ASA can figure out what traffic needs to be scanned (or in these cases, what get fast-pathed by it).

It flows like this: traffic enters the ASA and is decrypted if it's VPN. Then firewall policies are applied (there's no need to scan the traffic if it's denied already). THEN it goes to the SFR module. That's when FP checks it's own filters and does its thing. Then it passes everything left over back to the firewall.

So I would say, no, you don't want to create anything in FireSIGHT that duplicates what you're already doing on the firewall. Let the firewall handle its things, and SourceFire handle its own by just looking at the traffic left over and deciding whether it might be malicious.
 

[Matthew]

That does seem to make more sense to me now since the initial policy map does not define which traffic should be inspected or sent to the module, and that in Cisco documentation it is typically applied to the global service policy.