Understanding Management Interfaces

When configuring Cisco Secure Firewall Threat Defense (FTD), it’s crucial to understand the roles and best practices surrounding the management and diagnostic interfaces. These interfaces serve different purposes and are managed through specific areas in the FMC (Firewall Management Center) GUI or CLI.

Management Interface

The management interface is a foundational part of Secure Firewall deployment. It is used to assign the IP address for FTD, which facilitates communication between FTD and FMC. This interface is also responsible for terminating the SFTunnel, acting as a source for rule-based syslogs, and providing SSH and HTTPS access to the FTD system. Because of its essential role, this configuration is mandatory.

Initial configuration of the management interface is typically performed via the CLI. However, if updates are needed post-deployment, they can be made through the FMC GUI by navigating to Devices > Device Management and editing the relevant device. Configuration options will be available under the Overview tab.

 

Security-conscious administrators may want to limit SSH access to specific IP ranges. This can be achieved using an ACL in the CLI with a command such as:

configure ssh-access-list 10.0.0.0/8

 

Diagnostic Interface

The diagnostic interface, by contrast, is optional and not recommended for most deployments. It provides remote access (SSH and HTTPS) specifically to the ASA engine within FTD and is used for LINA-level syslogs, AAA, SNMP, and similar functions. However, it’s generally better to rely on a data interface for these purposes, especially if there’s no internal router, as this interface must be on the same subnet as the management interface. Additionally, once configured, it becomes a regular interface and is no longer available for other data networking purposes.

If the diagnostic interface is needed, configuration is performed by going to Devices > Device Management in the FMC and editing the device under the Interfaces tab. A dedicated section will appear if diagnostic support is present.

To enable SSH and HTTPS access to the diagnostic interface, go to Devices > Platform Settings, then configure access under Secure Shell and HTTP settings.

 

Configuring Interfaces

The Interfaces section is where administrators define and manage the individual interfaces for the Secure Firewall platform. Each interface can be configured with a specific mode to determine how it behaves within the network. For example, setting an interface to Passive mode enables it to function like a SPAN interface, receiving mirrored traffic from other switch ports for monitoring purposes without participating in forwarding or filtering. This is ideal for traffic visibility and analysis, but these interfaces cannot perform any enforcement actions. Alternatively, the ERSPAN mode allows the interface to receive spanned ERSPAN traffic, while the None mode designates it as a standard Layer 2 or Layer 3 interface, which is typically used in production traffic flows.

Navigate to Devices> Device Management. 

 

Click on the pencil next to the device that you would like to modify.

 

 

This should take you right to the Interfaces tab. When editing an interface, clicking the pencil icon provides access to various configuration options.

 

The Edit Physical Interface menu will pop-up.

On the General tab, you have the option of configuring the following:

  • Name – Think of it like the nameif interface of an ASA
  • Enabled – Enable the interface
  • Management Only – Configure the interface for management access only
  • Mode – You can select one of the following:
    • Passive – Where it will sit off a SPAN interface or mirrored port which allows for traffic to be copied from other ports on a switch. The function is to provide visibility within the network without being in the flow of network traffic. The system cannot take certain actions such as blocking or shaping traffic. Passive interfaces receive all traffic unconditionally and no traffic received on these interfaces is retransmitted.
    • ERSPAN – Where it will receive spanned ERSPAN traffic
    •  – Means its a regular layer 2 or layer 3 interface
  • Security Zone – Configures the security zone of an interface which can later be used in policy rules.
  • MTU – Choose the MTU for the interface. Default is 1500.
  • Priority – This is a priority used for policy based routing if you want to distribute traffic across multiple egress interfaces

 

 

The IPv4 tab allows you to choose the IP assignment method, be it DHCP, PPPoE, or a static IPv4 address, providing flexibility for different deployment scenarios.

 

 

For IPv6 configurations, the IPv6 tab includes multiple sub-tabs.

IPv6: The Basics tab has the following options:

  • Enable IPv6
  • Enforce EUI 64 – Enforce EUI-64 addressing which ensures compliance with EUI64 standards and drops traffic from non-compliant sources.
  • Link-Local Address – Statically assign link-local addresses.
  • Autoconfiguration – Enable auto-configuration.
  • Obtain Default Route – Whether or not to get the default route from the DHCP server.

 

 

IPv6: The Address tabs allows you to add an IPv6 addresss to the interface and to force Enforce EUI 64 compliance.

 

 

