Cisco Secure Firewall offers a comprehensive set of Platform Settings that allow administrators to configure core device behavior and streamline configuration across multiple firewalls. These settings govern general operational aspects and can be reused across your deployment for consistency and efficiency.

Let’s explore the key components and configuration options available in the Secure Firewall Platform Settings.

 

Configuring Platform Settings

Platform Settings control foundational aspects of Secure Firewall and can be shared between multiple devices for standardization. These settings include network service controls, protocol inspection behavior, system access methods, and more. A shared policy makes it much easier to configure multiple devices for consistency such as standardizing SSH access to all the Secure Firewalls in one single policy.

 

Configuration of Platform Settings

Step 1: Create a Platform Policy

  • Navigate to Devices> Platform Settings

 

  • Click the New Policy button and choose Threat Defense Policy

 

  • Give the policy a name and add the devices you wish to be covered by this policy to the Selected Devices and Templates table.

 

  • Under the Trusted DNS Servers tab, you can configure specific trusted DNS services for DNS snooping to map the application domains to IPs in order to detect the application in the first packet.
    • You can enable the Trust Any DNS Server setting if you wish. By default, it is disabled.
    • If you do not want to trust any DNS server, you can specify below that settingto trust based on:
      • DNS Servers discovered by dhcp-pool are considered trusted DNS servers
      • DNS Servers discovered by dhcp-relay are considered trusted DNS servers
      • DNS Servers discovered by dhcp-client are considered trusted DNS servers
      • DNS Server Group are considered trusted DNS servers
    • You can also click the Edit button under the Specify DNS Servers setting to trust specific DNS servers.
    • Click Save to save the policy when done.

 

 

Step 2: Configure the Platform Settings

Next we will go over each platform setting, what it does, and how to configure each one.

 

ARP Inspection

This setting only applies in transparent mode. It is used to detect ARP spoofing on the network. By enabling ARP inspection, it also automatically enables Flood Protection. When Flood Protection is enabled, if an ARP packet doesn’t match a static ARP entry, the firewall will flood the packet out of all its interfaces to determine its legitimacy.

To configure this setting:

  • Click the Add button

 

  • Check the Inspect Enabled box to enable ARP inspection.
    • Note: As stated above,  Flood Enabled will automatically be enabled as well automatically.
  • Add the interfaces that you would like to enable ARP inspection on to the Selected Zones/Interfaces table
    • Note: If you don’t see any interfaces available, that might be due to the fact that no firewall in your deployment is configured in transparent mode.
  • Click Ok when done and save the policy.

 

 

Banner

This setting is to set a banner message that users see when logging into the device. You can only use ASCII characters but you can use dynamic variables to add the $(hostname) or $(domain).

  • To configure, just add your login banner and save the policy.

 

 

DNS

DNS servers in Cisco Secure Firewall are used to resolve hostnames for both data and special management traffic, but this procedure applies only to data DNS settings. You can configure multiple DNS server groups to handle different domain resolutions, using internal DNS for internal domains and public DNS for internet access. DNS server selection depends on routing lookups and the interface settings where DNS is enabled. Additionally, trusted DNS servers can be set for DNS snooping to assist in identifying applications based on domain resolution from the first packet.

  • Click on the Enable DNS name resolution by device setting to enable DNS resolution on the device
  • Click the Add button on the DNS Server Groups to add an existing group object or create one.

 

  • Select a group object from the dropdown or click the + New Group button to create a new one.
    • Optionally, check the Make as default box to make it resolve all domains
    • If you do not want it to be the default DNS group, then you can filter the domain in the Filter Domain field.

 

  • Optionally, you can modify the Expiry Entry Timer (minimum time-to-live for the DNS entry) and Poll Timer (time limit after the device queries the DNS server to resolve the FQDN)
  • On the field below, you can choose which interface objects will be used to connect with the DNS servers by moving the interfaces into the Selected Interface Objects table.
  • By checking the Enable DNS Lookup via diagnositic/Management interface also box, the management/diagnostic interfaces may be used for DNS lookup. You would likely want to check this box if you are using the firewall in transparent mode.

 

 

External Authentication

When you enable external authentication in Cisco Secure Firewall, user credentials are verified through LDAP or RADIUS using an external authentication object. These objects can be shared between the management center and devices, but due to differences in user handling and timeout ranges, separate objects are often recommended, especially if you define users directly on the RADIUS server. Only one authentication object can be assigned per platform settings policy, and certain features like CAC-enabled LDAP cannot be used for CLI access. For threat defense SSH access, only a subset of fields in the object is used; others are ignored unless also used by the management center. Usernames must be lowercase and Linux-valid, excluding special characters like @ or /. Internal users must be added via CLI, and internal accounts take precedence during login authentication. RADIUS users should be assigned the appropriate privilege level to ensure successful access, while LDAP users always receive Config privileges.

  • To start the configuration, click on the Manage External Authentication Server link.

 

  • This will open a new tab to the External Authentication page. Click Add External Authentication Object to add an external authentication server.

 

  • You can choose to configure an LDAP or RADIUS server for external authentication. Below is an example of an AD domain controller configured for external authentication.

 

  • After configuring the LDAP server, click Save to continue.
  • Move the slider to enable the LDAP server, click Save and Apply, and apply changes.

 

  • Going back to the Platform Settings, refresh the External Authentication tab and you should now see your new LDAP server. Move the slider to enable.
  • Click Save to save the policy.

 

 

Fragment Settings

By default, Secure Firewall allows up to 24 fragments per IP packet and 200 fragments in reassembly. If your network doesn’t rely on fragmented traffic (e.g., NFS over UDP), it’s best to set the Chain limit to 1 to reduce the risk of DoS attacks that exploit fragmentation.

  • The settings that can be configured under this policy include:
    • Size (Block): Max number of fragments allowed for reassembly.
    • Chain (Packet): Max number of fragments in a single IP packet.
    • Timeout (Sec): Time limit to wait for all fragments to arrive after the first one.
  • Click Save to save the policy.

 

 

HTTP Access 

You can enable the HTTPS server on Cisco Secure Firewall to support health checks from cloud load balancers, such as AWS Application Load Balancers. This HTTPS configuration applies only to data interfaces (including management-only ones), not the dedicated Management interface. The device does not support a web interface for configuration in this mode—HTTPS is strictly for external service use like health monitoring. You don’t need an access rule; just ensure HTTPS is enabled on a reachable interface. If you use AnyConnect VPN on an interface, you can’t also use HTTPS on the same port (e.g., 443); instead, configure HTTPS on an alternate port like 4443.

  • Check the Enable HTTP Server box to enable HTTP on the device
  • Optionally, you may configure another port to use for HTTP. By default, 443 is used
  • Click Add to add the interface ot enable HTTPS on.

 

  • Under the Add HTTP Configuration dialog window, add the IP address that will be used for the HTTPS configuration and the interfaces to allow HTTP connections on.
  • Click Ok and then save the policy.

 

 

ICMP Access

