Section 6-1. Transparent Firewall Mode | CCNP BCMSN Exam Certification Guide (3rd Edition)

6-1. Transparent Firewall Mode

Traditionally, Cisco firewalls have operated by performing Layer 3 (IP address) operations. Naturally, the stateful inspection process can look at higher layers within the IP packets being examined. But the firewall itself has maintained its own interface IP addresses and acted as a router or gateway to the networks that connect to it. This is called routed firewall mode.

Beginning with PIX 7.0 and FWSM 2.2(1), a Cisco firewall can be configured to operate in transparent firewall mode. The firewall appears to operate as a Layer 2 device without becoming a router hop or a gateway to the connected networks. This is also known as a Layer 2 firewall or a stealth firewall, because its interfaces have no IP addresses and can't be detected or manipulated. Only a single management address can be configured on the firewall.

As a Layer 2 device, a transparent mode firewall can be dropped or wedged into an existing network, separating the inside and outside without changing any existing IP addresses. This is commonly called bump in the wire because the firewall doesn't break or segment the IP subnet along a wireit more or less becomes part of the wire. This makes a new installation very straightforward.

You can think of a transparent mode firewall as a type of transparent bridge, where packets are bridged from one interface to another based only on their MAC addresses. The firewall maintains a MAC address table from received packets, containing the source MAC address and the source interface. The firewall can forward a packet by knowing the location or the egress interface of the destination MAC address.

Figure 6-1 illustrates the transparent firewall process. Host A sends a packet to Host B. Notice that Hosts A and B are located on the same IP subnet. Their local-ip and foreign-ip addresses only designate that "local" is on the inside of the firewall and "foreign" is on the outside. When the firewall builds a conn table entry, the host addresses are shown in this fashion.

Figure 6-1. Transparent Firewall Operation

TIP

In transparent mode, a firewall can support only two interfacesthe inside and the outside. If your firewall supports more than two interfaces from a physical and licensing standpoint, you can assign the inside and outside to two interfaces arbitrarily. After those interfaces are configured, the firewall does not permit a third interface to be configured.

Some platforms also support a dedicated management interface that can be used for all firewall management traffic. However, the management interface can't be involved in accepting or inspecting user traffic.

In multiple-context mode, each context also has two interfaces (inside and outside). However, each context must use a pair of interfaces that is different from any other context. In other words, contexts cannot share inside and outside interfaces because of the bridging operation.

When a firewall enters transparent mode, it no longer supports or has a need for address translation. After all, that is a function based on having different IP subnets on different firewall interfaces. In transparent mode, both interfaces must share the same IP subnet. However, IP packets are still inspected without the Layer 2 limitation. Full extended access lists (IP protocol and port numbers) are used to evaluate traffic policies, and the firewall's application inspection engines can interpret IP activity at any layer.

If a transparent firewall acts as a Layer 2 device, is it limited to IP traffic? From a traffic inspection standpoint, it is; only IP traffic can be inspected and policies enforced. However, from a bridging perspective, the firewall can transparently bridge non-IP packets from one interface to another. This is done by configuring the permitted EtherTypes explicitly in a special interface access list.

A transparent firewall can also maintain an ARP table, where MAC and IP addresses are associated as a pair. These are learned from ARP replies that are overheard on an interface. Normally, the ARP table is used only for management traffic to and from the transparent firewall when the firewall itself needs to send packets to a destination.

You can configure the firewall to support ARP inspection, which can detect and prevent ARP spoofing. ARP requests and replies are forwarded through the firewall by default, as if the two firewall interfaces were bridged. This creates the potential for a malicious host to send spoofed ARP replies with its own MAC address. By doing so, the malicious host can advertise itself as a router's IP address, causing other hosts to send their traffic to it instead of to the router.

ARP inspection uses static ARP entries as the basis for its inspection process. The firewall examines each ARP reply packet it overhears and compares the source IP and MAC addresses, as well as the source interface, to known static entries in its own ARP table. If the ARP reply matches an existing entry, it is allowed to pass through the firewall. If any of its information conflicts with an existing entry, the firewall assumes the ARP reply contains spoofed addresses and drops the packet. If an existing ARP entry can't be found, the firewall can be configured to transmit or drop the ARP reply packet.