IPv6:The Prefixes tab allows you to add a prefix, configure whether you would like to advertise it, use it for autoconfiguration, and the preferred lifetime. If you check on default here, it uses the prefix of whatever IP address that is assigned to the interface.

 

 

The Settings tab will will allow you to configure additional settings such as DAD attempts, NS intervals, reachable time, enable or disable, RA, RA lifetime, and RA interval.

 

 

IPv6: The DHCP tab is where you would enable the interface as a DHCP client, enable DHCP for address configuration, enable DHCP for non-address configuration, enable default route using DHCP, and configure a DHCP server pool.

 

 

On the Path Monitoring tab, you can enable IP-based monitoring or HTTP-base monitor which can be used with policy-based routing.

 

 

The Hardware Configuration tab allows you to configure the speed and duplex of the interface.

 

 

The Manager Access interface allows you to filter management networks to manage the device via the data interface

 

 

The Advanced tab allows you to configure active/standby MAC addresses statically, static ARP entries, and anti-spoofing (uRFP) allowing full fragment reassembly.

 

Creating Sub-Interfaces

To support VLAN segmentation and logical separation of traffic, Cisco Secure Firewall allows administrators to configure sub-interfaces. These can be created by navigating to Devices > Device Management > Device-Name, and then selecting the Interfaces tab.

From there, click on Add Interfaces and choose Sub Interface from the dropdown options.

 

When defining a sub-interface, you can specify a Sub-Interface ID and associate it with a VLAN ID. This enables tagged VLAN traffic to be handled separately on the same physical interface. Additionally, you can modify other attributes like the MTU size, and bind the sub-interface to the correct parent physical interface (e.g., GigabitEthernet0/0).

Once the sub-interface is created, head over to the IPv4 tab to assign an IP address. You can set the IP type to static, DHCP, or PPPoE, depending on your network architecture. In routed deployments, setting a static IP address, such as 192.168.201.1/24, is a common choice for clarity and control.

 

Configuring ERSPAN Passive Mode

Cisco Secure Firewall supports Encapsulated Remote Switch Port Analyzer (ERSPAN) mode for passive traffic monitoring. ERSPAN allows administrators to mirror traffic from one or more source ports across distributed switches and forward that traffic to the firewall over a GRE tunnel for deep inspection. This is particularly useful for out-of-band monitoring scenarios in complex networks.

ERSPAN interfaces are only supported when Secure Firewall is operating in routed mode, not transparent. To configure an ERSPAN interface, navigate to Devices > Device Management, select the device, and access the Interfaces tab. From there, edit the interface you want to designate for ERSPAN.

In the interface settings, set the mode to ERSPAN, provide a name, and enable the interface. Under the General tab, you’ll also configure the Flow ID and Source IP, both of which are required for GRE encapsulation and identifying traffic flows.

 

Next, go to the IPv4 tab to assign an IP address and subnet to the ERSPAN interface. This address must match the network design used by the source switches sending ERSPAN traffic.

 

To validate the ERSPAN session, use the following CLI commands on Secure Firewall:

show run interface g0/0
show log

These commands help verify interface configuration and monitor log entries related to ERSPAN traffic.

Once ERSPAN is active, navigate to Analysis > Connection Events in the Secure Firewall Management Center. Here, you can observe ERSPAN traffic, including details such as initiator/responder IPs, ports, and applied access control policies. Events will clearly indicate ERSPAN as the ingress interface, confirming that mirrored traffic is being received and inspected.

This setup allows Secure Firewall to function as a centralized traffic analysis and threat detection point without directly participating in the traffic flow—making ERSPAN mode ideal for out-of-band monitoring, compliance validation, and forensic capture scenarios.

 

Routed Interface Behavior

Routed interfaces are available only in routed deployments and align with a traditional Layer 3 firewall design. These interfaces, whether physical or logical (such as VLAN-tagged sub-interfaces), support full L3 capabilities. This includes integration with NAT, dynamic routing protocols, and policy-based routing.

Traffic through routed interfaces is forwarded based on route lookups, with the next-hop address resolved using ARP. Because of this, routed interfaces can drop traffic if no valid route exists or if ARP resolution fails. Furthermore, traffic on routed interfaces undergoes thorough inspection through both the LINA engine and Snort engine, ensuring that full deep packet inspection and threat detection are enforced.

This design provides a robust and flexible routing and inspection architecture, ideal for enterprise deployments that require segmentation, redundancy, and advanced policy enforcement.

 

Inline Sets and IPS Mode