By default, Secure Firewall allows ICMP to any interface over IPv4 or IPv6, except for broadcast pings and traffic sent through one interface to another. You can create ICMP rules to restrict access by host, network, or message type, similar to access control rules. If you define any ICMP rule, an implicit deny is added at the end, so include a final “permit any” rule if you want to allow unspecified types. It’s strongly recommended to permit ICMP type 3 (unreachable), as blocking it can break path MTU discovery and disrupt IPsec or PPTP traffic. ICMP is also essential for IPv6 neighbor discovery.

  • If you would like, you can rate-limit ICMP to protect against abuse.
  • Click Add to add interfaces and specify the ICMP types allowed in.

 

  • In the Add ICMP dialog box, you can start adding rules on which types of ICMP messages to allow or block.
    • Action – Choose whethre to Permit or Deny
    • ICMP Service – You can configure here which ICMP type and code to allow. You may need to create a port object for the types by clicking the + sign next to it.
    • Network – The network you are controlling
    • Selected Zones/Interfaces – The interfaces you will enfoce this rule on
  • Once you have configured all your rules, save the policy.

 

 

Netflow

NetFlow on Secure Firewall captures IP traffic as it enters or exits an interface and sends it to a NetFlow collector for analysis, helping you monitor traffic sources, patterns, and bandwidth usage. When using native NetFlow, be sure to disable any existing syslog-based flow exports to avoid conflicts.

  • To start the configuration, slide the Enable Flow Export slider
  • Configure the Active Refresh Interval, Delay Flow Create, and Template Timeout Rate.
  • Click the Add Collector button

 

  • In the Add Collector dialog window, you can choose the host to send Netflow to as well as the port.
  • If no current interface groups are showing as available, click the + sign to create one.

 

  • In the Interface Group dialog box, give the interface group a name.
  • Select the Secure Firewall that you would like to add interfaces from the dropdown
  • Add interfaces to the Selected Interfaces table.
  • Click Ok when completed

 

  • Add the newly created interface group to the Selected Interface Groups table
  • Click Ok

 

 

SSH Access

To allow management access via SSH on a data interface like “outside,” you must explicitly enable SSH for that interface. Secure Firewall uses the CiscoSSH stack based on OpenSSH, supporting FIPS compliance and secure updates. SSH is enabled by default on the Management interface and configured separately from data interfaces. SSH access to data interfaces uses the regular routing table, not static management routes, and does not require additional access rules. You can only SSH to a reachable interface, and if using VPN, it must terminate on the same virtual router as the SSH interface or be route-leaked. Supported ciphers include AES variants with SHA2 for integrity and DH Group 14 for key exchange.

  • To configure SSH access, click the + Add to start the configuration

 

  • In the Add Secure Shell Configuration dialog box, configure the network object or group that identifies the hosts or networks that you’ll allow to make SSH connections.
  • Move the interfaces that you wish SSH connections to come in on to the Selected Zones/Interfaces table.
  • Click Ok to close the dialog box and save your policy.

 

 

SMTP Server

This is where you identify the SMTP servers to send email alerts directly from the firewalls.

  • To configure this, simply choose a primary server IP address and an optional secondary server IP address for the SMTP server.
  • Save your policy

 

 

SNMP

SNMP on Cisco Secure Firewall enables network monitoring using SNMP versions 1, 2c, and 3, all of which can run simultaneously. It supports read-only access via GET requests, but does not allow SNMP write operations like SET. You can configure the firewall to send SNMP traps (event notifications) to a Network Management System (NMS) or allow the NMS to browse Management Information Bases (MIBs) using GET-NEXT or GET-BULK requests. Traps notify management stations of key events like link status changes, helping administrators monitor device health and activity.

The agent runs on the Secure Firewall and responds to information requests from a network management station (NMS) but does not allow changes via SET commands. Browsing refers to the NMS polling the agent for device status using GET-NEXT or GET-BULK requests. MIBs (Management Information Bases) define standardized data points, like connections, traffic, or failovers, that the NMS can monitor. Traps are alerts automatically sent from the agent to the NMS for key events like interface changes or restarts. Each event is tagged with an OID (Object Identifier) to uniquely identify its source.

MIBs (Management Information Bases) can be either standard (defined by the IETF in RFCs) or enterprise-specific. SNMP traps—used to report critical events like errors or failures—are defined in these MIBs. Cisco Secure Firewall includes compiled support for both standard and enterprise-specific traps as part of its software.

  • To enable SNMP, check the Enable SNMP Servers box.
  • If you wish to only configure the basic options:
    • Add the read community string under Read Community String
    • Optionally, you may add a System Administrator Name, Location, and modify the default Listen Port.

 

  • To add an SNMP management host, click + Add in the Hosts tab below.

 

  • This will allow you to define different read community strings and other options per SNMP management server. In the Add SNMP Management Hosts dialog window, configure the management host by adding the following:
    • IP Address – The SNMP management host IP address
    • SNMP Version – Versions can be 1, 2c, or 3
    • Community String – This is the Read Community String which can be used for SNMP polls or traps.
    • Poll – Enabled by default. This lets the management station poll requested information from the device
    • Traps – Enabled by default. This lets the device send events to the management station as they occur
    • Trap Port – This is 162 by default but can be changed to a different port.
    • Reachable By – Define whether the SNMP management server should be communicating with the device by the device’s management interface or specific security zones/named interfaces.
    • Selected Zones/Interfaces – Modify this to specify which security zones/named interfaces the SNMP management server may communicate with the devices if you decide not to choose the management interface.
  • Click Ok to close the dialog window when done.

 

  • If you wish to use SNMP v3, you may click on the Users tab and then click + Add to add SNMP users.

 

  • In the Add Username dialog box, you may configure the following per user:
    • Security Level – Allows you to configure authentication and privacy algorithms depending on which option you choose.
      • NoAuth – This option means that there is not authentication or privacy applied to messages sent between the device and the SNMP management server.
      • Auth – Provides authentication but no privacy. This means that the messages themselves are authenticated. If you choose this option, you will need to configure the following:
        • Encryption Password Type – Options are Clear Text or Encrypted. If you choose Encrypted, the password must be formatted as xx:xx:xx…, where xx are hexadecimal values.
        • Auth Algorithm Type – Options include SHA, SHA224, SHA256, and SHA384.
        • Authentication Password – Enter the password used for authentication. If you choose Encrypted Password Type, the password must be formatted as xx:xx:xx…, where xx are hexadecimal values.
      • Priv – This option configures authentication and privacy so the messages are both private and authenticated. If you choose this option, you will need to configure the following:
        • Encryption Password Type – Options are Clear Text or Encrypted. If you choose Encrypted, the password must be formatted as xx:xx:xx…, where xx are hexadecimal values.
        • Auth Algorithm Type – Options include SHA, SHA224, SHA256, and SHA384.
        • Authentication Password – Enter the password used for authentication. If you choose Encrypted Password Type, the password must be formatted as xx:xx:xx…, where xx are hexadecimal values.
        • Encryption Type – Options are AES128, AES192, and AES256
        • Encryption Password – Enter the password used for authentication. If you choose Encrypted Password Type, the password must be formatted as xx:xx:xx…, where xx are hexadecimal values.
    • Username – This is the username of the SNMP user

 

