Traffic security – ACL,CBAC,ZBF

Welcome again !

I have a feeling that if I was to skip one of those sections is my Lab preparation then in the exam I would definitely get the one I decided to skip , just my luck 🙂

Recently I have been looking into differences between CBAC and ZBF and various ACLs. All of these security technologies are on the CCIE R&S blueprint so definitely it’s a “must-know” thing. Once again I’ve gathered the most relevant info and put it all together so we do not have to jump from one website to another.

As for the differences between CBAC and ZBF I must say that there are not too many , and the only caveat is that with CBAC considering below topology is that you need to have multiple inspection policies from each interface in order to manipulate the traffic flow and if for instance we get another LAN interface or another DMZ or another ISP interface then knowing that CBAC is configured per interface , it then can quickly become a nightmare to manage where as with ZBF everything is configured per zone.

The whole “traffic security” evolution went from ACL “established” to reflexive ACLs, to CBAC (Context Based Access Controls) and now to ZBF (Zone Based Firewalls).


In order to make it all look like in real life we have:

1: static default route on R2 pointing to the ISP(R3)
ip route

2: we are redistributing this static route into eigrp so that R1 and R4 and stuff that’s behind them know how to reach the internet
router eigrp 124
 redistribute static metric 1 1 1 1 1

Ok let’s begin and the first one is :


CBAC – Context Based Access Controls

We will allow ONLY telnet traffic from within our LAN and DMZ to the internet and nothing else

ACL is applied inbound on the internet facing interface F1/1 as you would normally have configured on your network.

R2(config)#ip access-list extended POLICE
R2(config-ext-nacl)#deny ip any any
R2(config-ext-nacl)#int f 1/1
R2(config-if)#ip access-group POLICE in

R2(config)#ip inspect name CBAC telnet
R2(config)#int f 1/1
R2(config-if)#ip inspect CBAC out



Telnet will now work
R4(config)#do telne
Trying… Open


and for instance ICMP or anything else except for telnet will not
R1(config)#do ping
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 0 percent (0/5)


You can test from either R1 or R4 or from VMs that sit behind them , does not really matter the point is the only telnet traffic gets a “handstamp” as it is send outbound to the internet and therefore on the way back it is allowed back into our LAN. Now what if we need to allow HTTP and HTTPS back to our DMZ from the internet ? Well we CAN NOT apply inspect policy outbound on R2 Fa1/1 without overwriting the existing one for our telnet traffic , so let’s create this policy inbound on R2 f2/0 ?

(Do not forget to enable http and https service on R3 for this otherwise you will not be able to test)
R3(config)#ip http server
R3(config)#ip http secure-server

R2(config)#ip inspect name CBACDMZ http
R2(config)#ip inspect name CBACDMZ https
R2(config-if)#int f 2/0
R2(config-if)#ip inspect CBACDMZ in



Telnet on port 80 and 443 works but we’ve lost our original telnet access that we configured previously !
R4(config)#do telne 80
Trying, 80 … Open

R4(config)#do telne 443
Trying , 443 … Open

R4(config)#do telne
% Connection timed out; remote host not responding

It’ll still work from R1 but not from R4 so to fix we need to add another (the same in this example) policy to allow telnet into CBACDMZ policy

R1(config)#do telne
Trying… Open

R2(config)#ip inspect name CBACDMZ telnet

R4(config)#do telne
Trying… Open


This is exactly what I meant but CBAC being not so easy to manage if your plan is to add more interfaces , zones , subnets to your internet facing router …
Basic CBAC as you can see it’s very easy to configure (certainly you can go much deeper) and from what I’ve seen over the years on Customer’s networks is that network engineers do configure it the easiest way possible cause simple it’s a real pain to manage and troubleshoot , add policies and many more.

It practically only requires two simple steps
1: Create an inspect name policy which tells what traffic to inspect
2: Apply it inbound or outbound on the interface





So now we will do the same, block icmp ,allow telnet from anywhere and allow http/https ONLY from the DMZ cause this is where most likely our web servers will reside

R2(config-cmap)#class-map type inspect match-any ICMP
R2(config-cmap)#match protocol icmp
R2(config)#class-map type inspect match-any TELNET
R2(config-cmap)#match protocol telnet
R2(config-cmap)#class-map type inspect match-any HTTP
R2(config-cmap)#match protocol https
R2(config-cmap)#match protocol http

R2(config)#policy-map type inspect INSIDE_OUT
R2(config-pmap)#class ICMP
R2(config-pmap)#class TELNET
R2(config-pmap)#class HTTP

