Configuring FDM-Managed Devices

Interfaces

You can use Security Cloud Control to configure and edit data interfaces or the management/diagnostic interface on an FDM-managed device.

At this time, Security Cloud Control can only configure routed interfaces and bridge groups. It does not support the configuration passive interfaces.

Guidelines and Limitations for Firepower Interface Configuration

When you use Security Cloud Control to configure the device, there are several limitations to interface configuration. If you need any of the following features, you must use Firepower Management Center to configure the device.

Firewall

  • Routed firewall mode only is supported. You cannot configure transparent firewall mode interfaces.

  • Only physical firepower 1010 devices support interfaces configured for switch port mode. See Switch Port Mode Interfaces for an FDM-Managed Device for more information.

Passive

  • At this time, Security Cloud Control does not identify passive interface mode in the interface table ad you cannot configure passive or ERSPAN interfaces. You must use the FDM-managed UI to configure and identify passive interfaces.

IPS-Only Mode

  • You cannot configure interfaces to be inline (in an inline set), or inline tap, for IPS-only processing. IPS-only mode interfaces bypass many firewall checks and only support IPS security policy. In comparison, Firewall mode interfaces subject traffic to firewall functions such as maintaining flows, tracking flow states at both IP and TCP layers, IP defragmentation, and TCP normalization.

  • Optionally, you can configure IPS functions for this firewall mode traffic according to your security policy.

EtherChannel

Security Cloud Control supports read, create, and abilities for devices running Version 6.5 and later. To create Etherchannel interfaces, see Add an EtherChannel Interface for an FDM-Managed Device for more information. To create

  • You can configure up to 48 EtherChannels on physical Firepower devices, although how many interfaces can be active at a time depends on your device model. For device-specific limitations, see Device-Specific Requirements.

  • All interfaces in the channel group must be the same media type and capacity, and must be set to the same speed and duplex. The media type can be either RJ-45 or SFP; SFPs of different types (copper and fiber) can be mixed. You cannot mix interface capacities (for example 1GB and 10GB interfaces) by setting the speed to be lower on the larger-capacity interface.

  • The device to which you connect the EtherChannel must also support 802.3ad EtherChannels.

  • The FDM-managed device does not support LACPDUs that are VLAN-tagged. If you enable native VLAN tagging on the neighboring switch using the Cisco IOS vlan dot1Q tag native command, then the FDM-managed device will drop the tagged LACPDUs. Be sure to disable native VLAN tagging on the neighboring switch.

  • All FDM-managed device configuration refers to the logical EtherChannel interface instead of the member physical interfaces.


    Note

    Interfaces set up as portchannels can only use physical interfaces, redundant interfaces, and subinterfaces are supported as bridge group member interfaces.

Bridge Groups

At this time, Security Cloud Control supports the configuration of one bridge group. To determine if your device supports bridge groups, see Bridge Group Compatibility in FDM-Managed Device Configurations for more information.

When adding an interface to a bridge group, keep the following in mind:

  • The interface must have a name.

  • The interface cannot have any IPv4 or IPv6 addresses defined for it, either static or served through DHCP.

  • BVI can have either VLAN interfaces or other routed interfaces as a member interface, but you cannot have both as member interfaces on a single BVI.

  • BVI can have either VLAN interfaces or other routed interfaces as a member interface, but you cannot have both as member interfaces on a single BVI.

  • The interface cannot be Point-to-Point Protocol over Ethernet (PPPoE)

  • The interface cannot be associated with a security zone (if it is in a zone). You must delete any NAT rules for the interface before you can add it to a bridge group.

  • Enable and disable the member interfaces individually. Thus, you can disable any unused interfaces without needing to remove them from the bridge group. The bridge group itself is always enabled.

  • You can configure the interfaces that will be members of the bridge group. See Configure a Bridge Group for interface requirements and creation.

Point-to-Point Protocol over Ethernet

  • You cannot configure Point-to-Point Protocol over Ethernet (PPPoE) for IPv4. If the Internet interface is connected to a DSL, cable modem, or other connection to your ISP, and your ISP uses PPPoE to provide your IP address, you must use the FDM to configure these settings.

VLAN

To configure VLAN interfaces and VLAN members, see Configure an FDM-Managed Device VLAN for more information. To configure VLAN for switch port mode, see Configure an FDM-Managed Device VLAN for Switch Port Mode for more information.

  • The interface must be physical.

  • The interface cannot be management-only.

  • The interface cannot be associated as any other type of interface, including BVI, subinterfaces, another VLAN interface, EtherChannel, etc.

  • The interface cannot be a BVI member or an etherchannel member.

  • Device models support varying numbers of VLAN members. See Maximum Number of VLAN Members by Device Model for more information.


    Note

    To configure VLAN for your environment, see Configure Firepower VLAN Subinterfaces and 802.1Q Trunking for more information.

Network Module Cards

Optional network module installations are limited to the ASA 5515-X, 5525-X, 5545-X, and 5555-X, and the Firepower 2100 series devices.

  • Cards are only discovered during bootstrap (that is, initial installation or reimage, or when switching between local/remove management). Security Cloud Control sets the correct defaults for speed and duplex for these interfaces. If you replace an optional card with one that changes the speed/duplex options for the interfaces, without changing the total number of interfaces available, reboot the device so that the system recognizes the correct speed/duplex values for the replaced interfaces. From an SSH or Console session with the device, enter the reboot command. Then, using Security Cloud Control, edit each physical interface that had capability changes and select valid speed and duplex options, as the system does not automatically correct your original settings. Deploy your changes right away to ensure correct system behavior.

  • You cannot enable or disable network modules or perform breakout online insertion and removal (OIR) of interfaces on FDM-managed Secure Firewall 3100 series devices.


  • Note

    Replacing a card with one that changes the total number of interfaces, or removing interfaces that were referred to by other objects, can result in unexpected problems. If you need to make this kind of change, please first remove all references to the interfaces you will remove, such as security zone membership, VPN connections, and so forth. We also suggest you do a backup prior to making the change.

Interfaces on Virtual FDM-Managed Devices

  • You cannot add or remove interfaces without reinitializing a virtual FDM-managed device. You must execute these actions in an FDM-managed device.


    Note

    If you replace interfaces with ones that have different speed/duplex capabilities, reboot the device so that the system recognizes the new speed/duplex values with the following procedure: from the device's CLI console, enter the reboot command. Then, in Security Cloud Control, edit each interface that had capability changes and select valid speed and duplex options, as the system does not automatically correct your original settings. Deploy your changes right away to ensure correct system behavior.

Maximum Number of VLAN Members by Device Model

The device model limits the maximum number of VLAN subinterfaces that you can configure. Note that you can configure subinterfaces on data interfaces only, you cannot configure them on the management interface. The following table explains the limits for each device model.

Model

Maximum VLAN Subinterfaces

Firepower 1010

60

Firepower 1120

512

Firepower 1140, Firepower 1150

1024

Firepower 2100

1024

Secure Firewall 3100

1024

Firepower 4100

1024

Firepower 9300

1024

ASA 5508-X

50

ASA 5515-X

100

ASA 5516-X

100

ASA 5525-X

200

ASA 5545-X

300

ASA 5555-X

500

ISA 3000

100

Firepower Data Interfaces

Security Cloud Control supports configuring routed interfaces and bridge virtual interfaces on FDM-managed devices.

Routed Interfaces

Each Layer 3 routed interface (or subinterface) requires an IP address on a unique subnet. You would typically attach these interfaces to switches, a port on another router, or to an ISP/WAN gateway.

You can assign a static address, or you can obtain one from a DHCP server. However, if the DHCP server provides an address on the same subnet as a statically-defined interface on the device, the system will disable the DHCP interface. If an interface that uses DHCP to get an address stops passing traffic, check whether the address overlaps the subnet for another interface on the device.

You can configure both IPv6 and IPv4 addresses on a routed interface. Make sure you configure a default route for both IPv4 and IPv6. This task will need to be performed on the FDM-managed device using Firepower Device Manager. See "Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager, Version x.x.x", The Basics > Routing for information about configuring a default route.

Bridge Groups and Bridge Virtual Interfaces

A bridge group is a group of interfaces that the FDM-managed device bridges instead of routes. Bridged interfaces belong to a bridge group, and all interfaces are on the same network. The bridge group is represented by a Bridge Virtual Interface (BVI) that has an IP address on the bridge network. Interfaces included in the bridge group are called "members."

You can route between routed interfaces and BVIs, if you name the BVI. In this case, the BVI acts as the gateway between member interfaces and routed interfaces. If you do not name the BVI, traffic on the bridge group member interfaces cannot leave the bridge group. Normally, you would name the interface so that you can route member interfaces to the Internet.

FDM-managed devices only support one bridge group, therefore, Security Cloud Control can only manage that one bridge group and cannot create additional bridge groups on the device. Security Cloud Control can only manage BVIs on FDM-managed devices installed directly on hardware, not on virtual FDM-managed device instances.

One use for a bridge group in routed mode is to use extra interfaces on the FDM-managed device instead of an external switch. You can attach endpoints directly to bridge group member interfaces. You can also attach switches to add more endpoints to the same network as the BVI.

Passive Interfaces

Passive interfaces monitor traffic flowing across a network using a switch SPAN (Switched Port Analyzer) or mirror port. The SPAN or mirror port allows for traffic to be copied from other ports on the switch. This function provides the system visibility within the network without being in the flow of network traffic. When configured in a passive deployment, 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.

At this time, Security Cloud Control has limited support for managing passive interfaces on the FDM-managed device:

  • Passive interfaces must be configured on the FDM-managed device.

  • Routed interfaces cannot be changed to passive interfaces and passives interfaces cannot be changed to routed interfaces using Security Cloud Control.

  • Security Cloud Control does not identify passive interfaces in the interface table.

Management/Diagnostic Interface

The physical port labeled Management (or for FDM-managed device virtual, the Management 0/0 virtual interface) actually has two separate interfaces associated with it.

  • Management virtual interface-This IP address is used for system communication. This is the address the system uses for Smart Licensing and to retrieve database updates. You can open management sessions to it (Firepower Device Manager and CLI). You must configure a management address, which is defined on System Settings > Management Interface.

  • Diagnostic physical interface-The physical Management port is actually named Diagnostic. You can use this interface to send syslog messages to an external syslog server. Configuring an IP address for the Diagnostic physical interface is optional. The only reason to configure the interface is if you want to use it for syslog. This interface appears, and is configurable, on the Security Devices > Interfaces page. The Diagnostic physical interface only allows management traffic, and does not allow through traffic.

(Hardware devices.) The recommended way to configure Management/Diagnostic is to not wire the physical port to a network. Instead, configure the Management IP address only, and configure it to use the data interfaces as the gateway for obtaining updates from the Internet. Then, open the inside interfaces to HTTPS/SSH traffic (by default, HTTPS is enabled) and open Firepower Device Manager using the inside IP address. This task you must perform on Firepower Device Manager directly. See "Configuring the Management Access List" in the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for instructions.

For FDM-managed device virtual, the recommended configuration is to attach Management0/0 to the same network as the inside interface, and use the inside interface as the gateway. Do not configure a separate address for Diagnostic.


Note

For special instructions on how to edit the Management interface see Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for Firepower version 6.4 or higher. Open the guide and navigate to The Basic > Interfaces > Management/Diagnostic Interface. Management interface configuration should be done on the Firepower Device Manager.

Interface Settings

Use these topics to configure interface settings.

Use of Security Zones in Firepower Interface Settings

Each interface can be assigned to a single security zone. You then apply your security policy based on zones. For example, you can assign the inside interface to the inside zone; and the outside interface to the outside zone. You can configure your access control policy to enable traffic to go from inside to outside, but not from outside to inside, for example.

Each zone has a mode, either routed or passive. This relates directly to the interface mode. You can add routed and passive interfaces only to the same mode security zone.

Bridge Virtual Interfaces (BVIs) are not added to security zones. Only member interfaces are added to security zones.

You do not include the Diagnostic or Management interface in a zone. Zones apply to data interfaces only.

Security Cloud Control does not currently support the management, monitoring, or use of Virtual Tunnel Interface (VTI) tunnels on ASA or FDM-managed devices. Devices with configured VTI tunnels can be onboarded to Security Cloud Control but it ignores VTI interfaces. If a security zone or static route references a VTI, Security Cloud Control reads the security zone and static route without the VTI reference. Security Cloud Control support for VTI tunnels is coming soon.

See Security Zone Object for more information about security zones.

Assign an FDM-Managed Device Interface to a Security Zone

Before you Begin

An interface has the following limitations when adding a security zone:

  • The interface must have a name.

  • The interface cannot be management-only. This option is enabled and disabled from the Advanced tab of the interface.

  • You cannot assign a security zone to a bridge group interface.

  • You cannot assign a security zone to an interface configured for switchport mode.

  • Security Cloud Control does not currently support the management, monitoring, or use of Virtual Tunnel Interface (VTI) tunnels on ASA or FDM-managed devices. Devices with configured VTI tunnels can be onboarded to Security Cloud Control but it ignores VTI interfaces. If a security zone or static route references a VTI, Security Cloud Control reads the security zone and static route without the VTI reference. Security Cloud Control support for VTI tunnels is coming soon.

Assign a Firepower Interface to a Security Zone

Use the following procedure to associate a security zone to an existing interface:

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab to locate the device or the Templates tab to locate the model device.

Step 3

Click the FTD device and select the FDM-managed device you want to modify.

Step 4

In the Management pane located to the right, click Interfaces.

Step 5

Select the interface you want to add a security zone to and click Edit.

Step 6

Use the Security Zone drop-down menu and select the security zone you want associated with this interface.

Note

 

If need to, ceate a new security zone from this drop-down menu by clicking Create New.

Step 7

Click Save.

Step 8

Deploy Configuration Changes from Security Cloud Control to FDM-Managed Device.

Use of Auto-MDI/MDX in Firepower Interface Settings

For RJ-45 interfaces, the default auto-negotiation setting also includes the Auto-MDI/MDIX feature. Auto-MDI/MDIX eliminates the need for crossover cabling by performing an internal crossover when a straight cable is detected during the auto-negotiation phase. Either the speed or duplex must be set to auto-negotiate to enable Auto-MDI/MDIX for the interface. If you explicitly set both the speed and duplex to a fixed value, thus disabling auto-negotiation for both settings, then Auto-MDI/MDIX is also disabled. For Gigabit Ethernet, when the speed and duplex are set to 1000 and full, then the interface always auto-negotiates; therefore Auto-MDI/MDIX is always enabled and you cannot disable it.

These settings are configured on the Advanced tab when editing an interface.

Use of MAC Addresses in Firepower Interface Settings

You can manually configure Media Access Control (MAC) addresses to override the default value.

For a high availability configuration, you can configure both the active and standby MAC address for an interface. If the active unit fails over and the standby unit becomes active, the new active unit starts using the active MAC addresses to minimize network disruption.

Active and standby MAC addresses are configured on the Advanced tab when configuring an interface.

Default MAC Addresses

Default MAC address assignments depend on the type of interface.

  • Physical interfaces - The physical interface uses the burned-in MAC address.

  • Subinterfaces - All subinterfaces of a physical interface use the same burned-in MAC address. You might want to assign unique MAC addresses to subinterfaces. For example, your service provider might perform access control based on the MAC address. Also, because IPv6 link-local addresses are generated based on the MAC address, assigning unique MAC addresses to subinterfaces allows for unique IPv6 link-local addresses.

Use of MTU Settings in Firepower Interface Settings

About the MTU

The MTU specifies the maximum frame payload size that the FDM-managed device can transmit on a given Ethernet interface. The MTU value is the frame size without Ethernet headers, VLAN tagging, or other overhead. For example, when you set the MTU to 1500, the expected frame size is 1518 bytes including the headers, or 1522 when using VLAN. Do not set the MTU value higher to accommodate these headers.

Path MTU Discovery

The FDM-managed device supports Path MTU Discovery (as defined in RFC 1191), which lets all devices in a network path between two hosts coordinate the MTU so they can standardize on the lowest MTU in the path.

MTU and Fragmentation

For IPv4, if an outgoing IP packet is larger than the specified MTU, it is fragmented into 2 or more frames. Fragments are reassembled at the destination (and sometimes at intermediate hops), and fragmentation can cause performance degradation. For IPv6, packets are typically not allowed to be fragmented at all. Therefore, your IP packets should fit within the MTU size to avoid fragmentation.

For UDP or ICMP, the application should take the MTU into account to avoid fragmentation.


Note

The FDM-managed device can receive frames larger than the configured MTU as long as there is room in memory.

MTU and Jumbo Frames

A larger MTU lets you send larger packets. Larger packets might be more efficient for your network. See the following guidelines:

  • Matching MTUs on the traffic path: We recommend that you set the MTU on all FDM-managed device interfaces and other device interfaces along the traffic path to be the same. Matching MTUs prevents intermediate devices from fragmenting the packets.

  • Accommodating jumbo frames: A jumbo frame is an Ethernet packet larger than the standard maximum of 1522 bytes (including Layer 2 header and VLAN header), up to 9216 bytes. You can set the MTU up to 9198 bytes to accommodate jumbo frames. The maximum is 9000 for FDM-managed virtual.


    Note

    Increasing the MTU assigns more memory for jumbo frames, which might limit the maximum usage of other features, such as access rules. If you increase the MTU above the default 1500 on ASA 5500-X series devices or FDM-managed virtual, you must reboot the system. You do not need to reboot Firepower 2100 series devices, where jumbo frame support is always enabled.

    Jumbo frame support is enabled by default on Firepower 3100 devices.

IPv6 Addressing for Firepower Interfaces