SNMP traps on Cisco Secure Firewall are unsolicited notifications sent to a management station when specific events occur, such as link status changes or syslog triggers. Unlike SNMP browsing, traps are pushed automatically and include an object ID (OID) identifying the source. These traps are defined in standard or enterprise-specific MIBs and are built into the firewall software. Some traps may not apply to all hardware models. For example, devices without field-replaceable units will ignore related traps.

  • To configure the SNMP traps, click on the SNMP Traps tab.
  • You can now modify and enable specific SNMP traps. Let’s run through them all:
    • All SNMP – This selects all possible traps for all sections below it.
    • Syslog – This enables the transmission of SNMP trap-related syslog messages
    • Standard – These are enabled by default.
      • Authentication – Indicates an authentication failure caused by an incorrect community string in the SNMP request.
      • Link Up – One of the device’s network interfaces has become active and is now operational.
      • Link Down – Indicates that one of the device’s network interfaces has failed or gone offline.
      • Cold Start – Indicates that the device is rebooting in a way that may alter its configuration or protocol implementation.
      • Warm Start – Indicates that the device is rebooting without any changes to its configuration or protocol implementation.
    • Entity MIB –
      • Field Replaceable Unit Insert – Indicates that a hardware component, like a power supply, fan, or module, has been added to the device.
      • Field Replaceable Unit Delete – Indicates that a hardware component, such as a power supply or module, has been removed from the device.
      • Configuration Change – Indicates that a hardware modification has occurred on the device.
    • Connection Limit Reached – Indicates a connection was denied because the device hit its maximum configured connection limit.
    • Other –
      • NAT Packet Discard – Indicates that IP packets were dropped because available NAT addresses or ports dropped below the configured threshold.
      • CPU Rising Threshold – Alerts when CPU usage exceeds a set threshold for a specified duration.
        • Percentage – The high CPU threshold defaults to 70% (configurable between 10–94%), with a fixed critical threshold at 95%.
        • Period – The default CPU monitoring period is 1 minute, adjustable between 1 and 60 minutes.
      • Memory Rising Threshold – Alert is triggered when memory usage surpasses a set limit, indicating reduced available memory.
        • Percentage – The high memory threshold defaults to 70%, with a configurable range between 50% and 95%.
      • Failover – Triggered when the device’s failover state changes, as reported by the CISCO-UNIFIED-FIREWALL-MIB.
      • Cluster – Indicates a change in the device’s cluster health status, as reported by the CISCO-UNIFIED-FIREWALL-MIB.
      • Peer Flap – Signals BGP route flapping, where frequent updates are sent due to unstable network reachability.

 

  • Save and deploy your policy to your devices.

 

 

SSL

To configure SSL settings in Secure Firewall Management Center, you must have admin privileges, operate in a leaf domain, and use a fully licensed system. SSL settings are disabled in evaluation mode or if your license doesn’t meet export compliance. For Remote Access VPN with SSL, your Smart Account must also support strong-crypto features.

  • To configure the SSL settings, you’ll need to set the minimum SSL versions for the server.
    • TLS Version – You can select TLSV1, TLSV1.1, TLSV1.2, or TLSV1.3
    • DTLS Version – You can choose DTLSv1 or DTLSv1.2.
    • Diffie-Hellman Group – You can choose Group 1, Group 2, Group 5, Group 14, or Group 24.
    • Elliptical Curve Diffie-Hellman Group – You can select Group 19, Group 20, or Group 21.
  • Click the + Add button to bring up the Add SSL Configuration dialog box. You can choose the following options:
    • Protocol Version – This specifies the TLS protocols to use when establishing remote access VPN sessions. The options available for choice are TLSv1, TLSv1.2, TLSv1.4, DTLSv1, or DTLSv1.2.
    • Security Level – This indicates the security positioning you would like to set up for the SSL. The options available are All, Low, Medium, High, Fips, or Custom. If you choose custom, you can select which cipher suites to add below.

 

  • Click OK to close the dialog window and save your policy.

 

 

Syslog

Secure Firewall supports system logging (syslog) to help identify network or configuration issues and to track security events. Logs can be sent to one or more syslog servers for centralized, long-term storage and analysis. There are three main categories of syslog messages: device and system health logs (e.g., NAT, VPN, routing –  configured in Platform Settings), security event logs (e.g., malware, intrusion events – configured in Platform Settings and access control policies), and policy/rule-related logs (e.g., access control and intrusion rules – configured in alert responses). You can also direct logs to various destinations, such as syslog servers, email, or internal buffers, for flexible monitoring and alerting.

Syslog messages in Cisco Secure Firewall are categorized by severity levels ranging from 0 to 7, where lower numbers indicate more critical events. Levels include emergencies (0) for system failure, alerts (1) and criticals (2) for urgent issues, and errors (3) or warnings (4) for general fault conditions. Less severe messages include notifications (5), informational (6) logs, and debugging (7), which should only be used temporarily due to the high volume of output. Note that Secure Firewall does not generate messages at level 0 (emergencies).

You can filter syslog messages so that only specific logs are sent to selected output destinations. You can filter messages based on message ID, severity level, or message class (e.g., routing, VPN), although this does not apply to security events, such as intrusion or connection logs. These filters are managed through custom message lists or by assigning message classes directly to output destinations. This helps streamline log management and avoid overwhelming storage or monitoring systems