Cisco Secure Firewall supports the configuration of Inline Sets to enable inline IPS mode with transparent firewalling. This setup is intended for use cases where you want to deploy Next-Generation Intrusion Prevention System (NGIPS) functionality only, without the broader Next-Generation Firewall (NGFW) feature set such as NAT, ACLs, or L3/L4 routing.

To create an inline set, navigate to Devices > Device Management, select the target device, and go to the Inline Sets tab. Click the Add Inline Set button to create a new inline set.

 

From there, you can configure a new set by specifying a name, MTU, and optionally enabling the FailSafe option. You’ll also assign a pair of physical interfaces (e.g., INSIDE <-> OUTSIDE) to form the inline set. When FailSafe is enabled, traffic will continue to pass through even if the Secure Firewall system fails, ensuring network continuity.

You also have the option to propagate link state, which helps maintain consistent link behavior. If one interface in the pair goes down, the other will automatically be brought down as well, preserving end-to-end link integrity.

 

Configuring an Inline Pair effectively bridges two physical interfaces, similar to how classic IPS systems operate. This setup is available in both routed and transparent firewall deployment modes. However, it’s important to note that many ASA engine features, such as NAT, L3/L4 routing, and ACLs , are not supported for traffic flowing through an inline pair. Instead, this traffic is inspected by the Snort engine, and only a few LINA engine checks are applied. Inline sets are best suited for deep packet inspection and intrusion detection/prevention scenarios where full NGFW capabilities are not required.

Additionally, Cisco Secure Firewall also supports Inline Tap operation. In this mode, two physical interfaces are bridged similarly to an inline pair, but with a key difference: traffic is not dropped. Instead, Secure Firewall applies Snort engine checks to a copy of the traffic rather than acting as a gatekeeper. This is ideal for passive monitoring environments where visibility is critical, but you don’t want the firewall to interrupt traffic flow.

Inline IPS and tap modes are valuable tools in your security arsenal, especially when deploying Secure Firewall in environments where deep visibility and threat detection are prioritized over enforcement and policy-based traffic control.

 

DHCP Services

Cisco Secure Firewall offers integrated DHCP functionality, allowing administrators to configure the firewall as a DHCP server directly from the management interface. This capability is useful in smaller or branch office deployments where an external DHCP server might not be present. By enabling the DHCP service on a selected interface, the firewall can dynamically assign IP addresses, subnet masks, default gateways, and DNS information to connected clients. You can configure this under the DHCP tab of the device.

 

In addition to acting as a DHCP server, Secure Firewall can also function as a DHCP relay agent, forwarding DHCP requests from clients to a central DHCP server located elsewhere in the network. This is particularly useful in segmented network designs where DHCP services need to be centralized.

 

For environments that utilize Dynamic DNS (DDNS), Secure Firewall allows configuration of DDNS settings in the same DHCP section. This enables the firewall to update DNS records dynamically as DHCP leases are issued or released, helping maintain accurate name resolution for dynamically assigned hosts.

 

Whether serving as the authoritative DHCP server or forwarding requests as a relay, these features allow Secure Firewall to integrate more tightly into core network services without relying on external appliances.

 

Secure Firewall Routing

When configuring routing on a Cisco Secure Firewall appliance, administrators can access the relevant settings through the management interface by navigating to Device Management > Device > Routing. This is the central location within the Secure Firewall Management Center  where all routing protocols and static route configurations are defined and managed.

 

Secure Firewall supports a wide range of routing protocols to meet different networking requirements and deployment environments. Among the supported protocols are OSPF (Open Shortest Path First) and OSPFv3, EIGRP, RIP (Routing Information Protocol), and BGP (Border Gateway Protocol). EIGRP, OSPF and OSPFv3 are used for dynamic routing in both IPv4 and IPv6 scenarios. RIP is available for simpler or legacy network scenarios. BGP allows for scalable inter-domain routing and is commonly used in ISP and enterprise edge deployments.

Administrators can also configure Static Routes, which are essential for deterministic routing or in environments where dynamic protocols are unnecessary or undesired. For multicast traffic, Multicast Routing support is available, which allows the Secure Firewall to efficiently distribute streaming or real-time data to multiple recipients across the network using protocols like PIM (Protocol Independent Multicast).

Overall, the Secure Firewall platform offers robust and flexible routing capabilities directly integrated into the management center, enabling secure and efficient traffic handling across complex enterprise and service provider networks.

 

Configuring BGP