Configuring a Transparent Firewall

Follow these steps to configure a firewall for transparent mode:

Enter transparent firewall mode:

 Firewall(config)# firewall transparent

By default, a firewall operates in routed mode. You can use this command to initiate transparent firewall mode. Transparent mode begins immediately and doesn't require a firewall reload.

CAUTION

Because transparent and routed modes use different approaches to network security, the running configuration is cleared as soon as transparent mode begins. The idea is to enter transparent mode and build an appropriate configuration from scratch.

For that reason, you should save the routed mode running configuration to Flash memory or to an external server. That way, you have a copy in case you need to revert to routed mode or you need to refer to some portion of that configuration.

You can always display the current firewall mode with the show firewall command. For example, a firewall is configured for transparent mode in the following command sequence:

 Firewall# show firewall Firewall mode: Router Firewall# configure terminal Firewall(config)# firewall transparent Switched to transparent mode Firewall(config)# exit Firewall# Firewall# show firewall Firewall mode: Transparent Firewall#

Configure an interface.

In transparent mode, none of the firewall interfaces can support an IP address. You still have to configure the necessary interface media parameters (speed and duplex), any VLAN information, a logical name, and a security level. These parameters are configured in the following steps.

a. Define a physical interface:

FWSM 2.x

PIX 7.x

[View full width]

 Firewall(config)# interface hardware-id Firewall(config-if)# speed {auto | 10 | 100 |  nonegotiate} Firewall(config-if)# duplex {auto | full | half} Firewall(config-if)# [no] shutdown

The interface is referenced by its hardware-id, such as GigabitEthernet0 or Ethernet0 in PIX 7.x. (The actual name is not case-sensitive when you enter it.)

You can set the interface speed with one of the following keywords: auto (negotiates the speed; this is the default), 10 (10 Mbps only), 100 (100 Mbps only), or nonegotiate (fiber-optic interfaces only). You can set duplex mode using one of the following keywords: auto (autonegotiate; this is the default), full (full duplex only), or half (half duplex only).

By default, interfaces are administratively shut down with the shutdown command. You can enable an interface by using the no shutdown interface configuration command.

b. Define a VLAN interface:

FWSM 2.x	`Firewall(config)#` `interface vlan` `vlan_id`
PIX 7.x	Firewall(config)# interface hardware_id[.subinterface] Firewall(config-subif)# vlan vlan_id

On an FWSM platform, VLAN interfaces are inherent, because the platform has no physical interfaces. Only the VLAN number vlan_id needs to be provided.

In PIX 7.0, logical VLAN interfaces must be carried over a physical trunk interface, identified as hardware_id (GigabitEthernet0, for example). A subinterface number is added to the physical interface name to create the logical interface. This is an arbitrary number that must be unique for each logical interface. The VLAN number is specified as vlan_id in a separate vlan subinterface configuration command.

Packets being sent out a logical VLAN interface are tagged with the VLAN number as they enter the physical trunk link. The VLAN number tag is stripped off at the far end of the trunk, and the packets are placed on the corresponding VLAN. The same process occurs when packets are sent toward the firewall on a VLAN.

The trunk encapsulation used is always IEEE 802.1Q, and the tagging encapsulation and unencapsulation are automatically handled at each end of the trunk. Make sure the far-end switch is configured to trunk unconditionally.

c. Name the interface, and assign a security level:

FWSM 2.x	`Firewall(config)#` `nameif` `vlan-id if_name` `securitylevel`
PIX 7.x	Firewall(config-if)# nameif if_name Firewall(config-if)# security-level level

On an FWSM platform, the interface is identified by its vlan-id (vlan5, for example; the word vlan is always present). If multiple-context security mode is being used, the vlan-id could be an arbitrary name that has been mapped to the context by the allocate-interface command in the system execution space.