You can configure two types of unicast IPv6 addresses for Firepower physical interfaces.

  • Global—The global address is a public address that you can use on the public network. For a bridge group, you configure the global address on the Bridge Virtual Interface (BVI), not on each member interface. You cannot specify any of the following as a global address.

    • Internally reserved IPv6 addresses: fd00::/56 (from=fd00:: to= fd00:0000:0000:00ff:ffff:ffff:ffff:ffff)

    • An unspecified address, such as ::/128

    • The loopback address, ::1/128

    • Multicast addresses, ff00::/8

    • Link-local addresses, fe80::/10

  • Link-local—The link-local address is a private address that you can only use on the directly-connected network. Routers do not forward packets using link-local addresses; they are only for communication on a particular physical network segment. They can be used for address configuration or for the Network Discovery functions such as address resolution and neighbor discovery. Each interface must have its own address because the link-local address is only available on a segment, and is tied to the interface MAC address.

At a minimum, you need to configure a link-local address for IPv6 to operate. If you configure a global address, a link-local address is automatically configured on the interface, so you do not also need to specifically configure a link-local address. If you do not configure a global address, then you need to configure the link-local address, either automatically or manually.

Configuring Firepower Interfaces

When you attach a cable to an interface connection (physically or virtually), you need to configure the interface. At minimum, you need to name the interface and enable it for traffic to pass through it. If the interface is a member of a bridge group, naming the interface is sufficient. If the interface is a bridge virtual interface (BVI), you need to assign the BVI an IP address. If you intend to create VLAN subinterfaces rather than a single physical interface on a given port, you would typically configure the IP addresses on the subinterface, not on the physical interface. VLAN subinterfaces let you divide a physical interface into multiple logical interfaces that are tagged with different VLAN IDs.

The interface list shows the available interfaces, their names, addresses, and states. You can change the state of an interface, on or off, or edit an interface, by selecting the interface row and clicking Edit in the Actions pane. The list shows the interface characteristics based on your configuration. Expand an interface row to see subinterfaces or bridge group member.

Configure a Physical Firepower Interface

At a minimum, you must enable a physical interface to use it. You would also typically name it and configure IP addressing; however, you would not configure IP addressing if you intend to create VLAN subinterfaces, if you are configuring a passive mode interface, or if you intend to add the interface to a bridge group.


Note

You cannot configure IP addresses on bridge group member interfaces or passive interfaces, although you can modify advanced settings, that are not related to IPv6 addressing.

You can disable an interface to temporarily prevent transmission on the connected network. You do not need to remove the interface's configuration. At this time, Security Cloud Control can only configure routed interfaces and bridge groups. Security Cloud Control lists passive interfaces but you cannot reconfigure them as active interfaces from Security Cloud Control.


Note

Note: Security Cloud Control does not support Point-to-Point Protocol over Ethernet (PPPoE) configurations for IPv4. Configuring this option in an FDM-managed devicemay cause isses in the Security Cloud Control UI; if you must configure PPPoE for your device, you must make the appropriate changes in an FDM-managed device.

Procedure
Procedure

Step 1

In the left pane, click Security Devices and click the device whose interfaces you want to configure and click Interfaces in the Management pane on the right.

Step 2

On the Interfaces page, select the physical interface you want to configure.

Step 3

In the Actions pane on the right, click Edit.

Step 4

Give the physical interface a Logical Name and, optionally, a Description. Unless you configure subinterfaces, the interface should have a name.

Note

 

If you change the name, the change is automatically reflected everywhere you used the old name, including security zones, syslog server objects, and DHCP server definitions. However, you cannot remove the name until you first remove all configurations that use the name, because you typically cannot use an unnamed interface for any policy or setting.

Step 5

Pick one of these options:

  • If you intend to add sub-interfaces:

If you intend to configure subinterfaces for this physical interface, you are probably done. Click Save and continue with Configure Firepower VLAN Subinterfaces and 802.1Q Trunking ; otherwise, continue.

Note

 

Even when configuring subinterfaces, it is valid to name the interface and supply IP addresses. This is not the typical setup, but if you know that is what you need, you can configure it.

Configure IPv4 Addressing for the Physical Interface

Warning

After you configure and save a DHCP address pool, the DHCP address pool is bound to the interface's configured IP address(es). If you edit the interface's subnet mask after you configure a DHCP address pool, deployments to the FDM-managed device fail. Also, if you edit the DHCP address pool in the FDM-managed console and read the configuration from an FDM-managed device to Security Cloud Control, the read fails.

Procedure

Step 1

In the "Editing Physical Interface" dialog, click the IPv4 Address tab.

Step 2

Select one of the following options from the Type field:

  • Static-Choose this option if you want to assign an address that should not change. ​Enter in the interface's IP address and the subnet mask for the network attached to the interface. For example, if you attach the 10.100.10.0/24 network, you could enter 10.100.10.1/24. Ensure that the address you enter is not the network ID or the broadcast address for the network and the address is not already used on the network.

    • Standby IP Address and Subnet Mask - If you configured high availability, and you are monitoring this interface for HA, also configure a standby IP address on the same subnet. The standby address is used by this interface on the standby device. If you do not set the standby IP address, the active unit cannot monitor the standby interface using network tests; it can only track the link state.

    • (Optional) DHCP Address Pool - Enter a a single DHCP Server IP address, or an IP address range. The range of IP addresses must be on the same subnet as the selected interface and cannot include: the IP address of the interface itself, the broadcast address, or the subnet network address. Specify the start and end address for the pool, separated by a hyphen. To temporarily disable this DHCP server, edit the server in the DHCP Servers section of the Firepower Threat Defense Device Settings page.

  • Dynamic (DHCP)-Choose this option if the address should be obtained from the DHCP server on the network. Change the following options if necessary:

    • Obtain Default Route-Whether to get the default route from the DHCP server. You would normally check this option.

    • DHCP Route Metric-If you obtain the default route from the DHCP server, enter the administrative distance to the learned route, between 1 and 255.

      Note

       

      If there is a DHCP server configured for the interface, you are shown the configuration. You can edit or delete the DHCP address pool. If you change the interface IP address to a different subnet, you must either delete the DHCP server, or configure an address pool on the new subnet, before you can save the interface changes.

Step 3

Click Save if you are done or continue with one of these procedures:

Configure IPv6 Addressing for the Physical Interface
Procedure

Step 1

In the "Editing Physical Interface" dialog, click the IPv6 Address tab.

Step 2

State-To enable IPv6 processing and to automatically configure the link-local address when you do not configure the global address, click the State slider to enable it. The link-local address is generated based on the interface MAC addresses (Modified EUI-64 format).

Note

 

Disabling IPv6 does not disable IPv6 processing on an interface that is configured with an explicit IPv6 address or that is enabled for auto configuration.

Step 3

Address Auto Configuration-Check this option to have the address automatically configured. IPv6 stateless autoconfiguration will generate a global IPv6 address only if the link on which the device resides has a router configured to provide IPv6 services, including the advertisement of an IPv6 global prefix for use on the link. If IPv6 routing services are not available on the link, you will get a link-local IPv6 address only, which you cannot access outside of the device's immediate network link. The link local address is based on the Modified EUI-64 interface ID.

Although RFC 4862 specifies that hosts configured for stateless autoconfiguration do not send Router Advertisement messages, the FDM-managed device does send Router Advertisement messages in this case. Select Suppress RA to suppress messages and conform to the RFC.

Step 4

Suppress RA-Check this box if you want to suppress router advertisements. The Firepower Threat Defense device can participate in router advertisements so that neighboring devices can dynamically learn a default router address. By default, router advertisement messages (ICMPv6 Type 134) are periodically sent out each IPv6 configured interface.

Router advertisements are also sent in response to router solicitation messages (ICMPv6 Type 133). Router solicitation messages are sent by hosts at system startup so that the host can immediately autoconfigure without needing to wait for the next scheduled router advertisement message.

You might want to suppress these messages on any interface for which you do not want the Firepower Threat Defense device to supply the IPv6 prefix (for example, the outside interface).

Step 5

Link-Local Address-If you want to use the address as link local only, enter it in the Link-Local Address field. Link local addresses are not accessible outside the local network. You cannot configure a link-local address on a bridge group interface.

Note

 

A link-local address should start with FE8, FE9, FEA, or FEB, for example fe80::20d:88ff:feee:6a82. Note that we recommend automatically assigning the link-local address based on the Modified EUI-64 format. For example, if other devices enforce the use of the Modified EUI-64 format, then a manually-assigned link-local address may cause packets to be dropped.

Step 6

Standby Link-Local Address-Configure this address if the interface connects a high availability pair of devices. Enter the link-local address of the interface on the other FDM-managed device, to which this interfaces is connected.

Step 7

Static Address/Prefix—If you do not use stateless autoconfiguration, enter the full static global IPv6 address and network prefix. For example, 2001:0DB8::BA98:0:3210/48. For more information on IPv6 addressing, see IPv6 Addressing for Firepower Interfaces.

Step 8

Standby IP Address-If you configure high availability, and you are monitoring this interface for HA, also configure a standby IPv6 address on the same subnet. The standby address is used by this interface on the standby device. If you do not set the standby IP address, the active unit cannot monitor the standby interface using network tests; it can only track the link state.

Step 9

Click Save if you are done or continue with one of these procedures:

Enable the Physical Interface
Procedure

Step 1

Select the interface you want to enable.

Step 2

Slide the State slider at the top right of the window, associated with the interface's logical name to blue.

Step 3

Review and deploy now the changes you made, or wait and deploy multiple changes at once.

Configure Firepower VLAN Subinterfaces and 802.1Q Trunking

VLAN subinterfaces let you divide a physical interface into multiple logical interfaces that are tagged with different VLAN IDs. An interface with one or more VLAN subinterfaces is automatically configured as an 802.1Q trunk. Because VLANs allow you to keep traffic separate on a given physical interface, you can increase the number of interfaces available to your network without adding additional physical interfaces or devices.

Create subinterfaces if you attach the physical interface to a trunk port on a switch. Create a subinterface for each VLAN that can appear on the switch trunk port. If you attach the physical interface to an access port on the switch, there is no point in creating a subinterface.


Note

You cannot configure IP addresses on bridge group member interfaces, although you can modify advanced settings as needed.

Before You Begin

Prevent untagged packets on the physical interface. If you use subinterfaces, you typically do not also want the physical interface to pass traffic, because the physical interface passes untagged packets. Because the physical interface must be enabled for the subinterface to pass traffic, ensure that the physical interface does not pass traffic by not naming the interface. If you want to let the physical interface pass untagged packets, you can name the interface as usual.

Procedure
Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab to locate the device or the Templates tab to locate the model device.

Step 3

Click the FTD tab and click the device whose interfaces you want to configure.

Step 4

Click Interfaces in the Management pane at the right.

Step 5

On the Interfaces page, select the physical interface you want to configure and in the Actions pane at the right, click + New Subinterface.

Notice that the Parent Interface field shows the name of the physical interface for which you are creating this subinterface. You cannot change the parent interface after you create the subinterface.

Step 6

Give the subinterface a logical name and, optionally, a description. Without a logical name, the rest of the interface configuration is ignored.

Note

 

If you change the name, the change is automatically reflected everywhere you used the old name, including security zones, syslog server objects, and DHCP server definitions. However, you cannot remove the name until you first remove all configurations that use the name, because you typically cannot use an unnamed interface for any policy or setting.

Step 7

Configure the VLAN ID and Subinterface ID:

  • VLAN ID - Enter a VLAN ID between 1 and 4094 that will be used to tag the packets on this subinterface.

  • Subinterface ID - Enter the subinterface ID as an integer between 1 and 4294967295. The number of subinterfaces allowed depends on your platform. You cannot change the subinterace ID after you create the subinterface.

Continue with Configure IPv4 Addressing for the Subinterface and Configure IPv6 Addressing for the Subinterface.

Configure IPv4 Addressing for the Subinterface
Procedure

Step 1

In the "Adding Subinterface" dialog, click the IPv4 Address tab.

Step 2

Select one of the following options from the Type field:

  • Static-Choose this option if you want to assign an address that should not change.

    Enter in the interface's IP address and the subnet mask for the network attached to the interface. For example, if you attach the 10.100.10.0/24 network, you could enter 10.100.10.1/24. Ensure that the address you enter is not the network ID or the broadcast address for the network and the address is not already used on the network.

  • Enter a Standby IP Address and Subnet Mask only if this interface is being used in a high availability pair of devices.

  • Dynamic (DHCP)-Choose this option if the address should be obtained from the DHCP server on the network. Change the following options if necessary:

    • Obtain Default Route-Whether to get the default route from the DHCP server. You would normally check this option.

    • DHCP Route Metric-If you obtain the default route from the DHCP server, enter the administrative distance to the learned route, between 1 and 255.

      See Configuring DHCP Server.

      Note

       

      If there is a DHCP server configured for the interface, you are shown the configuration. You can edit or delete the DHCP address pool. If you change the interface IP address to a different subnet, you must either delete the DHCP server, or configure an address pool on the new subnet, before you can save the interface changes.

Step 3

Click Create if you are done or continue with one of these procedures:

Configure IPv6 Addressing for the Subinterface
Procedure

Step 1

Click the IPv6 Address tab.

Step 2

Enable IPv6 processing-To enable IPv6 processing and to automatically configure the link-local address when you do not configure the global address, move the State slider to blue. The link-local address is generated based on the interface MAC addresses (Modified EUI-64 format).

Note

 

Disabling IPv6 does not disable IPv6 processing on an interface that is configured with an explicit IPv6 address or that is enabled for auto configuration.

Step 3

Address Auto Configuration-Check this option to have the address automatically configured. IPv6 stateless auto configuration will generate a global IPv6 address only if the link on which the device resides has a router configured to provide IPv6 services, including the advertisement of an IPv6 global prefix for use on the link. If IPv6 routing services are not available on the link, you will get a link-local IPv6 address only, which you cannot access outside of the device's immediate network link. The link local address is based on the Modified EUI-64 interface ID.

Step 4

Suppress RA-Check this box if you want to suppress router advertisements. The Firepower Threat Defense device can participate in router advertisements so that neighboring devices can dynamically learn a default router address. By default, router advertisement messages (ICMPv6 Type 134) are periodically sent out each IPv6 configured interface.

Router advertisements are also sent in response to router solicitation messages (ICMPv6 Type 133). Router solicitation messages are sent by hosts at system startup so that the host can immediately autoconfigure without needing to wait for the next scheduled router advertisement message.

You might want to suppress these messages on any interface for which you do not want the Firepower Threat Defense device to supply the IPv6 prefix (for example, the outside interface).

Step 5

Link-Local Address-If you want to use the address as link local only, enter it in the Link-Local Address field. Link local addresses are not accessible outside the local network.

Note

 

A link-local address should start with FE8, FE9, FEA, or FEB, for example fe80::20d:88ff:feee:6a82. Note that we recommend automatically assigning the link-local address based on the Modified EUI-64 format. For example, if other devices enforce the use of the Modified EUI-64 format, then a manually-assigned link-local address may cause packets to be dropped.

Step 6

Standby Link-Local Address-Configure this address if your interface connects a high availability pair of devices.

Step 7

Static Address/Prefix-If you do not use stateless autoconfiguration, enter the full static global IPv6 address and network prefix. For example, 2001:0DB8::BA98:0:3210/48. For more information on IPv6 addressing, see IPv6 Addressing, on page 136.

Step 8

Standby IP Address-If you configure high availability, and you are monitoring this interface for HA, also configure a standby IPv6 address on the same subnet. The standby address is used by this interface on the standby device. If you do not set the standby IP address, the active unit cannot monitor the standby interface using network tests; it can only track the link state.

Step 9

Click Create if you are done or continue with one of these procedures:

Enable the Physical Interface
Procedure

Step 1

To enable the subinterface, slide the State slider, associated with the subinterface's logical name to blue.

Step 2

Review and deploy now the changes you made, or wait and deploy multiple changes at once.

Configure Advanced Firepower Interface Options

Advanced interface options have default settings that are appropriate for most networks. Configure them only if you are resolving networking problems.

The following procedure assumes the interface is already defined. You can also edit these settings while initially editing or creating the interface.

This procedure and all of the steps in it are optional.

Limitations:

  • You cannot set MTU, duplex, or speed for the Management interface on a Firepower 2100 series device.

  • The MTU of an unnamed interface must be set to 1500 bytes.

Procedure

Step 1

In the navigation pane, click Security Devices.

Step 2

Click the Devices tab to locate the device or the Templates tab to locate the model device.

Step 3

Click the FTD tab and click the device whose interfaces you want to configure.

Step 4

Click Interfaces in the Management pane at the right.

Step 5

On the Interfaces page, select the physical interface you want to configure and in the Actions pane at the right, click Edit.

Step 6

Click the Advanced tab.

Step 7

Enable for HA Monitoring is automatically enabled. When this is enabled, the device includes the health of the interface as a factor when the HA pair decides whether to fail over to the peer unit in a high availability configuration. This option is ignored if you do not configure high availability. It is also ignored if you do not configure a name for the interface.

Step 8

To make a data interface management only, check Management Only.

A management only interface does not allow through traffic, so there is very little value in setting a data interface as a management only interface. You cannot change this setting for the Management/Diagnostic interface, which is always management only.

Step 9

Modify the IPv6 DHCP configuration settings.

  • Enable DHCP for IPv6 address configuration - Whether to set the Managed Address Configuration flag in the IPv6 router advertisement packet. This flag informs IPv6 autoconfiguration clients that they should use DHCPv6 to obtain addresses, in addition to the derived stateless autoconfiguration address.

  • Enable DHCP for IPv6 non-address configuration - Whether to set the Other Address Configuration flag in the IPv6 router advertisement packet. This flag informs IPv6 autoconfiguration clients that they should use DHCPv6 to obtain additional information from DHCPv6, such as the DNS server address.

Step 10

