Clarification on FirePower policy default action.

[willb1]

Forgive me if this is a dumb question.

We will be migrating from ASA's to FPR's and I am testing configurations in a separate testing network.

I need clarification on the access control policy default action. Specifically, when used as a perimeter firewall, how is outside-in traffic blocked? ASA's by default are configured with the global deny all and the inside ACL configured by default to allow traffic to any less secure networks.

Should I:

1. Configure the ACP with a default action of 'Block all traffic' and add a rule to allow traffic from the inside zone to the outside zone (with inspection)?

or

2. Leave the default action set with an intrusion prevention policy defined? I realize that, with an auto NAT rule and default route set, only traffic initiated from the inside will be permitted back from the outside and that unsolicited outside traffic will be blocked, but is this the correct way to handle this?

[Rob Ingram · Accepted solution]

@willb1 option 1. Explictly permit traffic from inside zone to outside zone and vice versa. Traffic is stateful, so obviously will automatically permit the return traffic.

Unlike the ASA, the FTD doesn't use the security-level to determine whether traffic is allowed from higher to lower interface. You need to explictly permit/deny the traffic in the ACP.

[willb1]

Thank you!

[willb1]

To confirm, the final ACP rule should look like below, correct?

[Aref Alsouqi]

I wouldn't recommend creating the rule that way because on your rule you are allowing any traffic from outside to inside. The way how I would do it would be to only allow the inside to outside, and if you have any traffic that should be allowed from the outside to inside (say towards a web server or similar) I would create a separate rule dedicated to that traffic which will define the destination host as well as the service ports. Obv you would also need to create the NAT rules if required. The implicit deny is still valid on the FTDs, you don't have to explicitly define the deny all rule.

[willb1]

Thank you. I tested the policy configured to only allow traffic from the inside zone to the outside zone but return traffic is blocked.

[Aref Alsouqi]

That is weird, the return traffic should be allowed by the firewall as each session going out would have a state entry on the firewall. Just to confirm, when you say the return traffic is blocked, you mean if you browse a web site from an internal endpoint is not working? How many WAN circuits do you have? in case you have multi how are they connected to the firewall?

[willb1]

We have multiple remote sites which connect via GRE tunnels over IPSec VPN connections back to our Corporate FPR. I have replicated the setup in the staging environment. We only have a single circuit at each location. The VPN is up, the GRE tunnel is up, and traffic is flowing. Return traffic to the remote site is being blocked at the Corporate FPR, which is configured with a similar policy.

[Eric R. Jones]

Ours came out of the box "Access Control:Block all traffic" and we kept the Default Prefilter Policy in place. Then migrated over all our rules from the ASA using the migration tool. The one thing that stumped us for about 30 minutes was why traffic wasn't flowing as we thought it should. Head slap when we realized we had to deploy again after a minor change.

[Aref Alsouqi]

Sorry, not sure I'm following correctly. The return traffic is the traffic that will be passing through the same firewall where the leaving traffic existed it. However, if you are referring to other firewalls in the remote sites, then those firewalls might have security rules that are blocking the traffic. From the local firewall perspective, the outbound traffic would be from inside to outside, and from the remote site firewalls perspective, it will be inbound traffic coming from outside to inside. For those firewalls you would need to create the policy to allow the traffic from outside to inside specifying the networks as the source and destination.

[willb1]

I apologize. The return traffic for the branch office is being blocked at the Corporate FPR. 

With the GRE tunnels, all traffic is routed through our Corporate office unless the circuit is down at which time traffic is routed out of the remote offices' local circuit.

[Aref Alsouqi]

No problem :). From the topology you shared it seems the corp firewall has a different segment where the remote office traffic will be received on. If that is the case, then the policy rule you created won't match that traffic as it is conditioned to the inside as the source and the outside as the destination. You would need to create an additional rule from inside to whatever that segment is.