The firewalls organize syslog messages into message classes, which group related logs by feature or function, such as VPN, routing, NAT, and access control. Each class corresponds to a specific range of message ID numbers and allows administrators to filter or direct logs based on type. For example, syslog IDs starting with 611 belong to the vpnc (VPN client) class. You can assign an entire class to a specific logging destination or build message lists using these classes for more refined filtering. Many VPN-related syslog messages include identifying information, such as group name, username, and IP address. Note that these classes apply only to operational logs, not to security events like intrusion or connection logs, and some are available only in the management center UI, not directly on the device.

  • In the Syslog section of the Platform Settings, we start at the Logging Setup tab. Here we can configure the following:
    • Enable Logging – Enabling this option activates data plane system logging on the Secure Firewall Threat Defense device.
    • Enable logging on the failover standby unit. This is fairly self-explanatory. If your firewall has a standby unit, you should enable it as well.
    • Send syslogs in EMBLEM format – To display the priority (PRI) value in syslog messages from a managed Secure Firewall device, enable EMBLEM format logging. Note that EMBLEM requires the use of UDP, as it is not compatible with TCP.
    • Send debug messages as syslogs – Enabling this option redirects all debug trace output to syslog using message ID 711001. Still, it won’t appear in the console unless you explicitly configure the console as a logging destination with debug-level logging.
    • Memory Size of the Internal Buffer (bytes) – You can set the size of the internal logging buffer (default: 4096 bytes, range: 4096–52,428,800). Once full, the buffer overwrites the oldest syslog messages.
    • Logging to Secure Firewall Management Center – You can configure syslog logging to the management center by selecting either All Logs or VPN Logs, and choosing a severity level such as critical, alerts, or emergencies. By default, All Logs use the critical level, and VPN Logs use errors. Since VPN syslogs can generate high volume, especially with Remote Access VPN, it’s recommended to limit logging to error level or higher to avoid overloading the management center.
    • FTP Server Information – Optionally, you can configure an FTP server to save syslog buffer contents before they are overwritten by specifying the server details in the logging settings. Some of the things that you can configure under this are:
      • FTP Server Buffer Wrap – To preserve log buffer contents before they’re overwritten, enable the FTP option and enter the destination details. Deselect the option to remove the FTP configuration.
      • IP Address – Choose the host network object that defines the IP address of the FTP server for log buffer uploads.
      • Username – Enter the FTP username required to authenticate and connect to the server.
      • Path – Specify the file path, relative to the FTP root directory, where the log buffer contents will be stored.
      • Password – Enter and confirm the FTP password used to authenticate the specified username.
      • Interface Groups – Enter the allowed interface groups for communication to this FTP server.
    • Flash Size – Optionally, set the flash size to save log buffer contents locally before they’re overwritten. Here are some options to consider if you would like to enable it.
      • Flash – Enable this option to save log buffer contents to flash memory before they are overwritten.
      • Maximum flash to be used by logging (KB) – Set the maximum flash storage space for logs, ranging from 4 to 8,044,176 kilobytes.
      • Minimum free space to be preserved (KB) – Define the minimum free space to retain in flash memory, with a configurable range of 0 to 8,044,176 kilobytes.

 

  • To view syslog messages at a specific destination, you must enable that destination and apply a message filter. Navigate to the Logging Destinations tab.
  • Click + Add to add a destination.

 

  • On the Add Logging Filter dialog box, we can configure the following:
    • Logging Destination – Select a destination, such as Console, Email, Buffer, SNMP Trap, SSH Sessions, or Syslog Server, and apply a message filter to customize the output. Note that Console and SSH session logging only work within the diagnostic CLI (system support diagnostic-cli).
    • Event Class – Choose how to filter unlisted event classes by severity, a custom event list, or disable logging entirely for that destination.

 

    • To create filters per event class, click Add.
      • Select the event class and set a severity level to control which messages are logged.

 

  • Click Ok to close the dialog windows and save your policy.
  • You can configure a list of email recipients to receive syslog messages. To do so, navigate to the Email Setup tab.
    Note that most platform settings don’t apply to security event messages, such as connection or intrusion logs.
  • Under Source e-mail address, configure the email address that you wish to use for the syslog messages you want to send as emails.
  • Click + Add to configure the email recipient.

 

  • In the Add Email Recipient dialog box, you can configure the destination email address to which syslog messages will be sent and the syslog severity for which emails will be sent.

 

  • Click Ok to close the box and save your policy.
  • An event list is a custom filter that allows you to control which syslog messages are sent to a destination based on event class, severity, and message ID, providing more precision than severity alone. To use one, first create it under Event Lists tab, then later apply it as a filter in Logging Destinations. Let’s navigate to the Event Lists tab to make one.
  • Click on the + Add button to open the Add Event List dialog box.

 

  • Name the event list and click + Add to add an event class.

 

  • Choose the event class and syslog severity from the dropdown and click Ok.

 

  • Once done, click Ok to close the Add Event List window and save your policy.
  • You can control syslog message rates by setting limits per severity level or specific message ID, with message ID limits taking precedence if both are configured. Navigate to the Rate Limit tab to start this configuration.
    • Under the Logging Level sub-tab, we can limit message generation by severity level. Click the + Add button to start this configuration.

 

    • This will open the Add Rate Limit for Syslog Logging Level dialog box. From here, you can specify the logging severity level, the maximum number of messages allowed, and the time interval in seconds for resetting the counter. Click Ok when done.
    • To limit the number of messages by syslog message ID, navigate to the Syslog Level subtab and click + Add to open the Add Rate Limit for Message Level dialog box.

 

    • From this dialog window, we can configure the syslog message ID we are rate limiting, along with the maximum number of messages for that specific ID and the number of seconds before the counter resets.

 

    • Click Ok to close the dialog box and then save your policy.
  • General syslog settings let you customize messages by setting the facility code, enabling timestamps, defining a device ID, adjusting severity levels, and disabling specific message IDs. To configure these settings, navigate to the Syslog Settings tab. Under this tab, you can configure the following:
    •  Facility – Choose a syslog facility (default: LOCAL4) to help syslog servers categorize messages. This is primarily used for system logs and is not typically used for security events.
    • Enable timestamp on syslog messages – This includes the date and time a messages was generated in the syslog message.
      • Timestamp Format – You can choose between two syslog timestamp formats: the default Legacy format (MMM dd yyyy HH\:mm\:ss), which omits time zone info, or RFC 5424 format (ISO 8601), which includes a “Z” to indicate UTC.
    • Enable syslog device ID – To add a device identifier to syslog messages and you can choose from Interface IP, a custom text string, or the device’s hostname to prepend to each log message.
    • Enable All Syslog Messages – You can configure all syslog messages as a specific logging level.
    • Enable Individual Syslog Messages – To enable specific syslog messages that you want to enable.
      • Netflow equivalent syslogs – By default, NetFlow is enabled. You can reduce redundant logging by selecting this option, which suppresses matching syslog messages without overwriting existing rules.
    • The Syslog Message table allows you to customize individual syslog messages by adjusting their severity level or disabling them altogether. Use it only if you want to override default settings, select a message ID, choose a new logging level, or mark it as suppressed to stop its generation. Click the +Add button to open the Add Syslog Settings window.

 

  • From this window, configure the Syslog ID, Logging Level, and whether or not to enable this syslog ID.

 

  • Click Ok once completed and save the policy.
  • To send syslog messages to an external server, we will need to configure a syslog server and ensure the devices can reach it over the network. Navigate to the Syslog Servers tab. Under this tab, you can configure the following:
    • Allow user traffic to pass when TCP syslog server is down – To ensure traffic continuity, it’s recommended to enable this option, which allows connections even if all TCP-based syslog servers are unreachable. This setting is enabled by default, but if previously disabled in older versions (6.2.x or earlier), it must be manually re-enabled after upgrading. When disabled, traffic is only blocked if none of the configured TCP syslog servers are reachable.
    • Message Queue Size (Messages) – This setting defines how many syslog messages the firewall can temporarily store when the syslog server is busy. The default is 512, with 0 allowing unlimited queuing (based on available memory). If the queue limit is exceeded, messages are dropped; therefore, it’s essential to size the queue based on the available block memory.
    • Click the + Add button to add a new syslog server. This will open up the Add Syslog Server dialog box. In this box, you can configure the following:

 

      • IP Address – Choose a network host object that defines the IP address of the syslog server for log message delivery.
      • Protocol & Port – Select either TCP or UDP as the protocol for syslog communication and specify the port – UDP (default: 514) is faster and lighter, while TCP (default: 1470) must be configured manually. Valid custom ports range from 1025 to 65535.
      • Log Messages in Cisco EMBLEM format (UDP only) – Enable to log messages in EMBLEM format, which is only available when using UDP as the syslog protocol.
      • Enable secure syslog – Enable encryption of syslog communication between the device and server using SSL/TLS over TCP.
      • Reachable by Device Management Interface – Sends syslogs out of the management interface. Recommended when configuring syslog on Snort events. Note: This option doesn’t support secure syslog.
      • Reachable by Security Zones or Named Interfaces – Select the interface/security zones that you want to send the syslog messages out of.

 

  • Click Ok to close the dialog box.
  • Save your policy and deploy it to the devices.

 

 

Timeouts

You can configure global idle timeouts for various services with this setting. You can easily change the timeout for certain services from the default in this menu.

 

 

Time Synchronization

Configure a Network Time Protocol (NTP) server to keep your Secure Firewall devices in sync; ideally, all devices and the management center should use the same NTP server. If the device can’t reach its NTP servers, it will fall back to syncing with the management center. NTPv4 is supported. This menu is easy to configure by either selecting the Management Center or a specific NTP server.

 

 

Time Zone

By default, Secure Firewall uses UTC, but you can set a different time zone for time-based policy enforcement, such as time-based ACLs, which are supported in Snort 3 starting with management center 7.0.

Configuring the time zone is simply selecting one from the dropdown box in this menu.

 

 

UCAPL/CC Compliance

You may enable either Unified Capabilities Approved Product List (UCAPL) or Common Criteria (CC) compliance by choosing from a dropdown in this menu.

 

 