The interface is given the arbitrary name if_name (1 to 48 characters) that other firewall commands can use to refer to the interface. For example, you could name an interface inside, outside, or something completely different.

A security level is also assigned to the interface as a level (a number from 0 to 100, from lowest to highest). On an FWSM, the level must be given immediately following the security keyword, as in securitylevel. Security levels 0 and 100 are reserved for the outside and inside interfaces, respectively. Other perimeter interfaces should have levels between 1 and 99.

For example, the outside interface could be configured as follows:

FWSM 2.x	`Firewall(config)#` `nameif vlan10 outside security0`
PIX 7.x	Firewall(config)# interface gigabitethernet0 Firewall(config-if)# nameif outside Firewall(config-if)# security-level 0

NOTE

Security levels are used only to determine how the firewall inspects and handles traffic. For instance, traffic passing from a higher-security interface toward a lower one is assumed to be going toward a less-secure area. Therefore, it is forwarded with less-stringent policies than traffic coming in toward a higher-security area.

In addition, firewall interfaces must have different security levels. The only exceptions are with PIX 7.0 and FWSM 2.2+, which allow interfaces to have the same security level only if the same-security-traffic permit inter-interface global configuration command has been used.

Configure a management address:

 Firewall(config)# ip address ip_address subnet_mask

The firewall can support only a single IP address for management purposes. The address is not bound to an interface, as in routed mode. Rather, it is assigned to the firewall itself, accessible from either of the bridged interfaces.

The management address is used for all types of firewall management traffic, such as Telnet, SSH, HTTP, SNMP, Syslog, TFTP, FTP, and so on.

NOTE

A transparent firewall can also support multiple security contexts. In that case, you must configure interface IP addresses from the respective context. The system execution space uses the admin context interfaces and IP addresses for its management traffic.

(Optional) Configure routing information for management purposes:

 Firewall(config)# route if_name foreign_network foreign_mask gateway   [metric]

You can configure a static route to allow the firewall to send management traffic to addresses that are not on the local IP subnet. Dynamic routing protocols are not supported in transparent firewall mode.

The remote network can be found on the firewall interface named if_name (outside, for example). It has network address foreign_network and subnet mask foreign_mask. The next-hop router address is given as gateway. You can also specify a distance metric, which is the number of router hops until the gateway is reached. If you omit the metric, it defaults to one hop.

You can repeat this command to define other stable, static routes.

You don't have to configure a static route for the subnet directly connected to the firewall interfaces. However, you should define one static route as a default route toward the outside public network. For that, use 0 for the foreign_network and foreign_mask values. If other IP subnets are active on the inside of the firewall, you need to define static routes for each of them.

For example, suppose a firewall is located on the network 10.1.0.0 255.255.0.0. Its next-hop router on the outside interface is 10.1.1.1. A router exists at 10.1.1.2 on the inside of the firewall, where subnets 192.168.1.0/24 and 192.168.100.0/24 can be found. You can use the following commands to configure this routing information on a transparent firewall:

 Firewall(config)# route outside 0 0 10.1.1.1 1 Firewall(config)# route inside 192.168.1.0 255.255.255.0 10.1.1.2 1 Firewall(config)# route inside 192.168.100.0 255.255.255.0 10.1.1.2 1

(Optional) Manipulate the MAC address learning process.

By default, a firewall learns MAC addresses as they are received on any interface. You can use the following commands to display the current MAC address learning state and current MAC address table entries, respectively:

 Firewall# show mac-learn Firewall# show mac-address-table [count] [static] [if_name]

You can specify a single interface as if_name on PIX 7 or as interface if_name on an FWSM platform.

For example, the following output indicates that MAC address learning is enabled on both firewall interfaces and that the MAC address table has been populated with a few entries:

 Firewall# show mac-learn interface                         mac learn -------------------------------------------  outside                            enabled  inside                             enabled Firewall# Firewall# show mac-address-table interface                   mac  address          type      Age(min) ------------------------------------------------------------------ outside                    00a0.c900.0201          dynamic    5 inside                     0050.e2c6.f680          dynamic    4 outside                    0008.20f7.fbfc          dynamic    4 Firewall#

