As networks expanded and began handling sensitive business and personal data, the demand for stronger security measures led to the creation of the firewall. The term “firewall” originally referred to a physical barrier—typically made of stone or metal—designed to prevent the spread of fire between buildings. In networking, firewalls serve a similar purpose: they separate trusted, protected networks from untrusted or public networks, such as the internet, to prevent unauthorized access.
In the early days, network protection relied primarily on Access Control Lists (ACLs). These lists—standard, extended, numbered, or named—controlled traffic based on IP addresses and ports. While effective for basic filtering, ACLs lacked intelligence and required constant manual updates. As networks evolved, new firewall technologies emerged to address more complex threats.
Evolution of Firewall Technologies
By the late 1990s, stateful firewalls became the standard. These devices could track active sessions and make decisions based on the state and context of traffic. For example, stateful inspection ensured that only packets belonging to established, valid sessions were allowed through. Early Cisco implementations used “TCP established” ACL options and reflexive ACLs, later evolving into dynamic and time-based ACLs that provided temporary or scheduled access control.
Today’s firewalls have grown far beyond simple packet filters. Modern types include:
In modern network design, firewalls must be strategically placed to secure sensitive systems while still allowing necessary communication. The best designs balance protection and accessibility by layering firewall rules at the edge, core, and host levels.
Hands-On Learning
To reinforce these concepts, learners should practice configuring and testing real or simulated firewall technologies. In lab environments, students can use Cisco routers to explore:
Example configuration of a simple ZBF on a Cisco router:
! Define security zones zone security INSIDE zone security OUTSIDE ! Create a policy map for traffic inspection class-map type inspect match-any WEB-TRAFFIC match protocol http match protocol https policy-map type inspect INSIDE-TO-OUTSIDE class type inspect WEB-TRAFFIC inspect class class-default drop log ! Apply zones to interfaces zone-pair security IN-OUT source INSIDE destination OUTSIDE service-policy type inspect INSIDE-TO-OUTSIDE interface GigabitEthernet0/0 zone-member security OUTSIDE interface GigabitEthernet0/1 zone-member security INSIDE
Hands-on labs are available to guide learners through configuring ACLs, CBAC, and ZBF using both the command-line interface (CLI) and graphical tools. These exercises encourage real-world thinking about how to secure edge routers and internal resources effectively.
Access Control Lists (ACLs) remain a fundamental tool in network security, used to filter, permit, or deny traffic based on a set of defined conditions. ACLs help administrators enforce security policies, mitigate attacks, and control how packets traverse network interfaces. They can filter traffic at multiple layers of the OSI model, from Layer 2 (Data Link) through Layer 4 (Transport) and even Layer 7 (Application).
Understanding ACL Types and Evolution
Historically, ACLs were implemented as simple numbered lists that filtered traffic using Ethernet types or MAC addresses. For example, ACL numbers 200–299 were used for Ethernet-type filters, while ACLs numbered 700–799 filtered based on MAC addresses. Today, ACLs have evolved to focus primarily on IP traffic, using IPv4 or IPv6 addresses combined with TCP and UDP port numbers to classify and control packets with much greater precision.
Standard ACLs
Standard ACLs are the simplest type and filter packets solely based on the source IP address. They cannot inspect destination information or port numbers. They are best used close to the destination network to avoid unnecessarily filtering legitimate traffic.
R1(config)# access-list 10 permit 192.168.10.0 0.0.0.255 R1(config)# access-list 10 deny any R1(config-if)# ip access-group 10 in
In this example, only packets sourced from the 192.168.10.0/24 network are permitted to enter the interface. All other traffic is implicitly denied.
Extended ACLs
Extended ACLs provide much greater control by filtering based on multiple fields: source and destination IP addresses, Layer 4 protocols (TCP, UDP, ICMP, etc.), and port numbers. They are typically placed close to the source of the traffic to minimize unnecessary network load.
R1(config)# access-list 101 permit tcp 192.168.10.0 0.0.0.255 any eq 443 R1(config)# access-list 101 deny tcp any any eq 21 R1(config)# access-list 101 permit ip any any R1(config-if)# ip access-group 101 in
This configuration allows HTTPS traffic (TCP/443) from the 192.168.10.0/24 network while denying FTP (TCP/21) from any source.
Named ACLs
To make ACL management easier, Cisco introduced named ACLs, which replace numeric identifiers with descriptive names. Named ACLs are more flexible: you can insert, delete, or reorder specific entries without recreating the entire list.
R1(config)# ip access-list extended SECURE-WEB R1(config-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255 any eq 443 R1(config-ext-nacl)# deny ip any any log R1(config-ext-nacl)# exit R1(config-if)# ip access-group SECURE-WEB in
Named ACLs are ideal for dynamic environments where frequent policy updates are required. The no command can remove individual entries without deleting the entire ACL.
no
VTY Line Access Control
ACLs can also be applied to virtual terminal (VTY) lines to restrict remote administrative access via SSH or Telnet. Standard ACLs are typically used for this purpose.
R1(config)# ip access-list standard ADMIN-ACCESS R1(config-std-nacl)# permit 192.168.100.0 0.0.0.255 R1(config)# line vty 0 4 R1(config-line)# access-class ADMIN-ACCESS in R1(config-line)# transport input ssh
This configuration restricts SSH access to the router to devices within the 192.168.100.0/24 subnet.
Logging and Monitoring ACL Activity
When troubleshooting or investigating attacks, administrators can enable logging within ACL statements. The log keyword records matching packets to the router’s console, buffer, or syslog server. However, logging consumes additional CPU resources and should only be used temporarily during diagnostics.
log
R1(config)# access-list 105 permit tcp any any eq 22 log
Each log entry includes action (permit or deny), protocol, source and destination addresses, and port numbers. Logs are generated for the first match and every five minutes thereafter while traffic continues to match the rule.
Best Practices and Common Pitfalls
permit
in
out
Example Using Sequence Numbers:
R1(config)# ip access-list extended FIREWALL-IN R1(config-ext-nacl)# 10 permit tcp 10.0.0.0 0.0.0.255 any eq 443 R1(config-ext-nacl)# 20 deny ip any any log R1(config-ext-nacl)# 15 permit tcp 10.0.0.0 0.0.0.255 any eq 80
Here, the new statement numbered 15 is inserted between 10 and 20 without re-creating the ACL.
Conclusion
ACLs remain a cornerstone of Cisco network security. They provide a flexible, efficient, and powerful method for filtering traffic and enforcing security policies. While more advanced technologies such as Zone-Based Firewalls (ZBF) and Next-Generation Firewalls (NGFW) offer deep inspection capabilities, ACLs continue to play a vital role at the edge and core of modern enterprise networks.
When designing an access control strategy, the choice between using a standard or extended ACL depends on how granular the filtering needs to be. Standard ACLs filter traffic based only on the source IP address, while extended ACLs provide finer control, allowing filtering by protocols, ports, and destination addresses.
Example 1 – Blocking a Subnet with a Standard ACL
Suppose all traffic from subnet 172.16.4.0/24 must be denied access to another subnet, while all other traffic should pass. A standard ACL can easily achieve this when applied outbound on an interface:
172.16.4.0/24
R1(config)# access-list 1 deny 172.16.4.0 0.0.0.255 R1(config)# access-list 1 permit any R1(config)# interface FastEthernet0/0 R1(config-if)# ip access-group 1 out
This configuration denies traffic from subnet 172.16.4.0/24 from leaving interface Fa0/0, effectively blocking its access to other networks.
Fa0/0
Command Breakdown:
0.0.0.255
Example 2 – Blocking FTP Traffic with an Extended ACL
Extended ACLs allow filtering based on more specific criteria, such as protocols and ports. Consider a scenario where FTP traffic from subnet 172.16.4.0/24 must be blocked from reaching 172.16.3.0/24 while all other traffic remains permitted:
172.16.3.0/24
R1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 21 R1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 20 R1(config)# access-list 101 permit ip any any R1(config)# interface FastEthernet0/1 R1(config-if)# ip access-group 101 in
In this configuration:
permit ip any any
ACL Placement Considerations:
Example Behavior:
With the above ACL applied inbound on Fa0/1, all FTP traffic from 172.16.4.0/24 destined for 172.16.3.0/24 will be dropped immediately upon entering the router. However, FTP sessions from 172.16.4.0 to other networks are unaffected and will be permitted.
Fa0/1
172.16.4.0
Key Takeaway: Always remember that ACLs are processed top-down and end with an implicit deny all. For proper functionality, ensure a final permit ip any any statement is included when other traffic should pass unfiltered.
deny all
When configuring Access Control Lists (ACLs), understanding the direction of traffic flow through the router is essential. Traffic direction determines whether an ACL inspects packets entering or leaving an interface.
Inbound (Ingress) Traffic: Inbound traffic refers to packets entering a router interface before being routed to their destination. Inbound ACLs filter traffic prior to any routing table lookups, making them efficient for early packet control.
Outbound (Egress) Traffic: Outbound traffic refers to packets that have already been processed by the router’s routing table and are about to exit an interface. Outbound ACLs are applied after the routing decision is made and before the packet leaves the interface.
ACLs can track return traffic dynamically using features such as reflexive ACLs or stateful firewalls like Zone-Based Policy Firewalls (ZBF), which maintain session tables to allow legitimate return traffic automatically.
ACL Placement Guidelines
Most modern networks use Extended ACLs to balance access control with resource efficiency. For instance, administrators may permit business-critical HTTPS traffic (TCP port 443) while blocking insecure or nonessential protocols.
Using Tools to Identify Open Ports
Before defining ACL rules, administrators often use network scanners like Nmap to identify open ports on target devices. For example, if an ACL blocks POP3 (TCP port 110) from external access but allows it internally, an Nmap scan will show port 110 as open when performed from within the LAN, but filtered or closed when scanned externally.
Verifying ACL Configuration
Once ACLs are applied, verification ensures that desired traffic passes and unwanted traffic is blocked. Two useful Cisco IOS commands include:
R1# show ip access-lists
This displays all ACLs and the number of packets matching each access control entry (ACE). Packet counts confirm whether ACL rules are functioning as expected.
R1# show running-config | include access-group
This command identifies which interfaces have ACLs applied and in which direction (inbound or outbound).
Logging Considerations
While the log option can be used to monitor packets that match ACL entries in real time, it can impose a heavy processing load on routers and switches. Logging should be enabled temporarily for troubleshooting or validation, then disabled once the configuration has been verified.
Example Verification Workflow:
R1# show ip access-lists R1# show running-config | section interface R1# debug ip packet detail R1# undebug all
Using this workflow, administrators can view ACL hit counts, confirm interface bindings, and perform targeted debugging—then quickly disable debugging to restore performance.
Key Takeaway: Effective ACL design relies on correctly identifying traffic direction, strategic placement, and proper verification. Misplaced ACLs or unchecked logging can degrade performance or inadvertently block critical business services.
In earlier Cisco IOS environments, Cisco Security Device Manager (SDM) provided a graphical interface for configuring routers, including Standard and Extended Access Control Lists (ACLs). Although SDM simplified complex configurations for administrators, it has since become a legacy tool. Cisco SDM has been replaced by Cisco Configuration Professional (CCP) and, more recently, by Cisco DNA Center and web-based GUIs found on modern ISR and Catalyst devices.
Nevertheless, understanding SDM remains valuable for legacy networks and certification purposes, as many older routers still support SDM-based configurations.
Legacy SDM Interface Overview
SDM consisted of two main frames:
ACL configuration was accessed via Configure > Additional Tasks > ACL Editor. Administrators could create, edit, and apply access rules through the SDM wizard interface.
Types of Rules in Cisco SDM
Within SDM, ACLs were grouped under several functional categories:
Creating Standard ACLs Using Cisco SDM (Legacy Procedure)
Applying ACLs to Interfaces
To view the actual IOS commands SDM generates, go to View > Running Config from the menu bar. This allows administrators to understand the underlying CLI structure that SDM executes on the router.
Modern Alternatives to SDM
Example CLI Equivalent of a Standard ACL Configuration
R1(config)# access-list 10 permit 192.168.10.0 0.0.0.255 R1(config)# access-list 10 deny any R1(config)# interface GigabitEthernet0/1 R1(config-if)# ip access-group 10 in
Key Takeaway: While Cisco SDM is now considered obsolete, understanding its workflow is useful for managing legacy devices. Modern network management emphasizes centralized, API-driven configuration and automation tools that build upon the foundational concepts introduced by SDM.
Dynamic Access Control Lists (ACLs), also known as lock-and-key ACLs, were introduced in Cisco IOS around 1996 — before ACL logging and reflexive ACLs became standard features. They represented one of the earliest forms of on-demand, user-authenticated access control on Cisco routers. Dynamic ACLs apply exclusively to IP traffic and rely on Telnet or SSH authentication combined with Extended ACLs to grant temporary access through a router or firewall.
How Dynamic ACLs Work
By default, an extended ACL is configured to deny traffic through the router. When an external user wants to gain access, they initiate a Telnet or SSH session to the router. Once authenticated—either through a local username/password or an AAA server (RADIUS or TACACS+)—the router terminates the session and dynamically inserts a new, temporary ACL entry into the access list. This entry allows the authenticated user’s IP traffic for a specific duration, controlled by idle and absolute timeout values.
This process effectively creates a temporary “hole” in the firewall—only for authenticated and approved users—and closes it automatically when the timer expires or the user disconnects.
Why Use Dynamic ACLs?
Dynamic ACLs are particularly useful for:
Advantages of Dynamic ACLs
Dynamic ACL Workflow
username
Configuration Steps
Step 1 – Create an Extended ACL
Start by defining an extended ACL that initially blocks traffic but allows Telnet or SSH connections used for authentication. A placeholder entry will be dynamically updated once users authenticate.
Router(config)# access-list 110 permit tcp any host 192.168.1.1 eq 22 Router(config)# access-list 110 dynamic remote_access timeout 10 permit ip any 192.168.10.0 0.0.0.255 Router(config)# interface GigabitEthernet0/0 Router(config-if)# ip access-group 110 in
Step 2 – Configure Authentication
Define authentication using a local database or AAA server. For example:
Router(config)# username netadmin secret MySecurePass Router(config)# aaa new-model Router(config)# aaa authentication login default local
Step 3 – Enable Dynamic Authentication on VTY Lines
Enable lock-and-key authentication using the autocommand access-enable command on the vty lines:
autocommand access-enable
Router(config)# line vty 0 4 Router(config-line)# autocommand access-enable host timeout 5 Router(config-line)# login authentication default
This configuration forces authentication before dynamic ACL entries are created. The host keyword ensures that the user’s specific IP address replaces the any keyword in the ACL entry, allowing user-specific filtering. The timeout value defines the idle timeout—how long the ACL entry remains active without activity.
host
any
timeout
Timeouts in Dynamic ACLs
Example Combined Configuration
! Step 1 - Define dynamic ACL Router(config)# access-list 120 permit tcp any host 192.168.1.1 eq 22 Router(config)# access-list 120 dynamic remote_access timeout 15 permit ip any 192.168.10.0 0.0.0.255 Router(config)# interface GigabitEthernet0/0 Router(config-if)# ip access-group 120 in ! Step 2 - Configure authentication Router(config)# username guest secret Secure123 Router(config)# aaa new-model Router(config)# aaa authentication login default local ! Step 3 - Enable lock-and-key authentication Router(config)# line vty 0 4 Router(config-line)# login authentication default Router(config-line)# autocommand access-enable host timeout 5
How It Works:
Modern Context
While dynamic (lock-and-key) ACLs were groundbreaking in the mid-1990s, they are now largely considered legacy security mechanisms. Modern Cisco platforms use AAA-based authentication with downloadable ACLs (dACLs) from Cisco ISE or ACS servers. These dACLs provide the same dynamic access concept—authenticated, temporary, per-user access—but with centralized policy management and enhanced scalability.
Summary
Dynamic ACLs introduced the concept of authenticated, temporary access control—a precursor to modern network access control frameworks. While they’re rarely used in production networks today, understanding them provides foundational insight into how Cisco’s context-based firewalls and Identity-Based Networking Services (IBNS) evolved.
Time-based Access Control Lists (ACLs), introduced to Cisco IOS in 1998, extend the functionality of extended ACLs by allowing permit/deny actions to be enforced only during specified time periods. This enables administrators to control access to network resources based on time of day, day of week, or specific calendar dates.
Time-based ACLs are especially useful when a temporary firewall exception is needed but should not remain open indefinitely. Examples include:
How Time-Based ACLs Work
Time-based ACLs are built on extended ACLs. A time-range object is created and then referenced inside a permit or deny statement. IOS evaluates the ACL entry only when the router’s clock matches the defined time window.
time-range
Creating a Time Range
Each time range must have a unique name (no spaces, must begin with a letter). The time-range configuration mode supports two types of schedules: absolute (one-time event) and periodic (recurring schedule).
Router(config)# time-range RANGE_NAME Router(config-time-range)# absolute start-time start-date end-time end-date Router(config-time-range)# periodic day hh:mm to [day] hh:mm
Absolute Time Range — one-time period only.
15:00
07 July 2025
23:59 31 December 2035
Periodic Time Range — recurring schedule.
Supported keywords for repeating periods include:
The router’s system clock must be set accurately for time-based ACLs to work correctly (manual clock or NTP recommended).
Referencing Time Ranges in ACLs
A time range is activated by adding time-range NAME to an extended ACL entry:
time-range NAME
Router(config)# access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq 443 time-range WORK_HOURS
The ACL entry is evaluated only when the router’s clock falls within the defined time window.
Configuration Example – Allow Internet Access Only During Lunch and After Work
Requirement: Employees should not access the Internet during normal business hours. Internet access should be permitted only during lunch (12:00–13:00) and again from 17:00–19:00.
R1(config)# time-range employee-time R1(config-time-range)# periodic weekdays 12:00 to 13:00 R1(config-time-range)# periodic weekdays 17:00 to 19:00 R1(config-time-range)# exit R1(config)# access-list 100 permit ip 192.168.1.0 0.0.0.255 any time-range employee-time R1(config)# access-list 100 deny ip any any R1(config)# interface FastEthernet0/1 R1(config-if)# ip access-group 100 in
Result:
Best Practices for Time-Based ACLs
Time-based ACLs remain useful today in environments that need scheduled access control without full firewall automation—though modern enterprise networks increasingly replace them with solutions such as dynamic downloadable ACLs (dACLs) from Cisco ISE and zero-trust identity policies.
Once an Access Control List (ACL) has been deployed, verification and troubleshooting are essential to ensure the ACL is filtering traffic as intended. Misconfigured ACLs can accidentally block legitimate traffic or unintentionally allow unauthorized access, so monitoring is a core security responsibility.
Viewing ACL Hit Counters
The primary verification method is the show access-lists command, which displays every ACL entry along with the number of packets that matched it. Each match counter reflects how many times traffic has been permitted or denied by that entry.
show access-lists
Router# show access-lists Router# show access-lists 100 Router# show access-lists BLOCK_FTP
Interpreting the output:
Using Debug for Real-Time Packet Inspection
For deeper troubleshooting, especially when packet filtering behaviors are unclear, use debug ip packet to observe traffic as it is processed by the router.
debug ip packet
Router# debug ip packet Router# debug ip packet 100 Router# debug ip packet 100 detail
Details and cautions:
Stop debugging output using:
Router# undebug all
Best Practices for ACL Verification
Even though there are only a few ACL verification commands, testing every ACL after deployment is critical. Proper validation prevents accidental service disruption and ensures the network remains protected against unauthorized access.
Access Control Lists (ACLs) remain one of the simplest and most effective first-line defenses in network security. When deployed properly, ACLs not only filter traffic — they actively mitigate attacks, block spoofed packets, protect key services, and limit malicious ICMP behavior.
Common Security Threats Addressed by ACLs
Blocking IP Spoofing
Most DoS attacks rely on spoofing. A router should never receive inbound packets containing internal or special-use source IP addresses. ACLs can immediately eliminate spoofed traffic by denying packets with forbidden source ranges.
Block inbound spoofed sources such as:
127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
224.0.0.0/4
Best practice also applies outbound:
If a packet leaves the network, its source IP must belong to the internal organization. All other source addresses should be denied.
! Drop spoofed inbound IPs ip access-list extended BLOCK-SPOOF deny ip 127.0.0.0 0.255.255.255 any deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any deny ip 224.0.0.0 15.255.255.255 any permit ip any any
Permitting Only Required Services Through the Firewall
Some protocols must be allowed through security boundaries — for example:
Routers may also require administrative access from approved IPs:
! Example — allow secure management ip access-list extended MGMT-ACCESS permit tcp host 203.0.113.10 any eq 22 ! SSH from NOC permit udp host 203.0.113.20 any eq 514 ! Syslog collector permit udp host 203.0.113.30 any eq 161 ! SNMP manager deny ip any any
Controlling ICMP for Security and Stability
ICMP plays two roles — attackers abuse it, but network devices also rely on it for troubleshooting and path management. A secure ACL approach blocks harmful ICMP messages while allowing operationally important ones.
Recommended ICMP allowed inbound:
Recommended ICMP allowed outbound:
All other ICMP messages should be blocked by default.
! Example ICMP control policy ip access-list extended ICMP-FILTER ! Inbound (from Internet) permit icmp any any echo-reply permit icmp any any source-quench permit icmp any any unreachable deny icmp any any ! Outbound permit icmp any any echo permit icmp any any parameter-problem permit icmp any any packet-too-big deny icmp any any
ACLs are powerful, but they are just one part of a secure perimeter. The next step in strengthening network defenses is exploring stateful firewalls, Zone-Based Firewall (ZBF), and Context-Based Access Control (CBAC), which build upon ACLs to provide deeper inspection and dynamic session awareness.
The term firewall originated long before computer networks existed. It described a fire-resistant barrier (usually stone or metal) that stopped flames from spreading between structures. The automotive and aviation industries later adopted the term for the partition that isolates the engine compartment from passengers. Today, the term has evolved again — a firewall in networking is a barrier that prevents unauthorized, malicious, or untrusted traffic from entering protected portions of a network.
In modern networks, a firewall is a system or collection of systems that enforces an access control policy between trusted and untrusted environments. A firewall may take many forms, including:
iptables
Regardless of scale or complexity, all firewalls share core characteristics:
1988 — Packet Filter Firewalls (Stateless) DEC introduced the first network firewall based on packet filtering. Individual packets were inspected using criteria such as source/destination IP, protocol, and port — then permitted or denied. These early firewalls were stateless, meaning they did not track whether packets belonged to an ongoing connection.
1989 — Stateful Firewalls AT&T Bell Labs pioneered the stateful firewall, which tracks active sessions. When a connection is established, temporary dynamic rules are created and removed when the session ends. Stateful inspection significantly improved protection against spoofing and DoS attacks by distinguishing legitimate return traffic from unsolicited traffic.
1990s onward — Dedicated Firewall Appliances Early firewalls ran as software on routers and servers. As traffic volumes increased, dedicated firewall appliances emerged to offload the CPU-intensive work of packet inspection. Today, organizations may deploy:
Modern Cisco ISR routers continue to support full stateful firewall capabilities, providing enterprise-grade protection for environments that don’t require a dedicated appliance.
Because of these risks, modern network security relies on defense-in-depth — combining firewalls with intrusion prevention, segmentation, endpoint security, strong authentication (Zero Trust), and continuous monitoring.
There is no single firewall type capable of solving every security challenge. The appropriate choice depends on:
A firewall system is often made up of multiple components, but the most recognizable function is traffic filtering — the selective permitting or denying of packets based on an organization’s security policy. Filtering can be implemented in several ways, which leads to different categories of firewalls. The most common types include:
Packet-filtering firewalls operate primarily at the Network Layer (Layer 3) but frequently enforce rules using Layer 4 protocol and port information. ACL-style logic determines whether a packet is permitted or denied based on:
These firewalls are sometimes called static filters because each packet is evaluated individually, without tracking whether it belongs to an active session. Despite their limitations, packet filters remain foundational — especially as part of router-based perimeter defenses.
Because services rely on specific ports, packet filters can be highly effective at limiting attack surfaces. For example, blocking outbound TCP port 25 on selected subnets prevents malware-infected workstations from attempting to send bulk spam or exfiltrate stolen data via SMTP.
Stateful firewalls are the most widely used firewall technology today. Instead of making decisions one packet at a time, a stateful firewall builds and maintains a state table that tracks connection information across all network interfaces. Each session is recorded in the table using metadata such as:
When a client inside the network initiates a connection, the stateful firewall records the session. When the external server responds, the packet is compared against the state table — legitimate return traffic is permitted automatically without requiring explicit ACL entries.
Modern stateful firewalls go even further, implementing protocol-aware support mechanisms. Examples include:
A potential drawback is that stateful inspection can expose internal IP addressing unless combined with NAT or proxy functions — which is why most commercial firewalls today blend stateful filtering + NAT + deep inspection into a single platform.
Cisco offers multiple firewall implementation paths, each suitable for different scale and budget requirements:
ASA was designed as a core component of Cisco’s Self-Defending Network model, providing multi-layer threat defense while maintaining ease of deployment and lower operational costs. ASA remains widely deployed, although many organizations are now transitioning toward Next-Generation Firewalls (NGFWs) with features like SSL decryption, identity-aware policy, and machine-learning-driven threat detection.
Firewalls are not one-size-fits-all. Selecting the correct solution involves a balance of:
No matter which platform is selected, successful deployment depends on thoughtful security architecture — including segmentation, redundancy, logging/monitoring, and policy governance.
In network security, the term demilitarized zone (DMZ) refers to a portion of a network that is isolated by a firewall or a set of firewalls. Borrowed from the military concept of a neutral buffer zone, a DMZ limits where untrusted devices can communicate while protecting trusted internal resources.
A DMZ helps define which parts of a network are trusted and which are untrusted. Firewall design is centered around controlling traffic at interfaces — determining whether to permit or deny packets based on their source, destination, and type of traffic.
Some deployments are simple, consisting of two firewall interfaces:
In this model, outbound traffic from the inside is usually allowed to the outside with few restrictions. Inbound traffic from the outside is normally blocked entirely or allowed only in very specific cases. Return traffic associated with legitimate outbound connections is allowed back in.
More advanced topologies introduce a third interface:
Common DMZ services include email, DNS, HTTP, and HTTPS servers. Typical traffic rules in a three-interface design:
A layered defense combines multiple firewalls and filtering methods to protect both the perimeter and sensitive internal segments. For example, a screened subnet configuration may include:
Only traffic that successfully passes each layer is permitted to reach internal hosts. A bastion host is specifically hardened for this purpose and is commonly located in the DMZ.
Although layered firewall architectures are powerful, they do not guarantee complete security. Additional considerations include:
A DMZ and layered firewall approach is effective only when combined with monitoring, patching, endpoint protection, and informed users.
Security professionals must define and maintain a written firewall policy. A good starting point includes:
A Cisco router running Cisco IOS Firewall can operate as both a router and a firewall. When two firewall devices are deployed, they can be connected by a LAN segment that serves as the DMZ. This setup provides redundancy for public access to DMZ resources and isolates internal networks from direct exposure.
Context-Based Access Control (CBAC) is a major component of the legacy Cisco IOS Firewall feature set. Unlike basic ACLs, CBAC performs stateful inspection at the Application Layer, allowing the firewall to understand how protocols behave, track active sessions, and dynamically permit return traffic. This enables CBAC to support complex and multi-channel applications such as FTP, H.323, and multimedia protocols, which standard ACLs cannot properly secure.
CBAC can also parse and translate NAT/PAT-embedded addressing information, helping ensure multi-channel and dynamic protocols continue functioning after address translation. In addition, CBAC can block peer-to-peer applications (such as Gnutella or KaZaA) and popular instant-messaging platforms (e.g., Yahoo!, AOL, MSN), giving administrators fine-grained control over non-business traffic.
1. Traffic Filtering CBAC dynamically permits return TCP/UDP traffic only when a session has been legitimately initiated. When inside hosts create connections, CBAC temporarily opens access in the ACL to allow the return packets back through the firewall. This supports intranet, extranet, and Internet perimeter deployments. Unlike stateless filtering, CBAC evaluates Layer 3 and 4 information and Application Layer state data, enabling support for protocols requiring multiple negotiated channels.
2. Traffic Inspection Since CBAC tracks TCP/UDP sessions, it can protect against attacks that exploit connection state. For example:
These protections help reduce DoS attack effectiveness by eliminating abnormal traffic before it reaches internal hosts.
3. Intrusion Detection CBAC includes a limited intrusion detection capability designed to identify specific attack signatures—particularly those targeting SMTP. When an attack signature is matched, CBAC: • Terminates the unauthorized connection • Generates syslog alerts for analysis
4. Alert and Audit Generation CBAC supports extensive session-based logging through syslog. Each inspected session can record timestamps, source/destination addresses, ports, and bytes transferred. Suspicious activity triggers real-time syslog alerts that can be forwarded to monitoring systems.
Introduced in 1997, CBAC was a major advancement over previous IOS solutions such as TCP established and reflexive ACLs. Key improvements include:
CBAC offers significant protections, but with important considerations:
Even though CBAC is considered a legacy technology today (superseded by Zone-Based Firewall), understanding it remains valuable for:
Traditional ACL-based filtering operates only at the Network and Transport Layers. CBAC goes further by implementing a stateful, application-aware packet filter that examines Application Layer information to track the full state of a session — including dynamic protocols like FTP, RPC, and SQL*Net that open multiple channels.
CBAC maintains a state table tracking active TCP, UDP, and ICMP sessions. As traffic exits the protected network, CBAC inserts temporary dynamic ACL entries to permit the returning traffic back in. These entries exist only for the life of the session and are never written to NVRAM.
Step-by-Step: Outbound Telnet Example
TCP Handling
When a TCP SYN packet is received, CBAC checks the ACL and — if permitted — creates a session entry tracking endpoint addresses, port numbers, sequence numbers, and flags. All subsequent packets are validated against this state. After the three-way handshake completes, all packets must carry the ACK flag; CBAC enforces this throughout the session lifetime.
! CBAC TCP session entry (conceptual) ! Src: 192.168.1.10:49200 Dst: 203.0.113.5:23 Proto: TCP ! Flags: SYN > SYN-ACK > ACK State: ESTABLISHED Idle: 3600s
UDP Handling
UDP has no handshake or teardown. CBAC creates a connection entry based solely on endpoint addresses and port numbers when the first packet is permitted. The entry is removed after a configurable idle timeout with no traffic.
! CBAC UDP session entry (conceptual) ! Src: 192.168.1.10:5000 Dst: 8.8.8.8:53 Proto: UDP Idle: 30s
Other IP Protocols
Protocols like GRE and IPsec are handled statelessly — similar to classic packet filtering. When a flow is initially permitted, all matching packets are allowed until an idle timer expires.
Dynamic Application Inspection
Protocols like FTP and VoIP signaling open a primary channel then negotiate secondary channels dynamically. CBAC parses the initial session to learn about these secondary channels and automatically permits them if the primary session was allowed.
! FTP active mode: CBAC parses the PORT command on TCP/21 ! and dynamically opens the data channel on TCP/20 ip inspect name CBAC_RULE ftp
Inspection Rules
An inspection rule defines which protocols CBAC monitors and is applied to an interface in a specific direction. Packets denied by an ACL are dropped before inspection occurs.
ip inspect name CBAC_RULE tcp ip inspect name CBAC_RULE udp ip inspect name CBAC_RULE ftp ip inspect name CBAC_RULE smtp ip inspect name CBAC_RULE http interface GigabitEthernet0/0 description Outside Interface ip inspect CBAC_RULE out ip access-group OUTSIDE_ACL in
Attack Detection
The Cisco IOS Firewall engine detects Application Layer attacks such as illegal SMTP commands. On detection it can generate alerts, protect system resources, or block packets from suspected attackers.
Timeouts and DoS Thresholds
CBAC tracks three thresholds to defend against TCP-based DoS attacks: total half-open sessions, half-open sessions per minute, and half-open sessions per host. When a threshold is exceeded, CBAC either resets the oldest half-open session or temporarily blocks all SYN packets — preventing the three-way handshake from completing and conserving router resources.
ip inspect tcp synwait-time 30 ip inspect tcp idle-time 3600 ip inspect udp idle-time 30 ip inspect dns-timeout 5 ip inspect max-incomplete high 1100 ip inspect max-incomplete low 900 ip inspect one-minute high 1100 ip inspect one-minute low 900 ip inspect tcp max-incomplete host 50 block-time 0
Verification
show ip inspect sessions show ip inspect sessions detail show ip inspect all show ip inspect interfaces show ip access-lists
There are four steps to configure CBAC:
Pick an Interface
Determine which interface is internal (where sessions originate) and which is external (where sessions are blocked). In a two-interface setup, CBAC blocks specified traffic from entering the protected network unless it belongs to a session initiated from inside. In a three-interface setup with a DMZ, external traffic can reach DMZ resources (e.g., DNS, web) while still being blocked from the internal network.
CBAC can also be configured in both directions on one or more interfaces — useful for extranet/intranet configurations or DoS protection. When configuring bidirectional CBAC, configure one direction first, then swap the internal/external designations for the other direction.
Configure IP ACLs at the Interface
ACLs must be configured on inside, outside, and DMZ interfaces. At minimum, apply ACLs on border routers between internal and external networks. Follow these guidelines:
Define Inspection Rules
Inspection rules specify which Application Layer protocols CBAC monitors at an interface. Typically one rule is sufficient; a second rule is only needed when enabling the firewall engine in two directions on a single interface.
Each rule is a series of statements sharing the same rule name, one per protocol. Generic TCP/UDP inspection dynamically permits return traffic; ICMP inspection allows echo-reply packets in response to previously seen echo requests.
Router(config)# ip inspect name inspection_name protocol [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Example 1 — Inspect SMTP and FTP with alerting and audit trails, 300s timeout:
ip inspect name FWRULE smtp alert on audit-trail on timeout 300 ip inspect name FWRULE ftp alert on audit-trail on timeout 300
Example 2 — Allow Java applet downloads only for hosts in the 10.224.10.0/24 subnet:
ip inspect name PERMIT_JAVA http java-list 10 access-list 10 permit 10.224.10.0 0.0.0.255
Example 3 — Inspect multiple protocols with a 12-hour TCP idle timeout:
ip inspect name in2out rcmd ip inspect name in2out ftp ip inspect name in2out tftp ip inspect name in2out tcp timeout 43200 ip inspect name in2out http ip inspect name in2out udp
Apply an Inspection Rule to an Interface
Router(config-if)# ip inspect inspection_name {in | out}
Two guiding principles for applying rules and ACLs:
Full Example — Inside users initiate TCP/UDP/ICMP to any external destination; external clients may only reach the DMZ SMTP server (209.165.201.1) and HTTP server (209.165.201.2):
! Internal ACL — permit outbound TCP, UDP, ICMP from inside network access-list 101 permit tcp 10.10.10.0 0.0.0.255 any access-list 101 permit udp 10.10.10.0 0.0.0.255 any access-list 101 permit icmp 10.10.10.0 0.0.0.255 any access-list 101 deny ip any any interface Fa0/0 ip access-group 101 in
! External ACL — permit only SMTP/HTTP to DMZ and select ICMP types access-list 102 permit tcp any 209.165.201.1 0.0.0.0 eq 80 access-list 102 permit tcp any 209.165.201.2 0.0.0.0 eq smtp access-list 102 permit icmp any any echo-reply access-list 102 permit icmp any any unreachable access-list 102 permit icmp any any administratively-prohibited access-list 102 permit icmp any any packet-too-big access-list 102 permit icmp any any echo access-list 102 permit icmp any any time-exceeded access-list 102 deny ip any any interface S0/0/0 ip access-group 102 in
! Inspection rules — applied inbound on internal interface ip inspect name MYSITE tcp ip inspect name MYSITE udp interface Fa0/0 ip inspect MYSITE in
CBAC automatically inserts temporary ACL entries on the external interface to permit TCP/UDP return traffic for sessions initiated from inside.
To remove all CBAC configuration, state table entries, dynamic ACL entries, and reset all timeouts to factory defaults:
Router(config)# no ip inspect
CBAC supports two logging functions: alerts and audits.
Alerts
Alerts report CBAC events such as DoS attacks, insufficient resources, and protocol violations. They are enabled by default and display on the console. To globally disable alerts (not recommended):
Router(config)# ip inspect alert-off
Example alert for an invalid SMTP command:
%FW-4-SMTP_INVALID_COMMAND: Invalid SMTP command from initiator (209.165.201.5:49387)
CBAC also detects other SMTP attacks, including pipe characters in To/From fields, :decode@ in headers, legacy wiz/debug commands, and Majordomo exploit attempts:
:decode@
wiz
debug
02:04:55: %FW-4-TCP_MAJORDOMO_EXEC_BUG: Sig:3107: Majordomo Execute Attack - from 209.165.201.5 to 192.168.1.1
Audits
Audit trails log all inspected connections — both valid and invalid — including state table additions and removals with basic session statistics. Disabled by default; enable with:
Router(config)# ip inspect audit-trail
Example audit entry for a Telnet session:
%FW-6-SESS_AUDIT_TRAIL: tcp session initiator (192.168.1.2:32782) sent 22 bytes responder (209.165.201.1:23) sent 200 bytes
By default, alerts and audits output to the console but can be redirected to the router's internal buffer or an external syslog server.
Show Commands
Router# show ip inspect [parameter]
Example — view a named inspection rule:
Router# show ip inspect name inspect_outbound Inspection name inspect_outbound cuseeme alert is on audit-trail is on timeout 3600 ftp alert is on audit-trail is on timeout 3600 http alert is on audit-trail is on timeout 3600 rcmd alert is on audit-trail is on timeout 3600 realaudio alert is on audit-trail is on timeout 3600 smtp alert is on audit-trail is on timeout 3600 tftp alert is on audit-trail is on timeout 30 udp alert is on audit-trail is on timeout 15 tcp alert is on audit-trail is on timeout 3600
Example — view active sessions and their dynamic ACL entries. The FTP control session was initiated from inside (192.168.1.2); CBAC dynamically opened the FTP data channel back from the server (209.165.201.1):
Router# show ip inspect sessions Established Sessions Session 25A3378 (209.165.201.1:20)=>(192.168.1.2:32704) ftp-data SIS_OPEN Session 25A5AC2 (192.168.1.2:32703)=>(209.165.201.1:21) ftp SIS_OPEN Router# show ip access-list Extended IP access list 100 permit tcp host 209.165.201.1 eq 21 host 192.168.1.2 eq 32703 (24 matches) permit tcp host 209.165.201.1 eq 20 host 192.168.1.2 eq 32704 (88 matches)
Debug Commands
For real-time troubleshooting, use debug ip inspect to observe CBAC operation as it happens:
debug ip inspect
Router# debug ip inspect protocol parameter
Supported application names: cuseeme, dns, ftp-cmd, ftp-token, h323, http, netshow, rcmd, realaudio, rpc, rtsp, sip, skinny, smtp, sqlnet, streamworks, tftp, vdolive.
cuseeme
dns
ftp-cmd
ftp-token
h323
http
netshow
rcmd
realaudio
rpc
rtsp
sip
skinny
smtp
sqlnet
streamworks
tftp
vdolive
Use debug ip inspect timers to monitor idle timeout events:
debug ip inspect timers
Router# debug ip inspect timers *Mar 2 01:20:43: CBAC* sis 25A3604 pak 2541C58 TCP P ack 4223720032 seq 4200176225(22) (10.0.0.1:46409) => (10.1.0.1:21) *Mar 2 01:20:43: CBAC* sis 25A3604 ftp L7 inspect result: PROCESS-SWITCH packet *Mar 2 01:20:43: CBAC sis 25A3604 pak 2541C58 TCP P ack 4223720032 seq 4200176225(22) (10.0.0.1:46409) => (10.1.0.1:21) *Mar 2 01:20:43: CBAC sis 25A3604 ftp L7 inspect result: PASS packet *Mar 2 01:20:43: CBAC* sis 25A3604 pak 2544374 TCP P ack 4200176247 seq 4223720032(30) (10.0.0.1:46409) <= (10.1.0.1:21) *Mar 2 01:20:43: CBAC* sis 25A3604 ftp L7 inspect result: PASS packet *Mar 2 01:20:43: CBAC* sis 25C1CC4 pak 2544734 TCP S seq 4226992037(0) (10.1.0.1:20) => (10.0.0.1:46411) *Mar 2 01:20:43: CBAC* sis 25C1CC4 pak 2541E38 TCP S ack 4226992038 seq 4203405054(0) (10.1.0.1:20) <= (10.0.0.1:46411)
Beginning with Cisco IOS Release 12.4(20)T, debug policy-firewall replaces debug ip inspect.
debug policy-firewall
While CBAC greatly extends the capability of Cisco routers as stateful firewalls, it does have limitations. Newer technologies build on CBAC's functionality while offering a more structured and intuitive implementation of the Cisco IOS Firewall feature set.
Introduced in Cisco IOS Release 12.4(6)T (2006), the zone-based policy firewall (ZPF) assigns interfaces to zones and applies inspection policies to traffic moving between them. This allows different inspection policies for multiple host groups on the same interface and enforces a default deny-all policy between zones — a significant departure from CBAC, where traffic was implicitly permitted until explicitly blocked.
ZPF supports the same features as CBAC — stateful packet inspection, application inspection, URL filtering, and DoS mitigation — but uses Cisco Common Classification Policy Language (C3PL), a hierarchical structure that makes policies modular, readable, and easier to troubleshoot.
CBAC Limitations Addressed by ZPF
ZPF Benefits
CBAC and ZPF can run concurrently on the same router, but cannot be combined on a single interface — an interface cannot simultaneously be a zone member and have IP inspection configured.
Designing a Zone-Based Firewall
Common ZPF designs include LAN-to-Internet firewalls, firewalls with public servers, redundant firewalls, and complex multi-zone firewalls.
ZPF supports three actions for traffic between zones:
ip inspect
The police option can be combined with inspect or pass to apply rate limiting to a traffic class.
police
inspect
pass
Zone and Interface Rules
The Self Zone
All IP interfaces on the router are automatically placed in the system-defined self zone when ZPF is configured. The self zone governs traffic destined for the router itself or generated by the router — it does not apply to traffic merely traversing the router.
The self zone is the only exception to the default deny-all policy. All traffic to any router interface is permitted unless explicitly restricted. To control this traffic, a zone-pair policy must be configured between the self zone and any other zone.
Additional rules when the router is in the traffic path:
ZPF configuration follows five steps:
zone security
class-map type inspect
policy-map type inspect
zone-pair security
zone-member security
Key considerations before configuring:
type inspect
zone-member
Step 1 — Create the Zones
Group interfaces with similar security requirements into the same zone.
Router(config)# zone security zone-name Router(config-sec-zone)# description line-of-description
Step 2 — Define Traffic Classes
Class maps define which traffic to match. Use match-any (default for L3/L4) to match any condition, or match-all to require all conditions. Class maps can be nested for hierarchical policy structures.
match-any
match-all
! Layer 3/4 class map Router(config)# class-map type inspect [match-any | match-all] class-map-name ! Match an ACL Router(config-cmap)# match access-group {access-group | name access-group-name} ! Match a protocol Router(config-cmap)# match protocol protocol-name ! Nest another class map Router(config-cmap)# match class-map class-map-name
Step 3 — Specify Firewall Policies
Policy maps bind traffic classes to actions: pass, inspect, drop, or police.
drop
Router(config)# policy-map type inspect policy-map-name Router(config-pmap)# class type inspect class-name Router(config-pmap-c)# pass | inspect | drop [log] | police ! Apply to all remaining unmatched traffic Router(config-pmap)# class class-default
Step 4 — Apply Firewall Policies to Zone Pairs
A zone pair defines a unidirectional traffic path between a source and destination zone. Attach a policy map to the zone pair to define how that traffic is handled.
Router(config)# zone-pair security zone-pair-name source source-zone-name destination destination-zone-name Router(config-sec-zone-pair)# service-policy type inspect policy-map-name
For deep packet inspection (Layer 7), attach a Layer 7 policy map within the top-level policy map:
Router(config-pmap-c)# service-policy {h323 | http | im | imap | p2p | pop3 | sip | smtp | sunrpc | urlfilter} policy-map-name
Step 5 — Assign Interfaces to Zones
Once an interface is assigned to a zone, all traffic to and from it is dropped by default unless a zone-pair policy explicitly permits it.
Router(config-if)# zone-member security zone-name
A typical two-interface ZPF setup inspects protocols such as HTTP, SMTP, and FTP using a policy map applied to a class map. Two zones (e.g., private and Internet) are created, interfaces are assigned to each, and a zone pair (e.g., priv-to-internet) ties them together with the policy map applied.
SDM Monitoring
In SDM, navigate to Monitor > Firewall Status to view activity per zone pair, including policy name, source zone, and destination zone. Three data collection modes are available:
Use show policy-map type inspect zone-pair session to view active connections in the ZPF state table:
show policy-map type inspect zone-pair session
Router# show policy-map type inspect zone-pair session Zone-pair: CNS-PAIR Service-policy inspect : HTTP-Policy Class-map: HTTP-Class (match-all) Match: access-group 110 Match: protocol http Inspect Established Sessions Session 643BCF88 (10.0.2.12:3364)=>(172.26.26.51:80) http SIS_OPEN Created 00:00:10, Last heard 00:00:00 Bytes sent (initiator:responder) [1268:64324] Session 643BB9C8 (10.0.2.12:3361)=>(172.26.26.51:80) http SIS_OPEN Created 00:00:16, Last heard 00:00:06 Bytes sent (initiator:responder) [2734:38447] Session 643BD240 (10.0.2.12:3362)=>(172.26.26.51:80) http SIS_OPEN Created 00:00:14, Last heard 00:00:07 Bytes sent (initiator:responder) [2219:39813] Session 643BBF38 (10.0.2.12:3363)=>(172.26.26.51:80) http SIS_OPEN Created 00:00:14, Last heard 00:00:06 Bytes sent (initiator:responder) [2106:19895] Class-map: class-default (match-any) Match: any Drop (default action) 58 packets, 2104 bytes
Unmatched traffic falls through to the class-default entry and is dropped — confirmed by the packet and byte counters shown above.
class-default
Firewalls alone cannot provide a complete security solution. Technologies such as network intrusion prevention are also required to close the remaining security gaps in a modern network.
This chapter examined Cisco IOS firewall technologies, focusing on Context-Based Access Control (CBAC) and Zone-Based Policy Firewall (ZPF).
CBAC extends traditional ACL filtering by implementing stateful, application-aware inspection at the Application Layer. It maintains a state table of active sessions and dynamically inserts temporary ACL entries to permit return traffic. CBAC handles TCP, UDP, and other IP protocols differently — tracking sequence numbers and flags for TCP, using idle timers for UDP, and handling protocols like GRE statelessly. It also supports dynamic application inspection for multi-channel protocols such as FTP. Configuration involves selecting interfaces, defining ACLs, creating inspection rules, and applying them to interfaces. CBAC provides alerting and audit trail logging, and includes DoS protection through configurable half-open session thresholds.
ZPF, introduced in Cisco IOS 12.4(6)T, offers a more structured alternative using Cisco Common Classification Policy Language (C3PL). Interfaces are assigned to security zones, and policies are applied to zone pairs rather than individual interfaces. The default interzone policy denies all traffic unless explicitly permitted — the opposite of CBAC's implicit allow model. ZPF supports three traffic actions: inspect, pass, and drop. The system-defined self zone controls traffic to and from the router itself. ZPF is configured in five steps: creating zones, defining class maps, building policy maps, applying policies to zone pairs, and assigning interfaces to zones.
Both technologies can coexist on the same router but cannot be applied to the same interface simultaneously. Troubleshooting both CBAC and ZPF relies on show and debug commands to inspect active sessions, dynamic ACL entries, and real-time firewall activity.