The simplest possible design is a protected LAN connected to the public IP network (for example, the Internet) through a firewall. No publicly accessible servers reside in the protected LAN (which means, for example, that the users connected to the LAN have to download their e-mails from somewhere else—for example, from their Yahoo! or Hotmail accounts). Figure 2-1 shows a simple firewall design.

Figure 2-1. Simple LAN-to-Internet firewall

Two firewall policies are commonly used in such setups:

When establishing a restrictive inside-to-outside policy, consider the following caveats:

The simple LAN-to-Internet firewall design successfully addresses the needs of small home offices and small companies (SOHO environment) that do not own e-mail or web servers. If customers want to run their own publicly accessible servers, however, the firewall policies have to be changed to allow incoming sessions (for example, incoming SMTP and HTTP sessions). Because of the many times hackers have successfully exploited publicly accessible servers to penetrate private networks, it’s almost a necessity to put such servers into a separate zone, as described in the next section.

There are two common ways of designing a firewall with a perimeter network (also known as demilitarized zone [DMZ]) containing public servers:

Figure 2-3. Transit perimeter network

As in the preceding section, a firewall with a perimeter network can implement a permissive firewall policy, where the internal users can access any service on the public network, or a more restrictive one, as documented in Table 2-3.

When designing a restrictive firewall policy, you must consider the implementation details of the DNS and e-mail services. DNS service can be implemented in the following ways:

E-mail service can also be implemented in several ways:

The firewall policy just documented is extremely restrictive, allowing only the minimum number of services needed. This results in a secure network (for example, if the perimeter server is compromised, it cannot be used to launch attacks on other networks), but it could also lead to reduced robustness of the network. (For example, if the perimeter server is compromised, the inside clients cannot access the Internet because the DNS services are no longer accessible.)

Some large organizations opt for an even more restraining policy with proxy servers in the perimeter network, thus eliminating any direct traffic between the internal network and the public Internet, as illustrated in Table 2-4.

The transition from the single-device design (Figure 2-2) to the design with a transit perimeter network (Figure 2-3) illustrates one of the advantages of a well-documented zone-based design: Because all the firewall policies have already been documented, they don’t have to be designed from scratch. You merely split the overall firewall policy into two parts: the inner firewall handles policies from inside to everywhere else, and the outer firewall handles policies from outside to everywhere else. In fact, two zones are merged into one on each of the devices (perimeter and outside zones are merged into the perimeter zone on the inner firewall, and perimeter and inside zones are merged into the perimeter zone on the outer firewall), resulting in policies shown in Table 2-5 and Table 2-6 (assuming a transit perimeter network with proxy servers). The merge is extremely simple because the previous firewall policy did not allow any direct traffic between the inside and outside zones.

As we move from simple SOHO designs to more-complex corporate designs, robustness and availability become more and more important. To reach high availability, network designers usually deploy redundant setups in which each critical device is duplicated, resulting in a design similar to the one shown in Figure 2-4.

Figure 2-4. Redundant firewall design

This scenario does not change the firewall policies. All the rules outlined in the preceding section are still valid (yet another benefit of a good design independent of the physical implementation).

Firewalls deployed by large organizations usually contain several zones in addition to the ones discussed in the previous sections. Typical large-scale firewalls include zones to support the following:

Not surprisingly, the firewall policy for such a firewall is substantial, as shown in Table 2-7.

Such a complex firewall is almost always implemented with multiple devices to improve its resiliency and reduce the complexity of each individual device’s configuration. Assuming a two-device nonredundant setup, you could end up with a design similar to the one in Figure 2-5.

Figure 2-5. Complex firewall design

As you saw in the preceding section, firewalls of larger organizations tend to become rather complex. Developing a good overall firewall policy in such cases can be a complicated, tedious, and error-prone task. It’s therefore best to approach the complex firewalls with the millennia-old divide-and-conquer principle. In the example from the preceding section, you could split the problem into three independent smaller firewalls, as shown in Figure 2-6.

Figure 2-6. Decomposed complex firewall

The firewall policy of each individual smaller firewall is significantly less complex than the overall policy because it contains fewer security zones. Furthermore, the designer can now implement different physical setups for each firewall based on its resiliency and availability requirements. For example, under budget restrictions, the e-commerce firewall could be implemented as a redundant transit perimeter firewall design (see the section “ Redundant Firewall Designs” and Figure 2-4 earlier in this chapter), the perimeter firewall could use the nonredundant setup (see the “ Firewall with Public Servers” section), and the VPN firewall could be based on a simple LAN-to-Internet firewall design.

In this chapter, you have seen how you can use zone-based firewall design principles to design a variety of firewall solutions, ranging from simple firewalls suitable to SOHO environments to complex redundant solutions deployed by large organizations. In the next chapters, you’ll find out how you can use the zone-based policy firewall configuration feature of Cisco IOS to translate these designs into actual router configuration commands.