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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.