Chapter 21: Transparent Firewall

This chapter will introduce you to the transparent firewall feature of the security appliances, which allows the appliances to behave similarly to layer 2 switches with firewall capabilities. The topics include

• Processing of layer 2 traffic versus layer 3 traffic

• Configuring transparent mode on the appliances

• Implementing advanced layer 2 features on the appliances

Layer 2 Processing of Traffic

If you have your Cisco Certified Network Associate (CCNA), then the Open Systems Interconnect (OSI) Reference Model is nothing new to you. The OSI Reference Model was primarily designed as a teaching aid to help people understand how computers create, transmit, and receive data. The appliances deal with all seven layers of the OSI Reference Model. Obviously they have to deal with the two bottom layers—physical and data link—in order to accept frames on an interface. And up through version 6 of the OS, the appliances had to route traffic, so they had to deal with layer 3. With application inspection of many traffic types, the appliances can deal with all seven layers.

In version 6.0 and earlier, as I mentioned, the appliances would not process traffic on an interface unless you assigned an IP address to them. So basically the appliance was acting as a routing device: traffic would come in an interface, the appliance would compare the destination IP address to its routing table, find the corresponding destination network and the interface to exit from, apply the policies to the packet, and the appliance would forward the packet out the exit interface. Without IP addressing on the appliance, traffic wouldn’t flow through it.

Routed vs. Transparent Mode

Starting in version 7 of the OS, the appliances support two modes of operation: routed and transparent. In routed mode, the appliance acts as a layer 3 device and forwards packets based on destination IP addresses. In transparent mode, the appliance acts as a layer 2 device, like a bridge or switch, and forwards Ethernet frames based on destination MAC addresses.

Figure 21-1 compares the two modes. Let’s examine the routed mode example shown on the left side first. The two interfaces, whether they’re physical or logical (trunked with VLANs), must be in separate VLANs (broadcast domains). Since routed mode is used and the appliance must see these as two distinct networks, two subnets are used for the layer 3 addressing. The appliance then forwards frames based on the IP addresses it sees inside the IP packet headers.

Figure 21-1: Routed and transparent mode comparison

The right side of Figure 21-1 shows an example of transparent mode. Notice that the two interfaces involved in the layer 2 process are in separate VLANs (broadcast domains), but they are in the same layer 3 subnet (10.0.1.0). When in transparent mode, the appliance behaves more like a layer 2 switch or bridge, where it switches frames between interfaces based on the MAC addresses in the Ethernet frame headers. As you will see later in the chapter, the appliances still have the capability of filtering traffic based on information in the layer 3 and layer 4 headers as well as the application layer (layer 7) payload.

One interesting point about the transparent mode process on the right side of Figure 21-1 is that the process is kind of strange when you examine it from a layer 2 device perspective. In a layer 2 network of switches, devices in the same subnet are in the same broadcast domain, and thus are in the same VLAN. So why would Cisco require you to put devices in the same subnet into different VLANs or broadcast domains?

Let’s examine Figure 21-2 to understand why Cisco makes this requirement. Cisco assumes that all the devices that need to communicate with each other are connected to the same switch. If you were to put all the devices in the same VLAN on the switch, then the appliance couldn’t control traffic between the devices, like the users and the default gateway, since the switch would allow devices in the same VLAN to communicate with each other. By placing the devices in separate VLANs, like 10 and 20 in the example shown in Figure 21-2, you are forcing the traffic to go through the appliance, where you can apply policies to the traffic.

Figure 21-2: Transparent mode, broadcast domains, and VLANs

Note

If the two interfaces of the appliance are connected to two different switches and the switches are not directly connected together, then you can use the same VLAN number for the interfaces of the appliance between the two switches.

Bridges vs. Transparent Mode

One thing to keep in mind about transparent mode is that even though an appliance is operating at layer 2, it does not behave exactly the same way as layer 2 switches or bridges. Yes, they are both operating at layer 2, but there are quite a few differences between how a switch and an appliance will handle traffic.

Let’s examine some of the things that switches and appliances have in common as well as some of their differences. Switches perform three primary functions:

• Learn what MAC addresses are associated with which interfaces, and store them in a local MAC address table (sometimes called a CAM table).

• Intelligently forward traffic using the MAC address table, but flood unknown destination unicast addresses, multicast addresses, and broadcast addresses.

• Use the Spanning Tree Protocol (STP) to break up layer 2 loops to ensure that only one active path exists between a source and destination.