Configure DAD Attempts - How often the interface performs Duplicate Address Detection (DAD), from 0 - 600. The default is 1. During the stateless auto configuration process, DAD verifies the uniqueness of new unicast IPv6 addresses before the addresses are assigned to interfaces. If the duplicate address is the link-local address of the interface, the processing of IPv6 packets is disabled on the interface. If the duplicate address is a global address, the address is not used. The interface uses neighbor solicitation messages to perform Duplicate Address Detection. Set the value to 0 to disable duplicate address detection (DAD) processing.

Step 11

Change the MTU (maximum transmission unit) to the desired value.

The default MTU is 1500 bytes. You can specify a value from 64 - 9198 (or 9000, for Firepower Threat Defense Virtual). Set a high value if you typically see jumbo frames on your network. See MTU Settings in Interfaces for more information.

Note

 

If you increase MTU above 1500 on ASA 5500-X series devices, ISA 3000 series devices, or Firepower Threat Defense Virtual, you must reboot the device. Log into the CLI and use the reboot command. You do not need to reboot the Firepower 2100 or Secure Firewall 3100 series devices, where jumbo frame support is always enabled.

Step 12

(Physical interface only.) Modify the speed and duplex settings.

The default is that the interface negotiates the best duplex and speed with the interface at the other end of the wire, but you can force a specific duplex or speed if necessary. The options listed are only those supported by the interface. Before setting these options for interfaces on a network module, please read Limitations for Interface Configuration.

  • Duplex- Choose Auto , Half , Full , or Default . Auto is the default when the interface supports it. For example, you cannot select Auto for the SFP interfaces on a Firepower 2100 or Secure Firewall 3100 series device. Select Default to indicate that Firepower Device Manager should not attempt to configure the setting.

    Any existing configuration is left unchanged.

  • Speed- Choose Auto to have the interface negotiate the speed (this is the default), or pick a specific speed: 10 , 100 , 1000 , 10000 Mbps. You can also select these special options:

    Any existing configuration is left unchanged.

    The type of interface limits the options you can select. For example, the SFP+ interfaces on a Firepower 2100 series device support 1000 (1 Gbps) and 10000 (10 Gpbs) only, and the SFP interfaces support 1000 (1 Gbps) only, whereas GigabitEthernet ports do not support 10000 (10 Gpbs). SPF interfaces on other devices might require No Negotiate . Consult the hardware documentation for information on what the interfaces support.

Step 13

(Optional, recommended for subinterfaces and high availability units.) Configure the MAC address.

MAC Address-The Media Access Control in H.H.H format, where H is a 16-bit hexadecimal digit. For example, you would enter the MAC address 00-0C-F1-42-4C-DE as 000C.F142.4CDE. The MAC address must not have the multicast bit set, that is, the second hexadecimal digit from the left cannot be an odd number.)

Standby MAC Address-For use with high availability. If the active unit fails over and the standby unit becomes active, the new active unit starts using the active MAC addresses to minimize network disruption, while the old active unit uses the standby address.

Step 14

Click Create.

Configure a Bridge Group

A bridge group is a virtual interface that groups one or more interfaces. The main reason to group interfaces is to create a group of switched interfaces. Thus, you can attach workstations or other endpoint devices directly to the interfaces included in the bridge group. You do not need to connect them through a separate physical switch, although you can also attach a switch to a bridge group member.

The group members do not have IP addresses. Instead, all member interfaces share the IP address of the Bridge Virtual Interface (BVI). If you enable IPv6 on the BVI, member interfaces are automatically assigned unique link-local addresses.

You typically configure a DHCP server on the bridge group interface (BVI), which provides IP addresses for any endpoints connected through member interfaces. However, you can configure static addresses on the endpoints connected to the member interfaces if you prefer. All endpoints within the bridge group must have IP addresses on the same subnet as the bridge group IP address.


Note

For ISA 3000, the device comes pre-configured with bridge group BVI, named inside, which includes all data interfaces except for the outside interface. Thus, the device is pre-configured with one port used for linking to the Internet or other upstream network, and all other ports enabled and available for direct connections to endpoints. If you want to use an inside interface for a new subnet, you must first remove the needed interfaces from BVI.

FDM-managed devices only support one bridge group; therefore, Security Cloud Control can only manage that one bridge group and cannot create additional bridge groups on the device.

After you create a bridge group on Security Cloud Control, you will not know the bridge group ID until after the configuration is deployed to the FDM-managed device. FDM-managed device assigns the bridge group ID, for example, BVI1. If the interface is deleted and a new bridge group is created, the new bridge group receives an incremented number, for example, BVI2.

Before you Begin

Configure the interfaces that will be members of the bridge group. Specifically, each member interface must meet the following requirements:

  • The interface must have a name.

  • The interface cannot be configured as management-only.

  • The interface cannot be configured for passive mode.

  • The interface cannot be an EtherChannel interface or an EtherChannel subinterface.

  • The interface cannot have any IPv4 or IPv6 addresses defined for it, either static or served through DHCP. If you need to remove the address from an interface that you are currently using, you might also need to remove other configurations for the interface, such as static routes, DHCP server, or NAT rules, that depend on the interface having an address. If you try to add an interface with an IP address to a bridge group, Security Cloud Control will warn you. If you continue to add the interface to the bridge group, Security Cloud Control will remove the IP address from the interface configuration.

  • BVI can have either VLAN interfaces or other routed interfaces as a member interface, but you cannot have both as member interfaces on a single BVI.

  • The interface cannot be Point-to-Point Protocol over Ethernet (PPPoE)

  • The interface cannot be associated with a security zone (if it is in a zone). You must delete any NAT rules for the interface before you can add it to a bridge group.

  • Enable and disable the member interfaces individually. Thus, you can disable any unused interfaces without needing to remove them from the bridge group. The bridge group itself is always enabled.

  • Bridge groups do not support clustering.


Note

Bridge groups are not supported on Firepower 2100 devices in routed mode or on VMware with bridged ixgbevf interfaces.

Configure the Name of the Bridge Group Interface and Select the Bridge Group Members

In this procedure you give the bridge group interface (BVI) a name and select the interfaces to add to the bridge group:

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab to locate the device or the Templates tab to locate the model device.

Step 3

Click the FTD tab and select the device for which you want to create a bridge group.

Step 4

Do one of the following:

  • Select the BVI bridge group and click Edit in the Actions pane.

  • Click the plus button and select Bridge Group Interface.

Note

 

You can create and configure a single bridge group. If you already have a bridge group defined, you should edit that group instead of trying to create a new one. If you need to create a new bridge group, you must first delete the existing bridge group.

Step 5

Configure the following:

  • Logical Name-You must give the bridge group a name. It can be up to 48 characters. Alphabetic characters must be lower case. For example, inside or outside. Without a name, the rest of the interface configuration is ignored.

Note

 

If you change the name, the change is automatically reflected everywhere you used the old name, including security zones, syslog server objects, and DHCP server definitions. However, you cannot remove the name until you first remove all configurations that use the name, because you typically cannot use an unnamed interface for any policy or setting.

  • (Optional) Description-The description can be up to 200 characters on a single line, without carriage returns.

Step 6

Click the Bridge Group Member tab. A bridge group can have up to 64 interfaces or subinterfaces to a single bridge group.

  • Check an interface to add it to the bridge group.

  • Uncheck an interface you want to remove from the bridge group.

Step 7

Click Save.

The BVI now has a name and member interfaces. Continue with the following tasks to configure the bridge group interface. You are not performing these tasks for the member interfaces themselves:

Configure the IPv4 Address for the BVI
Procedure

Step 1

Select the device for which you want to create a bridge group.

Step 2

Select the BVI in the list of interfaces and click Edit in the Actions pane.

Step 3

Click the IPv4 Address tab to configure the IPv4 address.

Step 4

Select one of the following options from the Type field:

  • Static-Choose this option if you want to assign an address that should not change. Type in the bridge group's IP address and the subnet mask. All attached endpoints will be on this network. For models with a pre-configured bridge group, the default for the BVI "inside" network is 192.168.1.1/24 (i.e. 255.255.255.0). Ensure that the address is not already used on the network.

    If you configured high availability, and you are monitoring this interface for HA, also configure a standby IP address on the same subnet. The standby address is used by this interface on the standby device. If you do not set the standby IP address, the active unit cannot monitor the standby interface using network tests; it can only track the link state.

    Note

     

    If there is a DHCP server configured for the interface, you are shown the configuration. You can edit or delete the DHCP address pool. If you change the interface IP address to a different subnet, you must either delete the DHCP server, or configure an address pool on the new subnet, before you can save the interface changes. See Configuring DHCP Server.

  • Dynamic (DHCP)-Choose this option if the address should be obtained from the DHCP server on the network. This is not the typical option for bridge groups, but you can configure it if needed. You cannot use this option if you configure high availability. Change the following options if necessary:

    • Route Metric—If you obtain the default route from the DHCP server, the administrative distance to the learned route, between 1 and 255. The default is 1.

    • Obtain Default Route—Check this option to get the default route from the DHCP server. You would normally select this option, which is the default.

Step 5

Continue with one of the following procedures:
Configure the IPv6 Address for the BVI
Procedure

Step 1

Click the IPv6 Address tab to configure IPv6 addressing for the BVI.

Step 2

Configure these aspects of IPv6 addressing:

Step 3

Enable IPv6 processing-To enable IPv6 processing and to automatically configure the link-local address when you do not configure the global address, slide the State slider to blue. The link local address is generated based on the interface MAC addresses (Modified EUI-64 format).

Note

 

Disabling IPv6 does not disable IPv6 processing on an interface that is configured with an explicit IPv6 address or that is enabled for autoconfiguration.

Step 4

Suppress RA-Whether to suppress router advertisements. The Firepower Threat Defense device can participate in router advertisements so that neighboring devices can dynamically learn a default router address. By default, router advertisement messages (ICMPv6 Type 134) are periodically sent out each IPv6 configured interface.

Router advertisements are also sent in response to router solicitation messages (ICMPv6 Type 133). Router solicitation messages are sent by hosts at system startup so that the host can immediately auto-configure without needing to wait for the next scheduled router advertisement message.

You might want to suppress these messages on any interface for which you do not want the FDM-managed device to supply the IPv6 prefix (for example, the outside interface).

Step 5

Static Address/Prefix-If you do not use stateless auto configuration, enter the full static global IPv6 address and network prefix. For example, 2001:0DB8::BA98:0:3210/48. For more information on IPv6 addressing, see IPv6 Addressing.

Step 6

Standby IP Address-If you configure high availability, and you are monitoring this interface for HA, also configure a standby IPv6 address on the same subnet. The standby address is used by this interface on the standby device. If you do not set the standby IP address, the active unit cannot monitor the standby interface using network tests; it can only track the link state.

Step 7

Continue with one of the following procedures:
Configure Advanced Interface Options

You configure most advanced options on bridge group member interfaces, but some are available for the bridge group interface itself.

Procedure

Step 1

The advanced settings have defaults that are appropriate for most networks. Edit them only if you are resolving network issues.

Step 2

Click OK.

Step 3

Click Save and deploy the changes to the Firepower device. See Deploy Configuration Changes from Security Cloud Control to FTD for more information.

What to do next

  • Ensure that all member interfaces that you intend to use are enabled.

  • Configure a DHCP server for the bridge group. See Configure DHCP Server.

  • Add the member interfaces to the appropriate security zones.

  • Ensure that policies, such as identity, NAT, and access, supply the required services for the bridge group and member interfaces.

Bridge Group Compatibility in FDM-Managed Configurations

In various configurations, where you can specify an interface, sometimes you will be able to specify a bridge virtual interface (BVI) and sometimes you will be able to specify a member of the bridge group. This table explains when a BVI can be used and when a member interface can be used.

Firepower Threat Defense Configuration Type

BVI can be used

BVI member can be used

DHCP server

Yes

No

DNS Server

Yes

Yes

Management access

Yes

No

NAT (Network Address Translation)

No

Yes

Security Zone

No

Yes

Site-to-Site VPN access point

No

Yes

Syslog Server

Yes

No
Delete a Bridge Group

When you delete a bridge group, its members become standard routed interfaces, and any NAT rules or security zone membership are retained. You can edit the interfaces to give them IP addresses. If you need to create a new bridge group, you must first delete the existing bridge group.

Procedure

Step 1

In the left pane, click Security Devices.

Step 2

Click the Devices tab.

Step 3

Click the FTD tab and select the device from which you want to delete the bridge group.

Step 4

Select the BVI bridge group and click Remove in the Actions pane.

Step 5

Review and deploy now the changes you made, or wait and deploy multiple changes at once.

Add an EtherChannel Interface for an FDM-Managed Device

EtherChannel Interface Limitations

An EtherChannel, depending on the device model, can include multiple member interfaces of the same media type and capacity and must be set to the same speed and duplex. You cannot mix interface capacities (for example 1GB and 10GB interfaces) by setting the speed to be lower on the larger-capacity interface. The Link Aggregation Control Protocol (LACP) aggregates interfaces by exchanging the Link Aggregation Control Protocol Data Units (LACPDUs) between two network devices.

EtherChannel interfaces have a number of limitations based on physical configuration and software versions. See the sections below for more information.

General Interface Limitations

  • EtherChannels are only available on devices running FDM-managed Version 6.5 and later.

  • Security Cloud Control supports EtherChannel interface configuration on the following Firepower devices: 1010, 1120, 1140, 1150, 2110, 2120, 2130, 2140, 3110, 3120, 3130, and 3140. For interface limitations per device model, see Device-Specific Requirements.

  • All interfaces in the channel group must be the same media type and capacity, and must be set to the same speed and duplex. The media type can be either RJ-45 or SFP; SFPs of different types (copper and fiber) can be mixed. You cannot mix interface capacities (for example 1GB and 10GB interfaces) by setting the speed to be lower on the larger-capacity interface.

  • The device to which you connect the EtherChannel must also support 802.3ad EtherChannels.

  • The FDM-managed device does not support LACPDUs that are VLAN-tagged. If you enable native VLAN tagging on the neighboring switch using the Cisco IOS vlan dot1Q tag native command, then the FDM-managed device will drop the tagged LACPDUs. Be sure to disable native VLAN tagging on the neighboring switch.

  • All FDM-managed device configuration refers to the logical EtherChannel interface instead of the member physical interfaces.

  • Portchannel interfaces are displayed as physical interfaces.

Device-Specific Limitations

The following devices have specific interface limitations:

1000 Series

  • Firepower 1010 supports up to 8 EtherChannel interfaces.

  • Firepower 1120,1140,1150 supports up to 12 EtherChannel interfaces.

  • 1000 series do not support LACP rate fast; LACP always uses the normal rate. This setting is not configurable.

2100 Series

  • Firepower 2110 and 2120 models supports up to 12 EtherChannel interfaces.

  • Firepower 2130 and 2140 models support up to 16 EtherChannel interfaces.

  • 2100 series do not support LACP fast rate; LACP always uses the normal rate. This setting is not configurable.

Secure Firewall 3100 Series

  • All Secure Firewall 3100 models support up to 16 EtherChannel interfaces.

  • The Secure Firewall 3100 models support LACP fast rate.

  • The Secure Firewall 3100 series models do not support enabling or disabling of network modules and breakout online insertion and removal (OIR) of interfaces.

4100 Series and 9300 Series

  • You cannot create or configure EtherChannels on the 4100 and 9300 series. Etherchannels for these devices must be configured in the FXOS chassis.

  • Etherchannels on the 4100 and 9300 series appear in Security Cloud Control as physical interfaces.

Add an EtherChannel Interface

Use the following procedure to add an EtherChannel to your FDM-managed device:


Note

If you want to immediately create another EtherChannel, check the Create another checkbox and then click Create.

Procedure

Step 1

Click the Devices tab.

Step 2

Click the FTD tab and select the device you want to add an EtherChannel to.

Step 3

In the Management pane located to the right, select Interfaces.

Step 4

Click the blue plus button and select EtherChannel.

Step 5

(Optional) Enter a Logical Name.

Step 6

(Optional) Enter a description.

Step 7

Enter the EtherChannel ID.

For Firepower 1010 series, enter a value between 1 and 8.

For the Firepower 2100, 3100, 4100, and 9300 series, enter a value between 1 and 48.

Step 8

Click the drop-down button for Link Aggregation Control Protocol and select one of the two options:

  • Active - Sends and receives LACP updates. An active EtherChannel can establish connectivity with either an active or a passive EtherChannel. You should use the active mode unless you need to minimize the amount of LACP traffic.

  • On - The EtherChannel is always on, and LACP is not used. An on EtherChannel can only establish a connection with another EtherChannel that is also configured to be on.

Step 9

Search for and select the interfaces you want to include in the EtherChannel as memebers. You must include at least one interface.

Warning: If you add an EtherChannel interface as a member and it already has an IP address configured, Security Cloud Control removes the IP address of the member.

Step 10

Click Create.

Edit Or Remove an EtherChannel Interface for FDM-Managed Device

Use the following procedures to either modify an existing EtherChannel interface, or remove an EtherChannel interface from an FDM-managed device.

Edit an EtherChannel

Note that EtherChannels have several limitations you must be aware of when modifying. See Guidelines and Limitations for Firepower Configuration for more information.


Note

EtherChannels must have at least one member.

Use the following procedure to edit an existing EtherChannel:

Procedure

Step 1

In the navigation pane, click Security Devices.

Step 2

Click the Devices tab.

Step 3

Click the FTD tab and select the threat defense associated with the Etherchannel you want to modify.

Step 4

In the Management pane located to the right, click Interfaces.

Step 5

On the Interfaces page, select the EtherChannel interface you want to edit. In the Actions pane located to the right, click the edit icon .

Step 6

Modify any of the following items:

  • Logical name.

  • State.

  • Description.

  • Security Zone assignment.

  • Link Aggregation Control Protocol status.

  • IP address configuration in either the IPv4, IPv6, or Advanced tabs.

  • EtherChannel members.

