Admittedly, the zone based firewall is something that I’ve never actually implemented. So this was a little bit ‘learn as I go’ process.
The zone based firewall feature of IOS aims to make using the router as a firewall slightly easier than it had been with the normal IOS access-lists. While there are ton of recommended ways to deploy this firewalling method, I think it’s easier to learn just by showing an example. Let’s take this topology for instance…
(Yes, I made the ‘cloud’ bigger to fill space)
Here we have a user that’s trying to access some content on the server 10.20.30.40. The user is attached to a switch which in turn it attached to a router that has a WAN connection which ,in some way shape or form, provides the user access to the server. To provide some layer of security, we are going to configure router1 as a zone based firewall (ZBF).
Let’s start with the basics. The first step in ZBF is to define the zones. In this example, it’s quite simple. You have a WAN zone and a LAN zone…
Here we can see the LAN zone in blue and the WAN zone in red. Once you have defined the zones, you need to know a few zone rules…
-Zones are defined by interfaces
-Traffic can travel freely between two or more interfaces in the same zone
-Traffic is not allowed (except by policy) to communicate between zones
-Traffic is not allowed between non-defined interfaces (interfaces not part of a zone) and zoned interfaces
So that makes sense so far. Let’s start the config by defining some zones…
We can then look at the zones with the ‘show zone security’ command…
As expected, we see the two zones we created, however we are also seeing one called ‘self’. Per the description we can see that this is a system defined zone, one that the router creates for itself automatically and is for traffic that is headed to ,or coming from, the routers control plane. By default, all traffic is allowed in and out of this zone.
The next step is to define zone pairs. We need some way to tell the router which traffic needs to be firewalled. The easiest way to do this is tell the router the source and the destination zones. This matching of zones together is considered to be a ‘zone pair’. Let’s define two zone pairs, one for each direction of traffic…
Here we created two zone pairs, one (inbound) for the traffic from WAN to LAN and another (outbound) for the traffic from LAN to WAN.
The next task is to define class-maps that can be used to identify the traffic that will traverse the zones. Class maps should sound familiar if you’ve ever worked with a more recent QOS deployment on Cisco gear. Class-maps are what we use to classify certain types of traffic. They can match on multiple different characteristics as we soon shall see. Let’s define a few class maps to use in this example…
The first class-map (red) uses the ‘match-any’ syntax meaning that it only needs to find one match in the list for the class to be considered a match. Here we tell the class to look for either http or DNS protocol traffic.
The second class-map (blue) uses the ‘match-all’ syntax meaning that it will only match the class if all of the match statements are hit. He we are looking for traffic that matches ACL 1 (standard ACL which lists the web server’s IP address) as well as ICMP protocol traffic.
The third class-map (green) is also a match-all. It’s look for traffic matching the ACL that’s also http protocol traffic.
Defining the class-maps is much like defining the rule set you intend to use on a ‘normal’ firewall. I’ve made these three class-maps with the intention of allowing traffic that matches them to flow through the ZBF.
The next step ,as you might have guessed, is to configure policy-maps to define the actions for each class you match on…
In the above output, I do just that. I create two policy-maps which map the classes that I had defined above to a particular action. The three main actions that we need to be aware of are…
Drop – Drops the traffic that matches the class
Pass – Passes the traffic that matches the class
Inspect – Inspect allows the traffic to pass, but also tracks state for the connection. For instance, if you allow http in on your WAN zone with the pass action, you also need to allow it back in the LAN zone zone with the pass action. On the other hand, if you define the WAN inbound action with inspect, that router will allow the return TCP traffic back through the router automagically. We’ll see this in action shortly.
Keep in mind that the policy-map automatically creates a class default class with the action of drop even if you don’t configure one. We can see this by examining the policy-map after applying the above configuration…
Just something to keep in mind as you build the policy-maps.
The configuration we’ve seen so far uses a lot of the QOS like class and policy map configuration with the addition of the ‘type inspect’ syntax. It should be noted that you need to use that for the show commands as well. For instance…
Note how the normal ‘show class-map’ command didn’t give us any output.
The next step is to link the policy-maps to the zones using a zone service-policy (see how much this looks like QOS?). This is done as shown below…
Here you can see us modifying the zone-pairs we created earlier and adding the associated service-policy to each pair. The last step of the process is associate the zones to the interfaces. Note, you can NOT use sub-interfaces for this configuration…
And that’s it! You have successfully configured ZBF! Now let’s take a look and see what traffic is being allowed through the router. To look at the inbound zone-pair, use this command…
As you can see, there’s a wealth of information here. Now let’s look at the outbound zone-pair…
So the real question here is does it work. Can the client browse to a webpage, and can the web server ping the client?…
Yes, and yes! Now let’s examine why. Recall that I talked above about the different actions that can be applied when a class-map is matched. I used the inspect action for all of my classes. If we take a look at the web_server_http class that’s applied as part of the inbound policy, we can see that it isn’t getting any hits…
That’s because the client is initiating the session from zone LAN towards zone WAN. The LAN policy-map is using the inspect action. Let’s change the policy-map action on the outbound zone policy to be pass rather than inspect and see what happens…
As you can see, it wants you to remove the action before you configure a new one. Above I removed the inspect action and changed to the action to pass. Then I tried from the client machine again…
Seems that I can no longer access the web page. Looking at the inbound policy, I still don’t see any hits for inbound http from the web server…
Anyone catch what’s wrong? We aren’t allowing the DNS request through! So as I said, this was a learn as you go blog, but I had planned for this and attempted to fix the problem with this configuration…
This would allow the DNS ‘protocol’ back in as far as I was concerned. As it turned out that didn’t fix the issue. To be frank, I’m still a little confused why it wouldn’t. I’m sure the answer lies in how the router processes the ‘protocol’ match statements but I can’t find any documentation on how it actually does. My testing seems to confirm that the router isn’t matching the return traffic based on the match protocol command which is odd considering that with the ‘inspect’ action this worked just fine. Oh well. The fix I implemented to get the’ ‘pass’ action working looked like this…
Two access-lists looking for the source port on the return traffic. Then I modified the class-maps to check for the access-list match rather than the protocol match…
Once that went in, my web session started working as expected again.
So there you have it, a quick look at the zone based firewall. Unfortunate that we ran into something that didn’t make sense, but that’s the reason I lab this up (And you should too!). I’m hoping I’ll find an answer to the weird protocol match behavior shortly. When I do, I’ll be sure to update this.