Performance Profile

The performance profile in Secure Firewall (7.3+) controls how CPU cores are allocated between the data plane (Lina), which handles VPN, routing, and basic L3/L4 functions, and Snort, which performs deep packet inspection for features such as intrusion prevention and malware filtering. While the default profile offers balanced core usage, you can adjust it to prioritize VPN or inspection workloads for better performance. This feature is supported on Firepower 4100/9300, Secure Firewall 3100/4200 (7.4+), and Threat Defense Virtual, but only on standalone systems, not clusters, HA pairs, or multi-instance setups. Core assignments must be in even numbers, with a minimum of 2.

  • In this menu, you can configure the performance profile by selecting the desired profile using the radio button. The options include:
    • Default – This recommended setting offers the best balance for deployments using both VPN and intrusion inspection, ensuring optimal performance across core system functions.
    • VPN Heavy with prefilter fastpath – If your device is mainly used as a VPN endpoint with fastpath enabled in the prefilter policy, select this profile to allocate 90% of CPU cores to the data plane and 10% to Snort for maximum VPN performance.
    • VPN Heavy with inspection – For VPN-focused deployments without fastpath enabled, choose this profile to allocate 60% of CPU cores to the data plane and 40% to Snort. This profile is ideal when advanced inspection is handled by another device in the network.
    • IPS Heavy – If the device is used primarily for intrusion prevention without VPN, select this profile to dedicate 70% of CPU cores to Snort and 30% to the data plane for enhanced inspection performance.

 

The Secure Firewall Platform Settings allow you to shape the foundational behavior of your firewall appliances. From defining how fragmented packets are handled, to setting up secure access and monitoring via SSH, SNMP, and syslog, these configurations form the bedrock of a consistent and secure firewall deployment.

Ensure that your platform settings are aligned with your organization’s policy and use shared objects whenever possible for easier management at scale.

 

 

Configuring IGMP Multicast Routing

Multicast traffic plays a crucial role in efficiently distributing content, such as video streams, software updates, and real-time data, across networks. Cisco Secure Firewall supports multicast routing through the use of IGMP and PIM, both of which can be configured via the FMC GUI. Next, we will walk through enabling multicast routing and configuring IGMP on the Secure Firewall interfaces. IGMP allows IP hosts to report their multicast group memberships to directly connected routers, enabling dynamic registration on a LAN. Routers use IGMP to listen for these messages and periodically send queries to identify which multicast groups are active or inactive on each subnet.

 

Step 1: Enable Multicast Routing

Enabling multicast routing on Cisco Secure Firewall automatically activates IGMP and PIM on all interfaces. IGMP handles group membership discovery on local subnets, while PIM builds and maintains the multicast forwarding tables needed to route traffic across the network.

  • To begin multicast configuration, navigate to Device > Device Management > Device > Routing > Multicast Routing > IGMP
  • Check the box labeled Enable Multicast Routing.
    • This enables both IGMP and PIM on all interfaces.

 

 

Step 2: Add or Modify IGMP Parameters per Interface

Secure Firewall allows you to configure IGMP parameters on a per-interface basis, including the forward interface, query intervals, and response timers. This granular control enables optimized multicast traffic handling and effective group membership management.

To configure IGMP settings:

  • Under the Protocol tab, click Add.

 

  • In the Add IGMP parameters window:
    • Select the interface (e.g., Outside).
    • Enable or disable IGMP.
    • Optionally configure:
      • Forward Interface – This option allows you to specify which interface the Secure Firewall will use to forward IGMP messages. This enables the firewall to act as an IGMP proxy, relaying multicast membership requests from internal hosts to an upstream multicast router.
      • Version (typically IGMPv2 or IGMPv3) – Typically IGMP version 1 or 2. By default, Threat Defense devices run on IGMP version 2.
      • Query Interval – Defines how often the designated router sends IGMP host-query messages, with a default of 125 seconds and a range of 1 to 3600 seconds. If the Secure Firewall doesn’t detect a query within the timeout period, it assumes the role of designated router and begins sending queries itself.
      • Response Time – This setting defines how long the Secure Firewall waits (default: 10 seconds, range: 1–25) for a reply to an IGMP host query. If no response is received within this interval, the device removes the multicast group from its table.
      • Group Limit – This setting controls the maximum number of multicast group memberships allowed per interface, with a default of 500 and a configurable range from 1 to 500. If IGMP membership reports exceed this limit, they are ignored, and traffic for those excess groups is not forwarded, helping to manage resource usage and prevent overload.
      • Query Timeout – This defines how long the Secure Firewall waits (default: 255 seconds, range: 60–300) before taking over as the IGMP querier on an interface if no other querier is detected. This ensures continuity in multicast group management when the previous querier becomes inactive.Tip: Disabling IGMP is simply a matter of unchecking the “Enable IGMP” box for a specific interface.

 

 

Step 3: Set IGMP Access Control (Optional)

Access control lists (ACLs) can be used on Cisco Secure Firewall to manage which multicast groups hosts are allowed to join, providing an added layer of control and security over multicast traffic.

To control which multicast groups can be requested:

  • Go to the Access Group tab.
  • Click Add

 

  • Choose the interface.
  • Apply a Standard or Extended Access List to filter multicast group requests.
  • Click Ok to close the dialog window.

This allows fine-grained control over multicast group membership.

 

 

Step 4: Static Group Configuration

In cases where no hosts can report IGMP membership or there are no members on a segment, you can configure a statically joined IGMP group on Secure Firewall. This forces multicast traffic to be forwarded to the specified segment without requiring membership reports, enabling faster switching. The interface forwards the traffic but isn’t treated as a multicast group member itself. If you want the Secure Firewall to forward multicast traffic without waiting for a join request, use the Static Group tab:

  • Click Add under Static Group.

 

  • In the Add IGMP Static Group Parameters dialog box, define the interface you want to statically assign the multicast group to and the multicast group address.
  • This configures the firewall to always forward traffic for that multicast group.

 

 

Step 5: Join a Multicast Group from Secure Firewall

You can configure a Secure Firewall interface to join a multicast group, prompting upstream routers to maintain routing table entries and keep multicast paths active. This is useful for scenarios where the firewall needs to receive multicast traffic directly or act as a participant in the group. To have the firewall itself join a multicast group (e.g., for monitoring or routing):

  • Go to the Join Group tab.
  • Click Add.
  • In the Add IGMP Join Group parameters dialog window, select the interface you want to be a member of the multicast group and specify the multicast join group.

This is particularly useful in scenarios where the firewall needs to participate in multicast streams directly.

Additional Recommendations:

  • If multicast traffic originates from the inside zone, consider creating a prefilter rule to fastpath the traffic and bypass inspection.
  • Always validate PIM configurations and interfaces if routing across multiple subnets.
  • By enabling and tuning IGMP on Cisco Secure Firewall, network administrators can ensure efficient multicast distribution while maintaining control and visibility through FMC.

 

 

Configuring PIM Multicast Routing

PIM (Protocol Independent Multicast) is essential for forwarding multicast traffic across multiple subnets and routers. Cisco Secure Firewall provides full PIM configuration via the FMC GUI, allowing you to control neighbor relationships, static RPs, route trees, and even bootstrap routing. We will walk through the step-by-step configuration of PIM on Cisco Secure Firewall.

Step 1: Enable PIM on Interfaces