Warning

 

If you add an EtherChannel interface as a member and it already has an IP address configured, Security Cloud Control removes the IP address of the member.

Step 7

Click Save.

Remove an EtherChannel Interface

Note

EtherChannel interfaces associated with a high availability (HA) or any other configuration. You must manually remove the EtherChannel interface from all configurations before deleting it from Security Cloud Control.

Use the following procedure to remove an EtherChannel interface from an FDM-managed device:

Procedure

Step 1

In the navigation pane, click Security Devices.

Step 2

Click the Devices tab.

Step 3

Click the FTD tab and the threat defense associated with the Etherchannel you want to delete.

Step 4

In the Management pane located to the right, select Interfaces.

Step 5

On the Interfaces page, select the EtherChannel interface you want to edit. In the Actions pane located to the right, click Remove.

Step 6

Confirm you want to delete the EtherChannel interface and click OK.

Add a Subinterface to an EtherChannel Interface

EtherChannel Subinterfaces

The Interfaces page allows you to view which interfaces of a device have subinterfaces by expanding each interface. This expanded view also shows you the unique logical name, enabled/disabled state, any associated security zones, and mode of the subinterface. The interface type and mode of the subinterface is determined by the parent interface.

General Limitations

Security Cloud Control does not support subinterfaces for the following interface types:

  • Interface configured for management-only.

  • Interface configured for switch port mode.

  • Passive interfaces.

  • VLAN interfaces.

  • Bridge virtual interfaces (BVI).

  • Interfaces that are already a member of another EtherChannel interface.

You can create subinterfaces for the following:

  • Bridge group members.

  • EtherChannel interfaces.

  • Physical interfaces.

Add a Subinterface to an EtherChannel Interface

Use the following procedure to add a subinterface to an existing interface:


Note

If you want to immediately create another subinterface, check the Create another checkbox and then click Create.

Procedure

Step 1

In the navigation pane, click Security Devices.

Step 2

Click the Devices tab.

Step 3

Click the FTD tab and select the threat defense you want to add an EtherChannel to. In the Management pane located to the right, select Interfaces.

Step 4

Select the interface you want to group the subinterface under. In the Action pane located to the right, click the button.

Step 5

(Optional) Enter a Logical Name.

Step 6

(Optional) Enter a description.

Step 7

(Optional) Assign a security zone to the subinterface. Note that you cannot assign a security zone if the subinterface does not have a logical name.

Step 8

Enter a VLAN ID.

Step 9

Enter the EtherChannel ID. Use a value between 1 and 48; use values between 1 and 8 for the Firepower 1010 series.

Step 10

Select the IPv4, IPv6, or Advanced tab to configure the IP address of the subinterface.

Step 11

Click Create.

Edit or Remove a Subinterface from an EtherChannel

Use the following procedures to either modify an existing subinterface, or remove a subinterface from an Etherchannel interface.


Note

Subinterfaces and EtherChannel interfaces have a series of guidelines and limitations that may affect your configuration. See the general subinterface limitations for more information.

Edit a Subinterface

Use the following procedure to edit an existing subinterface associated with an EtherChannel interface:

Procedure

Step 1

In the navigation pane, click Security Devices.

Step 2

Click the Devices tab.

Step 3

Click the FTD tab and select the threat defense associated with the EtherChannel and subinterface you want to edit.

Step 4

In the Management pane located to the right, select Interfaces.

Step 5

Locate and expand the Etherchannel interface that the subinterface is a member of.

Step 6

Select the desired subinterface you want to edit. In the Action pane located to the right, click the edit icon .

Step 7

Modify any of the following items:

  • Logical name.

  • State.

  • Description.

  • Security Zone assignment.

  • VLAN ID

  • IP address configuration in either the IPv4, IPv6, or Advanced tabs.

Step 8

Click Save.

Remove a Subinterface from an EtherChannel

Use the following procedure to remove an existing subinterface from an EtherChannel interface:

Procedure

Step 1

In the navigation pane, click Security Devices.

Step 2

Click the Devices tab.

Step 3

Click the FTD tab and select the threat defense associated with the EtherChannel and subinterface you want to edit. In the Management pane located to the right, select Interfaces.

Step 4

Locate and expand the Etherchannel interface that the subinterface is a member of.

Step 5

Select the desired subinterface you want to delete.

Step 6

In the Actions pane located to the right, click Remove.

Step 7

Confirm you want to delete the subinterface interface and click OK.

Add Interfaces to a Virtual FDM-Managed Device

When you deploy a virtual FDM-managed device, you assign interfaces to the virtual machine. Then, from within an FDM-managed device, you configure those interfaces using the same methods you would use for a hardware device.

However, you cannot add more virtual interfaces to the virtual machine and then have FDM automatically recognize them. If you need more physical-interface equivalents for a virtual FDM-managed device, you basically have to start over. You can either deploy a new virtual machine, or you can use the following procedure.


Caution

Adding interfaces to a virtual machine requires that you completely wipe out the virtual FDM-managedconfiguration. The only part of the configuration that remains intact is the management address and gateway settings.

Before You Begin

Do the following in an FDM-managed device:

  • Examine the virtual FDM-managed device configuration and make notes on settings that you will want to replicate in the new virtual machine.

  • Select Devices > Smart License > View Configuration and disable all feature licenses.

Procedure

Step 1

Power off the virtual FDM-managed device.

Step 2

Using the virtual machine software, add the interfaces to the virtual FDM-managed device. For VMware, virtual appliances use e1000 (1 Gbit/s) interfaces by default. You can also use vmxnet3 or ixgbe (10 Gbit/s) interfaces

Step 3

Power on the virtual FDM-managed device.

Step 4

Open the virtual FDM-managed device console, delete the local manager, then enable the local manager. Deleting the local manager, then enabling it, resets the device configuration and gets the system to recognize the new interfaces. The management interface configuration does not get reset. The following SSH session shows the commands. 

> show managers
Managed locally.
> configure manager delete
If you enabled any feature licenses, you must disable them in Firepower Device Manager before deleting the local manager. Otherwise, those licenses remain assigned to the device in Cisco Smart Software Manager.
Do you want to continue[yes/no] yes
DCHP Server Disabled
> show managers
No managers configured.
> configure manager local
>

Step 5

Open a browser session to an FDM-managed device, complete the device setup wizard, and configure the device. See the "Complete the Initial Configuration" section of the Getting Started chapter of Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager, Version x.x.x, guide for more instructions.

Switch Port Mode Interfaces for an FDM-Managed Device

For each physical Firepower 1010 interface, you can set its operation as a firewall interface or as a switch port. Switch ports forward traffic at Layer 2, using the switching function in hardware. Switch ports on the same VLAN can communicate with each other using hardware switching, and traffic is not subject to the FDM-managed device security policy. Access ports accept only untagged traffic, and you can assign them to a single VLAN. Trunk ports accept untagged and tagged traffic, and can belong to more than one VLAN. For devices that have been reimaged to Version 6.4, Ethernet 1/2 through 1/8 are configured as access switch ports on VLAN 1; devices that are manually upgraded to Version 6.4 (and later), the ethernet configuration maintains the configuration prior ot upgrading. Note that switch ports on the same VLAN can communicate with each other using hardware switching, and traffic is not subject to the FDM-managed device security policy.

Access or Trunk

A physical interface configured as a switch port can be assigned as either an access port or a trunk port.

Access ports forward traffic to only one VLAN and accept only untagged traffic. We strongly recommend this option if you intend to forward traffic to a single host or device. You must also specify the VLAN you would like to be associated with the interface, otherwise it will default to VLAN 1.

Trunk ports forward traffic to multiple VLANs. You must assign one VLAN interface as the native trunk port and at least one VLAN as an associated trunk port. You can select up to 20 interfaces to be associated with the switch port interface, which enables traffic from different VLAN IDs to pass through the switch port interface. If an untagged traffic is passed through the switch port then the traffic is tagged with the VLAN ID of the native VLAN interface. Note that the default Fiber Distributed Data Interface (FDDI) & Token RING ID between 1002 and 1005 cannot be used for VLAN ID.

Change the Port Mode

If you select an interface that is configured for routed mode as a VLAN member, Security Cloud Control automatically converts the interface to switch port mode and configures the interface as an access port by default. As a result the logical name and the associated static IP addresses are removed from the interface.

Configuration Limitations

Be aware of the following limitations:

  • Only physical Firepower 1010 devices support switch port mode configuration. Virtual FDM-managed devices do not support switch port mode.

  • The Firepower 1010 device allows a maximum of 60 VLANs.

  • VLAN interfaces configured for switch port mode must be unnamed. This means the MTU must be configured to 1500 bytes.

  • You cannot delete an interface configured as a switch port mode. You must manually change the interface mode from switch port mode to routed mode.

  • Interfaces configured for switch port mode do not support IP addresses. If the interface is currently referenced in or configured for VPN, DHCP, or is associated with a static route, you must manually remove the IP address.

  • You cannot use any member of the bridge group interface as a switch port.

  • The MTU for a VLAN interface must be 1500 bytes. Unnamed VLAN interfaces do not support any other configuration.

  • Switch port mode does not support the following:

    • Diagnostic interface.

    • Dynamic, multicast, or Equal-Cost Multi-Path (ECMP) routing.

    • Passive interfaces.

    • Port etherchannels, or using an interface that is a member of an etherchannel.

    • Subinterfaces.

    • Failover and state link.

High Availability and Switch Port Mode Interfaces

You should not use the switch port functionality when using High Availability. Because the switch ports operate in hardware, they continue to pass traffic on both the active and the standby units. High Availability is designed to prevent traffic from passing through the standby unit, but this feature does not extend to switch ports. In a normal High Availability network setup, active switch ports on both units will lead to network loops. We suggest that you use external switches for any switching capability. Note that VLAN interfaces can be monitored by failover, while switch ports cannot.


Note

You can only use a firewall interface as the failover link.
Switch Port Mode Configurations in Templates

You can create templates of devices with interfaces configured for switch port mode. Beware the following scenarios when mapping interfaces from the template to a device:

  • If a template interface does not contain any VLAN members prior to applying the template, Security Cloud Control automatically maps it to an available device interface that has the same properties.

  • If a template interface that does not contain a VLAN member is mapped to a device interface that is configured as N/A, Security Cloud Control automatically creates an interface on the device the template is to be applied to

  • If a template interface containing a VLAN member is mapped to a device interface that is not present, applying a template will fail.

  • Templates do not support mapping more than one template interface to the same device interface.

  • The template's management interface must be mapped to the device's management interface.

Configure an FDM-Managed Device VLAN

You must first configure a VLAN interface if you intend to configure subinterfaces or switch ports.


Note

An FDM-managed device supports a maximum of 60 VLAN interfaces.

Procedure

Step 1

In the navigation pane, click Security Devices.

Step 2

Click the Devices tab to locate the device or the Templates tab to locate the model device.

Step 3

Click the FTD tab and select the desired device you want to create a VLAN on.

Step 4

In the Management pane at the right, click Interfaces.

Step 5

On the Interfaces page, click the button.

Step 6

Configure the following:

  • Parent Interface - The parent interface is the physical interface to which you want to add the subinterface. You cannot change the parent interface after you create the subinterface.

  • (Optional) Logical Name-Set the name for the VLAN, up to 48 characters. Alphabetic characters must be lower case. If you do not want to route between the VLAN and other VLANs or firewall interfaces, then leave the VLAN interface name empty.

    Note

     

    If you do not enter a name, the MTU in the Advanced Options must be set to 1500. If you change the MTU to something other than 1500, the VLAN must be unnamed.

  • (Optional) Description-The description can be up to 200 characters on a single line, without carriage returns.

  • (Optional) Security Zone - Assign the subinterface to a security zone. Note that you cannot assign a subinterface if it does not have a Logical Name. You ca also assign a security zone after creating a subinterface. See Use of Security Zones in Firepower Interface Settings for more information.

  • (Optional) VLAN ID-Enter the VLAN ID between 1 and 4070 that will be used to tag the packets on this subinterface.

    Note

     

    ​​​​​​VLAN interfaces are routed by default. If you add this VLAN interface to a bridge group at a later date, Security Cloud Control automatically changes the mode to BridgeGroupMember. Similarly, if you change this VLAN interface to switch port mode, Security Cloud Control automatically changes the mode to Switch Port.

  • (Optional) Subinterface ID - Enter the subinterface ID as an integer between 1 and 4294967295. This ID is appended to the interface ID; for example Ethernet1/1.100. You can match the VLAN ID for convenience, but it is not required. You cannot change the ID after you create the subinterface.

Step 7

Click the IPv4 Address tab and select one of the following options from the Type field:

  • Static - Choose this option if you want to assign an address that should not change. Type in the interface's IP address and the subnet mask for the network attached to the interface. For example, if you attach the 10.100.10.0/24 network, you could enter 10.100.10.1/24. Ensure that the address is not already used on the network.

    If you configured high availability, and you are monitoring this interface for HA, also configure a standby IP address on the same subnet. The standby address is used by this interface on the standby device. If you do not set the standby IP address, the active unit cannot monitor the standby interface using network tests; it can only track the link state.

    Note

     

    If there is a DHCP server configured for the interface, you are shown the configuration. You can edit or delete the DHCP address pool. If you change the interface IP address to a different subnet, you must either delete the DHCP server, or configure an address pool on the new subnet, before you can save the interface changes. See Configuring DHCP Server for more information.

  • Dynamic (DHCP)-Choose this option if the address should be obtained from the DHCP server on the network. You cannot use this option if you configure high availability. Change the following options if necessary:

    • Route Metric-If you obtain the default route from the DHCP server, the administrative distance to the learned route, between 1 and 255. The default is 1.

    • Obtain Default Route-Check this option to get the default route from the DHCP server. You would normally select this option, which is the default.

  • DHCP Address Pool - If there is a DHCP server configured for the interface, you are shown the configuration. You can edit or delete the DHCP address pool. If you change the interface IP address to a different subnet, you must either delete the DHCP server, or configure an address pool on the new subnet, before you can save the interface changes.

Step 8

(Optional) Click the IPv6 Address tab and configure the following:

  • State - To enable IPv6 processing and to automatically configure the link-local address when you do not configure the global address, slide the State slider to blue. The link local address is generated based on the interface MAC addresses (Modified EUI-64 format).

    Note

     

    Disabling IPv6 does not disable IPv6 processing on an interface that is configured with an explicit IPv6 address or that is enabled for autoconfiguration.

  • Address Auto Configuration - Check this option to have the address automatically configured. IPv6 stateless autoconfiguration will generate a global IPv6 address only if the link on which the device resides has a router configured to provide IPv6 services, including the advertisement of an IPv6 global prefix for use on the link. If IPv6 routing services are not available on the link, you will get a link-local IPv6 address only, which you cannot access outside of the device's immediate network link. The link local address is based on the Modified EUI-64 interface ID.

  • Suppress RA-Whether to suppress router advertisements. Threat Defense can participate in router advertisements so that neighboring devices can dynamically learn a default router address. By default, router advertisement messages (ICMPv6 Type 134) are periodically sent out each IPv6 configured interface.

    Router advertisements are also sent in response to router solicitation messages (ICMPv6 Type 133). Router solicitation messages are sent by hosts at system startup so that the host can immediately auto-configure without needing to wait for the next scheduled router advertisement message.

    We suggest suppressing these messages on any interface for which you do not want the FDM-managed device to supply the IPv6 prefix (for example, the outside interface).

  • Static Address/Prefix-If you do not use stateless auto configuration, enter the full static global IPv6 address and network prefix. For example, 2001:0DB8::BA98:0:3210/48. For more information on IPv6 addressing, see IPv6 Addressing for Firepower Interfaces.

  • Standby IP Address-If you configure high availability, and you are monitoring this interface for HA, also configure a standby IPv6 address on the same subnet. The standby address is used by this interface on the standby device. If you do not set the standby IP address, the active unit cannot monitor the standby interface using network tests; it can only track the link state.

Step 9

(Optional) Click the Advanced tab.

  • Select Enable for HA Monitoring if you want the health of the interface to be a factor when the system decides whether to fail over to the peer unit in a high availability configuration.

    This option is ignored if you do not configure high availability. It is also ignored if you do not configure a name for the interface.

  • Select Management Only to make a data interface management only.

    A management only interface does not allow through traffic, so there is very little value in setting a data interface as management only. You cannot change this setting for the Management/Diagnostic interface, which is always management only.

  • Modify the IPv6 Configuration settings.

    • Enable DHCP for IPv6 address configuration-Whether to set the Managed Address Configuration flag in the IPv6 router advertisement packet. This flag informs IPv6 autoconfiguration clients that they should use DHCPv6 to obtain addresses, in addition to the derived stateless autoconfiguration address.

    • Enable DHCP for IPv6 non-address configuration-Whether to set the Other Address Configuration flag in the IPv6 router advertisement packet. This flag informs IPv6 autoconfiguration clients that they should use DHCPv6 to obtain additional information from DHCPv6, such as the DNS server address.

    • DAD Attempts-How often the interface performs Duplicate Address Detection (DAD), from 0 - 600. The default is 1. During the stateless autoconfiguration process, DAD verifies the uniqueness of new unicast IPv6 addresses before the addresses are assigned to interfaces. If the duplicate address is the link-local address of the interface, the processing of IPv6 packets is disabled on the interface. If the duplicate address is a global address, the address is not used. The interface uses neighbor solicitation messages to perform Duplicate Address Detection. Set the value to 0 to disable duplicate address detection (DAD) processing.

  • Change the MTU (maximum transmission unit) to the desired value.

    The default MTU is 1500 bytes. You can specify a value from 64 - 9198 (or 9000 for virtual FDM-managed devices and 9184 for the Firepower 4100/9300). Set a high value if you typically see jumbo frames on your network.

    Note

     

    If you increase MTU above 1500 on ASA 5500-X series devices, ISA 3000 series devices, or virtual FDM-managed devices, the VLAN must be unnamed and you must reboot the device. Log into the CLI and use the reboot command. If the device is configured for HA, you must also reboot the standby device. You do not need to reboot Firepower models, where jumbo frame support is always enabled.

  • (Optional for subinterface and HA pairs) Configure the MAC address.

    By default, the system uses the MAC address burned into the network interface card (NIC) for the interface. Thus, all subinterfaces on an interface use the same MAC address, so you might want to create unique addresses per subinterface. Manually configured active/standby MAC addresses are also recommended if you configure high availability. Defining the MAC addresses helps maintain consistency in the network in the event of failover.

    • MAC Address-The Media Access Control in H.H.H format, where H is a 16-bit hexadecimal digit. For example, you would enter the MAC address 00-0C-F1-42-4C-DE as 000C.F142.4CDE. The MAC address must not have the multicast bit set, that is, the second hexadecimal digit from the left cannot be an odd number.)

    • Standby MAC Address-For use with HA pairs. If the active unit fails over and the standby unit becomes active, the new active unit starts using the active MAC addresses to minimize network disruption, while the old active unit uses the standby address.

