Firewall Basics with Cisco Zone-Based Firewall
Scenario
A branch router connects an internal LAN to the internet. Right now, every interface simply routes traffic with no security policy — any host on either side can reach any host on the other. Your goal is to enforce a real security boundary: internal users can reach the internet, but nothing unsolicited from the internet can reach the internal LAN.
Minimal addressing for this AddySec version
| Link | Network |
|---|---|
| PC1–R1 (LAN) | 192.168.10.0/24 |
| R1–R2 (simulated internet) | 20.20.20.0/30 |
| Server on R2 (simulated internet host) | 20.20.20.2 |
R1 is the router being secured. Its LAN-facing interface will join the INSIDE zone, and its internet-facing interface will join the OUTSIDE zone.
Step 1 — Prove there is no security boundary yet
Before configuring anything, confirm both directions currently work — this is your baseline.
PC1# ping 20.20.20.2
R2# ping 192.168.10.10
Both should succeed. This confirms the router is currently just forwarding traffic with no policy — exactly the problem you are about to fix.
Step 2 — Create the zones
R1(config)# zone security INSIDE
R1(config)# zone security OUTSIDE
R1(config)# interface g0/0
R1(config-if)# zone-member security INSIDE
R1(config)# interface g0/1
R1(config-if)# zone-member security OUTSIDE
Once an interface joins a zone, traffic through it is denied by default until a policy allows it — check this immediately.
Step 3 — Verify the default-deny takes effect
PC1# ping 20.20.20.2
This should now fail. This is expected and correct: assigning interfaces to zones enforces implicit deny between different zones, exactly like the implicit deny in a firewall rule base.
Step 4 — Build the policy to allow INSIDE → OUTSIDE
R1(config)# class-map type inspect match-any INSIDE-TO-OUTSIDE
R1(config-cmap)# match protocol icmp
R1(config-cmap)# match protocol tcp
R1(config)# policy-map type inspect INSIDE-TO-OUTSIDE-POLICY
R1(config-pmap)# class type inspect INSIDE-TO-OUTSIDE
R1(config-pmap-c)# inspect
R1(config)# zone-pair security IN-TO-OUT source INSIDE destination OUTSIDE
R1(config-sec-zone-pair)# service-policy type inspect INSIDE-TO-OUTSIDE-POLICY
Step 5 — Confirm stateful return traffic and blocked unsolicited traffic
PC1# ping 20.20.20.2
This should now succeed — the policy allows INSIDE-to-OUTSIDE traffic, and inspect builds a state entry that automatically permits the returning replies.
R2# ping 192.168.10.10
This should still fail — there is no OUT-TO-IN zone-pair, so unsolicited traffic from the internet has no policy allowing it in. This is the stateful firewall behaviour from Firewall Fundamentals in action.
Break it
Remove the zone-member security INSIDE command from R1’s LAN interface and try the tests again. Notice that once an interface leaves a zone, it is no longer subject to zone policy at all — a common real-world misconfiguration where someone assumes “no zone” means “safe” when it actually means “no inspection.”
Reference
- AddySec original content — written for the Network Security track, building on the ZBFW concept from Zone-Based Firewall.