Like switches, appliances when configured for transparent mode will perform the first bullet point: when a frame comes into an interface, the appliance compares the source MAC address in the frame and adds it to the MAC address table if it isn’t already there.

The appliance will also use the MAC address table to intelligently forward frames based on the destination MAC addresses in the frame headers; however, the appliance will not flood destination unicast addresses that are not found in the MAC address table. The appliance will flood broadcasts and multicasts. The appliance assumes that if the devices are using TCP/IP, they’ll go through the ARP process to discover destination MAC addresses that are associated with layer 3 IP addresses; through this discovery process the appliance will learn the respective source MAC addresses and the interfaces they are associated with. Therefore, if a device breaks away from this expectation and uses a hard-coded MAC address that the appliance hasn’t learned (either dynamically or statically), the appliance will drop the unknown destination MAC address.

The second deviation from layer 2 devices is that the appliances do not participate in STP. Thus it is very important that you ensure you don’t inadvertently create any layer 2 loops when setting up transparent mode. If you create a loop, you’ll quickly figure this out when the CPU utilization on the appliance and switches jumps up to 100 percent.

Note

In the example in Figure 21-2, I would recommend that you filter BPDUs (Bridge Protocol Data Units) on the two switch interfaces connected to the appliance, or disable STP completely on these two interfaces, to alleviate any confusion the switch might have about seeing its own BPDUs on different interfaces. Again, just make sure you aren’t creating any layer 2 loops when using transparent mode.

The third deviation from switches is that while switches process traffic at layers 1 and 2, the appliances can process traffic from layers 1 through 7! When an appliance is configured to operate in transparent mode, it will forward traffic based on layer 2 information, just like a switch; however, it can filter traffic on information at layers 2 through 7. Traffic filtering can be accomplished with Ether-Type ACLs, IP ACLs, and even application-specific policies created with Modular Policy Framework (MPF).

Supported and Unsupported Features

Certain features will be unavailable to you when the appliance is running in transparent mode. Here’s a list of unsupported features:

• Only two interfaces (physical or VLAN) can be used; you can get around this issue by using contexts, which are discussed in the next chapter. (With contexts, each context can use two interfaces if it is configured in transparent mode.)

• You cannot terminate VPNs like IPSec and WebVPN on the appliance.

• CDP (Cisco Discovery Protocol) and IPv6 packets are dropped.

• Ethernet frames that don’t have a valid Ether-Type greater than or equal to 0x600 are dropped; however, you can make exceptions for STP BPDUs and certain non-IP protocols.

• Through version 7, address translation was unsupported; in version 8, it is optional.

• Quality of Service (QoS) with low-latency queuing (LLQ) is unsupported as a policy.

• The appliance cannot act as a DHCP relay. (This isn’t necessary since DHCP requests, which are broadcasts, are transmitted between interfaces.)

• You cannot configure multicast commands. (Again, this isn’t necessary since multicast traffic is flooded between the two interfaces in transparent mode.)

• Routing is unsupported—the appliance is operating at layer 2!

Given the list of restrictions, transparent mode does provide some distinct advantages when running in transparent, versus routed, mode. First, you can easily insert an appliance in an existing segment and control traffic between the two sides without having to re-address or reconfigure the devices! Examine Figure 21-3 as an example. This figure shows a typical campus network design—the access layer connects the user devices; the distribution layer provides layer 3 separation from the rest of the network as well as other services, like security and QoS; and the core connects the various distribution layers and the campus data center. For the access layer devices, their default gateway is the layer 3 switch IP addresses, or more than likely a virtual address from HSRP (Hot Standby Router Protocol) or VRRP (Virtual Router Redundancy Protocol). You could easily place transparent mode appliances in this design without having to change any addressing on the devices at the access or distribution layers: when Cisco uses the term “transparent,” they mean it! If you put the appliances in as routed devices, you’d probably have to configure DHCP relay (see Chapter 26) to forward DHCP requests to the distribution layer; you’d have to change the default gateway address on the user devices to point to the security appliances; you’d have to create a separate subnet between the appliances and the distribution layer 3 switches; and you’d have to configure routing on the appliances.

Figure 21-3: Common use for transparent mode

Note

In the design in Figure 21-3, if the distribution devices are layer 3 switches like the Catalyst 6500s, another option would be to purchase the Firewall Services Module (FWSM), which is basically a modular card running software similar to that of the PIXs and ASAs.