Step 10

If you intend to create another subinterface for this device, check Create another prior to completing the subinterface configuration.

Step 11

(Optional) Activate the subinterface upon creation by toggling the State slider in the upper right corner of the pop-up window from grey to blue.

Step 12

Click OK.

Step 13

Review and deploy now the changes you made, or wait and deploy multiple changes at once.

Configure an FDM-Managed Device VLAN for Switch Port Mode

Be sure to read the limitations for switch port mode prior to configuration; see Switch Port Mode Interfaces for FTD for more information.


Note

You can assign or edit a VLAN member to a physical interface at any time. Be sure to deploy the changes to the device after you confirm the new configuration.

Create a VLAN Interface for Switch Port Mode
Procedure

Step 1

In the navigation pane, click Security Devices.

Step 2

Click the Devices tab to locate the device or the Templates tab to locate the model device.

Step 3

Click the FTD tab and select the device you want to configure interfaces for.

Step 4

In the Management pane on the right, click Interfaces.

Step 5

On the Interfaces page, click the button and choose VLAN Interface.

Step 6

View the VLAN Members tab and select the desired physical interfaces.

Note

 

If you chose to add a member that references a VLAN interface configured for either Access or Native Trunk, you can only select one VLAN as a member. Physical interfaces that references a VLAN interface configured for Associated Trunk supports up to 20 interfaces as members.

Step 7

Configure the rest of the VLAN interface, as described in Configure a FDM-Managed Device VLAN.

Step 8

Click Save. Confirm that you want to reset the VLAN configuration and reassign an IP address to the interface.

Step 9

Review and deploynow the changes you made, or wait and deploy multiple changes at once.

Configure an Existing Physical Interface for Switch Port Mode
Procedure

Step 1

In the navigation pane, click Security Devices.

Step 2

Click the Devices tab to locate the device or the Templates tab to locate the model device.

Step 3

Click the FTD tab and select the device you want to configure interfaces for.

Step 4

In the Management pane on the right, click Interfaces.

Step 5

On the Interfaces page, select the physical interface you want to modify. In the Action Pane on the right, click the edit icon .

Step 6

Interfaces configured for switch port mode do not support logical names. If the interface has a logical name, delete it.

Step 7

Locate the Mode and use the drop-down menu to select Switch Port.

Step 8

Configure the physical interface for switch port mode:

  • (Optional) Check the Protected Port check box to set this switch port as protected, so you can prevent the switch port from communicating with other protected switch ports on the same VLAN. You might want to prevent switch ports from communicating with each other if: the devices on those switch ports are primarily accessed from other VLANs; you do not need to allow intra-VLAN access; and you want to isolate the devices from each other in case of infection or other security breach. For example, if you have a DMZ that hosts three web servers, you can isolate the web servers from each other if you apply this option to each switch port. The inside and outside networks can both communicate with all three web servers, and vice versa, but the web servers cannot communicate with each other.

  • For the Usage Type, select Access or Trunk. See Switch Port Mode Interfaces for FTD to determine which port type you need.

    • If you select Trunk, you must select one VLAN interface as the Native Trunk VLAN to forward untagged traffic and at least one Associated VLAN to forward tagged traffic. Click the icon to view the existing physical interfaces. You can select up to 20 VLAN interfaces as associated VLANs.

    • You can create a new VLAN interface set to Access mode by clicking C reate new VLAN.

Step 9

Click Save. Confirm that you want to reset the VLAN configuration and reassign an IP address to the interface.

Step 10

Review and deploy now the changes you made, or wait and deploy multiple changes at once.

Viewing and Monitoring Firepower Interfaces

To view firepower interfaces, follow these steps:

Procedure

Step 1

In the navigation pane, click Security Devices.

Step 2

Click the Devices tab to locate the device or the Templates tab to locate the model device.

Step 3

Click the FTD tab and the device whose interfaces you want to view.

Step 4

Select Interfaces in the Management pane on the right.

Step 5

In the Interfaces table, select an interface.

  • If you expand the interface row, you see subinterface information.

  • On the right, you see detailed interface information.

Monitoring Interfaces in the CLI

You can view some basic information, behavior, and statistics about interfaces by connecting to the device using SSH and running the command below.

For an easy to connect to the device using SSH, onboard the FDM-managed device you want to monitor as an SSH device and then use the >_ Command Line Interface in Security Cloud Control.

  • show interface displays interface statistics and configuration information. This command has many keywords you can use to get to the information you need. Use ? as a keyword to see the available options.

  • show ipv6 interface displays IPv6 configuration information about the interfaces.

  • show bridge-group displays information about Bridge Virtual Interfaces (BVI), including member information and IP addresses.

  • show conn displays information about the connections currently established through the interfaces.

  • show traffic displays statistics about traffic flowing through each interface.

  • show ipv6 traffic displays statistics about IPv6 traffic flowing through the device.

  • show dhcpd displays statistics and other information about DHCP usage on the interfaces, particularly about the DHCP servers configured on interfaces.

Synchronizing Interfaces Added to a Firepower Device using FXOS

If an interface is added to a Firepower device by using the Firepower eXtensible Operating System (FXOS) Chassis Manager, on the Firepower 4100 series or 9300 series devices, Security Cloud Control does not recognize that configuration change and report a configuration conflict.

To see the newly added interface in Security Cloud Control, follow this procedure:

Procedure

Step 1

Log in to an FDM-managed device.

Step 2

From the FDM-managed main page, click View All Interfaces in the Interfaces panel.

Step 3

Click the Scan Interfaces button:

Step 4

Wait for the interfaces to scan, and then click OK.

Step 5

Deploy your changes on an FDM-managed device.

Step 6

Log in to Security Cloud Control as an Admin or SuperAdmin.

Step 7

In the left pane, click Security Devices.

Step 8

Click the Devices tab to locate the device or the Templates tab to locate the model device.

Step 9

Click the FTD tab and select the device with the expected new interface configuration.

Step 10

Click Check for Changes to immediately compare the copy of the configuration on the device with the copy of the configuration stored on Security Cloud Control. Security Cloud Control will detect the interface change and report a "Conflict Detected" state on the Security Devices page for the device.

Step 11

Resolve the Conflict Detected by clicking Review Conflict and then accepting the out of band changes.

Routing

Routing is the act of moving information across a network from a source to a destination. Along the way, at least one intermediate node is typically encountered. Routing involves two basic activities: determining optimal routing paths and transporting packets through a network.

Using Security Cloud Control, you can define a default route, and other static routes, for your FDM-managed devices. The following topics explain routing basics and how to use Security Cloud Control to configure static routing on your FDM-managed device:

About Static Routing and Default Routes

To route traffic to a non-connected host or network, you must define a route to that host or network. That defined route is a static route. Consider also configuring a default route. A default route is for all traffic that is not routed by other means to a default network gateway, typically the next hop router.

Default Route

If you do not know a route to a specific network, the simplest option is to configure a default route that sends all traffic to an upstream router, relying on that router to route the traffic for you. A default route identifies the gateway IP address to which the FDM-managed device sends all IP packets for which you did not define a static route. A default route is simply a static route with 0.0.0.0/0 (IPv4) or ::/0 (IPv6) as the destination IP address.

Static Routes

A static route is a route from one network to another network that you define and enter manually into the routing table. You might want to use static routes in the following cases:

  • Your network is small and stable and you can easily manage manually adding and changing routes between devices.

  • Your networks use an unsupported router discovery protocol.

  • You do not want the traffic or CPU overhead associated with routing protocols.

  • In some cases, a default route is not enough. The default gateway might not be able to reach the destination network, so you must also configure more specific static routes. For example, if the default gateway is outside, then the default route cannot direct traffic to any inside networks that are not directly connected to the FDM-managed device.

  • You are using a feature that does not support dynamic routing protocols.

Limitations:

  • Security Cloud Control does not currently support the management, monitoring, or use of Virtual Tunnel Interface (VTI) tunnels on ASA or FDM-managed devices. Devices with configured VTI tunnels can be onboarded to Security Cloud Control but it ignores the VTI interfaces. If a security zone or static route references a VTI, Security Cloud Control reads the security zone and static route without the VTI reference. Security Cloud Control support for VTI tunnels is coming soon.

  • FDM-managed device running on software version 7.0 or later allows configuring Equal-Cost Multi-Path (ECMP) traffic zones. When the FDM-managed device is onboarded to Security Cloud Control, it can read but cannot modify the ECMP configuration available in the global VRF routes because it does not allow a route to the same destination network with an identical metric value. You can create and modify ECMP traffic zones through FDM and then read it into Security Cloud Control. For more information on ECMP, see the "Equal-Cost Multi-Path (ECMP) Routing" section in the "Routing Basics and Static Routes" chapter of Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager, Version 7.0 or later.

The Routing Table and Route Selection

When NAT translations (xlates) and rules do not determine the egress interface, the system uses the routing table to determine the path for a packet.

Routes in the routing table include a metric called "administrative distance" that provides a relative priority to a given route. If a packet matches more than one route entry, the one with the lowest distance is used. Directly connected networks (those defined on an interface) have the distance 0, so they are always preferred. Static routes have a default distance of 1, but you can create them with any distance between 1-254.

Routes that identify a specific destination take precedence over the default route (the route whose destination is 0.0.0.0/0 or ::/0).

How the Routing Table is Populated

The FDM-managed device routing table can be populated with statically defined routes and directly connected routes. It is possible that the same route is entered in more than one manner. When two routes to the same destination are put into the routing table, the one that remains in the routing table is determined as follows:

  • If the two routes have different network prefix lengths (network masks), then both routes are considered unique and are entered into the routing table. The packet forwarding logic then determines which of the two to use.

For example, assume the following routes are entered in the routing table:

  • 192.168.32.0/24

  • 192.168.32.0/19

Even though the 192.168.32.0/24 route has the longer network prefix, both routes are installed in the routing table because each of these routes has a different prefix length (subnet mask). They are considered different destinations and the packet forwarding logic determines which route to use.

  • If multiple paths to the same destination are entered in the routing table, the route with the better metric, as entered with the static route, is entered into the routing table.

Metrics are values associated with specific routes, ranking them from most preferred to least preferred. The parameters used to determine the metrics differ for different routing protocols. The path with the lowest metric is selected as the optimal path and installed in the routing table. If there are multiple paths to the same destination with equal metrics, load balancing is done on these equal cost paths.

How Forwarding Decisions are Made

Forwarding decisions are made in this order:

  • Use NAT translations (xlates) and rules to determine the egress interface. If the NAT rules do not determine the egress interface, the system uses the routing table to determine the path for a packet.

  • If the destination does not match an entry in the routing table, the packet is forwarded through the interface specified for the default route. If a default route has not been configured, the packet is discarded.

  • If the destination matches a single entry in the routing table, the packet is forwarded through the interface associated with that route.

  • If the destination matches more than one entry in the routing table, then the packet is forwarded out of the interface associated with the route that has the longer network prefix length. For example, a packet destined for 192.168.32.1 arrives on an interface with the following routes in the routing table:

  • 192.168.32.0/24 gateway 10.1.1.2

  • 192.168.32.0/19 gateway 10.1.1.3

In this case, a packet destined to 192.168.32.1 is directed toward 10.1.1.2, because 192.168.32.1 falls within the 192.168.32.0/24 network. It also falls within the other route in the routing table, but 192.168.32.0/24 has the longer prefix within the routing table (24 bits verses 19 bits). Longer prefixes are always preferred over shorter ones when forwarding a packet.


Note

Existing connections continue to use their established interfaces even if a new similar connection would result in different behavior due to a change in routes.

Configure Static and Default Routes for FDM-Managed Devices

Define static routes on an FDM-managed device so it knows where to send packets bound for networks not directly connected to the interfaces on the system.

Consider creating a default route. This is the route for network 0.0.0.0/0. This route defines where to send packets whose egress interface cannot be determined by existing NAT translations, static NAT rules, or other static routes.

You might need other static routes if the default gateway cannot be used to get to all networks. For example, the default route is usually an upstream router on the outside interface. If there are additional inside networks that are not directly connected to the device, and they cannot be accessed through the default gateway, you need static routes for each of those inside networks.

You cannot define static routes for the networks that are directly connected to system interfaces. The system automatically creates these routes.

Procedure

Procedure

Step 1

In the navigation pane, click Security Devices.

Step 2

Click the Devices tab to locate the device or the Templates tab to locate the model device.

Step 3

Click the FTD device and select the device on which you want to define static routes.

Step 4

In the Management pane at the right, click Routing.

Step 5

On the Static Routing page, do one of the following:

  • To add a new static route, click the plus button .

  • Click the edit icon for the route you want to edit.

If you no longer need a route, click the trash can icon for the route to delete it.

Step 6

Configure the route properties

  • Protocol-Select whether the route is for an IPv4 or IPv6 address.

  • Interface-Select the interface through which you want to send traffic. The gateway address needs to be accessible through this interface.

  • Gateway-Select the network object that identifies the IP address for the gateway to the destination network. Traffic is sent to this address.

  • Metric-The administrative distance for the route, between 1 and 254. The default is for static routes is 1. If there are additional routers between the interface and the gateway, enter the number of hops as the administrative distance.

    Administrative distance is a parameter used to compare routes. The lower the number, the higher precedence the route is given. Connected routes (networks directly connected to an interface on the device) always take precedence over static routes.

  • Destination Network-Select the network object(s), that identifies the destination network, that contains the host(s), that uses the gateway in this route.

    To define a default route, use the pre-defined any-ipv4 or any-ipv6 network objects, or create an object for the 0.0.0.0/0 (IPv4) or ::/0 (IPv6) network.

Step 7

Click OK.

Step 8

Review and deploy now the changes you made, or wait and deploy multiple changes at once.

Static Route Example

See the Static Route Network Diagram for the addresses used in this example.

The goal is to create a static route that allows return traffic to the host at 20.30.1.2 in destination network 20.30.1.0/24.

The packet can take any path to reach the destination. When a network receives a packet on an interface, it determines where to forward the packet for the best route to a destination.


Note

The DMZ does not have a static route as it is connected directly to the interface.

For example, consider the following two routes for reaching the destination.

Route 1:
Procedure

Step 1

Packets come back to the outside interface, 209.165.201.0/27, looking for 20.30.1.2.

Step 2

We direct the packets to use the inside interface to get to the gateway 192.168.1.2, which is on the same network as the destination.

Step 3

From there, we identify the destination network by the gateway address for that network, 20.30.1.1.

Step 4

The IP address 20.30.1.2 is on the same subnet as 20.30.1.1. The router forwards the packet to the switch, the switch forwards the packet to 20.30.1.2.

Interface:Inside Destination_N/W:20.30.1.0/24 Gateway: 192.168.1.2 Metric: 1
Route 2:
Procedure

Step 1

Packets come back to the outside interface, 209.165.201.0/27, looking for 20.30.1.2.

Step 2

We direct the packets to use the internal interface to get to the gateway 192.168.50.20, which is multiple hops away from the destination network.

Step 3

From there, we identify the destination network by the gateway address for that network, 20.30.1.1.

Step 4

The IP address 20.30.1.2 is on the same subnet as 20.30.1.0. The router forwards the packet to the switch, the switch forwards the packet to 20.30.1.2.

Interface:Inside Destination_N/W:20.30.1.0/24 Gateway: 192.168.50.20 Metric: 100

Here is what the completed Add Static Route table would like for these routes.

Monitoring Routing

To monitor and troubleshoot routing, open Firewall Device Manager for the device and open the CLI console or log into the device CLI using SSH and use the following commands:

  • show route displays the routing table for the data interfaces, including routes for directly-connected networks.

  • show ipv6 route displays the IPv6 routing table for the data interfaces, including routes for directly-connected networks.

  • show network displays the configuration for the virtual management interface, including the management gateway. Routing through the virtual interface is not handled by the data interface routing table, unless you specify data-interfaces as the management gateway.

  • show network-static-routes displays static routes configured for the virtual management interface using the configure network static-routes command. Normally, there will not be any static routes, as the management gateway suffices for management routing in most cases. These routes are not available to traffic on the data interfaces. This command is not available in the CLI console.

About Virtual Routing and Forwarding

About VRF

Virtual routing and forwarding (VRF) allow multiple instances of a routing table to exist in a router. Firepower Version 6.6 introduces the ability to have a default VRF table and user-created VRF tables. A single VRF table can handle multiple types of varying routing protocols, such as EX, OSPF, BGP, IGRP, etc. Each routing protocol within a VRF table is listed as an entry. In addition to handling multiple types of common routing protocols, you can configure a routing protocol to reference an interface from another VRF. This allows you to segment network paths without using multiple devices.

