A Cisco zone-based firewall interview question often starts with three commands: class-map, policy-map and service-policy. The short answer is: a class-map selects traffic, a policy-map assigns an action, and a service-policy attaches that policy to a directional zone-pair.[1]
This guide follows one client connection through that hierarchy and shows why defining a policy is not the same as activating it.
What is a zone-based firewall?
Cisco Zone-Based Policy Firewall groups router interfaces into security zones and applies inspection policies to traffic crossing between those zones.[1]
For ordinary transit traffic between different zones, the baseline is deny unless a policy allows it.[1]
A zone-pair identifies the source zone and destination zone; it is not a bidirectional permission simply because both zones appear in its name.[1]
The useful memory aid is select → act → attach, with interface zone membership determining which boundary the traffic crosses.
Class-map vs policy-map vs service-policy
| Object | Question it answers | Example in this article |
|---|---|---|
| Security zone | Which interfaces belong to this security group? | USERS or SERVICES |
| Class-map | Which traffic should match? | TCP from one client to one server port |
| Policy-map | What should happen to matching traffic? | Inspect the selected connection; drop the rest |
| Zone-pair | In which initiation direction is the policy used? | USERS → SERVICES |
| Service-policy | Which policy is attached to this zone-pair? | Attach PM-USERS-SERVICES |
These relationships are the Cisco policy hierarchy; the names in the example are arbitrary, not reserved keywords.[1]
A class-map can select traffic by an ACL, protocol match or nested class-map.[1]
With multiple conditions, match-all requires every condition, while match-any requires only one.[1]
Interview trap: a class-map does not itself permit traffic, and a policy-map left unattached does not establish the intended inter-zone permission.[1]
Inspect vs pass vs drop
| Action | Result | What about return traffic? |
|---|---|---|
| inspect | Stateful handling of supported traffic | Corresponding replies are permitted using session state |
| pass | Forward matching traffic without session tracking | Requires a separate reverse-direction permission |
| drop | Discard matching traffic | Does not establish a return permission |
Cisco documents these three actions and the default drop action of class-default in an inspect-type policy-map.[1]
The difference between a reply and a new reverse connection is critical: inspection allows traffic belonging to the inspected session, not arbitrary connections initiated from the other zone.[1]
Do not describe pass as a simpler spelling of inspect; it lacks the stateful return-path behavior.[1]
Packet flow: client to application server
Consider this fictional, routed lab with no NAT:
Client 192.0.2.10
|
| USERS zone
v
Router running ZBF
|
| SERVICES zone
v
Server 198.51.100.20, TCP port 443
Assume both hosts use the router as their gateway and basic routing already works. The proposed policy permits only that client-to-server TCP service.
- The client sends the initial SYN toward the server.
- The intended ingress and egress interfaces place this new flow across USERS → SERVICES.
- The zone-pair selects the attached policy; the traffic matches the class criteria.
- The
inspectaction tracks the connection. - A valid server reply is handled as return traffic for that inspected session.
- A new, unrelated connection initiated from SERVICES toward USERS has no permission in this example and is denied.
This is a conceptual application of Cisco's zone-pair and inspection behavior, not a hardware packet-processing order diagram or an executed packet capture.[1]
Minimal Cisco-style configuration example
Lab only: this is an illustrative configuration fragment, not an executed router test or a production-ready firewall template. Verify syntax and feature support for your platform and release. Addresses are documentation examples; interface names must be adapted. Routing, interface addressing and host gateways are prerequisites, not configured below.
The object hierarchy and ACL-based classification follow Cisco's documented configuration model.[1]
zone security USERS
zone security SERVICES
!
ip access-list extended ACL-CLIENT-APP
permit tcp host 192.0.2.10 host 198.51.100.20 eq 443
!
class-map type inspect match-all CM-CLIENT-APP
match access-group name ACL-CLIENT-APP
match protocol tcp
!
policy-map type inspect PM-USERS-SERVICES
class type inspect CM-CLIENT-APP
inspect
class class-default
drop log
!
zone-pair security ZP-USERS-SERVICES source USERS destination SERVICES
service-policy type inspect PM-USERS-SERVICES
!
interface GigabitEthernet0/0/0
zone-member security USERS
!
interface GigabitEthernet0/0/1
zone-member security SERVICES
In this design, the ACL narrows the endpoints and service, while the protocol condition selects TCP inspection. The policy does not claim to decrypt or validate HTTPS content; its scope is connection admission and TCP state tracking.
The ACL is used as a classifier, not attached as an interface access-group: permit entries select traffic for the class, and the policy-map supplies the firewall action.[1]
For this proposed lab, unmatched traffic reaches the explicit default drop. Do not generalize that an ACL non-match always means a firewall drop: another policy class may select it in a different configuration.
Change-safety recommendation: prepare and review the complete policy before assigning interfaces to zones, retain console or out-of-band access, and schedule a rollback window. Assigning an interface to a zone can interrupt existing connectivity before the corresponding policies are ready.[1]
Defaults and exceptions worth knowing
- Different zones: ordinary transit traffic is denied without an allowing policy.[1]
- Same zone: traffic between member interfaces is permitted by default in the base model described here.[1]
- Zoned to unzoned: ordinary transit traffic cannot cross this boundary merely because a route exists.[1]
- Router itself: traffic to or from the router belongs to the special self-zone case and is permitted by default in the baseline model unless explicitly restricted.[1]
These are ZBF baseline behaviors, not promises that routing, other ACLs or other security features will allow the packet. A USERS-to-SERVICES transit policy is not a complete router-management security policy. Review self-zone access separately rather than assuming SSH, routing protocols and monitoring are automatically protected.
Troubleshooting checklist
Start with one new test connection and follow the configured objects rather than replacing inspection with a broad permit.
| Check | What to establish |
|---|---|
| Routing and endpoints | Correct gateway, forward route, return route and server listener |
| Zone membership | Actual ingress and egress interfaces belong to the intended zones |
| Zone-pair direction | Source is the initiating client's zone, not the replying server's zone |
| Attachment | The intended service-policy is present under that zone-pair |
| Classification | Addresses, ports and match-all/match-any logic select the intended test |
| Action and state | Matching traffic uses inspect when stateful replies are required |
| Other controls | Interface ACLs, NAT where applicable, and endpoint firewalls are checked separately |
Cisco's policy display commands expose class actions, counters and session information; command availability and output vary by release.[1]
show policy-map type inspect zone-pair
show policy-map type inspect zone-pair ZP-USERS-SERVICES
show policy-map type inspect zone-pair ZP-USERS-SERVICES sessions
Suggested interpretation: if the expected class has no activity during the test, revisit the path and classification. If sessions appear but the application fails, investigate server response, reverse routing and other filters before widening the rule. These are troubleshooting hypotheses, not proof from counters alone.
Do not use a ping as the only acceptance test for this fragment: it deliberately selects TCP to the application port, not ICMP. Test the permitted application and a deliberately forbidden new connection separately. Also assess logging volume before carrying drop log into production.
A concise interview answer
A zone-based firewall assigns interfaces to security zones and controls traffic between them. A class-map identifies traffic, a policy-map applies inspect, pass or drop, and a service-policy attaches the policy to a directional zone-pair.[1]
Inspect tracks supported sessions and allows their replies, whereas pass needs an independent return permission. I verify interface membership, zone-pair direction, policy attachment, matching counters and sessions, and handle self-zone traffic separately.[1]
Related reading
- Stateful vs Stateless Firewall Explained — session tracking and return-traffic fundamentals.
- NAT vs PAT vs Static NAT vs DNAT — address translation terminology and packet flow.
Summary
Remember classify, choose an action, attach the policy, then distinguish a new connection from a reply to an inspected session.[1]
Preparing for a network engineering interview? Draw two zones, explain the initial SYN and return SYN-ACK, then describe what would change if inspect became pass.
Post a Comment