Secure Firewall lets you enable or disable PIM on specific interfaces and configure the Designated Router (DR) priority to control which device handles multicast signaling. The DR is responsible for sending PIM register, join, and prune messages to the Rendezvous Point (RP). If multiple routers exist on a segment, the one with the highest DR priority, or the highest IP address if priorities are equal, is elected. By default, the firewall uses a DR priority of 1, sends router queries every 30 seconds, and issues join/prune messages every 60 seconds.

  • Navigate to Devices > Device Management > Device > Routing > Multicast Routing > PIM
  • In the Protocol tab, click Add.

 

  • In the Add PIM Parameters window:
    • Choose the interface (e.g., Outside).
    • Enable PIM.
    • Optionally configure:
      • DR Priority – This setting determines a Secure Firewall interface’s eligibility to become the designated router (DR) for multicast traffic on a subnet. The router with the highest priority (default: 1, range: 0–4294967294) is elected; setting the value to 0 prevents the firewall from being selected as the DR.
      • Hello Interval (seconds) – This specifies the frequency at which a Secure Firewall interface sends PIM hello messages to maintain neighbor relationships. The default is 30 seconds, with a configurable range from 1 to 3600 seconds.
      • Join/Prune Interval (seconds) – This sets how frequently the Secure Firewall sends PIM join and prune messages to manage multicast group memberships. By default, these messages are sent every 60 seconds, with a configurable range of 10 to 600 seconds.

 

 

Step 2: Restrict PIM Neighbors with Access Control

Secure Firewall allows you to filter which routers can become PIM neighbors, helping you enforce control over multicast routing relationships. This prevents unauthorized devices or stub routers from forming PIM adjacencies, enhancing network security and stability.

To limit PIM neighbor relationships:

  • Go to the Neighbor Filter tab.
  • Click Add

 

  • Select the interface and apply a standard access list to define permitted peers.

 

 

Step 3: Enable Bidirectional Neighbor Filtering (Optional)

A PIM bidirectional neighbor filter on Secure Firewall uses an ACL to control which routers can participate in the Designated Forwarder (DF) election process for bidirectional PIM. Without a filter, all neighbors are eligible by default. When a filter is applied, only ACL-permitted neighbors are considered bidirectionally capable. This ensures that only authorized and compatible routers engage in DF elections, helping maintain multicast efficiency and security. Notably, DF elections won’t occur if permitted routers lack bidirectional support or if bidirectional-capable routers are denied by the ACL. To enforce ACLs on bidirectional PIM neighbor relationships:

  • Navigate to the Bidirectional Neighbor Filter tab.
  • Click Add
  • Select the interface and apply the corresponding ACL.

 

 

Step 4: Configure Static Rendezvous Points (RP)

Secure Firewall can be configured to act as a Rendezvous Point (RP) for multiple multicast groups, with group-to-RP mappings defined using ACLs. If no ACL is specified, the RP applies to the entire multicast group range (224.0.0.0/4). However, each RP address must be unique, and the “All Groups” option can only be assigned to a single RP to avoid conflicts. To define a static RP:

  • Go to the Rendezvous Points tab.
  • Click Add

 

  • You can configure the following in the Add Rendezvous Point dialog box:
    • Rendezvous Point IP address – Select an existing IP address from the drop-down list or click the Add icon to create a new network object. This IP will serve as the RP for your multicast group mappings.
    • Use bi-directional forwarding – Enable this option if your multicast groups require bidirectional PIM mode. In this mode, the Secure Firewall sends a prune message back to the source if it receives multicast traffic without any directly connected group members or PIM neighbors, thereby reducing unnecessary traffic.
    • Use this RP for all Multicast Groups – This configures the specified Rendezvous Point (RP) as the default for all multicast groups on the interface, simplifying multicast routing when a single RP is sufficient for your deployment.
    • Use this RP for all Multicast Groups as specified below (pick a standard access list from a dropdown) – To assign a specific RP to selected multicast groups, select this option and choose a standard ACL from the dropdown list or create a new one. The ACL defines which multicast group ranges will use the selected RP.

 

 

Step 5: Customize the Multicast Routing Tree

By default, Secure Firewall PIM leaf routers switch to the shortest-path tree (SPT) as soon as traffic is received from a new source, minimizing delay but using more memory. You can configure the device to use either the SPT or shared tree globally or for specific multicast groups. The Multicast Groups table enables you to define shared-tree exceptions using ACL-style rules, processing entries top-down, allowing you to permit or deny specific multicast ranges with precision.

To select how the tree is constructed:

  • Go to the Route Tree tab.
  • Choose between:
    • Shortest Path – This option configures the Secure Firewall to use the shortest-path tree (SPT) for all multicast groups, optimizing for lower latency at the cost of increased memory usage.
    • Shared Tree – This option sets the Secure Firewall to use the shared multicast distribution tree (via the RP) for all multicast groups. This approach conserves memory and simplifies routing, though it may introduce slightly more latency compared to the shortest-path tree.
    • Shared Tree for below mentioned group (choose standard access list from the dropdown) – To use the shared tree for specific multicast groups, select this option and then choose a standard ACL from the drop-down list or create a new one. The ACL defines which multicast groups will use the shared tree instead of the default shortest-path tree.

 

 

Step 6: Filter Multicast Group Registration (If Acting as RP)

When Cisco Secure Firewall is configured as a Rendezvous Point (RP), you can restrict which multicast sources are allowed to register by specifying accepted source addresses. This helps prevent unauthorized or unwanted sources from sending PIM register messages to the RP.

If your Secure Firewall is acting as a Rendezvous Point (RP):

  • Use the Request Filter tab.
  • Click Add to apply access control via route maps or ACLs for multicast group registration requests.

 

 

Step 7: Configure Bootstrap Router (Optional)

You can configure Cisco Secure Firewall as a candidate Bootstrap Router (BSR), enabling it to advertise RP information dynamically within the multicast domain. This supports automated RP discovery and simplifies multicast configuration in larger networks.

  • Navigate to the Bootstrap Router tab.
  • Check the option to Configure this device as a Candidate Bootstrap Router (C-BSR).
  • Define:
    • Interface – Select the interface from the Interface dropdown list. This interface will provide the BSR address. Note that the selected interface must have PIM enabled for the BSR role to function properly.
    • Hashmask Length – Defines how many bits of the multicast group address are used in the hash function to map groups to RPs. For example, a value of 24 means only the first 24 bits are considered, allowing multiple groups to share the same RP. The valid range is 0 to 32 bits.
    • Priority – Sets the preference level for a candidate BSR on Cisco Secure Firewall. Higher values are favored during BSR election (range: 0–255; default: 0). If priorities match, the router with the higher IP address becomes the BSR.

 

  • Optionally add entries for Border BSR interfaces by clicking the Add button and providing an interface from the dropdown and checking the box to enable border BSR.

By fully configuring PIM on Cisco Secure Firewall through FMC, you can ensure optimized multicast routing, control peer relationships, and provide scalable RP advertisement options.

 

 

Configuring Static Multicast Routes

Static multicast routes on Cisco Secure Firewall allow you to direct multicast traffic over a different path than unicast traffic, ideal for scenarios where parts of the network don’t support multicast. For example, you can use a GRE tunnel between two multicast-capable devices to forward multicast packets. Unlike unicast routes, static multicast routes are not advertised or redistributed. Static multicast routes are also useful in scenarios where multicast Reverse Path Forwarding (RPF) needs to be manually defined due to asymmetrical paths or complex routing topologies.

