Convert ASA Config Notation to Firepower FTD

Migrating from Cisco ASA to Firepower Threat Defense (FTD) involves translating established network security policies and configurations into a new…

Migrating from Cisco ASA to Firepower Threat Defense (FTD) involves translating established network security policies and configurations into a new architecture. While both platforms are Cisco security offerings, their underlying configuration paradigms differ significantly. The Cisco Firepower Migration Tool (FMT) streamlines this conversion, but understanding its capabilities and limitations is crucial for a successful transition, particularly concerning object definitions, NAT, ACLs, and VPNs.

This article details the process of converting ASA configurations to FTD policy using the Migration Tool, focusing on critical elements like object groups, network address translation, access control lists, and VPN tunnels. It also highlights areas requiring manual intervention or careful post-migration validation.

Understanding the Firepower Migration Tool (FMT)

The Firepower Migration Tool (FMT) is a standalone application designed to assist in migrating configurations from Cisco ASA to FTD managed by a Firepower Management Center (FMC). As of FMT v3.0, it supports ASA software versions 8.4(1) and later. The tool ingests an ASA configuration file (show running-config output) and outputs a package compatible with FMC. This package can then be imported into an FMC, which subsequently deploys the policies to the FTD device.

FMT Workflow Overview

1. Export ASA Configuration: Obtain the running configuration from your ASA device. The command show running-config executed from privileged EXEC mode is sufficient. Save this output to a text file (e.g., asa_config.txt).
2. Launch FMT: Start the Firepower Migration Tool on a workstation.
3. Import ASA Config: Load the asa_config.txt file into FMT.
4. Review and Adjust: FMT parses the configuration and presents it in a structured view, highlighting potential issues or areas requiring review. This is where you can make pre-migration adjustments.
5. Export FTD Policy: FMT generates a migration package (typically a .tar.gz file).
6. Import into FMC: Log in to your Firepower Management Center, navigate to Devices > Migration, and import the generated package.
7. Deploy to FTD: After importing, review the imported policies within FMC and deploy them to your target FTD appliance.

It's vital to use a recent version of FMT, as Cisco frequently updates it to improve migration logic and support new features. Always check the release notes for compatibility with your specific ASA and FTD/FMC versions.

Object Groups and Network Objects

One of the most straightforward migrations involves network objects and service objects. ASA uses object network, object service, and object-group network, object-group service to define IP addresses, subnets, ranges, protocols, and ports. FMT effectively translates these into FTD's corresponding network objects, network groups, port objects, and port groups.

ASA Configuration Example:
object network obj_internal_server
 host 192.168.1.100

object network obj_dmz_subnet
 subnet 172.16.0.0 255.255.0.0

object-group network OG_Trusted_Hosts
 network-object host 192.168.1.50
 network-object host 192.168.1.51
 network-object object obj_internal_server

object-group service TCP_High_Ports tcp
 port-object range 1024 65535

object-group service Web_Services tcp
 port-object eq www
 port-object eq https

FMT processes these definitions and creates equivalent objects within the FMC's object manager. For instance, obj_internal_server becomes a Network Object of type "Host" with the value 192.168.1.100. OG_Trusted_Hosts becomes a Network Group containing the specified hosts and the object obj_internal_server. Similarly, service objects and groups are translated into Port Objects and Port Groups.

Caveat: Ensure there are no naming conflicts or special characters that might cause issues during import. FMT usually handles basic sanitation, but overly complex or non-standard names might require manual adjustment post-migration in FMC.

Network Address Translation (NAT) Rules

NAT rules are crucial for network connectivity and often represent a significant portion of an ASA configuration. FMT handles various NAT types: Static NAT (static), Dynamic PAT (pat), Identity NAT (no-nat), and Policy NAT (nat (inside,outside) source static ...).

ASA NAT Types and FTD Equivalents:

FMT generally migrates these rules into the FTD NAT policy with good fidelity. ASA's implicit NAT rule ordering (static before dynamic, specific before general) is translated into explicit rule order within the FTD NAT policy. You'll find these under Devices > NAT in FMC. Reviewing the order and specifics of the translated rules is critical, especially for complex scenarios with multiple interfaces and overlapping subnets.

ASA NAT Configuration Example:
object network WEB_SERVER_INTERNAL
 host 192.168.10.5
object network WEB_SERVER_EXTERNAL
 host 203.0.113.20

nat (dmz,outside) source static WEB_SERVER_INTERNAL WEB_SERVER_EXTERNAL access-list WEB_ACCESS
global (outside) 1 interface
nat (internal,outside) source dynamic any interface

This ASA config would result in two primary NAT rules in FTD: one for the static translation and another for the dynamic PAT to the outside interface IP. The access-list WEB_ACCESS part of the static NAT will also be translated, potentially becoming a matching condition in the FTD NAT rule.

Access Control Lists (ACLs) and Access Rules

ASA ACLs (access-list ... permit/deny ... statements) are the foundation of traffic filtering. FMT translates these into FTD's Access Control Policy (ACP). An ASA interface's access-group command becomes a set of access control rules within the ACP applied to the corresponding FTD interface.

ASA ACL Configuration Example:
access-list OUTSIDE_IN extended permit tcp any host 192.168.10.5 eq www
access-list OUTSIDE_IN extended permit tcp any host 192.168.10.5 eq https
access-list OUTSIDE_IN extended permit icmp any host 192.168.10.5 echo-reply
access-list OUTSIDE_IN extended deny ip any any
access-group OUTSIDE_IN in interface outside

