The Modular Policy Framework (MPF) is a core feature of Cisco ASA firewalls, allowing administrators to define flexible, granular security policies beyond traditional access control lists (ACLs). MPF provides a comprehensive mechanism for managing traffic inspection, connection restrictions, traffic prioritization, and policing.
One of the most critical functions of MPF is connection inspection. ASA treats TCP and UDP connections as stateful by default, which allows it to track session states and enforce security accordingly. Additionally, MPF enables stateful inspection of ICMP, which is not inherently connection-oriented. This allows administrators to inspect and enforce policies on ICMP traffic with similar depth and precision as TCP/UDP.
MPF also facilitates connection restriction, allowing administrators to define maximum allowed connections per protocol, set per-client maximums, and control embryonic (half-open) connections both globally and per client. This is particularly useful for mitigating resource exhaustion attacks, such as SYN floods.
Through traffic prioritization, MPF enables the ASA to prioritize latency-sensitive traffic, which is especially valuable in environments running voice, video, or other real-time applications. Moreover, MPF supports traffic policing, allowing for rate-limiting of incoming and outgoing traffic per interface to maintain performance and prevent abuse.
The core components of MPF include:
- Access Control Lists (ACLs): Used to categorize traffic based on parameters like source/destination IP, protocol, and port number. Extended ACLs provide the needed granularity.
- Class Maps: These define traffic classes and can operate at Layer 3/4 or Layer 7. Regex-based class maps are also supported for advanced matching.
- Policy Maps: These apply actions to class maps and can operate at both Layer 3/4 and Layer 7.
- Service Policies: These apply the configured policy maps to interfaces or globally on the ASA.
Cisco ASA inspects a wide variety of default application-layer protocols out of the box. These include:
- Voice and video protocols: SIP, H.323 (RAS and 225), SCCP
- Common network services: FTP, DNS, TFTP, NETBIOS, SUN RPC, XDMCP, RSH, RSTP, SQL.Net
- Email protocols: ESMTP
- Other infrastructure protocols: SQL.Net
While TCP and UDP inspection is foundational, ASA gives additional scrutiny to these predefined protocols, ensuring deep packet inspection and appropriate handling of session state and application behavior. This capability makes the MPF system functionally similar to QoS configurations found in routers, especially in its class-map and policy-map structure.
Configuring traffic inspection using MPF requires three essential steps. First, you must identify the traffic you want to inspect using a class-map. The class-map defines the matching criteria for traffic, which can be based on ACLs, Layer 3/4 parameters, or more advanced application-layer identifiers.
Once the traffic is identified, the next step is to create a policy-map that specifies the action to be taken on that traffic. Common actions include set connection, inspect, shape, qos, and others. This is where you determine how the traffic will be handled after being matched by the class-map.
The third and final step is applying this policy using a service-policy, either on a specific interface or globally. This binds the policy-map to actual traffic flow, ensuring enforcement.
By default, ASA devices come with a global policy called global_policy. This policy uses a class named inspection-default, which matches default-inspection-traffic. This match includes a predefined list of Layer 7 ports and protocols that Cisco considers critical for inspection. The default action associated with this class is inspect, which performs stateful inspection on the matching protocols.
This global policy is applied using the command service-policy global_policy global, which enforces it across all interfaces on the ASA.
To view the specific contents of the default-inspection-traffic class, the best approach is to enter the ASA’s CLI in global configuration mode and run:
class-map inspection_default match ?
There is no direct show command to list the default inspection contents, so administrators must inspect the container by manually navigating the class-map configuration.
By default, ASA inspects traffic for RFC compliance, ensuring that protocols behave as expected. It also handles certain dynamic port protocols like FTP. However, it’s worth noting that although HTTP is included in the default-inspection-traffic list, ASA does not inspect HTTP by default. While the traffic may match the class, no inspection or action is applied unless explicitly configured.
Expanding on the functionality of the inspect action within Cisco ASA’s Modular Policy Framework, it’s important to understand that inspection goes beyond simply checking whether traffic adheres to protocol standards. For example, when FTP traffic is inspected, the ASA firewall not only checks for compliance but also dynamically manages port openings to accommodate the traffic flow.
With Active FTP, the client opens a connection to the server’s command port (typically TCP 21), but then the server initiates a separate connection back to the client on a different port for data transfer. This behavior can pose challenges when the client’s firewall blocks inbound traffic from the server. In contrast, Passive FTP—the more commonly used variation—keeps control with the client. The client connects to port 21 on the server for control and then receives a port number from the server’s FTP port comment for the data channel. The actual data transfer occurs over a higher-numbered port that the client connects to.
ASA is intelligent enough to inspect and interpret the FTP control channel, detect the port number mentioned in the command, and dynamically open that port on the firewall. This dynamic inspection ensures that the data channel is not blocked, allowing seamless FTP operations even through strict firewall rules.
When defining class-maps in MPF, Cisco ASA offers a variety of match criteria that allow administrators to tailor traffic policies with precision. Some of the key match options include:
- access-list: Matches traffic based on a defined access control list.
- any: Matches any packet.
- dscp: Matches based on IP DSCP (Differentiated Services Code Point) values.
- flow: Matches traffic according to a predefined flow policy.
- port: Matches based on TCP or UDP port numbers.
- precedence: Matches based on IP precedence values.
- rtp: Matches RTP traffic using specific port numbers.
- tunnel-group: Matches traffic associated with a defined tunnel group.
These match options provide the flexibility needed to implement granular control over both traffic inspection and policy enforcement.
Configuring MPF for Non-standard Ports
To extend Cisco ASA’s Modular Policy Framework (MPF) to handle protocols operating on non-standard ports, administrators can manually configure inspection policies tailored to those ports. A common use case is when FTP is run on a non-default port such as TCP 2121. To handle this, you start by configuring an access control list (ACL) that permits traffic to the non-standard port. For example:
access-list permit tcp any host 10.2.2.2 eq 2121
Next, define a class-map to match this port:
class-map FTP_2121 match port tcp eq 2121
Then create a policy-map that specifies what to do with this traffic:
policy-map POLICY_FTP class FTP_2121 inspect ftp
Finally, apply this policy to the appropriate interface:
service-policy POLICY_FTP interface outside
MPF also allows advanced filtering for Layer 7 protocols like HTTP. For example, to filter web traffic to a specific domain (e.g., *.cisco.com), begin by creating a regular expression:
regex CISCO .*cisco.com
Use this regex in a Layer 7 HTTP class map:
class-map type inspect http CM_L7_HTTP match request header host CISCO
Then create a corresponding Layer 7 policy map:
policy-map type inspect http PM_L7_HTTP
class CM_L7_HTTP
{Drop | reset | log}
You also need a Layer 4 class map for port 80 traffic:
class-map HTTP_80 match port tcp eq 80
Tie it all together with a Layer 4 policy map:
policy-map MPF class HTTP_80 inspect http PM_L7_HTTP
And apply it to the appropriate interface:
service-policy MPF interface inside
To inspect other non-standard services like FTP on port 2100, the approach is similar. Define a class-map for that port:
class-map NS-FTP match port tcp eq 2100
Then reference it in the global policy map:
policy-map global_policy class NS-FTP inspect ftp
This ensures that even FTP sessions on unexpected ports are properly inspected and dynamically supported by the ASA. These configurations demonstrate how MPF enables flexible, protocol-aware inspection across both traditional and customized network scenarios.
Understanding FTP Modes with Cisco ASA MPF
It’s important to understand how File Transfer Protocol (FTP) behaves, especially since it operates in two distinct modes: Active and Passive. Each mode handles control and data channels differently, which can impact how firewalls inspect and permit the traffic.
In Active FTP mode, the client initiates the control connection from a high-numbered port (typically something like TCP 1024) to the server’s control port TCP 21. The server then responds and attempts to open the data connection from its own data port TCP 20 back to the client’s high-numbered dynamic port. This reverse initiation of the data connection can trigger rejections from firewalls like Cisco ASA unless FTP inspection is explicitly enabled. Without proper inspection, ASA might drop the returning connection from port 20, not recognizing it as part of the established session.
In contrast, Passive FTP mode shifts more control to the client side. While the client still connects to the server on TCP port 21 for the control session, the data session is initiated by the client as well, but to a random high-numbered port specified by the server. The server communicates the intended data port in its response (typically over the FTP control channel), and the client connects to that port from another dynamic source port. This can cause complications, as multiple random ports are now involved and may not be pre-permitted through the firewall.
Here’s the critical part: Cisco ASA can intelligently monitor the FTP control channel, identify the negotiated port numbers, and dynamically allow the related connections. This is why enabling inspect ftp in the ASA’s policy map is vital. Without this inspection, Passive mode—despite being the default for many FTP clients—can fail if ASA doesn’t understand and permit the random data port used.
Ultimately, whether you’re working with Active or Passive FTP, ASA’s deep inspection capabilities are key to ensuring seamless communication. Passive mode is more firewall-friendly since the client initiates both connections, but proper MPF configuration is still required to avoid unexpected drops or broken sessions.
SMTP Inspection
Simple Mail Transfer Protocol (SMTP), which typically operates over TCP port 25, is used to send email from clients to servers or between mail servers. ASA inspects SMTP traffic by examining both the SMTP header length and the SMTP body length, helping to detect malformed or malicious email content. Since SMTP often involves a connection from a higher client port to the well-known port 25, ASA’s stateful inspection ensures compliance with expected behaviors and can enforce policy-based filtering accordingly.
DNS Inspection
Domain Name System (DNS) traffic is critical for network functionality and is typically seen over UDP or TCP port 53. ASA’s MPF supports DNS-specific inspection features that enhance security:
- DNS Guard: Allows only the first response to a DNS query, helping to mitigate DNS poisoning.
- DNS Header Length Check: Validates that DNS headers do not exceed the expected 64-byte length.
- DNS Query Length Check: Ensures DNS queries stay within a valid range (512 to 1024 bytes).
- DNS Doctoring Check: Helps detect and prevent manipulation of DNS responses.
ASA also tracks idle timeouts for DNS sessions and ensures stateful processing for both TCP- and UDP-based queries.
TFTP Inspection
Trivial File Transfer Protocol (TFTP) traffic typically runs over UDP port 69. While simple in operation, TFTP is often used in network booting and device provisioning. ASA can monitor and inspect this traffic to ensure it conforms to expected behavior, although it is inherently connectionless and stateless, which poses challenges that MPF helps mitigate.
HTTP Inspection
By default, HTTP traffic is not automatically inspected by MPF. However, ASA can be configured to inspect specific HTTP characteristics, including:
- HTTP Header Length: Ensuring headers conform to expected lengths, protecting against header overflow attacks.
- Regex Filtering: Using regular expressions to restrict or allow HTTP requests based on domain names or URL patterns. This is especially useful for web filtering, blocking access to specific sites or content.
RSH Inspection
Remote Shell (RSH) is a protocol used in Unix and Linux systems to execute shell commands remotely over a network. It operates on TCP port 514. Although considered largely obsolete and insecure compared to SSH, RSH traffic can still be inspected by ASA if it’s used in legacy environments. MPF allows monitoring and restriction of such traffic to ensure compliance and detect misuse.
Each of these inspection capabilities enhances the ASA’s ability to enforce protocol-specific security policies, detect anomalies, and maintain proper traffic flow through the firewall.
XDMCP Inspection
X Display Manager Control Protocol (XDMCP) is used for remote desktop access in thin client environments, primarily within Linux or Unix systems. The session begins with a UDP port 177 connection for management, followed by a TCP port 6000 connection for graphical display. ASA’s MPF can track both connections to ensure continuity and allow only authorized sessions to pass through.
SIP Inspection
Session Initiation Protocol (SIP) is a cornerstone of VoIP communications and typically runs over UDP or TCP port 5060—with UDP being the most common. SIP uses this control port to initiate sessions but will then negotiate additional UDP ports for audio and synchronization streams between endpoints.
Initially, clients communicate through a gateway, and once the session is established, endpoints reuse dynamically assigned ports to communicate directly. To support SIP over ASA, it’s critical to allow 5060 and configure MPF to inspect and dynamically manage the additional media connections based on the negotiated ports.
SCCP Inspection
The Skinny Client Control Protocol (SCCP), also used in VoIP, operates on TCP port 2000. SCCP uses a control channel for call signaling and establishes separate audio sessions similar to SIP. ASA’s inspection mechanism for SCCP mirrors that of SIP—it monitors control traffic and dynamically permits audio port connections negotiated during the call setup.
CTIQBE Inspection
CTIQBE (Computer Telephone Interface Quick Buffer Encoding) is another VoIP protocol using TCP port 2748. Its operational model closely resembles SIP and SCCP in that it establishes a control connection and then negotiates dynamic media sessions. ASA can inspect CTIQBE traffic to ensure secure call setup and media negotiation, providing the same type of control and visibility as with the other VoIP protocols.
MGCP Inspection
Media Gateway Control Protocol (MGCP) is used for VoIP and video communication, particularly between call managers and gateways. It uses UDP port 2427 for control signaling. Like SIP and SCCP, MGCP also relies on dynamic port negotiations for media, making ASA’s stateful inspection and dynamic pinhole creation critical for uninterrupted communication.
MPF IPSec Pass-Through Inspection
ASA supports inspection of IPSec traffic, including ESP (Encapsulating Security Payload) and AH (Authentication Header) protocols. With MPF, you can define per-client maximums for IPSec tunnels, allowing granular control over how many encrypted sessions are permitted from each source. This is especially useful in multi-tenant VPN environments or remote access scenarios with resource constraints.
Configuring MPF for Protocol Inspection on Interfaces
One common situation when working with ASA is discovering that ping (ICMP) does not work by default, even though NAT and routing are properly configured. To allow ICMP through the ASA, you must explicitly configure an MPF policy to inspect it.
Start by ensuring your PAT (Port Address Translation) is configured. For example:
nat (inside,outside) source dynamic any pat-pool interface
This sets up basic NAT. However, ICMP packets like ping won’t pass unless you define a policy to inspect them.
To begin, verify the currently active MPF configurations with:
show running-config policy-map
If needed, clear any default policies to start fresh:
clear configure service-policy clear configure policy-map clear configure class-map
Next, create an access-list to permit ICMP:
access-list icmp-acl permit icmp any any
Use that ACL in a class-map:
class-map icmp-class match access-list icmp-acl
Now define a policy-map that applies inspection:
policy-map global class icmp-class inspect icmp
Finally, apply this policy either globally or on a specific interface using:
service-policy policy-name interface nameif
This structured approach allows ICMP (ping, traceroute, etc.) to pass through the ASA, enabling testing and diagnostics without compromising security posture.
MPF Connection Restriction Per Client
To begin, you’ll need to define relevant network and service objects. These objects represent the host whose connections will be regulated and the specific service you’re targeting:
object network host host x.x.x.x object service service1 service tcp source eq port
Next, configure a NAT statement using these objects:
nat (inside,outside) 1 source static host-object interface service service1 service1
Then create an access control list (ACL) that permits traffic for the defined host and port:
access-list name permit tcp any object host eq port
Apply this ACL to the appropriate interface:
access-group name in interface nameif
For the MPF to apply connection restrictions, you must also create a separate ACL specifically for the policy:
access-list name permit tcp any object host eq service-port
Now move on to building your class-map, which ties into the MPF engine:
class-map name1 match access-list acl-name
Define a policy-map or modify an existing one to include the class:
policy-map pmap-name class name1 set connection conn-max num set connection embryonic-conn-max num set connection per-client-embryonic-max num set connection per-client-max num
This setup enables the ASA to limit the total connections and embryonic (half-open) connections both globally and per client. These values are critical for mitigating SYN flood attacks and controlling client behavior.
Finally, apply the policy-map to an interface:
service-policy pmap-name interface nameif
This approach gives you fine-grained control over how clients can use network services, reducing the risk of overload or abuse—especially for publicly exposed services like HTTP, DNS, or FTP.
MPF Traffic Prioritization (for Delay-Sensitive Traffic)
One of the key capabilities of MPF is prioritizing latency-sensitive traffic—such as voice or video—by enabling a priority queue on the ASA interface:
priority-queue nameif
Once enabled, you’ll need to define a class-map to match the delay-sensitive traffic. This can be done using an access list or, in VPN deployments, by matching a specific tunnel-group:
class-map name match tunnel-group x.x.x.x
You can also match traditional traffic selectors such as access lists if tunnel groups aren’t used.
Next, include that class in a policy-map and apply the priority action to ensure low-latency processing:
policy-map name class class-name priority
Finally, bind the policy to an interface using:
service-policy pmap-name interface nameif
This configuration ensures that high-priority traffic—such as voice streams—takes precedence over other types, helping to reduce jitter and delay.
MPF Traffic Policing
Where prioritization accelerates traffic, traffic policing does the opposite—it limits throughput to prevent certain sources or destinations from consuming excessive bandwidth.
Start by creating an ACL to define the traffic to be policed:
access-list name deny ip any x.x.x.x mask
Use that ACL in a class map:
class-map name match access-list acl-name
Then create or modify a policy-map to include a policing policy for that traffic:
policy-map name
class cmap-name
policy {input | output} bits-per-second {burst-bytes | conform-action} {drop | transmit | exceed-action}
You define whether the policy applies to input or output traffic, and specify the rate limit, burst size, and actions to take when traffic conforms or exceeds limits—such as dropping packets or transmitting them.
Apply the service policy:
service-policy name interface nameif
This technique is essential for managing non-critical or abusive traffic, helping maintain the health of the network for all users.
MPF FTP Inspection Configuration
FTP is inherently complex due to its use of separate control and data channels, and ASA’s inspection capabilities are designed to make FTP traffic work seamlessly through the firewall.
To start, you can define a class-map to match FTP traffic. You have the flexibility to match using several criteria, including predefined traffic categories, ACLs, DSCP values, flows, ports, and even VPN tunnel-groups:
class-map name
match {default-inspection-traffic | any | access-list | dscp | flow | port | precedence | rtp | tunnel-group}
Once the class map is defined, associate it with a policy-map that applies the FTP inspection action:
policy-map name class cmap-name inspect ftp
Finally, apply this policy to the appropriate ASA interface:
service-policy name interface nameif
This allows ASA to dynamically manage FTP’s control and data sessions, including non-standard ports and passive mode operations.
MPF SMTP Inspection Configuration
For SMTP inspection, a structured approach using object definitions makes configuration clean and scalable.
Start by defining the SMTP server as a network object:
object network smtp-server-object host x.x.x.x
Then, create an ACL that permits SMTP traffic (port 25) to that server:
access-list name permit tcp any object smtp-server-object eq 25
Next, define a class-map that matches this ACL:
class-map cmap-name match access-list acl-name
Now, you can build an Extended SMTP (ESMTP) policy map to enforce deep inspection based on mail characteristics such as body size. For example, you can trigger a reset if the body length exceeds 100 bytes:
policy-map type inspect esmtp esmtp-pmap-name
match body length gt 100
{reset | drop-connection}
Tie this ESMTP map to a standard policy map for deployment:
policy-map name class cmap-name inspect esmtp esmtp-pmap-name
Apply the final policy to the interface:
service-policy name interface nameif
This level of granularity allows administrators to enforce compliance, protect against malformed messages, and prevent misuse of the mail infrastructure, without relying solely on external email security gateways.
MPF DNS Inspection Configuration
DNS inspection through MPF allows for a deeper level of control and security over domain resolution traffic. Begin by creating an ACL to permit traffic to your DNS server:
access-list name permit udp any object dns-server-object eq 53
Then define a class-map that matches the ACL:
class-map cmap-name match access-list acl-name
To enable DNS-specific inspections, you’ll create a type inspect DNS policy-map, which supports several critical enforcement mechanisms:
policy-map type inspect dns dns-pmap-name dns-guard ! Enforces a single DNS response per query protocol-enforcement ! Validates DNS message structure id-mismatch ! Detects frequent DNS ID mismatches id-randomization ! Adds randomness to DNS query IDs message-length maximum 1024 ! Ensures DNS message size is within spec nat-rewrite ! Rewrites IP in A-records if needed
Then, embed this DNS-specific inspection policy into a regular MPF policy-map:
policy-map name class cmap-name inspect dns dns-pmap-name
Apply the service policy to the desired interface:
service-policy name interface nameif
This configuration secures DNS queries by guarding against spoofing, oversized responses, and malformed packets—all while maintaining performance.
MPF TFTP Inspection Configuration
Though often overlooked, Trivial File Transfer Protocol (TFTP) is commonly used in network boot environments and device provisioning, making its inspection vital for trusted network operations.
If desired, you can first define an ACL to match the traffic. Then proceed to create a class-map using flexible matching options:
class-map name
match {default-inspection-traffic | any | access-list | dscp | flow | port | precedence | rtp | tunnel-group}
Attach this to a policy-map with the inspect tftp command:
policy-map name class cmap-name inspect tftp
And apply it:
service-policy name interface nameif
Since TFTP is UDP-based and connectionless, this inspection ensures state tracking and allows the firewall to open ephemeral ports dynamically, enabling the transfer process to complete without interruption or vulnerability to misuse.
MPF HTTP Inspection for Site Blocking (IP-Based and L7)
Blocking access to specific HTTP-based websites is one of the practical applications of MPF on Cisco ASA. You can accomplish this by combining access control lists (ACLs), class-maps, regex filters, and Layer 7 policy maps.
To begin, create an ACL that matches HTTP traffic on TCP port 80:
access-list acl-name permit tcp any any eq 80
Then create a class-map to match this traffic:
class-map name regex regex-name [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+
This regex pattern matches numeric IP addresses (instead of domain names) in HTTP headers—a common technique used to bypass DNS-based filters.
Now configure a Layer 7 policy map to block HTTP requests matching this regex:
policy-map type inspect http L7-pmap-name match request header host regex regex-name drop-connection
Attach this policy to a standard MPF policy map:
policy-map name class cmap-name inspect http L7-pmap-name
Finally, apply the policy to the relevant interface:
service-policy name interface nameif
This implementation enables deep packet inspection of HTTP headers and drops connections that attempt to access content using direct IP addresses, which is often associated with circumvention or malicious behavior.
Useful MPF Show Commands
Once MPF configurations are applied, you’ll need to monitor and troubleshoot their operation. Cisco ASA provides several useful CLI commands for this:
- show run class-map – Displays all class-map definitions currently in the running configuration.
- show policy-map – Lists configured policy maps and associated actions.
- show run nat – Shows NAT configuration blocks.
- show nat – Displays active NAT translations and hit counts.
- show xlate – Displays actual connection translations, which is useful for tracking active sessions rather than just configuration.
These commands are essential for confirming your MPF setup, tracking hits, and ensuring policies are being enforced correctly on live traffic.
Advanced MPF Techniques: Custom Port Matching and Connection Control
To close out our series on Cisco ASA’s Modular Policy Framework (MPF), let’s look at some advanced techniques, particularly custom traffic matching and connection management, which are vital for fine-tuning traffic inspection and defense against TCP-based attacks.
Creating a Class Map for Custom Ports
MPF allows for granular control by enabling administrators to match traffic not just on standard ports like HTTP (port 80), but also on non-standard ports such as TCP 8080, which is commonly used for alternative web services or proxy servers.
To create a new class map for inspecting TCP port 8080 traffic:
class-map HTTP8080 match port tcp eq 8080
You’re not limited to ports. MPF also supports matching based on DSCP values, flow identifiers, port precedence, RTP streams, and VPN tunnel-groups, among others, making it adaptable to nearly any traffic scenario.
Once the class map is defined, you can integrate it into a policy using the global policy map:
policy-map global_policy class HTTP8080
From here, you can attach any desired inspection or action—such as connection limiting, prioritization, or traffic policing, based on your organizational needs.
Controlling Embryonic and Total Connections
Beyond matching traffic, ASA can limit the number of connections, both globally and on a per-client basis. This includes embryonic connections, which are half-open TCP sessions (identified by the SYN/ACK state) often seen in SYN flood attacks.
By configuring limits on total concurrent sessions and embryonic sessions, administrators can protect against resource exhaustion and service disruption. These limits can be applied directly within a policy map using:
set connection conn-max number set connection embryonic-conn-max number
These advanced MPF capabilities equip your ASA to not only identify and inspect traffic but also proactively mitigate abuse at the connection level.
Configuring ASA to Limit Connections and Embryonic Thresholds
To protect internal resources like a web server in the DMZ, begin by defining an ACL that matches incoming TCP traffic destined for a specific IP and port—for example, HTTP on TCP port 80:
access-list TO_DMZ_SRV permit tcp any host 172.16.1.50 eq 80
Next, create a class-map to identify the matched traffic:
class-map TO_DMZ_SRV match access-list TO_DMZ_SRV
Now, create a policy-map to associate this class-map with specific connection limits:
policy-map SECURE_SRV class TO_DMZ_SRV set connection conn-max 5000 set connection per-client-embryonic-max 10
This configuration allows a maximum of 5,000 simultaneous TCP connections overall, while restricting each individual client to just 10 embryonic (half-open SYN-ACK) connections—an effective way to mitigate SYN flood attacks without fully dropping initial connections.
Optional Connection Management Parameters
ASA provides additional fine-grained connection control within MPF, including:
- advanced-options: Enables configuration of more specific parameters.
- conn-max: Sets the total allowable concurrent connections. A default value of 0 implies unlimited.
- decrement-ttl: Reduces the TTL (Time to Live) value in packets, often used in security enforcement or diagnostics.
- embryonic-conn-max: Limits the total number of half-open TCP sessions globally.
- per-client-embryonic-max: Caps the number of embryonic connections per source IP.
- per-client-max: Limits the total simultaneous connections per client.
- random-sequence-number: Enables or disables TCP sequence number randomization for added security.
- timeout: Allows for connection timeout tuning, helping to close idle or hung sessions.
Finally, apply the configured service policy to the appropriate interface, such as your external interface:
service-policy SECURE_SRV interface outside
This setup ensures that the ASA not only inspects traffic but also intelligently manages connection limits to protect services from being overwhelmed.
Understanding MPF Order of Operations and Policy Scope in Cisco ASA
To wrap up our comprehensive look at Cisco ASA’s Modular Policy Framework (MPF), it’s crucial to understand the order of operations and how policy maps are evaluated, especially when multiple policies (global and interface-specific) are involved. These rules dictate how ASA applies inspection, QoS, and connection control features to traffic as it flows through the firewall.
Per-Feature Evaluation and Precedence
MPF evaluates policies on a per-feature basis. This means that for each feature, such as inspect, set connection, or qos, the ASA will apply only one matching policy, and that match depends on whether the policy is defined globally or at the interface level.
For example, if a packet matches both an interface-level policy-map and a global policy-map for the same feature type (like traffic inspection), only the interface policy-map will take effect. The global policy acts as a catch-all fallback and only applies when no interface-specific match exists.
This design ensures that interface-specific configurations override global settings, maintaining granularity and control over per-interface behaviors. If there’s a contradiction or overlap, the interface-level policy always wins.
Behavior of set connection and Match Logic
The set connection command is part of ASA’s TCP normalization toolkit. It’s used to enforce parameters such as TTL, maximum connections, embryonic connection thresholds, and TCP sequence randomization. Like other MPF features, set connection is applied based on where it’s configured, either globally or per interface, but not both simultaneously.
Additionally, policy-map class matching is feature-specific and exclusive. A single packet can match only one class-map per feature type. So if you’ve configured inspection on a packet in an interface policy-map, that same feature won’t be re-applied via the global policy.
It’s also important to note: MPF doesn’t work on a “first match wins” model across different features. Instead, it works as first match per feature. Every class-map that matches gets evaluated, but only the first match for each individual feature type is used in enforcement.
This logic ensures that Cisco ASA’s MPF system provides both flexibility and precision in traffic handling, allowing administrators to build efficient, layered policies that prioritize local interface control but still retain global fallback behavior.
Layer 7 Inspection with MPF: Blocking Access to Specific URLs
As a final advanced use case for Cisco ASA’s Modular Policy Framework (MPF), let’s look at how to perform Layer 7 (L7) inspection to block access to specific websites, such as www.facebook.com. This approach inspects the HTTP request headers to match domain names, using regular expressions (regex) to identify patterns, and then applies policy actions accordingly.
Step-by-Step: Blocking a URL with L7 Inspection
To block access to a URL like Facebook, you must define an L7 policy-map that inspects HTTP headers for matches against a regex string. This allows ASA to detect specific sites regardless of the destination IP.
1. Create a Layer 7 Class-Map for HTTP
Define a class that matches traffic by inspecting the HTTP request header for a regex pattern:
class-map type inspect http CM_L7_HTTP match request header host regex FB regex FB *fb.com
This captures any HTTP Host header containing fb.com, which would cover most Facebook-related URLs.
2. Create a Layer 7 Policy-Map
Link the class to a policy-map and define what action to take when a match is found:
policy-map type inspect http PM_L7_HTTP class CM_L7_HTTP reset log
You have three available actions to choose from:
- reset: Sends a TCP RST packet to immediately terminate the session (preferred for speed).
- log: Records the match in the log for auditing.
- drop connection: Drops the connection silently; can cause client retries and delay.
3. Create a L3/L4 Policy for HTTP Traffic
You’ll still need a Layer 3/4 class-map to match the base HTTP traffic:
class-map CM_L3_HTTP match port tcp eq 80
And then apply your Layer 7 inspection policy within a standard policy map:
policy-map PM_L3_HTTP class CM_L3_HTTP inspect http PM_L7_HTTP
4. Apply the Service Policy
Finally, bind the policy to the inside interface (or any applicable zone):
service-policy PM_L3_HTTP interface inside
This configuration ensures that any HTTP traffic containing fb.com in the Host header will be identified and dropped or reset based on your preference. It’s a lightweight and flexible method of web filtering at the firewall level, without requiring a full proxy setup.