You can use any of the following steps to modify the MAC address learning process:

a. (Optional) Set the MAC address table aging time:

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

As new addresses are learned, they are placed in the MAC address table. If no traffic is seen to include a MAC address that is already in the table, that entry is aged out and removed after minutes (5 to 720 minutes; the default is 5).

b. (Optional) Define a static MAC address table entry:

 Firewall(config)# mac-address-table static if_name mac_address

You might define a static entry for a MAC address that can never be learned. This might occur if a host or server always listens to traffic using one MAC address and transmits using another. In that case, the transmit address can be learned, but the receiver address cannot.

After a static entry is configured, the firewall always expects that MAC address to be found on the specified interface. If the same MAC address appears on a different firewall interface, the firewall drops those packets.

For example, the following commands configure two static entries in the MAC address table:

 Firewall(config)# mac-address-table static inside 0006.5b02.a841 Firewall(config)# mac-address-table static outside 0040.9646.6cf6

(Optional) Disable MAC address learning on an interface:

 Firewall(config)# mac-learn if_name disable

By default, MAC address learning is enabled on every firewall interface. You can disable it on a firewall interface named if_name (outside, for example) so that only static MAC address table entries are used during a packet-forwarding operation.

This might be handy in a scenario where you want to keep tight control over the MAC addresses that can be learned dynamically. However, static entries would need to be added for each new host, increasing the amount of firewall administration needed.

(Optional) Use ARP inspection.

a. Add a static ARP entry:

 Firewall(config)# arp if_name ip_address mac_address

The IP address is associated with the MAC address (dotted-triplet nnnn.nnnn.nnnn format). These are expected to be found on the firewall interface named if_name (outside, for example).

Static ARP entries never age out. To clear a static ARP entry, repeat the command by beginning with the no keyword.

NOTE

The arp command syntax also includes an optional alias keyword. In routed firewall mode, this makes the firewall use proxy ARP when it gets an ARP request for that address rather than forwarding the request to the actual target.

In transparent mode, this keyword has no effect. The firewall doesn't interact with other hosts using Layer 3 mechanisms, so proxy ARP isn't possible.

For example, the following commands configure static ARP entries in preparation for ARP inspection:

 Firewall(config)# arp inside 192.168.198.199 0006.5b02.a841 Firewall(config)# arp outside 172.21.4.9 0040.9646.6cf6

b. Enable ARP inspection on an interface:

 Firewall(config)# arp-inspection if_name enable [flood | no-flood]

By default, ARP inspection is disabled on all firewall interfaces. When enabled, ARP replies received on the interface named if_name (outside, for example) are inspected and matched against known static ARP entries. One of the following actions is taken:

- If the MAC address and the IP address are both found in the ARP table in a single entry, the ARP reply must be valid and is allowed to pass through the firewall.

- If either the MAC address or the IP address is found in the ARP table, but not both in a single entry, the ARP reply contains invalid or spoofed information. Therefore, it is dropped and not forwarded through the firewall.

- If neither the MAC nor IP address is found in the ARP table, you can select the action as one of flood (forward or flood the ARP packet out the other firewall interface so that it can reach its destination) or no-flood (drop the ARP packet without forwarding it). By default, the flood action is assumed.

NOTE

ARP inspection is effective only in handling ARP packets that need to traverse the firewall. In other words, the ARP requester and responder are located on different firewall interfaces. If both hosts are located on the same firewall interface, the ARP reply can be answered directly without having to pass through the firewall.

You can display the ARP inspection status on each interface with the following command:

 Firewall# show arp-inspection

For example, the firewall in the following output has ARP inspection enabled on both interfaces, but only the inside interface is configured to flood unknown ARP replies:

 Firewall# show arp-inspection interface                arp-inspection         miss ---------------------------------------------------- outside                  enabled                no-flood inside                   enabled                flood Firewall#

TIP

