Home > Articles > Cisco

Basic Zone-Based Firewall Fundamentals

  • Print
  • + Share This
In order to truly understand the concept of a zone-based firewall and to configure it in such a way that would be the most useful for each specific application, some basic concepts must be considered and understood. In this article, Sean Wilkins focuses on these, basic zone-based firewall fundamental concepts, how to interpret them, and how to use them correctly for each specific application.
Like this article? We recommend

The first thing that must be understood when tasked with implementing a zone-based firewall is that its configuration differs from the traditional firewall (Context-Based Access Control or CBAC) configurations that were used in the past. In previous firewall configurations, each interface was individually configured with a specific firewall policy that worked in combination with an access-list. Traffic was inspected for specifically configured protocols and allowed based on the configuration. One of the main problems that people had with CBAC was that it required a large number of configuration commands to be entered onto each associated interface; this made configuration time consuming, and made minor modifications just as time consuming.

With a zone-based firewall solution, zones are created for each part of the network that required different access/traffic control policies. The most common configuration of these is to have private (inside), public (outside), and DMZ (“demilitarized” or neutral) zones. The private zone is for interfaces which route traffic towards the inside of the organizational network, the public zone is for interfaces with traffic going towards a public network (i.e. Internet) and the DMZ zone (if needed) is for interfaces with traffic going towards a DMZ (i.e. public web and mail servers). When configuring this configuration, interfaces on the router are only able to be part of one zone at a time. Of course, the number of zones is not restricted to this sample configuration.

In order to make sure the concept of zones is clear, the following examples will show some common zone designs. As stated above, the most configurations of zones are using public, private, and DMZ zones. Figure 1 shows an example of this configuration:

Figure 1 Basic Zone Example

Another common example is used when there are multiple administrative areas inside an organization. For example, in a university setting, there are devices which are used primarily for administration and devices which are used primarily for academics. In order to protect the administrative devices from the academic devices, separate zones can be created. An example of this zone configuration is shown in Figure 2:

Figure 2 University Zone Example

Now with a firm understanding of zones, let us look at how these different zones are connected together. When configuring access and policy between zones, zone-pairs are created to link one zone to another. These zone-pairs are unidirectional and are configured with a specific traffic policy that is used when traffic passes from the source zone to destination zone. If traffic must pass between two zones in both directions, then two separate zone-pairs must be configured. The number of different policy options is quite vast and will be covered in later configuration articles.

By default, all traffic which is traveling through the router, from any source or destination zone, is dropped. There are two exceptions to this default rule:

  • When traffic has a source and destination on interfaces in the same zone
  • When traffic is sourced or destined for the router itself

Using the first example from above, a zone-pair can be set up between the private and the public zones. In a situation like this, where in normal circumstances the public zone should never be able to directly contact a device on the private zone, another feature of zone-based firewall configuration can be used. In this situation, the private zone must have access to the public zone but not vice versa; zone-pairs, by default, will permit all return traffic. In this situation, only the configuration of one zone-pair is required; this is shown in Figure 3:

Figure 3 Common Zone-Pair Example

In a situation like shown in Figure 2 above, the configuration of two zone-pairs between the administrative and academic zones may be required if traffic is sourced and destined independently from both sides; this example is shown in Figure 4:

Figure 4 Two-Zone-Pair Example

The other exception to the default drop rule is when traffic is destined for the router itself; normally this is control and management plane traffic. By default, all traffic going to and from the router itself is passed. In order to control the traffic that is allowed directly into or out of the router, the system-defined self zone can be used. Figure 5 shows an example of a zone-pair between the private and self zones.

Figure 5 Self Zone Example

Another new feature is now available with the new IOS version 15.0(1)M (and later) software. Before the release of IOS version 15.0(1)M, all traffic that was sourced and destined on interfaces in the same zone would be passed, by default (as stated above). With the release of IOS version 15.0(1)M, it is now possible to create a zone pair with the source and destination zones being the same, this is called intrazone. When configured in this way, policies can be enabled on all traffic going between interfaces in the same zone. This extends the functionality of the firewall as it allows policy control not only between zones but also within zones themselves; of course the traffic would need to pass between zone interfaces on the firewall itself in order to be effective. An example of this functionality is shown in Figure 6.

Figure 6 Intrazone Zone-Pair Example

The last of the basic fundamentals that must be understood is how a zone-based firewall interacts with existing Access Control List (ACL). As ACLs are not used in the configuration of a zone-based firewall, it is important to note that when they do co-exist on an interface that is also configured as part of a zone, the ACL will always be considered before any of the zone-based firewall policies. The existing ACLs must be configured to allow some traffic through in order for the zone-based policy to be considered.

As the concept of a zone being used for firewall configuration is different from previous firewall alternatives, it is important to understand the basics in order to ensure that the devices requiring security are kept as secure as possible. It is also important for these devices to be able to communicate with required devices without being hindered by firewall policy. The zone-based firewall feature provides another tool to use to help in accomplishing these goals.

  • + Share This
  • 🔖 Save To Your Account