In this tutorial, we are going to cover the complex task of configuring an IOS firewall with three interfaces by using context-based access control. This tutorial will show us how a zone-based policy firewall, another topic to cover in the future, can be an enhancement and a replacement for CBAC.
CBAC Stateful IOS Firewall with Three interfaces
In our previous CBAC articles, the IOS firewalls configured all had two interfaces facing, respectively, the inside ( or LAN) network and the outside network (Internet). That is because the context-based access control IOS firewall is best suited to routers with two interfaces. The necessary configurations to make a working context-based access control IOS firewall are simple and easy when we have only two areas interconnected by the CBAC router because it is easy to choose among the two which area is most “trusted” and apply CBAC to inspect traffic from that area and automatically (and most of all temporarily) open gates for its return flow. When the number of areas (and therefore the number of interfaces on the CBAC router) increases to three or more, there will be a need to do all the possible area associations, two-by-two, to determine what traffic directions to inspect. Multiple traffic direction inspections make it more complex than only one traffic direction inspection.
Let us take the following topology, for example:
GNS3 LAB : CISCO IOS FIREWALL (STATEFUL) – CBAC – three interfaces – clean slate
Our CBAC router is seated between three areas/networks: the inside network, the DMZ network, and the outside network (Internet).
Basic IP connectivity is configured with static routing and no access-lists applied. Traceroute tests are successful, as shown in the console output below:
The same is true of ping:
Note that this topology could get more complex with additional areas if we choose to further segment our inside network and add to the CBAC router additional segments for STAFF, FACULTY, and STUDENTS networks. Sticking to our topology shown above, we will have to map out properly the kind of traffic that will be traversing our CBAC router. Your mileage may vary but the general rules below will frequently apply to typical and simple networks.
We generally will want to:
- Allow hosts on the inside (LAN) to have access to any host on the outside area (Internet).
-  Allow anyone on the Internet to connect to specific hosts and ports on the DMZ.
-  Allow inside users to connect to specific hosts and ports on the DMZ.
-  Deny any connection from hosts in the DMZ to the LAN.
-  Deny any connection from hosts in the DMZ to the Internet.
 Deny any connection from the Internet to the LAN.