If you are having trouble getting ARP inspection to work properly, make sure that all the addresses involved in ARP requests and replies are configured as static ARP entries. If the firewall receives an ARP packet and finds a corresponding entry in its ARP table that was learned dynamically, the ARP packet is dropped. Only static ARP entries are used with ARP inspection.

For example, suppose ARP inspection has been enabled on a firewall's outside interface. The firewall has already learned the MAC and IP addresses for a router on the outside and has created a dynamic ARP entry for it. When the router sends an ARP reply toward the outside firewall interface, ARP inspection rejects it. The following Syslog output is generated when this happens:

 %PIX-3-322002: ARP inspection check failed for arp response received   from host 0008.20f7.fbfc on interface outside. This host is   advertising MAC Address 0008.20f7.fbfc for IP Address   192.168.93.129, which is dynamically bound to MAC Address   0008.20f7.fbfc Firewall# show arp         outside 192.168.93.129 0008.20f7.fbfc         outside 192.168.93.130 0008.20f7.fb00         inside 192.168.93.134 0050.e2c6.f680 Firewall#

Although it looks like everything matches up with the outside host's addresses, the problem is that the ARP entry was dynamically learned and created.

Configure interface access lists.

Before traffic can be forwarded through the firewall, be sure to configure the appropriate security policies by applying an access list to each interface. Access lists are covered in detail in section 6-3, "Controlling Access with Access Lists."

Configure a forwarding policy for non-IP protocols.

a. Define an access list:

FWSM 2.x	`Firewall(config)#` `access-list` `acl_id` `ethertype` `{permit` \| `deny} {unicast` \| `multicast` \| `broadcast` \| `ethertype}`
PIX 7.x	`Firewall(config)#` `access-list` `acl_id` `ethertype` `{permit` \| `deny} {any` \| `bpdu` \| `ipx` \| `mpls-unicast` \| `mpls-multicast` \| `ethertype}`

By default, only IP packets are allowed to pass through a firewall (provided that those packets are permitted by the various inspection processes). You can create an access list that defines a policy on whether non-IP protocols can be forwarded through the firewall.

This command defines an access control entry (ACE) for the access list named acl_id. You can permit or deny the EtherType that is specified. Every access list always has an implicit deny all ACE at the end. Therefore, all non-IP EtherTypes are dropped unless they are explicitly permitted in an access list.

The EtherType value can be one of the following: any (any non-IP packet), bpdu (Bridge Protocol Data Unit, used for Spanning Tree Protocol operation), ipx (Novell IPX, 0x8137 and 0x8138), mpls-unicast (MPLS unicast, 0x8847), or mpls-multicast (MPLS multicast, 0x8848). You can also specify a numeric ethertype value, which is a 16-bit hexadecimal number greater than 0x600.

TIP

The IEEE assigns and maintains well-known EtherType values. You can search or download the most current list of values at http://standards.ieee.org/regauth/ethertype/index.shtml. Many other values are not publicly registered and are not shown in that listing.

You can repeat the access-list acl_id ethertype command to add more EtherTypes to be permitted or denied.

b. Apply the EtherType access list to an interface:

 Firewall(config)# access-group acl_id {in | out} interface if_name

The EtherType access list named acl_id is applied to the firewall interface named if_name (outside, for example). Generally this should be done in the in (inbound) direction, because the EtherType should be evaluated as packets are received, before being inspected.

You can apply one EtherType access list and one extended IP access list to the same interface.

TIP

A Cisco firewall can inspect only IP packets; no inspection is possible for non-IP EtherTypes. This means you have to explicitly permit those EtherTypes in an access list and apply the list to both the inbound and outbound interfaces in the inbound direction.

For example, the following commands configure a firewall to permit IEEE 802.1d Spanning Tree BPDU and Novell IPX traffic while denying all other non-IP packets. The access list is applied to the inbound direction on both sides of the firewall, allowing bidirectional forwarding:

 Firewall(config)# access-list MyEthertypes ethertype permit bpdu Firewall(config)# access-list MyEthertypes ethertype permit ipx Firewall(config)# access-group MyEthertypes interface in outside Firewall(config)# access-group MyEthertypes interface in inside