To configure static multicast routes:

  • Navigate to Devices > Device Management > Device > Routing > Multicast Routing > Multicast Routes
  • Click Add.

 

  • In the Add Multicast Route Configuration window, specify:
    • Source Network – Select a source network object from the dropdown or click the Add button to create a new network object representing the multicast source.
    • RPF Address (or Interface) – Choosing the Address radio button will allow you to configure a source IP address from which the multicast traffic is expected to arrive.
    • Source Interface – Choosing the Interface radio button will allow you to configure the appropriate source interface which is the multicast traffic from the specified source is expected to arrive.
    • Output Interface – Select the destination interface through which the multicast traffic should be forwarded. This defines the egress path for the static multicast route.
    • Distance – Sets the administrative distance for the static multicast route, with a valid range of 0 to 255. This value influences route preference if multiple paths exist.
  • This static route helps define how Secure Firewall determines the incoming and outgoing interfaces for multicast traffic.

 

 

Configuring Multicast Filters

To prevent multicast traffic from entering or leaving a defined network boundary, use the Multicast Boundary Filter feature:

  • Navigate to Devices > Device Management > Device > Routing > Multicast Routing > Multicast Boundary Filter
  • Click Add.

 

  • Configure:
    • Interface –  The interface where the boundary is enforced.
    • Standard Access List – Define which multicast groups are restricted.
    • Optionally, check “Remove any Auto-RP group announcement…” to filter Auto-RP traffic based on the boundary rules.

 

This enables strict control of multicast propagation across network domains, thereby improving security and reducing unnecessary multicast flooding.

With these multicast configuration steps complete, including IGMP, PIM, RPs, multicast routing trees, and boundaries, you now have full control over multicast traffic on Cisco Secure Firewall. Whether you’re optimizing for video streaming, group data delivery, or enterprise multicast segmentation, these features ensure robust and flexible deployment.

 

 

Configuring QoS

Quality of Service (QoS) on Cisco Secure Firewall enables administrators to manage bandwidth, prioritize traffic, and apply rate limiting to ensure performance consistency for critical applications. While QoS capabilities in version 6.1 are limited to rate limiting, understanding the deployment process and traffic flow is essential for effective implementation.

QoS Policy Creation in FMC

Creating QoS policies on FMC involves defining what traffic is subject to QoS treatment and on which interfaces. The core concepts include:

  • Rate Limiting Only in 6.1: As of version 6.1, rate limiting is the only feature supported. Shaping and other advanced features are not available.
  • Interface Selection via Security Zones or Interface Groups: Policies are applied based on source or destination zones or groups rather than individual interfaces.
  • Support for Routed Interfaces Only: QoS policies apply exclusively to routed interfaces.

 

 

QoS Policy Deployment on Secure Firewall Devices

Once the QoS policy is defined in FMC, it is deployed to the device with the following characteristics:

  • One QoS Policy per Device: Only a single QoS policy can be applied per Secure Firewall appliance.
  • Modular Policy Framework (MPF): When deployed, the policy is converted to Modular Policy Framework (MPF) commands using the LINA CLI.
  • Snort Integration: A qos.rules file is generated for the Snort engine to enforce relevant parts of the policy.
  • Rule ID Correlation: Rule identifiers are used to correlate QoS actions between the LINA engine and Snort inspection.

 

 

Traffic Flow with QoS Applied

When packets traverse the Secure Firewall, they are evaluated for QoS in the following order within the LINA engine:

  • Prefilter Rules: Traffic that is blocked or fastpathed at this stage bypasses QoS entirely.
  • L3/L4 ACL Evaluation: QoS is only applied to traffic that matches an Access Control List (ACL) and is permitted or trusted.
  • Snort QoS Policy: Once traffic passes LINA ACL checks, Snort processes any additional QoS rules defined for deep inspection.

 

 

QoS Eventing and Statistics

Monitoring QoS performance and behavior is crucial for optimization. Cisco Secure Firewall provides:

  • Connection Events Logging: QoS-related events are logged in the FMC’s Connection Events table.
  • Periodic Statistics Collection: Every 5 minutes, QoS statistics are compiled and made available via FMC dashboard widgets.
  • Dashboard Visualization: Six dedicated widgets were introduced to provide visibility into QoS performance metrics.

 

Core Components of QoS

Cisco Secure Firewall’s QoS architecture leverages both Snort and the LINA engine to implement and enforce traffic policies. Each engine plays a distinct role in classification and enforcement:

  • Snort Engine: Maintains a QoS policy inside the qos.rules file. Each entry is assigned a unique QoS Rule ID, which is referenced during traffic inspection.
  • LINA Engine (ASA): Applies QoS policy at the interface level using the Modular Policy Framework (MPF). Policies are created as policy-map entries, each linked to a corresponding QoS Rule ID.

 

QoS Traffic Flow and Operation

When a packet arrives at the Secure Firewall, the QoS decision-making process involves both classification and enforcement:

  1. Flow Creation: The LINA engine creates a flow and forwards the packet to the Snort engine for deep inspection.
  2. Policy Matching: Snort checks the qos.rules file and identifies if the flow matches any QoS Rule ID.
  3. Verdict Delivery: Snort returns a verdict to LINA, indicating a specific qos_rule_id (e.g., qos_rule_id x) for that flow.
  4. Enforcement: LINA compares the returned Rule ID with its own interface-based policy-map. If there’s a match, it enforces the configured rate limit.

This dual-engine approach ensures that:

  • Classification is handled by Snort
  • Rate limiting is enforced by LINA

 

Note:

  • Cisco Secure Firewall only supports rate limiting for QoS in current versions.
  • Snort handles traffic classification, while LINA applies interface-based enforcement.
  • The interaction between Snort and LINA ensures high fidelity in QoS policy application without compromising inspection depth or enforcement accuracy.

 

 

Configuring QoS Policies

Implementing QoS on Cisco Secure Firewall begins in the FMC GUI interface. Here’s how you can get started:

Step 1: Navigating to QoS Settings

To begin creating a QoS policy:

  • Navigate to Devices > QoS in the FMC.
  • Click the Add Policy button to define a new QoS policy.

 

  • Name the policy and add the target devices that you wish this policy to apply to. Click Save once done.

 

 

Step 2: Adding QoS Rules

Once your policy is created:

  • Click Add Rule to define traffic classification and rate-limiting actions.

 

In the rule editor, you can configure the following:

  • Name – Give the rule a name
  • Apply QoS On – Choose to apply the policy on the source or destination interface objects.
  • Traffic Limits –  Set Upload and Download bandwidth limits (range: 0.000–100000 Mbps).
  • Interface Object – Select interface groups such as Inside or Outside.
  • Traffic Criteria –  You can match based on:
    • Source/destination networks or IP addresses
    • Applications or ports
    • URLs
    • Users
    • Security Group Tags (SGTs)
    • ISE attributes

 

 

Step 3: Monitoring and Verifying QoS

FMC Dashboard Monitoring

You can monitor active QoS statistics and policy behavior in two places:

  • Analysis > Connection > Events – See logs of traffic matching QoS rules.
  • Overview > Dashboards > QoS – Visual widgets display bandwidth enforcement and rule hits.

 

CLI Verification on Secure Firewall

For deeper inspection and troubleshooting, use the following CLI commands on the Secure Firewall appliance:

  • show run policy-map
  • show run service-policy
  • cat qos.rules # (Expert mode)
  • System support firewall-engine-debug
  • debug snort event
  • show conn flow-rule qos qos-rule-ID
  • show service-policy policy