Putting those general rules into our topology transforms it into:
In Part I of this series on context-based access control, we should remember that CBAC configuration involves two steps:
-Inspect the triggering traffic and let the inspection engine dynamically generate temporary Access Control Lists for the corresponding return traffic.
-Deny any other traffic in the return direction.
The simple map above shows us that out of six possible traffic flow directions, our own made rules have canceled three flow directions. These rules are: rule , rule , and rule . These are three traffic flow directions we will not have to configure inspection for. These traffic flows will be left to be denied by the general deny statements that will be applied to the three interfaces on the CBAC router.
As shown by our flow map above, traffic will be allowed to flow in three directions only by rule , rule , and rule .
Let’s start the CBAC configuration for rule  with the access control lists that will prevent uninspected traffic from entering the outside interface of the CBAC router. We will then complete this configuration by configuring the inspect feature to inspect and dynamically create access control lists to allow in return traffic.
The following is the blocking access control list to apply on the outside interface of the CBAC router, in the incoming direction:
The log option will allow us to see the output logs on the console.
Let us apply this blocking access control list on the outside interface of the CBAC router:
Upon this command execution, outside router can no longer traceroute the inside router:
The CBAC router is nice enough to reply with an “!A” message. In this situation, the “!” means we’ve got a reply, and the “A” means Administratively prohibited. Combined, the two mean that CBAC router replied and said this traceroute is administratively prohibited.
So is the DMZ router:
On the inside router, traceroute to outside router fails
because return ICMP replies are blocked:
The same failure happens to ping test
because of the same access control list denying everything
but traceroute to the DMZ area is successful.
Traceroute from DMZ to outside will fail for the same reason as the previous scenario and traceroute to inside will succeed
Let’s create an inspect rule
and apply it to the outside interface of the CBAC router in the outgoing direction.
Now that traffic inspection has been configured and applied to the outside interface in the outgoing direction, ping tests work like a charm
while traceroute is still blocked
mainly because of the traceroute issue
as studied in the earlier subject “CISCO IOS FIREWALL (STATEFUL) – Context-Based Access Control (CBAC) – Part II.”
To fix, this we will just manually open a return path through the blocking access control list for the ICMP replies.
We will edit the blocking access control list to read:
That lets us traceroute successfully from inside to outside because the returning ICMP replies (port unreachable) are not blocked anymore after we edited the blocking access control list:
Note that the telnet from inside to outside is going through successfully because we are already inspecting any TCP traffic so as to allow any return TCP traffic.
The same point is valid for UDP traffic since it is also being inspected and temporary access control lists will be created to allow return UDP flows back in.
So, for now the users in the inside segment can access everything on the outside segment with the traceroute’s ICMP protocol/command.
Therefore we can put a “check” to the rule :Allow hosts on the inside (LAN) to have access to any host on the outside area (Internet).
However, in the process of configuring context-based access control, we have put an access control list that happens to prevent anything originating from outside (Internet) to access the DMZ or inside (LAN).Looking at our topology with our own crafted rules juxtaposed, we see that, on one hand, this would not constitute an issue as such for flows going from outside (Internet) to inside (LAN) since our own crafted rule  prohibits such traffic flow; but, on the other hand, traffic from outside (Internet) to DMZ is desirable and allowed by rule  for critical services like DNS (UDP 53), HTTP (TCP 80), SMTP (TCP 25) that reside in the DMZ zone to be accessed by people outside our company to resolve hosts in our domain, send emails to our mail server and access our website.
We will fix this by poking some holes on the wall of the blocking access control list.
Let’s do so by editing the said Access Control List.
Add a hole for any host on the outside (Internet) to access any port on the host 192.168.0.6.
This is a wide-open hole when we needed to open only for DNS, HTTP, SMTP, and telnet (since the router hasn’t any HTTP, DNS, and SMTP ports open, we will need telnet for demonstration, but beware of telnet security risks because of its clear text transmission, including usernames and passwords. This makes it a no-no in a production network for any worthy administrator).
We will narrow this wide-open hole with the inspect feature, which will inspect and open temporary gates for the configured protocols only: DNS, HTTP, SMTP and telnet.
At the end of the editing, the access control list looks like:
At this point, the traffic is able to go through the CBAC router when and only when it is destined for the DMZ router at 192.168.0.6.
Any attempt to reach a different un-allowed destination will fail
because of the blocking access control list applied on the outside interface of the CBAC router in its incoming direction:
Now that we have re-established connectivity between outside (Internet) and the host 192.168.0.6 in the DMZ area, let us go on and configure the CBAC in two steps:
The following is the blocking access control list to apply on the DMZ interface of the CBAC router in the incoming direction:
Let us apply this blocking access control list on the DMZ interface of the CBAC router:
Upon this command execution, the outside router can no longer traceroute the DMZ router’s IP address 192.168.0.6
due to the new access list control applied on the DMZ interface of the CBAC router in the inbound direction:
The same is bound to happen to ping tests.
Let’s create an inspect rule
and apply it to the outside interface of the CBAC router in the inbound direction:
Inspecting ICMP allows us now to ping from outside to host 192.168.0.6:
However, the traceroute is not yet working until we manually poke a hole on the wall of the blocking access control list CBAC_INTENSE_SCHOOL_DMZ_IN. Remember that traceroute sends requests with TCP and replies comes back in ICMP form. which doesn’t look like a mirror image of the requests because of the difference in the protocols.
Let’s poke the hole like this:
And the whole access control list looks like this:
This allows us to complete successfully the traceroute test:
And, lastly, inspecting allowed us to successfully perform the telnet test from outside to DMZ router:
Once again, the telnet protocol was set up here for demonstration purpose only. In real life, no serious administrator would telnet from outside (Internet) because of the clear text transmission used by telnet. Neither would he/she telnet from the inside segment.
The access control list “CBAC_INTENSE_SCHOOL_DMZ_IN” applied to the DMZ interface to implement CBAC according to rule  is now preventing IP connectivity from inside host(s) to DMZ host(s).\
There is, however, one major difference in the way this access control list is blocking these flows:
CBAC_INTENSE_SCHOOL_DMZ_IN is blocking the return traffic on its way to inside router.
CBAC_INTENSE_SCHOOL_OUTSIDE_IN is blocking traffic from outside to DMZ on its early outbound direction, not in its return traffic
That and the fact that the inside interface of the CBAC router doesn’t have any access control list applied implies that we will have just to add an appropriate IP inspect rule to the DMZ interface of the CBAC router to have return traffic allowed back in.
Let’s go on and create the inspect rule
and apply it to the DMZ interface of the CBAC router.
Ping now works
while the traceroute issue is still lingering.
Which we fix with the right permit statement in the right access control list
and we can now test traceroute.
At the end of the tutorial now, we can pause and reflect on how complex setting CBAC on a three interface router can be. Think now about a router with four interfaces or more. You will need clear planning and a good design so as to keep a clear mind on where you are going, every step of the configuration way.
I hope this tutorial was helpful both to illustrate how complex this is and to complete the right configurations for CBAC. This will prepare you when, in the future, zone-based policy firewall is covered, to understand how ZBPF can be a replacement to CBAC for larger networks.