A second advantage of using transparent mode is that non-IP traffic can be allowed between interfaces. By default non-IP traffic is denied, like AppleTalk, IPX, STP BPDUs, and MPLS (Multiprotocol Label Switching). This traffic can be configured to go through the appliance by using an Ether-Type ACL.

A third advantage of transparent mode is that many, many features that work in routed mode also are supported in transparent mode, like address translation (in version 8), stateful filtering, standard and extended ACLs, CTP, web content filtering, MPF, and many, many others.

Traffic Flow and ACLs

Cisco still uses security levels to control traffic between interfaces when an appliance is running in transparent mode, where the same rules apply:

• Outbound connections are allowed by default unless restricted.

• Inbound connections are denied by default unless allowed.

The exception to these rules is ARP packets, which are always allowed by default since ARP is used as a discovery process to learn the MAC addresses of devices. You can restrict ARP packets, however, but this is optional.

When an appliance is at the perimeter of your network, the outside is the Internet (the non-trusted devices), and the inside is your corporate network (the trusted devices). When you are using an appliance inside your network, like that shown in Figure 21-3, the outside of your network would be the user devices at the access layer, and the inside of your network the distribution and core layers. Given this design, all traffic originated by your users would be denied by default unless you configured ACL entries to allow traffic. This creates more work on your part, but you can be much more specific about what is and isn’t allowed.

Tip

A more scalable approach in this situation would be to use Cut-through Proxy (CTP) with downloadable ACLs. You’d create downloadable ACLs on a per-group basis on an AAA server, and once users authenticated, the ACL would be downloaded and used. This approach is more scalable and flexible because all your filtering policies are centralized in one location, making it easier to change policies.

Configuring Transparent Mode

When an appliance boots up, Cisco assumes you’re running it in routed mode. Of course, when you run the setup script (see Chapter 3), that’s the first question the script asks, where the answer defaults to routed mode. Changing it to transparent mode is a very simple process, as you’ll see in the next section.

Note

When setting up transparent mode, only two interfaces, physical and/or VLAN, can be used. The devices on the two sides must be in different broadcast domains, like VLANs, but they must be in the same subnet. You can get around the two-interface limit with transparent mode: set up contexts, which are discussed in Chapter 22. A context is basically a virtual firewall. You could have some contexts in transparent mode and some in routed mode, where the contexts in transparent mode support two interfaces each.

Switching to Transparent Mode

If your appliance is currently running in routed mode, you can very easily switch it to transparent mode with the following command:

myappliance(config)# firewall transparent
ciscoasa(config)#

Because many features in routed mode are unsupported in transparent mode, the configuration on the appliance is cleared. To revert back to routed mode, use the no firewall transparent command.

Security Alert!

When switching from routed to transparent mode, you are not prompted to continue the process—the appliance immediately executes the command, your configuration is erased, and you’re in transparent mode. So if you want to try transparent mode on an appliance with a routed mode configuration, first back up the configuration before trying it! (You would think, given that the appliance is doing something this drastic, the appliance would first display a note to you about the ramifications of executing the command and then would give you the option to abort it.)

Once you’ve converted the mode to transparent (or routed, for that matter), you can verify the mode with the show firewall command, like this:

ciscoasa(config)# show firewall
Firewall mode: Transparent

Management IP Address

You can assign an IP address to the appliance for management purposes. This IP address has to be from the subnet the two interfaces are connected to. For example, if you reexamine the right side of Figure 21-1, the management address would have to be an unused address from 10.0.1.0.

When you’re assigning a management IP address to the appliance, the address must be from the subnet connected to the two interfaces on the appliance. Here’s the command to configure the management address:

ciscoasa(config)# ip address IP_address [subnet_mask]
                      [standby IP_address]

Notice that the ip address command is a global command—you are not in an interface when configuring it. The standby parameter assigns a management IP address to the standby unit in a failover configuration (failover is discussed in Chapter 23). Use the show ip address command to verify your management IP address configuration.

Note

The assignment of a management address is optional. Also the management address is just that: a management address. For devices in the subnet, do not point them to this address as a default gateway. Remember that the appliance is in transparent mode, acting as a layer 2 device: it is not acting as a router.

MAC Address Table and Learning

As I mentioned in the “Bridges vs. Transparent Mode” section, the appliances will build a MAC address table of source MAC addresses associated with an interface. You can view the MAC address table with the show mac-address-table command:

ciscoasa# show mac-address-table  [logical_if_name | count | static]