These tools allow you to verify rule deployment, monitor enforcement, and debug classification.

 

 

Understanding uRPF (Unicast Reverse Path Forwarding)

Unicast Reverse Path Forwarding (uRPF), also known as anti-spoofing, is a critical security mechanism in Secure Firewall that protects your network from spoofed source IP addresses. It does so by verifying the reachability of the source address of incoming packets, ensuring they follow a valid return path through the network.

 

How uRPF Works

When uRPF is enabled, Secure Firewall performs two route lookups for every incoming packet:

  • First Lookup: For the destination IP address in the packet header, to determine where the packet is going.
  • Second Lookup: For the source IP address in the packet header, to verify whether the routing table has a valid return path for that source IP, specifically, whether the source IP would be reachable via the same interface the packet came in on.

If the second lookup fails (i.e., the source IP does not have a valid reverse path), the packet is dropped to prevent IP spoofing.

Note: uRPF is based on the routing table, so ensure routes are properly advertised and learned on all interfaces.

 

Enabling uRPF in Secure Firewall via FMC

To enable anti-spoofing on an interface in Cisco Secure Firewall through the Firepower Management Center (FMC):

  • Navigate to Devices > Device Management > Device > Interfaces.
  • Edit the interface where you want to enable uRPF.
  • Go to the Advanced > Security Configuration tab.
  • Check the box for Enable Anti Spoofing.
  • Save and Deploy the configuration.

 

Verifying uRPF via CLI

To confirm that uRPF is enabled and operating correctly, connect to the firewall CLI and use the following commands:

  • show run ip verify reverse-path
  • show ip verify statistics
  • show log

 

Important: Packet drops due to uRPF failures do not generate Connection Events in FMC. This means you’ll need to rely on CLI diagnostics or external syslog monitoring to detect uRPF-related drops.

 

 

IP Fragmentation Handling

Cisco Secure Firewall provides flexible options for managing fragmented IP packets. Proper configuration of IP defragmentation is crucial for maintaining network visibility and ensuring accurate traffic inspection, especially when dealing with protocols that can span multiple fragmented packets.

Fragment Handling Modes

Secure Firewall supports two primary modes for handling IP fragments:

  • Virtual Reassembly (default):
    A secure firewall reassembles the IP fragments internally for inspection but does not forward the reassembled packet to the destination. Only the original fragments are sent.
  • Full Reassembly:
    Secure Firewall reassembles the IP fragments internally and sends the fully reassembled packet to the destination.

 

 

Configuration Requirements

For interfaces operating in routed or transparent mode, fragment handling must be configured in two key locations:

  1. IP Defragmentation – Located within the Network Analysis Policy (NAP) settings.
  2. Fragment Settings – Found under Devices > Platform Settings in the Secure Firewall Management Center (FMC).

 

Special Note for Inline Pair Mode

In Inline Pair deployments, all fragment-handling configurations are performed solely under the IP Defragmentation preprocessor.

 

 

Configuring IP Defragmentation via Network Analysis Policy (NAP)

To fine-tune defragmentation behavior:

  • Navigate to Access Control > Intrusion > Network Analysis Policy

 

  • Create or edit a NAP policy.

 

  • Name the NAP policy and choose a base policy for it. Click Save once done.

 

  • You can choose to edit the policy for either Snort 2 or Snort 3 versions. Let’s take a look at Snort 2 first.

 

  • Under the IP Defragmentation section, you can configure the following parameters:
    • Preallocated Fragments: Sets memory allocation for handling expected fragment loads.
    • Servers: Can enter a single IP address, address block, of comma-separated list of servers.
    • Networks: Specifies source/destination IP ranges subject to fragment reassembly.
    • Policy: This is the OS profile.
    • Min TTL: Ensures fragment TTL is sufficient for valid reassembly.
    • Timeout: Defines how long fragments are stored waiting for completion.

 

  • In Snort 3, IP defragmentation is handled a little differently. Snort 3 uses inspectors, like the stream_ip inspector, to handle traffic normalization and analysis, including IP defragmentation. Click on the Snort 3 version to open the Snort 3 NAP.
  • Expand the stream_ip preprocessor.

 

  • Here you may configure similar settings as the classic IP Defragmentation policy from Snort 2 NAP.

 

 

Additional Fragment Settings in Platform Settings

Some fragmentation-related parameters must also be configured under Devices > Platform Settings > Fragment Settings

These settings control system-wide behavior beyond what is configured in the NAP.

 

Verifying Fragmentation Settings via CLI
To audit current fragmentation configurations, use the following Secure Firewall CLI commands:

View all applied fragment settings:

show run all fragment

 

View current fragment statistics and their associated settings:

show fragment

By default, Secure Firewall uses Virtual Reassembly, meaning fragments are reassembled for inspection but not forwarded in reassembled form. This behavior can be changed to Full Reassembly if your application or inspection requirements demand it.

 

 

Enabling Full Fragment Reassembly

By default, Cisco Secure Firewall uses Virtual Reassembly, which inspects IP fragments internally without forwarding the reassembled packet. In some scenarios, however, full reassembly may be required, particularly for applications or devices that depend on receiving the complete packet.

To enable Full Fragment Reassembly:

  • Navigate to Devices > Device Management
  • Edit the desired device.
  • Go to the Interfaces tab and select the interface you wish to modify.
  • Under the Advanced > Security Configuration tab, check the box labeled Allow Full Fragment Reassembly.
  • Save and deploy the changes.

Once enabled, Secure Firewall will forward the reassembled packets from the ingress interface to the destination.

 

 

Blocking Fragmented Packets Based on TTL

To block potentially malicious fragments using Time-To-Live (TTL) values:

  • Navigate to Policies > Access Control Policy, and create or edit a Network Analysis Policy.
  • Under the IP Defragmentation section, modify the Min TTL value.
  • Save and commit the changes.

You can further enhance detection by integrating Snort rules:

  • Go to Access Control > Intrusion and edit your intrusion policy.
    • In Snort 2, navigate to Policy Layers> My Changes> Rules

 

    • In Snort 3, navigate to Rule Overrides> All Rules

 

  • Filter by GID and enable Snort rule 123:11.

 

  • Commit changes and navigate back to Access Control > Access Control.
  • In the Advanced tab, assign the modified NAP policy.
  • Save and deploy.

 

 

Configuring Minimum Fragment Size in the Network Analysis Policy

To mitigate evasion techniques using small IP fragments:

  • Within your NAP policy, navigate to IP Defragmentation or stream_ip.
  • Locate the Minimum Fragment Size setting and increase the value (e.g., 250).
  • Enable the following Snort preprocessor signatures to strengthen your fragment inspection:
    • 123:7
    • 123:6
    • 123:4
    • 123:5
    • 123:13
  • Save and deploy the configuration.

 

Inline Pair Mode Considerations

If you’re using Inline Pair mode, you can still block fragments by applying the same IP Defragmentation settings within the NAP. Adjust the TTL and Minimum Fragment Size values, and enable the same Snort signatures to ensure consistent protection.

Properly configuring IP fragment handling in Cisco Secure Firewall is essential for defending against evasion tactics and ensuring inspection integrity. Use Virtual Reassembly when performance is a concern and Full Reassembly when applications demand complete packet delivery. Always review and tune NAP policies, and reinforce them with appropriate Snort rules for comprehensive protection.