Blog |Follow Nick on Twitter| About

Today's challenge was to get to grips with Cisco's ZBFW, there are a few examples out there if you google but this cisco pdf was the best resource I found.

I'm going to share with you my GNS3 config, my first gotcha was getting the "right" IOS version, the latest advanced sec 12.4 image for the 3725 doesn't cut it, you need to get a copy of c3725-advsecurityk9-mz.124-15.T7.bin.

My plan was simple, I wanted to re-create this following pseudo ASA style configuration:

access-list inside permit icmp any any
access-list inside permit tcp any any eq telnet
access-list outside permit tcp any host eq telnet
access-group inside in interface inside
access-group outside in interface outside

What's funny is that is 5 lines of code for ZBFW it's more than 20! Yes the IOS FW isn't a statefull firewall like the ASA but still more than 4 times the work... anyway, moving on...

The ZBFW is broken into four parts:

  • Assign Zones to Interfaces
  • Create a class-map to define interesting traffic
  • Create a policy-map to give your class an action
  • Create a zone pair to give you class a direction

As you can see in the picture, I have three routers Inside, Outside & Gateway; we will generate traffic from Inside -> Outside (and vice versa) and Gateway will be our firewall. In this blog post I'll discuss the inside -> outside policy, read though the attached config to work out how outside->inside works :)

Creating zones and applying them to interfaces is the easy bit...

zone security inside
 description LAN
zone security outside
 description Internet
interface FastEthernet0/0
 ip address
 zone-member security outside
interface FastEthernet0/1
 ip address
 zone-member security inside

ZBFW supports traffic matching by protocol, ACL or both. To start with I need to create a class map equivalent of:

access-list inside permit icmp any any

So that looks like:

class-map type inspect match-any myinspectclass
 match protocol icmp

Our action to this applied via the policy map will be "inspect" ... not "permit" like the access list, what we want to happen is the echo-request (echo) packet passing from the inside interface to the outside to be inspected so that the echo-reply packet is let back in...

policy-map type inspect myinspectpolicy
 class type inspect myinspectclass

To apply this inside -> outside we create a zone-pair...

zone-pair security in-out source inside destination outside
 service-policy type inspect myinspectpolicy

Part 1 done. breath, take a break.

We can now ping from inside to outside, but outside to inside fails. Part two is to create a separate "flow" to allow telnet out. Now we could update our existing class-map, but it's much clearer to create a new one, first we need an access-list...

ip access-list extended telnet_any
 permit tcp any any eq telnet

This will restrict our TCP protocol inspection to permit only telnet, without this ACL the following class map would permit (inspect) any TCP.

class-map type inspect match-all inspecttelnetclass
 match access-group name telnet_any
 match protocol tcp

Now that we have defined our traffic we can using the existing policy that permits the ICMP traffic through to permit this TCP thru, so this is the new policy map that replaces the one above:

policy-map type inspect myinspectpolicy
 class type inspect myinspectclass
 class type inspect inspecttelnetclass

The policy map will work top down, permitting ICMP traffic thru flow 1 (rule 1) and telnet through flow 2.... we don't need to touch the zone pair :)

Attached is my GNS3 .net file and the three router configs [1,2,3], hopefully it all makes sense :cool:



Nick Bettison ©