Cisco FTD Migration

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Cisco FTD Migration

L3 Networker

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.
4 REPLIES 4

L0 Member

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?

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.

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?

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...!

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!