Cisco Secure Firewall supports the same BGP configuration features as the classic ASA platform. However, unlike ASA where BGP is configured via CLI, Secure Firewall relies on the FMC GUI for BGP configuration. Therefore, familiarity with FMC’s interface and its routing configuration options is essential.

Step 1: Enable BGP and Define Your AS Number

To begin, navigate to the Routing tab for your Secure Firewall device in FMC.

  • Under General Settings> BGP, Check the box labeled Enable BGP
  • Enter your Autonomous System (AS) Number
    Acceptable formats include:

    • 16-bit: 1–65535
    • 32-bit: 1.0 – 65535.65535 or 1–4294967295
  • Click Save after entering your AS number.

 

Step 2: Enable BGP for IPv4 or IPv6

Expand the BGP folder in the FMC navigation pane and choose either IPv4 or IPv6, depending on your deployment.

  • Check the box for Enable IPv4 or Enable IPv6
  • Your previously configured AS number should be auto-filled

At this point, tabs will appear for:

  • General
  • Neighbor
  • Aggregate Address
  • Filtering
  • Networks
  • Redistribution
  • Route Injection

 

Step 3: Add a BGP Neighbor

Click the Neighbor tab and then Add to begin configuring a BGP peer.

In the Add Neighbor window:

  • Enter the IP Address of your BGP peer (e.g., 192.1.20.2)
  • Enter the Remote AS Number (e.g., 10000)
  • Optionally, provide a description

Check the box labeled Enable Address to activate the neighbor.

 

 

 

Step 4: Configure Networks for Advertisement

Go to the Networks tab and click Add to specify which internal networks should be advertised to your BGP neighbors.

  • Each network entry can be paired with an optional Route Map if policy-based control is desired.

 

Step 5: Enable Authentication (Optional but Recommended)

For added security, go to the Advanced tab in the neighbor configuration window:

  • Check Enable Authentication
  • Enter a Password and Confirm Password
  • Optionally configure Encryption, Graceful Restart, and other advanced options depending on your topology and requirements

Click OK to finalize the neighbor configuration.

 

Step 6: Configure Route Redistribution (If Needed)

If you want to redistribute routes from another routing protocol (e.g., OSPF, static routes) into BGP:

  • Go to the Redistribution tab
  • Click Add

 

  • Choose the Source Protocol, define metrics, and optionally apply a Route Map for more granular control

 

Step 7: Save and Deploy

After all BGP parameters and optional settings are configured:

  • Click Save
  • Deploy the policy to your Secure Firewall device to apply the BGP settings

 

Configuring Multihop BGP, Route Maps, and Prefix Lists

In certain scenarios, such as eBGP peering across multiple hops or when peers are not directly connected, you may need to configure multihop BGP on Cisco Secure Firewall. FMC makes this possible through the Advanced tab in the neighbor settings.

Step 8: Enable Multihop BGP

To allow BGP sessions with neighbors that are not directly connected:

  • In your existing BGP neighbor configuration, click the Advanced tab.
  • Under TTL Hops, check the box for Allow connections with neighbor that is not directly connected.
  • You can also define the TTL value (1–255) to limit how far the BGP packets can travel.

This option is crucial for multihop BGP scenarios, such as when traversing firewalls, load balancers, or intermediate routers.

 

Step 9: Add Networks with Optional Route Maps

To advertise specific networks:

  • Navigate to the Networks tab under the desired address family (IPv4 or IPv6).
  • Click Add and input the Network prefix you wish to advertise.

 

 

  • Optionally, apply a Route Map to control how or whether routes are advertised.

This allows for granular control over BGP route advertisement based on filters, match conditions, and policy logic.

 

Step 10: Create a Prefix List (Optional but Recommended)

Using prefix lists in BGP redistribution or filtering is a best practice. To create one:

  • Go to Objects > Object Management > Prefix List > IPv4 Prefix List.
  • Click Add IPv4 Prefix List and name it (e.g., HQ).

 

  • Add entries specifying the IP Prefix, Minimum, and Maximum Prefix Length, and set the Action to Allow or Deny.

 

  • Check Add to add the prefix.

This step is helpful when you want to restrict route redistribution to only a specific set of prefixes.

 

Step 11: Create a Route Map

With your prefix list ready, now create a route map that references it:

  • Navigate to Objects > Object Management > Route Map.
  • Click Add Route Map, name it (e.g., HQ_S_2_BGP), and then Add a new sequence.

 

 

  • Click the Add button

 

  • Under the Match > IPv4 > Address section, select Prefix List, and pick your previously defined list (HQ).

 

  • Save the route map.

