ASA to FTD policy migration best practice

[niko]

Hi,

When migrating ASA existing configuration to FTD, there are some options how to do it - Prefilter policy or Access Control policy (using Trust rules). Basically, my goal is to migrate the existing plain ASA configuration without using IPS ir any additional inspection initially. After making sure basic things are working fine - we may add additional inspection - and that's why using Access Control policy seems better - just change Trust to Allow, add inspections and you are good to go - with Prefilter there's more work to do. ACL/ACE list is rather biggish - really looking forward to doing it in automated way.

I understand they may serve similar purpose and there are use cases for both of them, but has anyone tested how they compare by performance/usability?

Using Prefilter:

+ Probably faster execution, no additional processing required by snort - plain ASA;

- No easy way to add inspection after migration;

- No L7, URL or any of the good FP stuff;

- No logical rule grouping

Using Access Control (with Trust):

+ Easier to add any inspection after migration;

+ L7 inspection and FP stuff can be used;

+ Rules can be grouped;

- More processing power required for each rule, SI is checked, so packets will go through Snort engine AND there will be impact if snort is restarted (and that happens with specific cases in mind mentioned in the configuration guide).

Are there any gotchas that should be noted though and I may have missed? What's the performance impact in both cases? 

[Rahul Govindan]

I recently migrated the ASA rules to prefilter policies first and then analyzed ones that needed further inspection. This worked out well as I could test basic access without further inspection and only allow further inspection if needed. 

If you are using an existing ASA (with no Firepower), using prefilter policies IMO is an easier step to go to. You can then add inspection for traffic only you select.

If you are already using ASA with Firepower, then you are most likely inspecting all the traffic through the ASA already. ACP may be a better option there (not always).

I have not really tested any performance differences between both methods, but my guess is that using pre-filter policies would have better performance than going to ACP.

[niko]

Thank you for the input.

At the moment ASA is using FP, but in catch-all mode without deep granularity - all filtering is done on the ASA with usual L3/L4 and FP is running in monitor-only, but after successful migration of the current configuration (ASA), inspections will be added for most of the traffic.

The complexity behind adding inspection for Prefilter is the fact you have to change the Prefilter rule itself and then add additional ACP rule for inspection options - to have better view over which traffic hits which rules and what policies are used for inspection as they may vary.

Using ACP seems to give more flexibility later on - select rule, change action, add inspection and you are good to go. But due to the same exact reason I have more faith in Prefilter rules - reduced complexity at first stage.

There are ~4k ACL lines, approx. half of them are remarks, so it could be 2-3k lines and even more (~20k) when objects are expanded, so replacing/moving them after migration has been done could turn out to be big PITA. :)

[Oliver Kaiser]

+1 for ASA w/ FP. I have gone through some FTD migrations and I would also recommend to go with ASA w/FP if you value stability. Wait for Q1 2018 until 6.3 is released... software quality should be improved then but as of now you would have some interesting months ahead if you go FTD. 

[Oliver Kaiser]

If your policy model is whitelist only I would recommend going with pre-filter as first migration step. It will make the migration easier since you wont face any L7 bugs / issues at first and you can start consolidating your ruleset as you move to the access control policy.

As for performance... keep elephant flows in prefilter policy since it uses NPUs to fastpath traffic and get more performance for large flows. Since snort spawn N number of processes and uses a hashing algorithm to select a process to process traffic you will see performance issues if you have flows like backup that transfer a lot of data.

SI isnt a real performance killer, just keep in mind that IPS and AMP can be real performance killers depending on your workload. :)

[gufari101]

i had around 8k rules in my firewall and i migrated successfully, and around 1k NAT policies.

The configuration toold won't migrate the static routes and there's another showstopper for me that i'm not able to search NAT rules, since there's not search bar under NAT section.
I'm using FMC 6.2.0 and FTD 6.2.0 on ASA-5555x firewalls.

Any suggestions?

[niko]

Did you migrate them via Prefilter or Access Control policies?

[gufari101]

ACP with Allow action for rules allowed already in ASA.

what is a number of NAT rules you've imported and how did you imported the routing configuration to FMC?

[niko]

There's no NAT for this specific device I'm migrating and regarding routing - I don't see too many options, but to move the routes manually. In my case that's not going to be a huge problem as migration will be done gradually, but may be worse if that should be done as a whole.

I'm guessing you are still trying to figure out if put this in production?

[gufari101]

The firewall i'm working on to migrate is perimeter and all the NAT policies are configured on that, there are 18 different DMZ's with 100's of NAT policies, ACLs and static routes configured on that.

I'm still trying to figureout whether to go for FTD to ASA w/ FPS.

[niko]

If you like sleeping well, go with ASA w/ FP due to more mature and stable operation overall. ASA stays ASA and if there are issues with FP - you can go around it without much hassle if you leave basic L3/L4 filtering on the ASA. Yes, there are two management points and integration is as it is - just like adding two independent products together.

FTD is still green-ish and there are shortcomings - deployment times, snort restarts, etc. It will probably just become better and better by each upgrade, but you will definitely have some headaches during the initial migration and operation right after that. If you are ready to accept that and have your support contract ready - go for it.