Cisco FTD Migration

[mb_equate]

I've embarked on my first FTD migration journey for a client and wanted to share my early [and tantalisingly promising] results. The customer is running NGFW Version 6.4.0.17 on FPR-2110 appliances. My exposure to FTD is on par with its popularity, so please bear with me.

First thing to note is FTD (and FMC) is basically code running on Linux VMs (mostly) and configuration stored in databases (also mostly). Don't forget your roots (Snort). Exports and backups appear to be Matryoshka dolls of tarred up gzipped tar files containing either transaction logs or binary files which are often large and not particularly useful. There are still remnants of ASA code running in places because a lot of features still rely on it. If this sounds strangely familiar, you haven't gone insane - they are following in the footsteps of the pink defenders.

Fortunately you don't have to deal with any of that, as the entire firewall configuration is also stored in a readable text file you can either extract from the diagnostic CLI (LINA) or export from an FTD backup (either locally or via FMC).

If you have SSH access to the FTD appliance:

1. Connect to the device and issue the following commands
   1. system support diagnostic-cli
   2. show running-config

If you have access to FMC:

1. Run an device backup
   1. This takes some time, apparently
2. Download the device backup and extract the file \tmp\BKP\tmp\backupk_nX\running_configuration_file.gz
3. From running_configuration_file.gz, extract the file \backup\running-config.cfg
   
   1. Crack it open, this is where things start looking hopeful

Once you have the config, go import it into an Expedition project and run the usual checks:

1. Monitor > check and fix issues
2. Network > check / fix interfaces, zones, VRs, VPNs etc
   1. Expedition appears to have done most of the heavy lifting
   2. Cannot comment on protocols, no dynamic routing this time
3. Policy > check and fix issues
   1. Remove redundant ACLs
      1. The ones you want to keep are tagged CSM_FW_ACL_
   2. Check new rules for NAT objects
   3. Validate policy / NAT
   4. Fix rule names (source remarks are in rule description)
   5. Opportunistic app-id adoption

The rest should be history - I'll update this thread once I've got the target hardware and working exports.

Limitations (so far...)

• The migration is NOT L7
  • This is because the L7 stuff, including IPS, is done by the Snort engine
    • You may recall this from ASA with FirePower
  • You will need to adopt app-ID manually or use ML
• ALL ACLs are migrated
  • Including redundant ones, crypto maps etc.

[Sinu79]

Hi,

Thanks for providing a detailed instruction on migrating FTD config to PA.

A quick question, you had CLI config output and backup output, which of the two config outputs did you use to import the config in Expedition?

If only one of the above was required, then why was the second output generated?

[mb_equate]

I used the backup output from FTD as I did not have SSH access to the device at the time. Both should work, I will confirm if they are identical.

One other limitation I ran into was the VPN naming convention, which was based on the crypto map ID. The raw ASA-like / LINA config had multiple orphaned maps with no associated tunnel-group and appears to be sufficient for a L3-4 system to function only - what you see in FTD / FMC appears to be augmented with content from the database, or as I suspect the LINA config is generated from the database because the device is still running ASA code under the hood.

[Sinu79]

Thanks again.

From running_configuration_file.gz, extract the file \backup\running-config.cfg, what did you mean by ''cracking it open''? Did you save it in a .txt format for it to be imported in Expedition or .cfg format was enough for the import process?

[mb_equate]

running-config.cfg is just a text file which I believe is generated by FTD and loaded by the ASA code hiding inside. It's in the same format as your traditional ASA (w FP) config stored in NVRAM or output of "show running-config". You need to extract it and import into your Expedition project as you would any other ASA config, or open in your favourite text editor to understand what's in it or make adjustments as required. I don't think the file extension makes any difference in this case, and it's not encrypted so officially no 'cracking' involved 😉

On that note, the IPsec PSKs are stored in this file in clear text...!

[Jorgen_Lanesskog]

FirePalo

FirePalo (Windows GUI) helps you convert rules and objects from Cisco FirePower to Palo Alto

(See the "Sceenshots from the application.docx")

Run "show access-control-config" from the FTD device and save output to a textfile. Open the textfile in FirePalo.exe and it will create editable objects. Finally, "commit" the changes and create a configuration in SET format that can be pasted into a Palo Alto device or Panorama.

This version will not convert device configuration like interfaces, routing or NAT. Some manual work needed for User-ID, URL Categories and Application filters.

Download the PaloAppID.txt file and place it with the FirePalo.exe. It contains all the Palo Alto APP-ID's

FirePalo also lets you export sections of the configuration to edit in preferred editor and than import the result back (great for search and replace). In addition you can easily lowercase or uppercase sections (or the entire configuration) and cut object names automatically to supported length. Further, you can convert services to applications (as not all services from FTD are supported as a service). Finally, you can add tags for objects, so that all rules using a certain object get the tag set.

Easily select if this is a standalone or Panorama configuration to be created (so that device group get included in the configuration).

FirePalo takes the output from the FTD and first turns it into a treeview. It then takes all the items in the treeview and creates objects you can edit, providing an unique ID for each object. This binds everything to the correct rules and all edits will be in place when you finally turn the objects into a treeview again ("commit"). You can then look through the result as a treeview and make more changes if needed (and then doing a new commit).

When everything looks good, you can generate the final configuration in SET format and paste it into the Palo Alto device or Panorama CLI.

jorlan72/FirePalo: FirePalo helps you convert rules and objects from Cisco FirePower to Palo Alto (g...