IOS Context-Based Access Control (CBAC)

By stretch | Tuesday, March 10, 2009 at 12:00 p.m. UTC

Cisco's Context-Based Access Control (CBAC) is a component of the IOS firewall feature set. Similar to reflexive ACLs, CBAC enables dynamic modification of access lists to allow certain incoming flows by first inspecting and recording flows initiated from the protected internal network. However, whereas reflexive ACLs act solely on L2-L4 protocol attributes, CBAC is able to inspect all the way to the application layer, taking into consideration characteristics of a flow on a per-protocol basis (or context).

Rather than over-analyzing CBAC operation in this article, I offer a simple scenario: a router with exactly two interfaces (one internal and one external) placed between two networks, one trusted (internal) and one untrusted (external). Our goal is to configure the router to protect the trusted network (typically a LAN or enterprise network) from the untrusted network (in our example, the Internet).


From the conceptual illustration, we see that there are four logical points (marked in blue) at which the router can inspect traffic:

  1. Inbound on the internal interface
  2. Outbound on the external interface
  3. Inbound on the external interface
  4. Outbound on the internal interface

While we can deploy independent, static ACLs at one, some, or all of these points simultaneously, CBAC is configured and operates per interface, dynamically modifying ACL entries facing one direction based on the traffic it sees flowing in the opposite direction.

For example, let's assume we first want to allow by default all traffic traversing the router from the internal LAN ( toward the Internet (for our purposes, This is already the case, as the router will of course forward all routable traffic when no access restrictions have been applied. We also want to deny by default all traffic flowing from the Internet toward the LAN; to accomplish this we can use a simple ACL to deny all IP traffic. We'll apply it to the external interface in the inbound direction (versus the internal interface outbound) so that the router itself is protected from untrusted traffic as well.

R1(config)# ip access-list extended DENY_ALL
R1(config-ext-nacl)# deny ip any any
R1(config-ext-nacl)# exit
R1(config)# interface f0/0
R1(config-if)# ip access-group DENY_ALL in

Note that an extended ACL is used here; more on that in a bit.


At this point, traffic can flow uninhibited from our trusted network to the untrusted network, but is completely blocked in the opposite direction. Not great if you favor bidirectional communication.

For instance, assume we now want to allow web access initiated from the internal network to return. One option would be to configure a more granular ACL in place of DENY_ALL, but that would not provide stateful tracking and may open a security hole. Another option would be to implement a reflexive ACL, but that would provide only limited state tracking. A more powerful solution is CBAC.

CBAC allows us to define an inspection rule for each protocol we want to monitor. In this case, we want to track HTTP and HTTPS sessions, so we create the following rule named "Web":

R1(config)# ip inspect name Web http
R1(config)# ip inspect name Web https

There are additional options per protocol, but for now we'll accept their defaults. Next we need to apply our inspection rule to an interface and in a particular direction. We apply the rule outbound on the external interface because:

  1. We want to inspect traffic originating from the trusted network, and
  2. We want to dynamically adjust the ACL restricting traffic inbound on the external interface.

This is done with the ip inspect command at interface configuration:

R1(config)# interface f0/0
R1(config-if)# ip inspect Web out


The CBAC configuration can be verified with show ip inspect all:

R1# show ip inspect all
Session audit trail is enabled
Session alert is enabled
one-minute (sampling period) thresholds are [400:500] connections
max-incomplete sessions thresholds are [400:500]
max-incomplete tcp connections per host is 50. Block-time 0 minute.
tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec
tcp idle-time is 3600 sec -- udp idle-time is 30 sec
dns-timeout is 5 sec
Inspection Rule Configuration
 Inspection name WEB
  http alert is on audit-trail is on timeout 3600
  https alert is on audit-trail is on timeout 3600
 Inspection name Web
  http alert is on audit-trail is on timeout 3600
  https alert is on audit-trail is on timeout 3600

Interface Configuration
 Interface FastEthernet0/0
  Inbound inspection rule is not set
  Outgoing inspection rule is Web
  http alert is on audit-trail is on timeout 3600
  https alert is on audit-trail is on timeout 3600
  Inbound access list is DENY_ALL
  Outgoing access list is not set

We've now enabled CBAC in one direction for HTTP and HTTPS traffic on this interface. Outbound traffic (going toward the Internet) is tracked as CBAC sessions, and the DENY_ALL extended ACL restricting inbound traffic is automatically modified to accommodate legitimate return traffic. We can see CBAC in action when a host and the trusted network initiates an HTTP connection to a web server on the Internet:

R1# show ip inspect sessions
Established Sessions
 Session 66E4E40C (>( http SIS_OPEN

From the output of show ip inspect sessions we can see that the trusted host has opened an HTTP connection to CBAC will continue to track this session until it is closed by either end, or the configured idle timer is reached.

When the session was initiated, CBAC automatically created an entry at the top of the DENY_ALL ACL in preparation for the legitimate return traffic.


We can enable audit trails to generate syslog messages for each CBAC session creation and deletion:

R1(config)# ip inspect audit-trail
%FW-6-SESS_AUDIT_TRAIL_START: Start http session: initiator ( --
responder (

Or, for even more verbosity, we can debug CBAC object creation:

R1# debug ip inspect object-creation
INSPECT Object Creations debugging is on
CBAC* OBJ_CREATE: Pak 6621F7A0 sis 66E4E154 initiator_addr ( responder_addr
( initiator_alt_addr ( responder_alt_addr (
CBAC OBJ-CREATE: sid 66E684B0 acl DENY_ALL Prot: tcp
 Src Port [80:80]
 Dst Port [12078:12078]
CBAC OBJ_CREATE: create host entry 66E568DC addr bucket 8 (vrf 0:0) insp_cb 0x66B61C0C

Of course there's far more to CBAC than we've covered here, but hopefully this example provides a decent illustration of the concept.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Security


Eric Phillips, CCIE #23378 (guest)
March 10, 2009 at 3:17 p.m. UTC

Hey Jeremy! Thanks for making this post. I use CBAC at dozens of sites as the Internet perimeter firewall.

A lot of folks ask what the difference is between reflexive access lists and CBAC is. The most important difference is CBAC has application awareness, so it can modify packets for applications that normally do not work with NAT. For example, FTP uses multiple ports, and imbeds the port number into a FTP packet. So with reflexive ACLs you cannot use active FTP through the firewall. However, CBAC will go inside the packet, see the port that needs to be opened, and open it. PPTP does the same with GRE, and H.323 video imbeds the internal IP address inside the H.323 packet, so CBAC needs to go in there and change the IP address.

In short, reflexive ACLs work great for HTTP and most “normal” traffic, but users will not be happy with just reflexive ACLs for a firewall; you need to use CBAC.


Dave Newstat (guest)
March 10, 2009 at 8:31 p.m. UTC

so... if I have site to site VPN connections, and access lists to allow GRE, I could maybe streamline this by using CBAC ?


ip access-list extended Shader_VPN_1 permit gre host xx.xx.xx.xx host yy.yy.yy.yy


Matt Gee (guest)
March 10, 2009 at 9:20 p.m. UTC

Nice one Stretch, pretty cool.

Vineet (guest)
March 11, 2009 at 5:23 a.m. UTC

Hi Jeremy

The example you used to explain CBAC was quite awesome. I am sure no one would ever ask the question "What are CBACs?" again.

Thanks a ton.

Karsten (guest)
March 11, 2009 at 7:58 a.m. UTC

Very good and well explained article. Only one point is not accurate any more. CBAC doesn't modify the ACLs any more. All is taken from the session-table which is evaluated earlier then the ACL. If I remember right, it was 12.2(8)T where Cisco made this change under the name "CBAC performance improvements".

Your visualization is great again. You (and Greg Ferro) are my grafics-heros! :-)

Ben (guest)
March 11, 2009 at 12:26 p.m. UTC

Great article. Now that the mystery of CBAC is solved, I look forward to the sequel on Zone Based Firewalls since that is Cisco's new buzz word. :)

Aaron Conaway (guest)
March 11, 2009 at 4:10 p.m. UTC

Great article as usual, Jeremy.

CBAC works great for network perimeters (read: Internet), but, since you can't share inspection information between routers (or can you?), any dual-headed perimeter may block unexpectedly. I'm thinking of something like 2 routers running BGP to the Internet; you may have a preferred route over router A, but the return path may prefer router B which has no record of the session and drop the packet.

Unknown (guest)
March 11, 2009 at 8:47 p.m. UTC

Zone Base Firewalls Replace CBAC :)

HH (guest)
March 12, 2009 at 10:32 a.m. UTC

Don't get me started about Zone based firewall, one of the most poorly implemented things in recent years by Cisco. Perticularly it's usage with their GUI tools and DHCP...

Gabriele Beltrame (guest)
March 12, 2009 at 12:34 p.m. UTC

While Zone Firewall will eventually replace and supercede CBAC (CBAC will not receive any new features), currently it does not support every feature (like IOS Firewall Failover, etc.)...

Dinger (guest)
March 12, 2009 at 1:04 p.m. UTC

Articles like this are the reason I hit up this site every morning; clear, concise, well-documented explanations of a non-basic networking concept.

Karsten (guest)
March 12, 2009 at 8:10 p.m. UTC

I have to correct my comment: It was 12.3(4)T and the feature is named "Firewall ACL Bypass".

@Aaron: There is SSO-Support for CBAC. But that's probably not exactly what you are looking for: IOS Firewall Stateful Failover

Neil (guest)
March 14, 2009 at 12:09 p.m. UTC

Hi Stretch, That was faboulous and I realy liked it like always. My quesiton could be a little out of the topic but believe it's really because of the sheer love for this website. The sidebar seems to be overflowing the sidebar content towards the ( i guess the width of the reight sidebar is something to do with. Can you just fix that, though I tried my best not to write about it , but I have been enjoying packetlife for the content and sometime's for the great simplistic design you have here and that overflowing sidebar just seems to bug me a lot. He he ( Cheers ! ) and thanks as always. 0_o

CPU (guest)
March 15, 2009 at 5:51 p.m. UTC

Thank's Jeremy!!!! Good stuff!

VSaltao (guest)
March 16, 2009 at 2:47 p.m. UTC

As always a very nice article.

Christian F. (guest)
March 16, 2009 at 8:16 p.m. UTC

Very nice.
Thank´s for the article!!! Very good.

Anuj (guest)
March 27, 2009 at 3:44 p.m. UTC

Nice work, have been reading your blog for quiet some time. It is really good.

Guru Guy (guest)
April 1, 2009 at 4:38 p.m. UTC

Very nice, Simply delicious article.

Totie (guest)
August 11, 2009 at 8:18 p.m. UTC

Nicely documented. I used CBAC on my network and just like the other users here, I started looking at Zone base firewall. It looks intimidating to setup on CLI but I think I can manage it. My question for the users in these forum is regarding VOIP. As some of us are aware, VOIP protocols like H.323 requires you to open up tons of tcp and udp ports in which I am not confortable of of opening these huge holes on my network.. Would zone base firewall help me with this issue? I have looked at CBAC briefly and as far as I can tell CBAC will not be able to help. I believe an ASA can do these but I am curious to know if I can achieve this using zonebase firewall since I am comfortable with my ISR routers. thanks

Rajeev Singh (guest)
August 28, 2009 at 7:50 a.m. UTC

Great Article ....

Fatman (guest)
November 3, 2009 at 11:23 p.m. UTC

You helped me secure my router. Thanks!

Under the circumstances, I don't think I'll add my URL. ;)

Anon (guest)
February 24, 2010 at 11:48 p.m. UTC


R1(config-ext-nacl)# deny ip any any

Not trying to be an as* but this is not necessary because an acl has an identical implicit deny at the end :) Anyway good job with this site.

February 24, 2010 at 11:51 p.m. UTC

@Anon: The ACE is added explicitly in the example for clarity.

Roav (guest)
February 26, 2010 at 12:59 a.m. UTC

Thanks for such clear and understandable material. This is quite good and it did help me understand this technology. thanks for taking the time to do this.

ash (guest)
March 18, 2011 at 2:13 p.m. UTC

great..u make my life easier :)

a guest (guest)
April 1, 2011 at 8:54 a.m. UTC

That was just.. great ;)

Captn Panic (guest)
April 29, 2011 at 8:45 p.m. UTC

Hi Jeremy ,

Thanks for article -- got me some way along with trying to figure this out.
My situation is a bit more complex. ( OK for a dumbass )
I have one dynamic IP and using NAT with PAT ( and two Vlans )
Trying to set up FTP ( Active and PASV ) in this situation with CBAC ( not sure if it can be done , I find so much info that seems to be contradictory ? )
I can get it all working with a normal ACL but CBAC FTP breaks it ?
Going around in circles at the moment.

Inigma Turner (guest)
July 25, 2011 at 3:42 p.m. UTC

Thank you for the info. I've been searching the internet for a few hours to discover the low down on the configuration of the firewall relating to the use of access-lists and the IP inspect rules that allow return traffic. I am now confident that I can protect my inside hosts.
Your diagrams are, as Mr. Lammle would say, cool.
I don't want to thank you as many times as Rupert has apologised, but until next time - Thanks

Gregorio (guest)
March 10, 2012 at 4:02 p.m. UTC

The best CBAC explanation I found. Very helpful for me

Vlandatabase (guest)
March 30, 2012 at 4:16 a.m. UTC

Thanks for the share J! Can we apply it to f0/1 instead f0/0?

Wingnut (guest)
May 24, 2012 at 8:45 p.m. UTC

Someone told me that CBAC is not supported on certain devices like switches. I don't have a lab right now to try it on. Does anyone if this is true or false? I would think anything running K9 code would be fair game to run CBAC but I'm looking for a definitive word. Google didn't give me a strong answer either way.

mikull (guest)
September 11, 2012 at 12:19 p.m. UTC


it will look something like this on the inside interface

 ip access-group 123 out
 ip inspect TRUSTED in
 duplex auto
 speed auto

Vinod (guest)
September 20, 2012 at 6:22 a.m. UTC

Best CBAC explanation I ever read. Very helpful for Beginners especially

kk (guest)
December 2, 2012 at 6:34 a.m. UTC

I have a doubt which i need clarification on :

  1. When said that CBAC is able to inspect all the way to the application layer, is this inspection a default feature of CBAC or is it turned on when we specify the (IP INSPECT name IN/OUT) command under the interface.

  2. Also if it is turned based on the IP INSPECT command, then is the application layer reading for that protocol also done in the direction only mentioned in the IP INSPECT command or is it a completely different matter.

Would highly appreciate any help here.

syed (guest)
September 16, 2013 at 9:19 a.m. UTC

Thank you so much for this article, great work.

flawless explanation.

CiscoBeginner (guest)
May 16, 2014 at 3:26 p.m. UTC

Thank you for this explanation, it has helped me a lot.

Ian Arakel (guest)
June 27, 2016 at 10:06 a.m. UTC

Thankyou very much

Comments have closed for this article due to its age.