FMT will convert this into an Access Control Policy with rules. The two TCP rules might be consolidated if using a port group, or remain separate depending on FMT's logic. The implicit deny ip any any at the end of an ASA ACL is typically handled by the FTD Access Control Policy's default action, which is configurable (e.g., Block All Traffic). The Migration Tool does not create an explicit "Deny Any Any" rule unless specified as such in the ASA config.

Important considerations:

• Rule Order: The order of rules in ASA ACLs is critical. FMT strives to maintain this order in the FTD ACP, but verification is essential, especially with complex ACLs and intra-interface rules.
• Grouping: FMT intelligently groups similar ASA ACL entries into single FTD access control rules using network and port objects/groups for better manageability.
• Logging: ASA ACLs often have implicit logging or specific log keywords. FTD ACP rules have extensive logging options (Connection events, Intrusion events, File events) which need to be configured appropriately post-migration.
• Global ACLs: ASA global ACLs (e.g., access-list global_acl global) will be translated into ACP rules that apply globally or are assigned to multiple interfaces based on their original intent.

Site-to-Site VPNs

Site-to-site IPsec VPNs are generally migratable, but they require significant manual review and potential adjustments. FMT can translate many common VPN configurations, including:

• IKEv1 and IKEv2 policies.
• IPsec transform-sets.
• Tunnel groups and pre-shared keys.
• Crypto map entries and their associated ACLs defining interesting traffic.

However, FTD's VPN configuration model is more granular and integrates with the overall policy framework (e.g., using network objects for VPN peers and protected networks). FMT will attempt to create the necessary VPN topologies, IKE/IPsec policies, and crypto map entries, but the following often require manual verification:

• Authentication Methods: While pre-shared keys translate well, certificate-based VPNs might require more attention, ensuring certificates are correctly imported and associated in FMC.
• NAT Exemption: ASA uses nat 0 access-list ... for NAT exemption. FMT translates this into the FTD NAT policy, ensuring the correct identity NAT rules are created and ordered appropriately.
• Advanced Settings: Dead Peer Detection (DPD), Rekey intervals, and other advanced IPsec parameters should be verified against the original ASA configuration and peer device settings.
• Traffic Selectors: FTD explicitly defines traffic selectors within the VPN topology. Ensure these match the ASA's crypto map ACLs precisely.

After FMT imports the VPN configuration into FMC (under Devices > VPN > Site-to-Site), carefully compare each setting with your ASA configuration. A common practice is to configure one or two VPNs manually in FTD first to understand the mapping before relying entirely on the tool.

Remote Access VPN (AnyConnect)

Remote Access VPN configurations (specifically Cisco AnyConnect) are not fully migrated by FMT. While some basic tunnel group parameters might translate, the AnyConnect profiles (XML files), client images, connection profiles, group policies, and DAP (Dynamic Access Policies) require re-creation within the FMC.

The ASA's WebVPN configuration, including portal customization, connection profiles (tunnel-group webvpn-attributes), group policies (group-policy attributes), and DAP policies (dap enable, dap anyconnect ...), needs to be manually re-engineered in FMC (under Devices > VPN > Remote Access).

• AnyConnect Client Profiles: Re-create your XML profiles using the AnyConnect Profile Editor.
• Client Images: Upload the necessary AnyConnect client images to FMC.
• Connection Profiles & Group Policies: Configure these from scratch in FMC, mapping ASA settings to FTD equivalents. This includes authentication methods (e.g., LDAP, RADIUS), IP address assignment, DNS servers, and split-tunneling configurations.
• Dynamic Access Policies (DAP): Re-create DAP policies in FTD based on your ASA's DAP rules, ensuring the correct conditions and actions are applied.

This is often the most time-consuming part of an ASA to FTD migration for organizations heavily reliant on AnyConnect. Thorough testing with a small group of users is essential.

Common Pitfalls and Troubleshooting

• Outdated FMT Version: Always use the latest version of the Firepower Migration Tool for best compatibility and feature support. Check Cisco's website regularly.
• Incomplete ASA Config: Ensure the show running-config output is complete and free of errors. Missing sections can lead to partial migrations.
• Unused/Stale Objects: ASA configurations often accumulate unused objects or ACL entries. FMT migrates everything it finds. Clean up the ASA config beforehand or purge unnecessary objects in FMC post-migration.
• Interface Naming: While FMT attempts to map ASA interfaces to FTD interfaces, manual verification of interface zones and security levels in FMC is crucial.
• ACL Rule Ordering: Despite FMT's best efforts, complex ACLs with overlapping rules or specific ordering requirements might need manual reordering in the FTD Access Control Policy.
• Deployment Failures: If FTD deployment fails after importing, check the FMC task logs for specific errors. Often, these relate to object conflicts, invalid configurations, or resource limitations on the FTD device.
• VPN Connectivity Issues: Debugging VPNs involves checking IKEv1/IKEv2 SAs, IPsec SAs, and NAT exemption rules. Ensure the peer configuration matches FTD's settings precisely.
• Performance Degradation: After migration, monitor FTD performance. Some features (e.g., deep packet inspection) are more resource-intensive than traditional ASA firewalling. Sizing considerations should be part of the initial FTD deployment planning.