Without any parameters, all the MAC addresses in the table are shown. You can limit the display to MAC addresses associated with a particular interface, to a count of the total addresses in the table, or to listing just the statically defined entries.

Here’s an example of this command:

ciscoasa# show mac-address-table
Interface   Mac Address     Type     Time Left
----------------------------------------------
outside     0009.7cbe.2101 static     -
inside      0010.7cbe.6102 static     -
inside      0009.7cbe.5103 dynamic    10

Notice that the first two entries have been statically defined (discussed later in this section) and the last dynamically learned.

Dynamically learned MAC addresses will be aged out of the table if they are idle for 5 minutes by default. This timer can be changed with the mac-address-table aging-time command.

ciscoasa(config)# mac-address-table aging-time minutes

If you want to hard-code a MAC address association for a logical interface, use the mac-address-table static command:

ciscoasa(config)# mac-address-table static logical_if_name mac_address

This is sometimes done to prevent MAC address spoofing of critical services like a default gateway or DHCP server. You can even completely disable MAC address learning on an interface with this command:

ciscoasa(config)# mac-learn logical_if_name disable

If you disable learning, then you must configure the necessary MAC address static entries for the interface, or only broadcasts and multicasts will be allowed on the interface.

And if you’re having problems with the MAC address learning function or the static entries you built on the appliance, you can use the debug mac-address-table command to troubleshoot the problems.

Additional Layer 2 Features

This section will discuss the configuration of a couple of enhanced layer 2 features of transparent mode: Ether-Type ACLs and ARP inspection.

Non-IP Traffic and Ether-Type ACLs

When you’re operating in routed mode, the only way to get non-IP traffic to flow through the appliance is to encapsulate it in GRE and tunnel it through the appliance using this layer 3 TCP/IP protocol. The appliances do not handle non-IP traffic natively—this must be handled by a different device (typically a router). The problem with a different device handling the traffic is that it isn’t very efficient: you’re adding overhead to the process and introducing delay by having to encapsulate and de-encapsulate every packet.

If you’re concerned about this process, you can run your appliance in transparent mode instead. Unlike TCP/IP unicast traffic, which uses security levels to determine whether a connection is allowed, all non-IP traffic is denied by default when running in transparent mode. To allow non-IP traffic, you must create an Ether-Type ACL (or ACLs) and apply it to each interface you want to allow the non-IP traffic on.

The syntax for creating an Ether-Type ACL is as follows:

ciscoasa(config)# access-list ACL_ID ethertype {deny | permit}
                      {ipx | bpdu | mpls-unicast | mpls-multicast |
                      any | hex_#_of_protocol} [log]

Notice that the ethertype parameter specifies that this is not an IP ACL. Following the permit or deny parameter, you specify the protocol that will be matched on. Optionally you can specify a hexadecimal number greater than or equal to 0x600 for the protocol (currently you cannot filter on actual MAC addresses in the Ethernet frame header). For example, TCP/IP uses a protocol number of 0x0800 and AppleTalk uses 0x809b.

Once you have created your Ether-Type ACL, you need to apply it to an interface with the access-group command, which was discussed in Chapter 5:

ciscoasa(config)# access-group ACL_ID in interface logical_if_name

Tip

Remember that when allowing non-IP traffic, you’ll need to apply an ACL (or ACLs) to both interfaces in order to allow traffic in both directions.

ARP Inspection

By default all ARP packets are allowed through the appliance. The source generates a broadcast ARP query to learn the IP-to-MAC address association of the destination. And since the appliance is learning the source MAC address of the requester, when the destination replies with an ARP unicast response, this is allowed (the source MAC address is in the ARP table), given that the destination MAC address is found in the MAC address table and the packet is an ARP reply.

The problem with the ARP protocol, however, is that it is very easy for an attacker to spoof responses or to generate a gratuitous ARP announcement with incorrect IP-to-MAC address information or by matching the attacker’s MAC address with someone else’s IP address. To somewhat limit the effectiveness of ARP spoofing, Cisco supports an ARP inspection feature on the appliances when they are running in transparent mode. The ARP inspection feature looks for mismatches between the IP address, MAC address, and the associated interface for ARP replies. If the appliance sees the wrong combination of IP-to-MAC address matching in an ARP reply, or sees an ARP reply with a source of an incorrect interface, the appliance will drop the packet. Of course the appliance has to know what the correct address matchings are; the appliance can either learn this dynamically by examining the ARP replies on its interfaces, or you can define them statically. The following sections will discuss how to configure and verify ARP inspection.

ARP Inspection Configuration

By default the ARP inspection feature is disabled, which means that when the appliance sees an ARP query, it is flooded out the opposite interface. Enabling ARP inspection is done with the arp-inspection command:

ciscoasa(config)# arp-inspection logical_if_name enable
                      [flood | no-flood]

ARP inspection is enabled on an interface-by-interface basis. The flood parameter, which is the default if omitted, will flood all ARPs received on the interface. The no-flood parameter will not forward an ARP reply if it doesn’t match a specific static ARP entry on the appliance. Therefore, when using the no-flood parameter, you’ll need to create static entries for the associated interface with the arp command:

ciscoasa(config)# arp logical_if_name IP_address MAC_address

If you don’t configure this command and ARP flooding is disabled, devices will be unable to communicate with each other via IP across the associated interface.

ARP Inspection Verification

To see the status of ARP inspection and your configuration, use the show arp-inspection command. Here’s an example:

ciscoasa# show arp-inspection
interface arp-inspection miss
-------------------------------------------------
inside enabled flood
outside disabled

Once you have enabled ARP inspection, to examine the local ARP table on the appliance, use the show arp command. Here’s an example:

ciscoasa# show arp
inside 10.0.1.11 0008.023b.1234
inside 10.0.1.12 0001.023a.abcd

If you are having issues with the ARP inspection feature, or feel that the appliance might be dropping ARP requests and replies that it shouldn’t, you can use the debug arp-inspection command to troubleshoot the problem.

Tip

The problem with ARP inspection on the appliance is that it will not stop ARP spoofing attacks occurring off the same interface, like a hacker impersonating a user’s MAC address, where both devices are connected to the same switch, which is then connected to an interface on the appliance. ARP inspection will prevent ARP spoofing attacks between interfaces on the appliance. Therefore, in production networks, I’ve never enabled this feature on the appliance; instead, I’ve enabled it on the switches. (Cisco Catalyst switches support an ARP inspection feature, as well as many other layer 2 security features.)

Transparent Firewall Example Configuration

Now that I’ve introduced the concepts of the transparent firewall feature, let’s look at an example configuration to see how it’s implemented. I’ll use the example shown previously in Figure 21-2 for this configuration, where I’ll assume VLAN 10 is the non-trusted side and VLAN 20 is the trusted side. Also, I’ll use an ASA 5510, with one physical interface connected to the switch, which will use 802.1Q trunking. The users should be allowed to open any HTTP, FTP, DNS, SMTP, or ICMP connection. ICMP won’t be configured as stateful, so for ICMP traffic from the campus network, the ICMP replies will have to be allowed back through the appliance.

Here’s the ASA 5510 configuration:

myasa# show firewall
Firewall mode: Router
myasa(config)# firewall transparent
ciscoasa(config)# show firewall
Firewall mode: Transparent
ciscoasa(config)# interface e0/0
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# exit
ciscoasa(config)# interface e0/0.10
ciscoasa(config-subif)# vlan 10
ciscoasa(config-subif)# nameif outside
ciscoasa(config-subif)# security-level 0
ciscoasa(config-subif)# exit
ciscoasa(config)# interface e0/0.20
ciscoasa(config-subif)# vlan 20
ciscoasa(config-subif)# nameif inside
ciscoasa(config-subif)# security-level 100
ciscoasa(config-subif)# exit
ciscoasa(config)# ip address 10.0.1.253 255.255.255.0
ciscoasa(config)# access-list ACLoutside permit icmp any any
ciscoasa(config)# access-list ACLoutside permit tcp any any eq 80
ciscoasa(config)# access-list ACLoutside permit tcp any any eq 21
ciscoasa(config)# access-list ACLoutside permit tcp any any eq 25
ciscoasa(config)# access-list ACLoutside permit udp any any eq 53
ciscoasa(config)# access-list ACLoutside deny ip any any
ciscoasa(config)# access-group ACLoutside in interface outside

In the preceding example, I enabled transparent mode. I then set up e0/0 with trunking, along with the two VLANs, 10 and 20. The management IP address I assigned was 10.0.1.253. I then set up an ACL to allow the users in VLAN 10 to access campus network resources in or beyond VLAN 20.

Tip

In real life, I would be as specific as possible about what is and isn’t allowed from the users to the campus network. My recommendation in a campus situation is to primarily rely on CTP with downloadable ACLs to restrict users’ access versus static ACL entries on the appliance: this gives you more flexibility and scalability when implementing your policies.