See About Virtual Routers and Virtual Routing and Forwarding (VRF) for more information.

VRF in Security Cloud Control

This feature is new to Firepower Version 6.6. When the FDM-managed device is onboarded to Security Cloud Control, the device routing page reads and supports only the VRFs defined on the global router of the FDM-managed device. To view the global VRF in Security Cloud Control, select the device from the Security Devices page and select Routing from the Management pane located to the right of the window. From here, you can view, modify, and delete the global VRF; note that Security Cloud Control retains the name of the VRF when reading the configuration from FDM.

Security Cloud Control firewall device manager doesn't read VRFs configured in the user-defined virtual routers. You must create and manage VRF tables through firewall device manager.

For information on global and user-defined routes, see the "Managing Virtual Routers" section in the "Virtual Routers" chapter of Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager, Version 7.0 or later.

Objects

An object is a container of information that you can use in one or more security policies. Objects make it easy to maintain policy consistency. You can create a single object, use it different policies, modify the object, and that change is propagated to every policy that uses the object. Without objects, you would need to modify all the policies, individually, that require the same change.

When you onboard a device, Security Cloud Control recognizes all the objects used by that device, saves them, and lists them on the Objects page. From the Objects page, you can edit existing objects and create new ones to use in your security policies.

Security Cloud Control calls an object used on multiple devices a shared object and identifies them in the Objects page with this badge .

Sometimes a shared object develops some "issue" and is no longer perfectly shared across multiple policies or devices:

  • Duplicate objects are two or more objects on the same device with different names but the same values. These objects usually serve similar purposes and are used by different policies. Duplicate objects are identified by this issue icon:

  • Inconsistent objects are objects on two or more devices with the same name but different values. Sometimes users create objects in different configurations with same name and content but over time the values of these objects diverge which creates the inconsistency. Inconsistent objects are identified by this issue icon:

  • Unused objects are objects that exist in a device configuration but are not referenced by another object, an access-list, or a NAT rule. Unused objects are identified by this issue icon:

You can also create objects for immediate use in rules or policies. You can create an object that is unassociated with any rule or policy. Before 28 June 2024, when you use an unassociated object in a rule or policy, Security Cloud Control created a copy of it and used the copy. Because of this behavior, you might have observed that there were two instances of the same object in the Objects menu. However, Security Cloud Control does not do that anymore. You can use an unassociated object in a rule or a policy but there are no duplicate objects that Security Cloud Control creates.

You can view the objects managed by Security Cloud Control by navigating to the Objects menu or by viewing them in the details of a network policy.

Security Cloud Control allows you to manage network and service objects across supported devices from one location. With Security Cloud Control, you can manage objects in these ways:

  • Search for and filter all your objects based on a variety of criteria.

  • Find duplicate, unused, and inconsistent objects on your devices and consolidate, delete, or resolve those object issues.

  • Find unassociated objects and delete them if they are unused.

  • Discover shared objects that are common across devices.

  • Evaluate the impact of changes to an object on a set of policies and devices before committing the change.

  • Compare a set of objects and their relationships with different policies and devices.

  • Capture objects in use by a device after it has been on-boarded to Security Cloud Control.


Note

Out-of-band changes that are done to objects are detected as overrides to the object. When such a change happens, the edited value gets added to the object as an override, which can be viewed by selecting the object. To know more about out-of-band changes on devices, see Out-of-Band Changes on Devices.

If you have issues with creating, editing, or reading objects from an onboarded device, see Troubleshoot Security Cloud Control for more information.

Objects

An object is a container of information that you can use in one or more security policies. Objects make it easy to maintain policy consistency. You can create a single object, use it different policies, modify the object, and that change is propagated to every policy that uses the object. Without objects, you would need to modify all the policies, individually, that require the same change.

When you onboard a device, Security Cloud Control recognizes all the objects used by that device, saves them, and lists them on the Objects page. From the Objects page, you can edit existing objects and create new ones to use in your security policies.

Security Cloud Control calls an object used on multiple devices a shared object and identifies them in the Objects page with this badge .

Sometimes a shared object develops some "issue" and is no longer perfectly shared across multiple policies or devices:

  • Duplicate objects are two or more objects on the same device with different names but the same values. These objects usually serve similar purposes and are used by different policies. Duplicate objects are identified by this issue icon:

  • Inconsistent objects are objects on two or more devices with the same name but different values. Sometimes users create objects in different configurations with same name and content but over time the values of these objects diverge which creates the inconsistency. Inconsistent objects are identified by this issue icon:

  • Unused objects are objects that exist in a device configuration but are not referenced by another object, an access-list, or a NAT rule. Unused objects are identified by this issue icon:

You can also create objects for immediate use in rules or policies. You can create an object that is unassociated with any rule or policy. Before 28 June 2024, when you use an unassociated object in a rule or policy, Security Cloud Control created a copy of it and used the copy. Because of this behavior, you might have observed that there were two instances of the same object in the Objects menu. However, Security Cloud Control does not do that anymore. You can use an unassociated object in a rule or a policy but there are no duplicate objects that Security Cloud Control creates.

You can view the objects managed by Security Cloud Control by navigating to the Objects menu or by viewing them in the details of a network policy.

Security Cloud Control allows you to manage network and service objects across supported devices from one location. With Security Cloud Control, you can manage objects in these ways:

  • Search for and filter all your objects based on a variety of criteria.

  • Find duplicate, unused, and inconsistent objects on your devices and consolidate, delete, or resolve those object issues.

  • Find unassociated objects and delete them if they are unused.

  • Discover shared objects that are common across devices.

  • Evaluate the impact of changes to an object on a set of policies and devices before committing the change.

  • Compare a set of objects and their relationships with different policies and devices.

  • Capture objects in use by a device after it has been on-boarded to Security Cloud Control.


Note

Out-of-band changes that are done to objects are detected as overrides to the object. When such a change happens, the edited value gets added to the object as an override, which can be viewed by selecting the object. To know more about out-of-band changes on devices, see Out-of-Band Changes on Devices.

If you have issues with creating, editing, or reading objects from an onboarded device, see Troubleshoot Security Cloud Control for more information.

Object Types

The following table describes the objects that you can create for your devices and manage using Security Cloud Control.

Table 1. Common Objects

Object Type

Description

Network

Network groups and network objects (collectively referred to as network objects) define the addresses of hosts or networks.

URL

Use URL objects and groups (collectively referred to as URL objects) to define the URL or IP addresses of web requests. You can use these objects to implement manual URL filtering in access control policies or blocking in Security Intelligence policies.

Table 2. FDM-Managed Device Object Types

Object

Description

Application Filter

An application filter object defines the applications used in an IP connection, or a filter that defines applications by type, category, tag, risk, or business relevance. You can use these objects in policies to control traffic instead of using port specifications.

AnyConnect Client Profile

AnyConnect Client Profile objects are file objects and represent files used in configurations, typically for remote access VPN policies. They can contain an AnyConnect Client Profile and AnyConnect Client Image files.

Certificate Filter

Digital certificates provide digital identification for authentication. Certificates are used for SSL (Secure Socket Layer), TLS (Transport Layer Security), and DTLS (Datagram TLS) connections, such as HTTPS and LDAPS.

DNS Group

DNS servers are needed to resolve fully-qualified domain names (FQDN), such as www.example.com, to IP addresses. You can configure different DNS group objects for management and data interfaces.

Geolocation

A geolocation object defines countries and continents that host the device that is the source or destination of traffic. You can use these objects in policies to control traffic instead of using IP addresses.

IKEv1 Policy

An IKEv1 policy object contain the parameters required for IKEv1 policies when defining VPN connections.

IKEv2 Policy

An IKEv2 policy objects contain the parameters required for IKEv2 policies when defining VPN connections.

IKEv1 IPSEC Proposal

IPsec Proposal objects configure the IPsec proposal used during IKE Phase 1 negotiations. The IPsec proposal defines the combination of security protocols and algorithms that secure traffic in an IPsec tunnel.

IKEv2 IPSEC Proposal

IPsec Proposal objects configure the IPsec proposal used during IKE Phase 2 negotiations. The IPsec proposal defines the combination of security protocols and algorithms that secure traffic in an IPsec tunnel.

Network

Network groups and network objects (collectively referred to as network objects) define the addresses of hosts or networks.

Security Zone

A security zone is a grouping of interfaces. Zones divide the network into segments to help you manage and classify traffic.

Service

Service objects, service groups, and port groups are reusable components that contain protocols or ports considered part of the TCP/IP protocol suite.

SGT Group

A SGT dynamic object identifies source or destination addresses based on an SGT assigned by ISE and can then be matched against incoming traffic.

Syslog Server

A syslog server object identifies a server that can receive connection-oriented or diagnostic system log (syslog) messages.

URL

Use URL objects and groups (collectively referred to as URL objects) to define the URL or IP addresses of web requests. You can use these objects to implement manual URL filtering in access control policies or blocking in Security Intelligence policies.

Shared Objects

Security Cloud Control calls objects on multiple devices with the same name and same contents, shared objects. Shared objects are identified by this icon
on the Objects page. Shared objects make it easy to maintain policies because you can modify an object in one place and that change affects all the other policies that use that object. Without shared objects, you would need to modify all the policies individually that require the same change.

When looking at a shared object, Security Cloud Control shows you the contents of the object in the object table. Shared objects have exactly the same contents. Security Cloud Control shows you a combined or "flattened" view of the elements of the object in the details pane. Notice that in the details pane, the network elements are flattened into a simple list and not directly associated with a named object.

Object Overrides

An object override allows you to override the value of a shared network object on specific devices. Security Cloud Control uses the corresponding value for the devices that you specify when configuring the override. Although the objects are on two or more devices with the same name but different values, Security Cloud Control doesn't identify them as Inconsistent objects only because these values are added as overrides.

You can create an object whose definition works for most devices, and then use overrides to specify modifications to the object for the few devices that need different definitions. You can also create an object that needs to be overridden for all devices, but its use allows you to create a single policy for all devices. Object overrides allow you to create a smaller set of shared policies for use across devices without giving up the ability to alter policies when needed for individual devices.

For example, consider a scenario where you have a printer server in each of your offices, and you have created a printer server object print-server. You have a rule in your ACL to deny printer servers from accessing the internet. The printer server object has a default value that you want to change from one office to another. You can do this by using object overrides and maintain rule and "printer-server" object consistent across all locations, although their values may be different.

Out-of-band changes that are done to objects are detected as overrides to the object. When such a change happens, the edited value gets added to the object as an override, which can be viewed by selecting the object. To know more about out-of-band changes, see Out-of-Band Changes on Devices.


Note

Security Cloud Control allows you to override objects associated with the rules in a ruleset. When you add a new object to a rule, you can override it only after you attach a device to the ruleset and save the changes. See Configure Rulesets for an FTD for more information.


Note

If there are inconsistent objects, you can combine them into a single shared object with overrides. For more information, see Resolve Inconsistent Object Issues.

Unassociated Objects

You can create objects for immediate use in rules or policies. You can also create an object that is unassociated with any rule or policy. When you use that unassociated object in a rule or policy, Security Cloud Control creates a copy of it and uses the copy. The original unassociated object remains among the list of available objects until it is either deleted by a nightly maintenance job, or you delete it.

Unassociated objects remain in Security Cloud Control as a copy to ensure that not all configurations are lost if the rule or policy associated with the object is deleted accidentally.

In the left pane, click Objects > and check the Unassociated checkbox.

Compare Objects

Procedure

Step 1

In the left pane, click Objects and choose an option.

Step 2

Filter the objects on the page to find the objects you want to compare.

Step 3

Click the Compare button .

Step 4

Select up to three objects to compare.

Step 5

View the objects, side-by-side, at the bottom of the screen.

  • Click the up and down arrows in the Object Details title bar to see more or less of the Object Details.

  • Expand or collapse the Details and Relationships boxes to see more or less information.

Step 6

(Optional) The Relationships box shows how an object is used. It may be associated with a device or a policy. If the object is associated with a device, you can click the device name and then click View Configuration to see the configuration of the device. Security Cloud Control shows you the device's configuration file and highlights the entry for that object.

Filters

You can use many different filters on the Security Devices and Objects pages to find the devices and objects you are looking for.

To filter, click in the left-hand pane of the Security Devices, Policies, and Objects tabs:

The Security Devices filter allows you to filter by device type, hardware and software versions, snort version, configuration status, connection states, conflict detection, and secure device connectors, and labels. You can apply filters to find devices within a selected device type tab. You can use filters to find devices within the selected device type tab.


Note

When the FTD tab is opened, the filter pane provides filters to show FDM-managed devices based on the management application through which the devices are accessed from Security Cloud Control.

  • FDM: Devices managed using FTD API or FDM.

  • FMC-FTD: Devices managed using Firepower Management Center.

  • FTD: Devices managed using FTD Management.

The object filter allows you to filter by device, issue type, shared objects, unassociated objects, and object type. You can include system objects in your results or not. You can also use the search field to search for objects in the filter results that contain a certain name, IP address, or port number.

The object type filter allows you to filter objects by type, such as network object, network group, URL object, URL group, service object, and service group. The shared objects filter allows filtering objects having default values or override values.

When filtering devices and objects, you can combine your search terms to create several potential search strategies to find relevant results.

In the following example, filters are applied to search objects that are "Issues (Used OR Inconsistent) AND Shared Objects with Additional Values.

Object Filters

To filter, click in the left-hand pane of the Objects tab:

  • Filter by Device: Lets you pick a specific device so that you can see objects found on the selected device.

  • Issues: Lets you pick unused, duplicate, and inconsistent objects to view.

  • Ignored Issues: Lets you view all the objects whose inconsistencies you had ignored.

  • Shared Objects: Lets you view all the objects that Security Cloud Control has found to be shared on more than one device. You can choose to see shared objects with only default values or override values, or both.

  • Unassociated Objects: Lets you view all the objects that are not associated with any rule or policy.

  • Object Type: Lets you select an object type to see only those type of objects that you have selected, such as network objects, network groups, URL objects, URL groups, service objects, and service groups.

Sub filters – Within each main filter, there are sub-filters you can apply to further narrow down your selection. These sub-filters are based on Object Type – Network, Service, Protocol, etc.

The selected filters in this filter bar would return objects that match the following criteria:

* Objects that are on one of two devices. (Click Filter by Device to specify the devices.) AND are

* Inconsistent objects AND are

* Network objects OR Service objects AND

* Have the word "group" in their object naming convention

Because Show System Objects is checked, the result would include both system objects and user-defined objects.

Show System-Defined Objects Filter

Some devices come with pre-defined objects for common services. These system objects are convenient because they are already made for you and you can use them in your rules and policies. There can be many system objects in the objects table. System objects cannot be edited or deleted.

Show System-Defined Objects is off by default. To display system objects in the object table, check Show System-Defined Objects in the filter bar. To hide system objects in the object table, leave Show System Objects unchecked in the filter bar.

If you hide system objects, they will not be included in your search and filtering results. If you show system objects, they will be included in your object search and filtering results.

Configure Object Filters

You can filter on as few or as many criteria as you want. The more categories you filter by, the fewer results you should expect.

Procedure

Step 1

In the left pane, click Objects.

Step 2

Open the filter panel by clicking the filter icon at the top of the page. Uncheck any filters that have been checked to make sure no objects are inadvertently filtered out. Additionally, look at the search field and delete any text that may have been entered in the search field.

Step 3

If you want to restrict your results to those found on particular devices:

  1. Click Filter By Device.

  2. Search all the devices or click a device tab to search for only devices of a certain kind.

  3. Check the device you want to include in your filter criteria.

  4. Click OK.

Step 4

Check Show System Objects to include system objects in your search results. Uncheck Show System Objects to exclude system objects from your search results.

Step 5

Check the object Issues you want to filter by. If you check more than one issue, objects in any of the categories you check are included in your filter results.

Step 6

Check Ignored issues if you want to see the object that had issues but was ignored by the administrator.

Step 7

Check the required filter in Shared Objects if you are filtering for objects shared between two or more devices.

  • Default Values: Filters objects having only the default values.

  • Override Values: Filters objects having overridden values.

  • Additional Values: Filters objects having additional values.

Step 8

Check Unassociated if you are filtering for objects that are not part of any rule or policy.

Step 9

Check the Object Types you want to filter by.

Step 10

You can also add an object name, IP address, or port number to the Objects search field to find objects with your search criteria among the filtered results.

When to Exclude a Device from Filter Criteria

When adding a device to filtering criteria, the results show you the objects on a device but not the relationships of those objects to other devices. For example, assume ObjectA is shared between ASA1 and ASA2. If you were to filter objects to find shared objects on ASA1, you would find ObjectA but the Relationships pane would only show you that the object is on ASA1.

To see all the devices to which an object is related, don't specify a device in your search criteria. Filter by the other criteria and add search criteria if you choose to. Select an object that Security Cloud Control identifies and then look in the Relationships pane. You will see all the devices and policies the object is related to.

Unignore Objects

One way to resolve unused, duplicate, or inconsistent objects is to ignore them. You may decide that though an object is unused, a duplicate, or inconsistent, there are valid reasons for that state and you choose to leave the object issue unresolved. At some point in the future, you may want to resolve those ignored objects. As Security Cloud Control does not display ignored objects when you search for object issues, you will need to filter the object list for ignored objects and then act on the results.

Procedure

Step 1

In the left pane, click Objects and choose an option.

Step 2

Filter and search for ignored objects.

Step 3

In the Object table, select the object you want to unignore. You can unignore one object at a time.

Step 4

Click Unignore in the details pane.

Step 5

Confirm your request. Now, when you filter your objects by issue, you should find the object that was previously ignored.

Deleting Objects

You can delete a single object or mulitple objects.

Delete a Single Object

