Firewall Basics with Cisco Zone-Based Firewall

beginner EVE-NG / Cisco IOS routers firewallzbfwnetwork-security

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

LinkNetwork
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.