Cisco IOS Release 12.3(7)T introduced the transparent firewall feature: the ability to filter IP traffic between a pair of bridged interfaces. This feature is fully supported by the new zone-based configuration commands, making transparent firewall configuration extremely simple. Before configuring this interesting feature (which introduces no additional configuration commands), you have to understand its underlying mechanisms and design rules, which we cover in depth in this chapter. Throughout most of the examples, we focus on a slightly modified version of the firewall with a perimeter network introduced in Chapter 4 “Case Study: Firewall with a Perimeter Network”, (Figure 6-1).
Our organization has built a switched LAN network with all clients and servers residing in one IP subnet. It has successfully implemented the external firewall and wants to increase the security of its internal LAN by isolating servers from the end users and giving only the network administrators privileged access to the servers. Traditionally, to implement this requirement, you would split the network into three subnets (requiring at least partial renumbering of the network) and install a firewall in the middle. In not-so-well-managed LAN environments, where the DNS and DHCP services are intermingled with static IP address and hostnames entered in hosts files, renumbering might not be a viable option.
Note
It’s a bad idea to connect inside and perimeter or outside devices to the same switch because they might end up being directly connected if the switch loses its configuration. However, if your router has a single physical LAN interface, that might be the only solution.
In the new firewall design, the inside clients and servers have been split into two separate VLANs, and the perimeter network is connected to a third VLAN, all three of them being connected to the firewall router with a VLAN trunk. (VLAN configuration on the router is included in Listing 6-1.) The client and the server host are in the same IP subnet, so the traffic between them has to be bridged. The firewall should thus perform interzone checks both on routed and bridged IP traffic.
Example 6-1. VLAN Configuration on the Firewall Router
interface FastEthernet0/0 description Trunk to the LAN switch ! interface FastEthernet0/0.1 encapsulation dot1Q 516 description Client VLAN ! interface FastEthernet0/0.5 encapsulation dot1Q 517 description Server VLAN ! interface FastEthernet0/0.100 encapsulation dot1Q 518 description Perimeter VLAN
The Cisco IOS transparent firewall relies on the integrated routing and bridging (IRB) infrastructure, where a group of bridged ports is treated as a logical IP interface. To configure IRB, perform the following steps:
Enable integrated routing and bridging with the bridge irb command.
Create a bridge group and specify its spanning tree protocol with the bridge number protocol protocol command.
Assign all bridged interfaces into the bridge group with the bridge-group number command.
Configure IP routing for the bridge group with the bridge number route ip command.
Configure a virtual IP interface representing the router’s attachment to the bridge group with the interface bvi number command.
Note
For the remainder of the router configuration, including Network Address Translation (NAT) configuration, see Chapter 4.
Listing 6-2 shows the IRB configuration of the firewall router. After these configuration commands, the router performs two distinct logical functions: It bridges between two interfaces and routes between BVI1, FastEthernet0/0.100, and the serial interface (see Figure 6-2).
Example 6-2. IRB and IP Configuration of the Firewall Router
bridge irb ! interface FastEthernet0/0.1 bridge-group 1 ! interface FastEthernet0/0.5 bridge-group 1 ! interface FastEthernet0/0.100 ip address 192.168.0.1 ip nat inside ! interface BVI1 ip address 10.0.0.1 255.255.255.0 ip nat inside ! bridge 1 protocol ieee bridge 1 route ip
The packets traversing the router thus take one of the following paths:
If the packet arrives through one of the bridged interfaces and the destination MAC address is not the router’s own MAC address, it’s bridged according to the entries in the bridge forwarding database (displayed with the show bridge number command).
If the packet arrives through one of the bridge interfaces with the router’s MAC address as the destination MAC address, it’s routed as if it were received through the BVI interface. The physical interface through which the packet has been received is mostly ignored in the routing process.
If the packet arrives through any other interface and is routed to the BVI interface, the outbound configuration of the BVI interface is applied (for example, the IP access list is checked, NAT translation is performed, and so on), and then the packet is bridged into the bridge group (which might involve flooding the packet if the ARP cache entry is still valid, but the destination MAC address is not available in the bridge forwarding database).
The transparent firewall feature of Cisco IOS can now be applied to the bridged interfaces by assigning them to security zones. For example, you can create two new zones (clients and servers) and assign VLAN 516 to the clients zone and VLAN 517 to the servers zone (Listing 6-3). The BVI1 interface is obviously assigned to the inside zone.
Example 6-3. Zone Assignments of the Inside Physical and Logical Interfaces
zone security Inside zone security Clients zone security Servers ! class-map type inspect match-any Exchange match protocol msrpc match protocol imap match protocol imaps match protocol pop3 match protocol pop3s match protocol smtp match protocol ldap match protocol ldaps ! class-map type inspect match-any Netbios match protocol netbios-ns match protocol netbios-ssn match protocol netbios-dgm ! class-map type inspect match-any SQLServer match protocol ms-sql ! policy-map type inspect ServerTraffic class type inspect SQLServer inspect class type inspect Netbios inspect class type inspect Exchange inspect class class-default drop ! zone-pair security ClientsToServers source Clients destination Servers service-policy type inspect ServerTraffic ! interface FastEthernet0/0.1 zone-member security Clients ! interface FastEthernet0/0.5 zone-member security Servers ! interface BVI1 zone-member security Inside
When defining the interzone policies, you have to define rules for traffic crossing from the clients zone to the servers zone (in our example, we allowed NetBIOS, SQL Server, and Outlook traffic from clients to the server) and vice versa (in our example, no sessions are allowed to be established from the servers toward the clients), but not between clients (or servers) and outside (or perimeter). This is a bit startling at first glance, but not if you consider the switching path a packet takes in the router:
When a packet is bridged between the Fast Ethernet interfaces, it’s considered to be crossing between the clients and servers zones.
When a packet arrives through the bridged interfaces and is routed to another subnet, it’s considered to be arriving through the BVI1 interface (thus from the inside zone).
It looks like a router would be split in two separate firewalls, one operating on the bridged level, and another one on the routed level (see Figure 6-3).
Using the transparent firewall feature in our sample firewall, you can filter the communication between the clients and the servers residing in separate VLANs, but you cannot use the clients and servers zones to limit traffic that these two groups of hosts are allowed to send to or receive from the perimeter or outside zones. If these hosts send the traffic to another routed zone, it appears as if the traffic is coming from the inside zone, so the only way to differentiate between clients and servers when routing IP traffic is to define traffic classes used in the inside zone based on their IP addresses. In our example, we would have to extend the configuration from Chapter 4 by defining new traffic classes covering traffic toward the server or originating from the server and inserting them at the beginning of corresponding policy maps:
Class map AllServerTraffic covers all routed traffic to and from the server. This class is used as a catchall class that drops all sessions that are not explicitly allowed.
Class map MailFromInside covers SMTP traffic from inside server to perimeter server.
There is no need for new classes covering traffic from outside or perimeter zones into the inside zone; no sessions are allowed from outside to inside anyway and the existing configuration of PerimeterToInside policy map (Listing 4-4) already filters traffic based on the server’s IP address.
The new classes are inserted at the beginning of the existing InsideToPerimeter policy map. (See Listing 4-4 for the complete configuration.) The InsideToOutside policy map is also modified to prevent session establishment from the server to the outside zone.
The modified firewall policy is included in Listing 6-4. As you can see, mixing IP hosts with different security requirements in the same security zone (which is obviously against the rules we established in Chapter 2 “Typical Zone-Based Firewall Designs,”, but is necessary because our design requirements and implementation details of the transparent firewall) degrades the concept of security zones to the complexity of building firewalls with IP access lists (most obvious in the InsideToPerimeter policy map).
Example 6-4. Modified Firewall Policy for the Inside-to-Perimeter Zone Pair
class-map type inspect match-all MailFromInside match protocol smtp match access-group name ServerAccess class-map type inspect match-all AllServerTraffic match access-group name ServerAccess ! ip access-list extended ServerAccess permit ip any host 10.0.0.10 permit ip host 10.0.0.10 any ! policy-map type inspect InsideToOutside class type inspect AllServerTraffic drop class type inspect WebTraffic ! defined in Chapter 4 inspect class type inspect FileTransfer inspect ! policy-map type inspect InsideToPerimeter class type inspect MailFromInside inspect class type inspect AllServerTraffic drop class type inspect PublicTraffic ! defined in Chapter 4 inspect class type inspect PublicManagement inspect
The previous discussion of the transparent firewall behavior might have led you to believe that it has only marginal usability for our case study. This is the completely wrong impression; it’s counterintuitive only when used in a combined routed/bridged environment. As an alternative, cleaner design, you could deploy the second physical firewall between the servers and the clients, operating it in bridged-only mode. To illustrate the dilemmas arising in a mixed bridged/routed environment, we will also add the administrators zone (VLAN 515) that has privileged access to the servers (Figure 6-4).
Note
Adding a second firewall in the inside network also slightly increases the security of the solution (defense-in-depth principle); if an intruder gains access to the outside firewall or breaks through its defenses, the internal firewall still protects the servers.
In the modified design, we still have three VLANs (servers, administrators, and clients) in the same IP subnet, so IRB is still needed to connect them. Ideally, both the inside and outside firewall would connect to all relevant VLANs (inside firewall to all three of them, outside firewall to clients and servers). However, with the introduction of the inter-VLAN bridge in the inside firewall, IRB can no longer be used on the outside firewall, because the attachment of two inter-VLAN bridges to the same VLANs would create a bridging loop, and at least one subinterface on the inside or outside firewall would be disabled, resulting in suboptimal traffic flow (Figure 6-5).
The easiest way out of this problem is to give administrators VLAN access to the firewall router through the clients VLAN, resulting in the logical firewall structure in Figure 6-6. (The switch physically connecting end devices to VLANs has been removed from the diagram for clarity.) The outside firewall router can then use the unmodified configuration from Chapter 4, and the inside firewall performs interzone traffic control on bridged traffic between internal VLANs.
Note
When configuring firewall policies, do not forget that the administrators have to pass through the clients zone to get to the Internet.
The inside firewall does not need IP routing at all, so it can be disabled if desired. IRB should be configured to give the device a single IP address reachable through all interfaces. The firewall zones can then be configured and attached to subinterfaces (Listing 6-5). After the initial configuration, you would create traffic classes, define firewall policies, and apply them to zone pairs as explained in the previous chapters.
Example 6-5. Initial Configuration of the Inside Firewall
no ip routing bridge irb ! zone security Administrators zone security Servers zone security Clients ! interface FastEthernet0/0.1 encapsulation dot1Q 516 description Client VLAN bridge-group 1 zone-member security Clients ! interface FastEthernet0/0.1 encapsulation dot1Q 515 description Administrators VLAN bridge-group 1 zone-member security Administrators ! interface FastEthernet0/0.5 encapsulation dot1Q 517 description Server VLAN bridge-group 1 zone-member security Servers ! interface BVI1 ip address 10.0.0.1 255.255.255.0 ! bridge 1 protocol ieee bridge 1 route ip
In this case study, you’ll see how you can use IP routing tricks to work around the limitations of the transparent firewall. Consider the network in Figure 6-7, where the public server is attached to the same LAN as the internal clients. Obviously, this is a large security risk (an intruder gaining access to the public server could immediately explore the internal LAN), so the administrator would like to move the server to the perimeter network. Assuming that IP renumbering is not possible, a transparent firewall would be an ideal solution. However, because of its limitations, it would be impossible to apply a clean three-zone design from Chapter 4 to this scenario.
The best solution in this case study is to use three IP subnets on the firewall as in Chapter 4 and rely on the local area mobility feature introduced in Cisco IOS Release 11.0 to insert a host route toward the public server in the perimeter network (see the Local Area Mobility White Paper and Cisco IOS documentation for more details), as illustrated in Figure 6-8.
Note
You could also use a static route pointing to the perimeter interface (ip route 10.0.0.20 255.255.255.255 FastEthernet0/0.5) rather than local area mobility. Local area mobility might not work on all router platforms.
The local area mobility feature is configured with the ip mobile arp command. Apart from that command, the IP routing configuration of the firewall is similar to the one from Chapter 4 (Listing 6-6).
Example 6-6. Configuration of Inside Interfaces on the Firewall Router
hostname fw ! interface Loopback1 ip address 172.16.10.33 255.255.255.240 ! interface FastEthernet0/0 description Inside network ip address 10.0.0.1 255.255.255.0 ip nat inside ! interface FastEthernet0/0.5 description Public Web server (Perimeter network) encapsulation dot1Q 100 ip address 10.0.1.1 255.255.255.0 ip nat inside ip mobile arp access-group PublicServerAddresses ! interface Serial0/0/0 no ip address encapsulation frame-relay ! interface Serial0/0/0.100 point-to-point description Link to the Internet ip address 192.168.201.6 255.255.255.252 ip nat outside frame-relay interface-dlci 100 ! ip route 0.0.0.0 0.0.0.0 Serial0/0/0.100 ! ip nat pool Internet 172.16.10.38 172.16.10.46 prefix-length 28 ip nat inside source static 10.0.0.20 172.16.10.34 ip nat source list InternalHosts pool Internet ip nat inside source list InternalHosts pool Internet ! ! list all IP addresses of the public servers in the following access-list ! ip access-list standard PublicServerAddresses permit host 10.0.0.20 ! ip access-list standard InternalHosts permit 10.0.0.0 0.0.0.255
After you’ve configured the local area mobility, you can check the proper insertion of the host routes with the show ip route mobile command and debug its operation with debug arp and debug ip mobile local-area (Listing 6-7).
Example 6-7. Debugging and Monitoring Local Area Mobility
fw#debug arp ARP packet debugging is on fw#debug ip mobile local-area IP local-area mobility debugging is on fw# 04:02:45: Local MobileIP: FastEthernet0/0.5 add 10.0.0.20 accepted 04:02:45: IP ARP: rcvd req src 10.0.0.20 0017.5926.3f50, dst 10.0.0.1 FastEthernet0/0.5 04:02:45: Local MobileIP: FastEthernet0/0.5 add 10.0.0.20 accepted 04:02:45: Local MobileIP: route 10.0.0.20 added 04:02:45: IP ARP: sent rep src 10.0.0.1 0017.5926.5c58, dst 10.0.0.20 0017.5926.3f50 FastEthernet0/0.5 fw#show ip route mobile 10.0.0.0 255.0.0.0 is variably subnetted, 3 subnets, 2 masks M 10.0.0.20 255.255.255.255 [3/1] via 10.0.0.20, 00:36:24, FastEthernet0/0.5
After you’ve successfully configured and tested local area mobility, you have a working firewall with three routed interfaces. You can complete the configuration using zones, traffic classes, and policies similar to those in Chapter 4.
In this chapter, you’ve seen how you can configure the Cisco IOS transparent firewall using the zone-based configuration commands. When designing the zone-based transparent firewall, keep in mind these guidelines:
Only a single zone pair is checked for every packet traversing the router.
If a packet is bridged through the router, the router checks the zone pair policy configured between the physical interface zones.
If a packet is routed, the router checks the zone pair policy between the zones of the BVI interface and the outbound IP interface.
If a packet is sent to the router itself, the router checks the zone pair policy between the zone of the BVI interface and the self zone.
Configuring a zone pair between a bridged and a routed zone makes no sense (because it will never be used).
Although you could, do not apply the same zone on bridged and routed interfaces; that will only lead to confusion.