R2(config)#policy-map type inspect OUTSIDE_IN
R2(config-pmap)#class TELNET
R2(config-pmap-c)#class ICMP
R2(config-pmap)#class HTTP

R2(config)#policy-map type inspect DMZ_OUTSIDE
R2(config-pmap)#class ICMP
R2(config-pmap-c)#class TELNET
R2(config-pmap-c)#class HTTP

R2(config)#zone security INSIDE
R2(config)#zone security OUTSIDE
R2(config)#zone security DMZ

R2(config)#int f 1/0
R2(config-if)#zone-member security INSIDE
R2(config)#int f 1/1
R2(config-if)#zone-member security OUTSIDE
R2(config)#int f 2/0
R2(config-if)#zone-member security DMZ

R2(config-if)#zone-pair security INSIDE_TO_OUT source INSIDE destination OUTSIDE
R2(config-sec-zone-pair)#service-policy type inspect INSIDE_OUT

R2(config-pmap-c)#zone-pair security OUTSIDE_TO_IN source OUTSIDE destination INSIDE
R2(config-sec-zone-pair)#service-policy type inspect OUTSIDE_IN

R2(config)#zone-pair security DMZ_TO_OUTSIDE source DMZ destination OUTSIDE
R2(config-sec-zone-pair)#service-policy type inspect DMZ_OUTSIDE

This accomplishes exactly the same as CBAC above but the best thing about ZBF is that we can now add a bunch of interfaces to any zone, and those policies take effect without you having to add or change anything.

If you’re having trouble remembering the order for the zone creation,  given that you know it must contain class and policy maps then you practically only have to remember these initial letters :

1 –  ZS – Zone security
2 – ZM – Zone Member
3 – ZP – Zone Pair

For some reason these got stuck in my head in this order and not sure why ? It’s like one of those phone numbers or a bank card pin kind of thing.




Another way to do it would be using a reflexive ACL. This is a simplest ACL to configure in my opinion. You can go deep and allow this subnet to reach this servers on this port etc … but I’ve decided to allow literally anything outbound and as the traffic comes back it’ll be able to pass through  in other words LAN and DMZ will be able to reach the internet and receive stuff from it but the internet will not be able to reach anything within the LAN or DMZ
You can of course permit HTTP on the INBOUND ACL so the internet can reach you’re web servers in your DMZ otherwise your customers will not be able to browse your company’s website which is something you may not want 🙂

R2(config)#ip access-list extended OUTBOUND
R2(config-ext-nacl)#permit ip any any reflect TO_REFLECT

R2(config-ext-nacl)#ip access-list extended INBOUND
R2(config-ext-nacl)#evaluate TO_REFLECT

R2(config-ext-nacl)#int f 1/1
R2(config-if)#ip access-group OUTBOUND out
R2(config-if)# ip access-group INBOUND in


Watch out for routing protocols with CBAC and reflexive ACL ! You need to allow it if you don’t want to lose adjacencies and you certainly do not have to do it when using ZBF as there is a ‘self’ zone created which by default allows traffic to and from this zone.





This ACL is commonly used to block all originating traffic from the Internet into a company’s network except for Internet traffic that was first initiated from users inside the company.
This is ONLY applicable to TCP access list entries to match TCP segments in other words you can filter stuff that ONLY relate to TCP (http,telnet,ftp etc) and nothing else. I would say it is useful for DMZ’s but apart from that there’s no much use for it on the network.

R2(config)#ip access-list extended ESTAB_CONNECTION
R2(config-ext-nacl)#permit tcp any any established
R2(config-ext-nacl)#int f 1/1
R2(config-if)#ip access-group ESTAB_CONNECTION in






The best out of all of them is without any doubt ZBF however if you had some budget to spend then instead of the router just simply put an ASA on the network perimeter as the internet facing appliance. This post is simply to get all of us ready for the CCIE R&S Lab Security section.









About ccie4all
Hello, and welcome to the first post of my CCIE blog This blog has got one simple goal and that is to improve our skills in Cisco Networking field so we can become best engineers on a job market. Wordpress Blog information about the changes made to Gns3 BGP , MPLS and R&S CCIE labs. In order to access and download all provided materials and receive important updates from Gns3 BGP , MPLS and R&S CCIE labs under GNS3 tab in the main header please go ahead and subscribe to ! All other posts have not been affected and can be accessed at any given time. Enjoy ! Tom

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: