You’ve got to have the Cisco IOS firewall set in the IOS to make use of Context-based Access control (CBAC), and the funny thing is, it’s rare to hear someone even Cisco differentiate between the two. People usually just refer to the Cisco IOS firewall and leave it at that. But what is it? Well, the CBAC’s job is to scrutinize any and all traffic that’s attempting to come through the firewall so it can find out about and control the state information for TCP and UDP sessions. And it uses that very information it’s gathered to determine whether to create a temporary pathway into the firewall’s access lists.
To make this happen, just configure ip inspect lists in the same direction the traffic is flowing. If you don’t do this, any return traffic won’t be able to get back through, which will negatively impact any session connections originating from inside the internal network in a big way.
Take a look at the picture below, which illustrates in a very simple way how the Cisco IOS firewall (CBAC) works.
A router that’s configured with the Cisco IOS firewall will process traffic in the following manner:
- First, if the inside ACL approves, the router will get all inside packets sent to it.
- Next, the approved traffic is subjected to the firewall’s ip to inspect the process, which adds the approved connection’s state information into the state table.
- Finally, the traffic passes through the IP inspect the process, which then creates a dynamic ACL entry and puts it into the outside ACL so that the return traffic will be allowed to pass back through the router.
Authentication Proxy
We have this set on all of my routers, but to be able to do that you must also have the Cisco IOS firewall feature set up. We have the configuration set up this way because the authentication proxy is a good thing to have on your side. This is true because it authenticates inbound users, outbound users, or both. Those who would normally be blocked by an ACL can just bring up a browser to get through the firewall and then authenticate on a TACACA+ or RADIUS server.
Monitoring Access lists
Again, it’s always good to be able to verify a router’s configuration. The following table lists the commands that can be used to verify the configuration.
| Command | Effect |
| Show access-list | Displays all access lists and their parameters configured on the router. This command does not show you which interface the list is set on. |
| Show access-list 110 | Shows only the parameters for the access-list 110. This command does not show you the interface the list is set on. |
| Show ip access-list | Shows only the IP access lists configured on the router. |
| Show ip interface | Shows which interfaces have access lists set. |
| Show running-config | Shows the access lists and which interfaces have access lists set. |
| Show mac access-group | Displays MAC address lists applied to all layer 2 interfaces or the specified layer 2 interfaces (used on layer 2 switches only). |
We’ve already used the show running-config command to verify that a named access-list was in the router as well as a MAC access list on a layer 2 switch. So now let’s take a look at the output from some of the other commands.
The show access-list command will list all access lists on the router, whether they’re applied to an interface or not.
Lab_A#show access-list
Standard IP access list 10
Deny 172.16.40.0, wildcard bits 0.0.0.255
Permit any
Standard IP access list BlockSales
Deny 172.16.40.0, wildcard bits 0.0.0.255
Permit any
Extended IP access list 110
Deny tcp any host 172.16.30.5 eq ftp
Deny tcp any host 172.16.30.5 eq telnet
Permit ip any any
Lab_A#First, notice that both access-list 10 and our named access-list appear on this list. Second, notice that even though we entered actual numbers of TCP ports in access-list 110, the show command gives us the protocol names rather than TCP ports for readability. (hey, not everyone has them all memorized!)
Here’s the output of the show ip interface command:
lab_A#show ip interface e1
Ethernet1 is up, line protocol is up
Internet address is 172.16.30.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is BlockSales
Inbound access list is not set proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is disabled
IP fast switching on the same interface is disabled
IP null turbo vector
IP multicast fast switching is disabled
IP multicast distributed fast switching is disabled
Router discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is disabled
Network address translation is disabled
Web cache redirect is disabled
BGP policy mapping is disabled
Lab_A#Be sure to notice the bold line indicating that the outgoing list on this interface is Block Sales but the inbound access list isn’t set.
As we’ve already mentioned, you can use the show running-config command to see any and all access lists. However, on a layer 2 switch, you can verify your interface configurations with the show mac access-group command.
S1#sh mac access-group
Interface FastEthernet0/1:
Inbound access-list is not set
Outbound access-list is not set
Interface FastEthernet0/2:
Inbound access-list is not set
Outbound access-list is not set
S1#Depending on how many interfaces you set your MAC access lists on, you can use the interface command to view individual interfaces.
S1#sh mac access-group interface f0/6
Interface FastEthernet0/6:
Inbound Outbound access-list is not setaccess-list is Todd_MAC_List