Caution

If cloud-delivered Firewall Management Center is deployed on your tenant:

Changes you make to the ASA, FDM, and FTD network objects and groups are reflected in the corresponding cloud-delivered Firewall Management Center network object or group. In addition, an entry is created in the Devices with Pending Changes page for each on-premises management center with Discover & Manage Network Objects enabled, from which you can choose and deploy the changes to the on-premises management center on which you have these objects.

Deleting a network object or group from either page deletes the object or group from both pages.
Procedure

Step 1

In the left pane, click Objects.

Step 2

Locate the object you want to delete by using object filters and the search field, and select it.

Step 3

Review the Relationships pane. If the object is used in a policy or in an object group, you cannot delete the object until you remove it from that policy or group.

Step 4

In the Actions pane, click the Remove icon .

Step 5

Confirm that you want to delete the object by clicking OK.

Step 6

Review and deploy the changes you made, or wait and deploy multiple changes at once.

Delete a Group of Unused Objects

As you onboard devices and start resolving object issues, you find many unused objects. You can delete up to 50 unused objects at a time.

Procedure

Step 1

Use the Issues filter to find unused objects. You can also use the Device filter to find objects that are not associated with a device by selecting No Device. Once you have filtered the object list, the object checkboxes appear.

Step 2

Check the Select all checkbox in the object table header to select all the objects found by the filter that appear in the object table; or, check individual checkboxes for individual objects you want to delete.

Step 3

In the Actions pane, click the Remove icon .

Step 4

Review and deploy now the changes you made, or wait and deploy multiple changes at once.

Network Objects

A network object can contain a host name, a network IP address, a range of IP addresses, a fully qualified domain name (FQDN), or a subnetwork expressed in CIDR notation. Network groups are collections of network objects and other individual addresses or subnetworks you add to the group. Network objects and network groups are used in access rules, network policies, and NAT rules. You can create, update, and delete network objects and network groups using Security Cloud Control.

Note that not all platforms support network objects, such as Cisco Merkai and Multicloud Defense; when you share dynamic objects, Security Cloud Control automatically translates the appropriate information from the originating platform or device into a set of usable information that Security Cloud Control can use.

Table 3. Pemitted Values of Network Objects

Device type

IPv4 / IPv6

Single Address

Range of addresses

Fully Qualified Domain Name

Subnet using CIDR Notation

FTD

IPv4 and IPv6

Yes

Yes

Yes

Yes

Multicloud Defense

IPv4 and IPv6

Yes

Yes

Yes

Yes
Table 4. Pemitted Contents of a Network Group

Device type

IP Value

Network Object

Network Groups

FTD

No

Yes

Yes

Multicloud Defense

Yes

Yes

Yes
Reusing Network Objects Across Products

If you have a Security Cloud Control tenant with a cloud-delivered Firewall Management Center and one or more on-premises management centers onboarded to your tenant:

  • When you create a Secure Firewall Threat Defense, FDM-managed threat defense, ASA, or Meraki network object or group, a copy of the object is also added to the objects list on the Objects page used when configuring cloud-delivered Firewall Management Center, and vice versa.

  • When you create a Secure Firewall Threat Defense, FDM-managed threat defense, or ASA network object or group, an entry is created in the Devices with Pending Changes page for each On-Premises Firewall Management Center for which Discover & Manage Network Objects is enabled. From this list, you can choose and deploy the object to the on-premises management center on which you want to use the object and discard the ones that you do not want. Navigate , Administration > Firewall Management Center select the on-premises management center, and click Objects to see your objects in the On-Premises Firewall Management Center user interface and assign them to policies.

Changes you make to network objects or groups on either page apply to the object or group instance on both pages. Deleting an object from one page also deletes the corresponding copy of the object from the other page.

Exceptions:

  • If a network object of the same name already exists for cloud-delivered Firewall Management Center, the new Secure Firewall Threat Defense, FDM-managed threat defense, ASA, or Meraki network object will not be replicated on the Objects page of Security Cloud Control.

  • Network objects and groups in onboarded threat defense devices that are managed by on-premises Secure Firewall Management Center are not replicated and cannot be used in cloud-delivered Firewall Management Center.

    Note that for on-premises Secure Firewall Management Center instances that have been migrated to cloud-delivered Firewall Management Center, network objects and groups are replicated to the Security Cloud Control objects page if they are used in policies that were deployed to FTD devices.

  • Sharing Network Objects between Security Cloud Control and cloud-delivered Firewall Management Center is automatically enabled on new tenants but must be requested for existing tenants. If your network objects are not being shared with cloud-delivered Firewall Management Center, contact TAC to have the features enabled on your tenant.

  • Sharing network objects between Security Cloud Control and On-Premises Management Center is not automatically enabled on Security Cloud Control for new on-premises management centers onboarded to Security Cloud Control. If your network objects are not being shared with On-Premises Management Center, ensure Discover & Manage Network Objects toggle button is enabled for the on-premises management center in Settings or contact TAC to have the features enabled on your tenant.

Viewing Network Objects

Network objects you create using Security Cloud Control and those Security Cloud Control recognizes in an onboarded device's configuration are displayed on the Objects page. They are labeled with their object type. This allows you to filter by object type to quickly find the object you are looking for.

When you select a network object on the Objects page, you see the object's values in the Details pane. The Relationships pane shows you if the object is used in a policy and on what device the object is stored.

When you click on a network group you see the contents of that group. The network group is a conglomerate of all the values given to it by the network objects.

Create or Edit a Firepower Network Object or Network Groups

A Firepower network object can contain a hostname, an IP address, or a subnet address expressed in CIDR notation. Network groups are conglomerates of network objects and network groups that are used in access rules, network policies, and NAT rules. You can create, read, update, and delete network objects and network groups using Security Cloud Control.

Firepower network objects and groups can be used by ASA, threat defense, FDM-managed, and Meraki devices. See Reusing Network Objects Across Products.


Note

If cloud-delivered Firewall Management Center is deployed on your tenant:

When you create an FTD, FDM, or ASA network object or group on the Objects page, a copy of the object is automatically added to the cloud-delivered Firewall Management Center and vice-versa. In addition, an entry is created in the Devices with Pending Changes page for each on-premises management center with Discover & Manage Network Objects enabled, from which you can choose and deploy the objects to the on-premises management center on which you want these objects.

Caution

If cloud-delivered Firewall Management Center is deployed on your tenant:

Changes you make to the ASA, FDM, and FTD network objects and groups are reflected in the corresponding cloud-delivered Firewall Management Center network object or group. In addition, an entry is created in the Devices with Pending Changes page for each on-premises management center with Discover & Manage Network Objects enabled, from which you can choose and deploy the changes to the on-premises management center on which you have these objects.

Deleting a network object or group from either page deletes the object or group from both pages.
Table 5. IP addresses that can be added to network objects

Device type

IPv4 / IPv6

Single Address

Range of addresses

Partially Qualified Domain Name (PQDN)

Subnet using CIDR Notation
Firepower IPv4 / IPv6 Yes Yes Yes Yes
Create a Firepower Network Object

Note

If cloud-delivered Firewall Management Center is deployed on your tenant:

When you create an FTD, FDM, or ASA network object or group on the Objects page, a copy of the object is automatically added to the cloud-delivered Firewall Management Center and vice-versa. In addition, an entry is created in the Devices with Pending Changes page for each on-premises management center with Discover & Manage Network Objects enabled, from which you can choose and deploy the objects to the on-premises management center on which you want these objects.
Procedure

Step 1

In the left pane, click Objects.

Step 2

Click the blue plus button to create an object.

Step 3

Click FTD > Network.

Step 4

Enter an Object Name.

Step 5

Select Create a network object.

Step 6

In the Value section:

  • Select eq and enter a single IP address, a subnet address expressed in CIDR notation, or a Partially Qualified Domain Name (PQDN).

  • Select range and enter an IP address range.

Note

 

Do not set a host bit value. If you enter a host bit value other than 0, Security Cloud Control unsets it while creating the object, because the cloud-delivered Firewall Management Center only accepts IPv6 objects with host bits not set.

Step 7

Click Add.

Attention: The newly created network objects aren't associated with any FDM-managed device as they aren't part of any rule or policy. To see these objects, select the Unassociated objects category in object filters. For more information, see Object Filters. Once you use the unassociated objects in a device's rule or policy, such objects are associated with that device.

Create a Firepower Network Group

A network group can contain network objects and network groups. When you create a new network group, you can search for existing objects by their name, IP addresses, IP address range, or FQDN and add them to the network group. If the object isn't present, you can instantly create that object in the same interface and add it to the network group.


Note

If cloud-delivered Firewall Management Center is deployed on your tenant:

When you create an FTD, FDM, or ASA network object or group on the Objects page, a copy of the object is automatically added to the cloud-delivered Firewall Management Center and vice-versa. In addition, an entry is created in the Devices with Pending Changes page for each on-premises management center with Discover & Manage Network Objects enabled, from which you can choose and deploy the objects to the on-premises management center on which you want these objects.
Procedure

Step 1

In the left pane, click Objects.

Step 2

Click the blue plus button to create an object.

Step 3

Click FTD > Network.

Step 4

Enter an Object Name.

Step 5

Select Create a network group.

Step 6

In the Values field, enter a value or name. When you start typing, Security Cloud Control provides object names or values that match your entry.

Step 7

You can choose one of the existing objects shown or create a new one based on the name or value that you have entered.

Step 8

If Security Cloud Control finds a match, to choose an existing object, click Add to add the network object or network group to the new network group.

Step 9

If you have entered a value or object that is not present, you can perform one of the following:

  • Click Add as New Object With This Name to create a new object with that name. Enter a value and click the checkmark to save it.

  • Click Add as New Object to create a new object. The object name and value are the same. Enter a name and click the checkmark to save it.

It's is possible to create a new object even though the value is already present. You can make changes to those objects and save them.

Note: You can click the edit icon to modify the details. Clicking the delete button doesn't delete the object itself; instead, it removes it from the network group.

Step 10

After adding the required objects, click Save to create a new network group.

Step 11

Preview and Deploy Configuration Changes for All Devices.

Edit a Firepower Network Object

Caution

If cloud-delivered Firewall Management Center is deployed on your tenant:

Changes you make to the ASA, FDM, and FTD network objects and groups are reflected in the corresponding cloud-delivered Firewall Management Center network object or group. In addition, an entry is created in the Devices with Pending Changes page for each on-premises management center with Discover & Manage Network Objects enabled, from which you can choose and deploy the changes to the on-premises management center on which you have these objects.

Deleting a network object or group from either page deletes the object or group from both pages.
Procedure

Step 1

In the left pane, click Objects.

Step 2

Locate the object you want to edit by using object filters and search field.

Step 3

Select the network object and click the edit icon in the Actions pane.

Step 4

Edit the values in the dialog box in the same fashion that you created them in "Create a Firepower Network Group".

Note

 
Click the delete icon next to remove the object from the network group.

Step 5

Click Save. Security Cloud Control displays the devices that will be affected by the change.

Step 6

Click Confirm to finalize the change to the object and any devices affected by it.

Edit a Firepower Network Group

Caution

If cloud-delivered Firewall Management Center is deployed on your tenant:

Changes you make to the ASA, FDM, and FTD network objects and groups are reflected in the corresponding cloud-delivered Firewall Management Center network object or group. In addition, an entry is created in the Devices with Pending Changes page for each on-premises management center with Discover & Manage Network Objects enabled, from which you can choose and deploy the changes to the on-premises management center on which you have these objects.

Deleting a network object or group from either page deletes the object or group from both pages.
Procedure

Step 1

In the left pane, click Objects.

Step 2

Locate the network group you want to edit by using object filters and search field.

Step 3

Select the network group and click the edit icon in the Actions pane.

Step 4

Change the object name and description if needed.

Step 5

If you want to change the objects or network groups that are already added to the network group, perform the following steps:

  1. Click the edit icon appearing beside the object name or network group to modify them.

  2. Click the checkmark to save your changes. Note: You can click the remove icon to delete the value from a network group.

Step 6

If you want to add new network objects or network groups to this network group, you have to perform the following steps:

  1. In the Values field, enter a new value or the name of an existing network object. When you start typing, Security Cloud Control provides object names or values that match your entry. You can choose one of the existing objects shown or create a new one based on the name or value that you have entered.

  2. If Security Cloud Control finds a match, to choose an existing object, click Add to add the network object or network group to the new network group.

  3. If you have entered a value or object that is not present, you can perform one of the following:

    • Click Add as New Object With This Name to create a new object with that name. Enter a value and click the checkmark to save it.

    • Click Add as New Object to create a new object. The object name and value are the same. Enter a name and click the checkmark to save it.

It's is possible to create a new object even though the value is already present. You can make changes to those objects and save them.

Step 7

Click Save. Security Cloud Control displays the policies that will be affected by the change.

Step 8

Click Confirm to finalize the change to the object and any devices affected by it.

Step 9

Preview and Deploy Configuration Changes for All Devices.

Add an Object Override

Caution

If cloud-delivered Firewall Management Center is deployed on your tenant:

Changes you make to the ASA, FDM, and FTD network objects and groups are reflected in the corresponding cloud-delivered Firewall Management Center network object or group. In addition, an entry is created in the Devices with Pending Changes page for each on-premises management center with Discover & Manage Network Objects enabled, from which you can choose and deploy the changes to the on-premises management center on which you have these objects.

Deleting a network object or group from either page deletes the object or group from both pages.
Procedure

Step 1

In the left pane, click Objects.

Step 2

Locate the object to which you want to add an override, using object filters and search field.

Step 3

Select the network object and click the edit icon in the Actions pane.

Step 4

Enter the value in the Override Values dialog box and click + Add Value.

Important

 
The override you are adding must have the same type of value that the object contains. For example, to a network object, you can configure an override only with a network value and not a host value.

Step 5

Once you see that the value is added, click the cell in the Devices column in Override Values.

Step 6

Click Add Devices, and choose the device to which you want the override to be added. The device you select must contain the object to which you are adding the override.

Step 7

Click Save. Security Cloud Control displays the devices that will be affected by the change.

Step 8

Click Confirm to finalize the addition of the override to the object and any devices affected by it.

Note

 
You can add more than one override to an object. However, you must select a different device, which contains the object, each time you are adding an override.

Step 9

See Object Overrides to know more about object overrides and Edit Object Overrides to edit an existing override.

Edit Object Overrides

You can modify the value of an existing override as long as the object is present on the device.

Procedure

Step 1

In the Security Cloud Control navigation bar on the left, click Objects.

Step 2

Locate the object having override you want to edit by using object filters and search field.

Step 3

Select the object having override and click the edit icon in the Actions pane.

Step 4

Modify the override value:

  • Click the edit icon to modify the value.

  • Click on the cell in the Devices column in Override Values to assign new devices. You can select an already assigned device and click Remove Overrides to remove overrides on that device.

  • Click arrow in Override Values to push and make it as the default value of the shared object.

  • Click the delete icon next to the override you want to remove.

Step 5

Click Save. Security Cloud Control displays the devices that will be affected by the change.

Step 6

Click Confirm to finalize the change to the object and any devices affected by it.

Step 7

Preview and Deploy Configuration Changes for All Devices.

Add Additional Values to a Shared Network Group

The values in a shared network group that are present on all devices associated with it are called "default values". Security Cloud Control allows you to add "additional values" to the shared network group and assign those values to some devices associated with that shared network group. When Security Cloud Control deploys the changes to the devices, it determines the contents and pushes the "default values" to all devices associated with the shared network group and the "additional values" only to the specified devices.

For example, consider a scenario where you have four AD main servers in your head office that should be accessible from all your sites. Therefore, you have created an object group named "Active-Directory" to use in all your sites. Now you want to add two more AD servers to one of your branch offices. You can do this by adding their details as additional values specific to that branch office on the object group "Active-Directory". These two servers do not participate in determining whether the object "Active-Directory" is consistent or shared. Therefore, the four AD main servers are accessible from all your sites, but the branch office (with two additional servers) can access two AD servers and four AD main servers.


Note

If there are inconsistent shared network groups, you can combine them into a single shared network group with additional values. See Resolve Inconsistent Object Issues for more information.


Caution

If cloud-delivered Firewall Management Center is deployed on your tenant:

Changes you make to the ASA, FDM, and FTD network objects and groups are reflected in the corresponding cloud-delivered Firewall Management Center network object or group. In addition, an entry is created in the Devices with Pending Changes page for each on-premises management center with Discover & Manage Network Objects enabled, from which you can choose and deploy the changes to the on-premises management center on which you have these objects.

Deleting a network object or group from either page deletes the object or group from both pages.
Procedure

Step 1

In the left pane, click Objects.

Step 2

Locate the shared network group you want to edit by using object filters and search field.

Step 3

Click the edit icon in the Actions pane.

  • The Devices field shows the devices the shared network group is present.

  • The Usage field shows the rulesets associated with the shared network group.

  • The Default Values field specifies the default network objects and their values associated with the shared network group that was provided during their creation. Next to this field, you can see the number of devices that contain this default value, and you can click to see their names and device types. You can also see the rulesets associated with this value.

Step 4

In the Additional Values field, enter a value or name. When you start typing, Security Cloud Control provides object names or values that match your entry.

Step 5

You can choose one of the existing objects shown or create a new one based on the name or value that you have entered.

Step 6

If Security Cloud Control finds a match, to choose an existing object, click Add to add the network object or network group to the new network group.

Step 7

If you have entered a value or object that is not present, you can perform one of the following:

  • Click Add as New Object With This Name to create a new object with that name. Enter a value and click the checkmark to save it.

  • Click Add as New Object to create a new object. The object name and value are the same. Enter a name and click the checkmark to save it.

It's is possible to create a new object even though the value is already present. You can make changes to those objects and save them.

Step 8

In the Devices column, click the cell associated with the newly added object and click Add Devices.

Step 9

Select the devices that you want and click OK.

Step 10

Click Save. Security Cloud Control displays the devices that will be affected by the change.

Step 11

Click Confirm to finalize the change to the object and any devices affected by it.

Step 12

Preview and Deploy Configuration Changes for All Devices.

Edit Additional Values in a Shared Network Group

Caution

If cloud-delivered Firewall Management Center is deployed on your tenant:

Changes you make to the ASA, FDM, and FTD network objects and groups are reflected in the corresponding cloud-delivered Firewall Management Center network object or group. In addition, an entry is created in the Devices with Pending Changes page for each on-premises management center with Discover & Manage Network Objects enabled, from which you can choose and deploy the changes to the on-premises management center on which you have these objects.

Deleting a network object or group from either page deletes the object or group from both pages.
Procedure

Step 1

In the left pane, click Objects.

Step 2

Locate the object having the override you want to edit by using object filters and search field.

Step 3

Click the edit icon in the Actions pane.

Step 4

Modify the override value:

  • Click the edit icon to modify the value.

  • Click the cell in the Devices column to assign new devices. You can select an already assigned device and click Remove Overrides to remove overrides on that device.

  • Click arrow in Default Values to push and make it an additional value of the shared network group. All devices associated with the shared network group are automatically assigned to it.

  • Click arrow in Override Values to push and make it as default objects of the shared network group.

  • Click the delete icon next to remove the object from the network group.

Step 5

Click Save. Security Cloud Control displays the devices that will be affected by the change.

Step 6

Click Confirm to finalize the change to the object and any devices affected by it.

Step 7

Preview and Deploy Configuration Changes for All Devices.

Deleting Network Objects and Groups in Security Cloud Control

If Cloud-delivered Firewall Management Center is deployed on your tenant:

Deleting a network object or group from the Objects page deletes the replicated network object or group from the Objects page on the cloud-delivered Firewall Management Center and vice-versa.

URL Objects

URL objects and URL groups are used by Firepower devices. Use URL objects and groups (collectively referred to as URL objects) to define the URL or IP addresses of web requests. You can use these objects to implement manual URL filtering in access control policies or blocking in Security Intelligence policies. A URL object defines a single URL or IP address, whereas a URL group defines more than one URL or IP address.

Before You Begin

When creating URL objects, keep the following points in mind:

  • If you do not include a path (that is, there is no / character in the URL), the match is based on the server's hostname only. The hostname is considered a match if it comes after the :// separator, or after any dot in the hostname. For example, ign.com matches ign.com and www.ign.com, but it does not match verisign.com.

  • If you include one or more / character, the entire URL string is used for a substring match, including the server name, path, and any query parameters. However, we recommend that you do not use manual URL filtering to block or allow individual web pages or parts of sites, as servers can be reorganized and pages moved to new paths. Substring matching can also lead to unexpected matches, where the string you include in the URL object also matches paths on unintended servers or strings within query parameters.

  • The system disregards the encryption protocol (HTTP vs HTTPS). In other words, if you block a website, both HTTP and HTTPS traffic to that website is blocked, unless you use an application condition to target a specific protocol. When creating a URL object, you do not need to specify the protocol when creating an object. For example, use example.com rather than http://example.com.

  • If you plan to use a URL object to match HTTPS traffic in an access control rule, create the object using the subject common name in the public key certificate used to encrypt the traffic. Also, the system disregards subdomains within the subject common name, so do not include subdomain information. For example, use example.com rather than www.example.com.

    However, please understand that the subject common name in the certificate might be completely unrelated to a web site's domain name. For example, the subject common name in the certificate for youtube.com is *.google.com (this of course might change at any time). You will get more consistent results if you use the SSL Decryption policy to decrypt HTTPS traffic so that URL filtering rules work on decrypted traffic.


    Note

    URL objects will not match HTTPS traffic if the browser resumes a TLS session because the certificate information is no longer available. So even if you carefully configure the URL object, you might get inconsistent results for HTTPS connections.

Create or Edit an FDM-Managed URL Object

URL objects are reusable components that specify a URL or IP address.

To create a URL object, follow these steps:

Procedure

Step 1

In the left pane, click Objects.

Step 2

Click > FTD > URL.

Step 3

Enter an object name and description.

Step 4

Select Create a URL object.

Step 5

Enter the specific URL or IP address for your object.

Step 6

Click Add.

Create a Firepower URL Group

A URL group can be made up of one or more URL objects representing one or more URLs or IP addresses. The Firepower Device Manager and Firepower Management Center also refer to these objects as "URL Objects."

Procedure

Step 1

In the left pane, click Objects.

Step 2

Click > FTD > URL.

Step 3

Enter an object name and description.

Step 4

Select Create a URL group.

Step 5

Add an existing object by clicking Add Object, selecting an object, and clicking Select. Repeat this step to add more objects.

Step 6

Click Add when you are done adding URL objects to the URL group.

Edit a Firepower URL Object or URL Group
Procedure

Step 1

In the left pane, click Objects.

Step 2

Filter the objects to find the object you want to edit and then select the object in the object table.

Step 3

In the details pane, click to edit.

Step 4

Edit the values in the dialog box in the same fashion that you created them in the procedures above.

Step 5

Click Save.

Step 6

Security Cloud Control displays the policies that will be affected by the change. Click Confirm to finalize the change to the object and any policy affected by it.

Application Filter Objects

Application filter objects are used by Firepower devices. An application filter object defines the applications used in an IP connection, or a filter that defines applications by type, category, tag, risk, or business relevance. You can use these objects in policies to control traffic instead of using port specifications.

Although you can specify individual applications, application filters simplify policy creation and administration. For example, you could create an access control rule that identifies and blocks all high risk, low business relevance applications. If a user attempts to use one of those applications, the session is blocked.

You can select applications and application filters directly in a policy without using application filter objects. However, an object is convenient if you want to create several policies for the same group of applications or filters. The system includes several pre-defined application filters, which you cannot edit or delete.


Note

Cisco frequently updates and adds additional application detectors via system and vulnerability database (VDB) updates. Thus, a rule blocking high risk applications can automatically apply to new applications without you having to update the rule manually.


Note

When an FDM-managed device is onboarded to Security Cloud Control, it converts the application filters to application filter objects without altering the rule defined in Access Rule or SSL Decryption. Because of a configuration change, the device's configuration status is changed to 'Not Synced' and requires configuration deployment from Security Cloud Control. In general, FDM does not convert the application filters to application filter objects until you manually save the filters.

Create and Edit a Firepower Application Filter Object

An application filter object allows you to target hand-picked applications or a group of applications identified by the filters. This application filter objects can be used in policies.

Create a Firepower Application Filter Object

To create an application filter object, follow this procedure:

Procedure

Step 1

In the left pane, click Objects.

Step 2

Click > FTD > Application Filter.

Step 3

Enter an object name for the object and optionally, a description.

Step 4

Click Add Filter and select the applications and filters to add to the object.

The initial list shows applications in a continually scrolling list. Click Advanced Filter to see the filter options and to get an easier view for selecting applications. Click Add when you have made your selections. You can repeat the process to add additional applications or filters.

Note

 

Multiple selections within a single filter criteria have an OR relationship. For example, Risk is High OR Very High. The relationship between filters is AND, so Risk is High OR Very High, AND Business Relevance is Low OR Very Low. As you select filters, the list of applications in the display updates to show only those that meet the criteria. You can use these filters to help you find applications that you want to add individually, or to verify that you are selecting the desired filters to add to the rule.

Risks: The likelihood that the application is used for purposes that might be against your organization's security policy, from very low to very high.

Business Relevance: The likelihood that the application is used within the context of your organization's business operations, as opposed to recreationally, from very low to very high.

Types: The type of application.

  • Application Protocol: Application protocols such as HTTP and SSH, which represent communications between hosts.

  • Client Protocol: Clients such as web browsers and email clients, which represent software running on the host.

  • Web Application: Web applications such as MPEG video and Facebook, which represent the content or requested URL for HTTP traffic.

Categories: A general classification for the application that describes its most essential function.

Tags: Additional information about the application, similar to category.

For encrypted traffic, the system can identify and filter traffic using only the applications tagged SSL Protocol. Applications without this tag can only be detected in unencrypted or decrypted traffic. Also, the system assigns the decrypted traffic tag to applications that the system can detect in decrypted traffic only, not encrypted or unencrypted.

Applications List (bottom of the display): This list updates as you select filters from the options above the list, so you can see the applications that currently match the filter. Use this list to verify that your filter is targeting the desired applications when you intend to add filter criteria to the rule. To add a specific application or applications to your object, select them from the filtered list. Once you select the applications, the filter will no longer apply. If you want the filter itself to be the object, do not select an application from the list. Then the object will represent ever application identified by the filter.

Step 5

Click OK to save your changes.

Edit a Firepower Application Filter Object
Procedure

Step 1

In the left pane, click Objects.

Step 2

Locate the object you want to edit by using object filters and search field.

Step 3

Select the object you want to edit.

Step 4

Click the edit icon in the Actions pane of the details panel.

Step 5

Edit the values in the dialog box in the same fashion that you created them in the procedures above.

Step 6

Click Save.

Step 7

Security Cloud Control displays the policies that will be affected by the change. Click Confirm to finalize the change to the object and any policy affected by it.

Geolocation Objects

A geolocation object defines countries and continents that host the device that is the source or destination of traffic. You can use these objects in policies to control traffic instead of using IP addresses. For example, using geographical location, you could easily restrict access to a particular country without needing to know all of the potential IP addresses used there.

You can typically select geographical locations directly in a policy without using geolocation objects. However, an object is convenient if you want to create several policies for the same group of countries and continents.

Update Geolocation Database

To ensure that you are using up-to-date geographical location data to filter your traffic, Cisco strongly recommends that you regularly update the geolocation database (GeoDB). At this time, this is not a task that you can perform using Security Cloud Control. See the following sections of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version your device is running to learn more about the GeoDB and how to update it.

  • Updating System Databases and Feeds

  • Updating System Databases

Create and Edit a Firepower Geolocation Filter Object

You can create a geolocation object by itself on the object page or when creating a security policy. This procedure creates a geolocation object from the object page.

To create a geolocation object, follow these steps:

Procedure

Step 1

In the left pane, click Objects.

Step 2

Click > FTD > Geolocation.

Step 3

Enter an object name for the object and optionally, a description.

Step 4

In the filter bar, start typing the name of a country or a region and you are presented with a list of possible matches.

Step 5

Check the country, countries, or regions that you want to add to the object.

Step 6

Click Add.

Edit a Geolocation Object
Procedure

Step 1

In the left pane, choose Objects.

Step 2

Use the filter panes and search field to locate your object.

Step 3

In the Actions pane, click Edit.

Step 4

You can change the name of the object and add or remove countries and regions to your object.

Step 5

Click Save.

Step 6

You will be notified if any devices are impacted. Click Confirm.

Step 7

If a device or policy was impacted, open the Security Devices page and Preview and Deploy the changes to the device.

DNS Group Objects

Domain Name System (DNS) groups define a list of DNS servers and some associated attributes. DNS servers are needed to resolve fully-qualified domain names (FQDN), such as www.example.com, to IP addresses. You can configure different DNS group objects for management and data interfaces.

FDM-managed devices must have a DNS server configured prior to creating a new DNS Group Object. You can either add a DNS Server to the Firepower Threat Defense Device Settings in Security Cloud Control or create a DNS server in firewall device manager and then sync the FDM-managed configuration to Security Cloud Control. To create or modify the DNS server settings in firewall device manager, see Configuring DNS for Data and Management Interfaces in the Cisco Firepower Device Manager Configuration Guide, Version 6.4. or later.

Create a DNS Group Object

Use the following procedure to create a new DNS group object in Security Cloud Control:

Procedure

Step 1

In the left pane, click Objects.

Step 2

Click > FTD > DNS Group.

Step 3

Enter an Object Name.

Step 4

(Optional) Add a description.

Step 5

Enter the IP address of a DNS server. You can add up to six DNS servers; click the Add DNS Server. If you want to remove a server address, click the delete icon.

Note

 

The list is in priority order: the first server in the list is always used, and subsequent servers are used only if a response is not received from the servers above it. Although you can add up to six servers, only the first 3 servers listed will be used for the management interface.

Step 6

Enter the Domain Search Name. This domain is added to hostnames that are not fully-qualified, for example, serverA instead of serverA.example.com.

Step 7

Enter the amount of Retries. The number of times, from 0 to 10, to retry the list of DNS servers when the system does not receive a response. The default is 2. This setting applies to DNS groups used on the data interfaces only.

Step 8

Enter the Timeout value. The number of seconds, from 1 to 30, to wait before trying the next DNS server. The default is 2 seconds. Each time the system retries the list of servers, this timeout doubles. This setting applies to DNS groups used on the data interfaces only.

Step 9

Click Add.

Edit a DNS Group Object

You can edit a DNS group object that was created in Security Cloud Control or in firewall device manager. Use the following procedure to edit an existing DNS group object:

Procedure

Step 1

In the Security Cloud Control navigation bar on the left, click Objects.

Step 2

Locate the DNS Group Object you want to edit by using object filters and search field.

Step 3

Select the object and click the edit icon in the Actions pane.

Step 4

Edit any of the following entries:

  • Object Name.

  • Description.

  • DNS Server. You can edit, add, or remove DNS servers from this list.

  • Domain Search Name.

  • Retries.

  • Timeout.

Step 5

Click Save.

Step 6

Preview and Deploy Configuration Changes for All Devices.

Delete a DNS Group Object

Use the following procedure to delete a DNS Group Object from Security Cloud Control:

Procedure

Step 1

In the left pane, click Objects.

Step 2

Locate the DNS Group Object you want to edit by using object filters and search field.

Step 3

Select the object and click the Remove icon .

Step 4

Confirm you want to delete the DNS group object and click Ok.

Step 5

Preview and Deploy Configuration Changes for All Devices.

Add a DNS Group Object as an FDM-Managed DNS Server

You can add a DNS group object as the preferred DNS Group for either the Data Interface or the Management Interface. See FDM-Managed Device Settings for more information.

Certificate Objects

Digital certificates provide digital identification for authentication. Certificates are used for SSL (Secure Socket Layer), TLS (Transport Layer Security), and DTLS (Datagram TLS) connections, such as HTTPS and LDAPS.

See the About Certificates and Configuring Certificates following sections of the Resuable Objects chapter of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version your device is running.

About Certificates

Digital certificates provide digital identification for authentication. A digital certificate includes information that identifies a device or user, such as the name, serial number, company, department, or IP address. A digital certificate also includes a copy of the public key for the user or device. Certificates are used for SSL (Secure Socket Layer), TLS (Transport Layer Security), and DTLS (Datagram TLS) connections, such as HTTPS and LDAPS.

You can create the following types of certificate:

  • Internal certificates—Internal identity certificates are certificates for specific systems or hosts. You can generate these yourself using the OpenSSL toolkit or get them from a Certificate Authority. You can also generate a self-signed certificate.

    The system comes with the following pre-defined internal certificates, which you can use as is or replace: DefaultInternalCertificate and DefaultWebServerCertificate

  • Internal Certificate Authority (CA) certificates—Internal CA certificates are certificates that the system can use to sign other certificates. These certificates differ from internal identity certificates with respect to the basic constraints extension and the CA flag, which are enabled for CA certificates but disabled for identity certificates. You can generate these yourself using the OpenSSL toolkit or get them from a Certificate Authority. You can also generate a self-signed internal CA certificate. If you configure self-signed internal CA certificates, the CA runs on the device itself.

    The system comes with the following pre-defined internal CA certificate, which you can use as is or replace: NGFW-Default-InternalCA

  • Trusted Certificate Authority (CA) certificates—A trusted CA certificate is used to sign other certificates. It is self-signed and called a root certificate. A certificate that is issued by another CA certificate is called a subordinate certificate.

    Certificate Authorities (CAs) are trusted authorities that "sign" certificates to verify their authenticity, thereby guaranteeing the identity of the device or user. CAs issue digital certificates in the context of a PKI, which uses public-key or private-key encryption to ensure security. A CA can be a trusted third party, such as VeriSign, or a private (in-house) CA that you establish within your organization. CAs are responsible for managing certificate requests and issuing digital certificates.

    The system includes many trusted CA certificates from third party Certificate Authorities. These are used by SSL decryption policies for Decrypt Re-Sign actions.

For more information, see the Certificate Types Used by Feature section of the Reusable Objects chapter of the Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager for the version your device is running.

Certificate Types Used by Feature

You need to create the right type of certificate for each feature. The following features require certificates.

Identity Policies (Captive Portal)—Internal Certificate

(Optional.) Captive portal is used in identity policies. Users must accept this certificate when authenticating to the device for purposes of identifying themselves and receiving the IP address associated with their usernames. If you do not supply a certificate, the device uses an automatically generated certificate.

SSL Decryption Policy—Internal, Internal CA, and Trusted CA Certificates.

(Required.) The SSL decryption policy uses certificates for the following purposes:

  • Internal certificates are used for known key decryption rules.

  • Internal CA certificates are used for decrypt re-sign rules when creating the session between the client and FDM-managed device.

  • Trusted CA certificates

    • They are used indirectly for decrypt re-sign rules when creating the session between the FDM-managed device and server. Unlike the other certificates, you do not directly configure these certificates in the SSL decryption policy; they simply need to be uploaded to the system. The system includes a large number of trusted CA certificates, so you might not need to upload any additional certificates.

    • When creating an Active Directory Realm object and configuring the directory server to use encryption.

Configuring Certificates

Certificates used in identity policies or SSL decryption policies must be an X509 certificate in PEM or DER format. You can use OpenSSL to generate certificates if needed, obtain them from a trusted Certificate Authority, or create self-signed certificates. </