10.5.8 Lab: Configure A Perimeter Firewall

10.5.8Lab: Configure a Perimeter Firewall

In today’s network environments, the perimeter firewall serves as the first line of defense against external threats. This lab walks you through the process of deploying a basic perimeter firewall on a Cisco router using the Zone‑Based Policy Firewall (ZPF) feature. By the end of the exercise you will have created security zones, defined class‑maps and policy‑maps, applied inspection policies, and verified traffic flow between the internal LAN, the DMZ, and the untrusted Internet. The steps below follow the topology shown in the lab manual (R1 as the firewall, Switch‑A for the inside network, Switch‑B for the DMZ, and a cloud representing the ISP).

Lab Overview

The lab assumes you have already completed the basic IP addressing and routing configuration for the three routers (R1‑inside, R1‑DMZ, R1‑outside) and that all devices can ping their directly connected neighbors.

Prerequisites

• Cisco IOS release 15.2(4)M or later (supports ZPF).
• Console access to R1 (the firewall router).
• Basic knowledge of ACLs, NAT, and Cisco IOS command modes.
• Two PC‑like hosts: PC‑Inside (10.1.10.10/24) and PC‑DMZ (172.16.20.10/24).
• A cloud router representing the ISP with a static route to the ISP‑provided address (203.0.113.1/30) on R1’s outside interface.

Step‑by‑Step Configuration

Below is the exact command sequence you will enter on R1. Each block is grouped by logical function; you can copy‑paste the blocks into the console, but be sure to verify the interface names match your topology (e.g., Gig0/0 for inside, Gig0/1 for DMZ, Gig0/2 for outside).

1. Define Security Zones

R1(config-sec-zone)# description Internal LAN zoneR1(config-sec-zone)# exit

R1(config)# zone security outside
R1(config-sec-zone)# description Untrusted Internet zone
R1(config-sec-zone)# exitR1(config)# zone security dmz
R1(config-sec-zone)# description Demilitarized zone for public servers
R1(config-sec-zone)# exit

Tip: Use show zone security to confirm the zones are present before proceeding.

2. Assign Interfaces to Zones

R1(config)# interface GigabitEthernet0/0
R1(config-if)# description Connection to Inside Switch
R1(config-if)# ip address 10.1.10.1 255.255.255.0
R1(config-if)# zone-member security inside
R1(config-if)# no shutdown
R1(config-if)# exit

R1(config)# interface GigabitEthernet0/1
R1(config-if)# description Connection to DMZ Switch
R1(config-if)# ip address 172.16.20.1 255.255.255.0
R1(config-if)# zone-member security dmz
R1(config-if)# no shutdown
R1(config-if)# exit

R1(config)# interface GigabitEthernet0/2
R1(config-if)# description Connection to ISP (Outside)
R1(config-if)# ip address 203.0.113.2 255.255.255.252R1(config-if)# zone-member security outsideR1(config-if)# no shutdown
R1(config-if)# exit

3. Create Class‑Maps

We will define three class‑maps: one for ICMP (to allow ping), one for HTTP/HTTPS (to allow web traffic from the inside to the DMZ and outside), and one for all other traffic (to be inspected by default).

R1(config)# class-map type inspect match-any ICMP-CLASS
R1(config-cmap)# match protocol icmp
R1(config-cmap)# exitR1(config)# class-map type inspect match-any WEB-CLASS
R1(config-cmap)# match protocol http
R1(config-cmap)# match protocol https
R1(config-cmap)# exit

R1(config)# class-map type inspect match-any DEFAULT-CLASS
R1(config-cmap)# match any
R1(config-cmap)# exit

Note: The match any statement catches everything not already matched by the previous class‑maps.

4. Build Policy‑Maps

Now we attach actions to the class‑maps. The policy‑map will inspect ICMP and web traffic, and drop everything else unless explicitly permitted later via an ACL (we’ll add a permissive ACL for return traffic).

R1(config-pmap)# class ICMP-CLASS
R1(config-pmap-c)# inspect
R1(config-pmap-c)# exit

R1(config-pmap)# class WEB-CLASS
R1(config-pmap-c)# inspect
R1(config-pmap-c)# exit

R1(config-pmap)# class class-default
R1(config-pmap-c)# drop   ; optional: you can use 'pass' and rely on ACLsR1(config-pmap-c)# exit
R1(config-pmap)# exit

Repeat the same policy‑map for the other zone pairs (inside‑dmz, dmz‑outside) if you want symmetric inspection. For brevity, we’ll create a single policy and reuse it:

R1(config)# policy-map type inspect INSIDE-DMZ-POLICY
R1(config-p

```text
R1(config-pmap)# class ICMP-CLASS
R1(config-pmap-c)# inspect
R1(config-pmap-c)# exit

R1(config-pmap)# class WEB-CLASS
R1(config-pmap-c)# inspect
R1(config-pmap-c)# exit

R1(config-pmap)# class class-default
R1(config-pmap-c)# drop
R1(config-pmap-c)# exit
R1(config-pmap)# exit

5. Apply Policy-Maps to Zone Pairs

Zone pairs define the directional traffic flow to which a policy-map is applied. We'll create pairs for traffic moving from inside to outside, inside to dmz, and dmz to outside.

R1(config)# zone-pair security INSIDE-TO-OUTSIDE
R1(config-sec-zone-pair)# source inside
R1(config-sec-zone-pair)# destination outside
R1(config-sec-zone-pair)# service-policy type inspect INSIDE-OUTSIDE-POLICY
R1(config-sec-zone-pair)# exit

R1(config)# zone-pair security INSIDE-TO-DMZ
R1(config-sec-zone-pair)# source inside
R1(config-sec-zone-pair)# destination dmz
R1(config-sec-zone-pair)# service-policy type inspect INSIDE-DMZ-POLICY
R1(config-sec-zone-pair)# exit

R1(config)# zone-pair security DMZ-TO-OUTSIDE
R1(config-sec-zone-pair)# source dmz
R1(config-sec-zone-pair)# destination outside
R1(config-sec-zone-pair)# service-policy type inspect INSIDE-DMZ-POLICY
R1(config-sec-zone-pair)# exit

Note: For the DMZ-TO-OUTSIDE pair, we reuse INSIDE-DMZ-POLICY since it has identical inspection rules (ICMP & web). Adjust if different policies are required for server-to-internet traffic.

6. Verification & Testing

1. Confirm zone-pair and policy bindings:

   R1# show zone-pair security
   R1# show policy-map type inspect
   

2. Test connectivity:
   • From an inside host (10.1.10.0/24), ping the router’s outside interface (203.0.113.2) and a public IP (e.g., 8.8.8.8).
   • Access a web server in the DMZ (172.16.20.0/24) and an external website.
   • Attempt an unsolicited connection from outside to inside (should be blocked).
3. Inspect session and statistics:

   R1# show zone-pair security statistics
   R1# show policy-map type inspect interface [interface]
   

Conclusion

By

By implementing a zone-based firewall policy on the router, we establish a robust security framework that enforces granular traffic inspection between network segments. This approach not only prevents unauthorized external access to sensitive internal resources but also isolates the DMZ from both internal and external threats. The combination of class-maps for precise traffic classification, policy-maps for stateful inspection, and zone-pairs for directional control ensures that only legitimate, permitted communication traverses security boundaries.

The reusability of policy-maps (e.g., INSIDE-DMZ-POLICY for multiple zone pairs) simplifies management while maintaining consistency. For environments requiring asymmetrical rules, unique policies can be applied per zone pair. Verification through show commands and real-world testing validates the configuration’s effectiveness, confirming that ICMP pings succeed, web access functions, and unsolicited connections are blocked.

Final Conclusion

Zone-based firewalling transforms a router into a multi-layered security gateway, dynamically inspecting traffic based on source/destination zones and application-layer criteria. This methodology is indispensable for modern networks, balancing security with usability. By systematically defining zones, classifying traffic, applying policies, and rigorously testing, administrators achieve a defensible perimeter that adapts to evolving threats while minimizing administrative overhead. For sustained effectiveness, regularly update inspection signatures and revisit policies to align with new applications or threat landscapes.

Conclusion

By implementing a zone-based firewall policy on the router, we establish a robust security framework that enforces granular traffic inspection between network segments. This approach not only prevents unauthorized external access to sensitive internal resources but also isolates the DMZ from both internal and external threats. The combination of class-maps for precise traffic classification, policy-maps for stateful inspection, and zone-pairs for directional control ensures that only legitimate, permitted communication traverses security boundaries.

The reusability of policy-maps (e.g., INSIDE-DMZ-POLICY for multiple zone pairs) simplifies management while maintaining consistency. For environments requiring asymmetrical rules, unique policies can be applied per zone pair. Verification through show commands and real-world testing validates the configuration’s effectiveness, confirming that ICMP pings succeed, web access functions, and unsolicited connections are blocked.

Final Conclusion

Zone-based firewalling transforms a router into a multi-layered security gateway, dynamically inspecting traffic based on source/destination zones and application-layer criteria. This methodology is indispensable for modern networks, balancing security with usability. By systematically defining zones, classifying traffic, applying policies, and rigorously testing, administrators achieve a defensible perimeter that adapts to evolving threats while minimizing administrative overhead. For sustained effectiveness, regularly update inspection signatures and revisit policies to align with new applications or threat landscapes. Furthermore, consider integrating this zone-based firewall with other security tools like intrusion detection/prevention systems (IDS/IPS) and security information and event management (SIEM) platforms for a comprehensive security posture. Logging and monitoring of firewall events are also crucial for identifying and responding to potential security incidents. Finally, documentation of the zone-based firewall configuration, including the rationale behind policy decisions, is essential for ongoing maintenance and troubleshooting.