Firepower Migration Tool and multiple ASA's to the same vFMC?

[andrew.butterworth]

I am working on a project to migrate one context each from two HA pairs of ASA5555-X's over to two HA pairs of FPR1140's running FTD.

I understand how the FMT works, however I don't think I've seen anything where two separate ASA's have been migrated to the same FMC?

My concerns are that the existing ASA's will have objects with the same names but different data and the FMC has a single object repository:

object network www-server-1
 host 10.1.1.1

& 

object network www-server-1
 host 10.2.2.2

It seems the FMT is a one-shot deal so I'm likely to need one (or more?) sacrificial vFMC's to test this out on before we hit the live FMC.

I am planning to compare the two configurations when we get a change-freeze initiated to see how much stuff I will need to manually edit.

Any tips or experience using the FMT with multiple ASA's and a single FMC?

Cheers

Andy

[Marvin Rhoads]

I've migrated more than one ASA to FTDs managed on the same FMC. I don't think i came across having the same object name with different values. Note you cannot merge the ASA configs onto a single target FTD. That's not supported using the tool.

Generally speaking the FMT is pretty robust though and will give you a pre- and post-migration report with any exceptions it finds.

[Chakshu Piplani]

Hi Andy,

FMT tool has a resolve conflict option, where it will ask you to rename the object while migrating it, if an object with same name exists on FMC, but your object has different values, check the below screenshot.

You will get this option prior to making the final "Push Configuration" to the FMC at the time of validation.

This is also mentioned in our guides:

https://www.cisco.com/c/en/us/td/docs/security/firepower/migration-tool/migration-guide/ASA2FTD-with-FP-Migration-Tool/b_Migration_Guide_ASA2FTD_chapter_0111.html

• An ASA object has the same name and configuration as an existing object in Firepower Management Center—The Firepower Migration Tool reuses the Firepower Management Center object for the Firepower Threat Defense configuration and does not migrate the ASA object.

• An ASA object has the same name but a different configuration than an existing object in Firepower Management Center—The Firepower Migration Tool reports object conflict and allows you to resolve the conflict by adding a unique suffix to the name of the ASA object for migration purposes.

• Multiple ASA objects have the same name but in different cases—The Firepower Migration Tool renames such objects to meet the Firepower Threat Defense object naming criteria

Regards,

Chakshu

Do rate helpful posts!

[andrew.butterworth]

I have been testing this offline with some FMCv's and FTDv's.  I can manipulate the source configuration files so the interfaces line up so I am happy with that aspect.

One thing that is happening is the per-interface ACLs are merged into a single global ACL (CSM_FW_ACL_), along with a single "access-group CSM_FW_ACL_ global" line.

Is this by design or have I done something wrong during the migration with the FMT?

I am using some sacrificial FMCv's and FTDv's on a test ESXi 6.5 host.  I am using FTD/FMC software 6.6.5 and the latest FMT v2.4,1.

Cheers

Andy

[Chakshu Piplani]

That's by design on Cisco FTD.

• A global Access Control List (ACL) named as CSM_FW_ACL_ to the FTD LINA engine
• Access Control (AC) rules in the /ngfw/var/sf/detection_engines/<UUID>/ngfw.rules file to the FTD Snort engine

Source: https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212321-clarify-the-firepower-threat-defense-acc.html

Regards,

Chakshu

Do rate helpful posts!

[andrew.butterworth]

I migrated a context from a HA pair of ASA5555-X's last night over to a pair of FPR1140 FTD's managed by a FMCv.  I used the FMT to migrate the objects, access-control policy and NAT to a vanilla FTD and then manually built the HA.  From a connectivity & NAT perspective it couldn't have gone smoother.

Now that some data is flowing into the FMC we have some application visibility, however I think the access-control policy needs tweaking.

I seem to recall on an older FMC (6.2?) that was managing an ASA5525-X with FirePOWER services I could right-click on the overview page and then be able to drill down to source/destination IP addresses and URLs.  If I do that on this newly migrated one I just get 'No Data'.

We have Base & Threat licenses.

[andrew.butterworth]

Spoke too soon.  Apparently the migration didn't completely work.

It looks like in migrating the ACL and merging the per-interface ACLs into a single Global ACL the tool adds source and destination zones rather than the ASA just having a source interface.  I think the FMT uses the routing table to determine the destination zone?

Original ACL on ASA

interface-x - source 10.1.1.0/24 -> destination 10.0.0.0/8 TCP/8080

Migrated to

global - source zone interface-x, source 10.1.1.0/24 -> destination zone interface-y destination 10.0.0.0/8 TCP/8080

Which prevented access to another local interface - lets say interface-z and zone interface-z with a 10.x.x.x prefix.

I managed to fix it by adding an identical rule after but setting the destination zone to 'Any'.

I'm not that impressed with the tool tbh..

[Marvin Rhoads]

Interfaces should generally be mapped to interface groups and zones. The FMT suggest the same when migrating. I've followed that method on a half dozen or so that I have done and it has always worked for me. The tool has saved me dozens of hours that I would have otherwise spent doing manual migrations.

[andrew.butterworth]

The tool has definitely saved me time, however this caused me a major headache as the majority of things worked with the customer testing.  I was only a day later when they realised there were some issues and initially they thought it was server related rather than the firewall migration.

If the firewall configuration isn't too large then its easy to sanity check it after the migration.  If its thousands of lines long then its much harder to check every line.

Luckily there was a pattern to it and it was only rules where the destination was a summary prefix covering multiple actual destinations - i.e. 10.0.0.0/8.  It seems the tool is matching exactly rather than looking a bit deeper as to what traffic is allowed.