You now have a complete route map object ready for use in redistribution or outbound route policies.

 

Step 12: Apply the Route Map to BGP Redistribution

To finish the integration:

  • Go back to your BGP configuration.
  • Click the Redistribution tab and then Add.

 

  • Set Source Protocol to Connected, Static, or any other you’re redistributing from.
  • Choose your Route Map from the dropdown.
  • Define metrics as needed and click OK.

This links your prefix control logic to your BGP process, ensuring only approved routes are advertised.

 

Advanced BGP Filtering and Attribute Control

Beyond enabling BGP and adding neighbors, Cisco Secure Firewall offers powerful options to control route advertisements using ACLs, prefix lists, route maps, and AS path filters. These tools provide granular control over what routes are advertised, received, or suppressed—essential for environments requiring policy enforcement and route hygiene.

Step 13: Filter BGP Routes Using ACLs

You can apply Access Control Lists (ACLs) to filter specific routes during BGP updates.

  • Go to Objects > Object Management > Access Lists > Standard.
  • Click Add Standard Access List.

 

  • Use the block action for networks you want to prevent from advertising and add a final permit any entry to avoid dropping all traffic.
  • Save the ACL.

 

Next:

  • Navigate to your BGP address family and go to the Filtering tab.
  • Click Add

 

  • Select the ACL, direction (inbound or outbound), and protocol (optional).
  • Click OK to apply.

 

Step 14: Configure Aggregate Routes with Attribute Maps

To summarize routes into aggregates:

  • Go to your BGP configuration and open the Aggregate Address tab.
  • Click Add

 

  •  Specify:
    • The aggregate network (e.g., 11.11.60.0/24)
    • Optional attribute map, advertise map, or suppress map
    • Enable AS set path generation if needed
    • Optionally check Filter all routes from updates to restrict inherited routes

This allows the Secure Firewall to advertise a summarized route while managing what contributes to the aggregate and what is suppressed.

 

Step 15: Define Per-Peer Prefix and AS Path Filters

For more targeted control:

  • Navigate to Objects > Object Management > Prefix List > IPv4 Prefix List and create a prefix list (e.g., DEFAULT, Internal_Subnets).

 

  • Optionally create an AS Path object under Objects > Object Management > AS Path
  • Click Add AS Path

 

  • Using regex to match local or remote AS patterns (e.g., ^$ for local-only routes).
  • Save the entries.

 

Step 16: Build Route Maps

With prefix and AS path lists in place, build a Route Map:

  • Go to Objects > Object Management > Route Map and click Add Route Map.

 

  • Create a Route Map Entry with:
    • Match clause using the prefix list

 

      • Optional AS path match or ACL

 

      • Under Set Clauses, configure actions such as:
        • Prepend AS Path
        • Apply Community attributes
        • Adjust Metric values
        • Set local preference, next hop, or origin under the Others tab

Use multiple sequences (e.g., 10, 20, etc.) to handle different match conditions.

 

Step 17: Assign Route Maps to Neighbors

To apply policies to specific peers:

  • Go back to your BGP Neighbor tab in the Device and either click the pencil to edit an existing neighbor or click Add to add a new neighbor.
  • Under the Filtering Routes tab, assign:
    • Access List (optional)
    • Route Map for incoming and outgoing updates
    • Prefix List
    • AS Path Filter

 

  • Set prefix limits and thresholds if needed (e.g., max 1000 prefixes with 75% warning threshold).

 

  • Save the neighbor config.

This per-peer granularity ensures precise routing policy enforcement.

 

 

Step 18: Verifying BGP from CLI

To verify BGP status and routing behavior from the Secure Firewall CLI, use the following commands:

  • show bgp
  • show route bgp
  • show bgp neighbors
  • show bgp summary

These outputs provide visibility into peer state, route tables, path attributes, and potential errors.

 

Conclusion

Cisco Secure Firewall with FMC delivers an enterprise-grade BGP implementation, enabling rich routing policies through the GUI. Whether you need:

  • Multihop BGP
  • Prefix/AS-path filtering
  • Aggregate route summaries
  • Attribute-based route manipulation
  • Per-peer inbound/outbound policy enforcement

…Secure Firewall gives you the tools to shape your routing behavior precisely. With proper configuration, it supports complex hybrid deployments, upstream provider policies, and internal segmentation.