The transparent mode feature on the FWSM configures the firewall to act in a Layer 2 mode, meaning that it will bridge between networks. Transparent mode helps provide a seamless transition when adding the FWSM into an existing infrastructure, by eliminating changes to the existing IP addressing scheme that otherwise would be needed.
With the FWSM configured for transparent mode, it acts as a “bump in the wire.” This configuration, known as a bridge group, supports only an inside and outside interface, essentially bridging the networks together, as shown in Figure 3-1. Up to eight bridge groups are supported on the FWSM, unless it’s configured for multiple contexts; then it’s eight bridge groups per context. Any attempt to configure more than eight will result in the following error message:
ERROR: Maximum number of interfaces already configured.
EtherType Access Control Lists (ACL) allow non-IP protocols such as Internetwork Packet Exchange (IPX), AppleTalk, Multiprotocol Label Switching (MPLS), and even bridge protocol data units (BPDU) to pass through the FWSM. These unique access lists allow EtherType values of greater than 0x5FF, with the exception of BPDUs, which carry spanning-tree information. BPDUs allow switches on the inside and outside interface to form spanning-tree adjacencies, consequently making the FWSM appear as a physical wire, at least from a spanning-tree perspective.
Figure 3-1 FWSM in Transparent Mode
For example, if an EtherType ACL is created to allow MPLS traffic through the FWSM, no inspection of the MPLS traffic will occur. Even though MPLS frames carry IP traffic, the MPLS header must be removed before inspection can occur.
WARNING Be aware that traffic is not inspected if it matches an EtherType ACL.
Techniques for inspecting MPLS frames are discussed in Chapter 22, “Designing a Network Infrastructure,” and Chapter 23, “Design Scenarios.”
IP traffic and Address Resolution Protocol (ARP) (EtherType 0x0806) frames cannot be denied by an EtherType ACL; even with a specific match to EtherType 0x0800 for IP and 0x0806 for ARP, the traffic will still flow through the FWSM. Does this sound like a security risk? Outside FWSM Switch Outside VLAN (Switch) Inside VLAN (Switch) Inside
Working with Transparent Mode 37
WARNING IP and ARP frames cannot be denied by an EtherType ACL.
IP traffic must be explicitly permitted through the use of an extended access list. By default, all IP traffic is denied.
ARP traffic is handled by ARP inspection and will compare the IP address, Media Access Control (MAC) address, and source interface of ARP frames with the static entries in the ARP table (these entries are created manually). In the event of a mismatch, that frame will be dropped. If there isn’t a match in the ARP table, there is a configurable option to forward the ARP frame out other interfaces. Use the following command to enable that feature:
FWSM (config)# aaraarprrppp--i--iiinnnnsspsspppeeceectcctittiiioonoon interface_name enn eeennnnaabaabbbllelle ee fflffllloooooooodddd
NOTE ARP inspection applies to all bridge groups.
To manage the FWSM or the transparent context by means other than connecting through the host-chassis, a management IP address must be assigned to the Bridge-Group Virtual Interface (BVI) that’s associated with the bridge group of the interfaces. The management address must also be a valid address related to the IP network and not an IP version 6 (IPv6) address.
If you have not used transparent mode in the past, this is one of those features to have in your “tool bag.” With the capability to have both routed and transparent support on the same FWSM, it offers tremendous functionality.
Advantages
Operating the FWSM or context in transparent mode provides three significant advantages:
•
The FWSM can be placed inline with the existing network.•
Routers on the inside and outside of the bridge group can establish a neighbor relationship via an Interior Gateway Protocol (IGP).•
Multiple types of traffic are supported.Placing the FWSM inline results in minimal reconfiguration of other devices within the network. Because the FWSM operates in a bridge mode, it can be easily placed directly in front of or behind the default gateway, as shown in Figure 3-2, and IP addressing will not be required to change.
Figure 3-2 Transparent Mode Inline Operation
Establishing a neighbor relationship between routers on the inside and outside of the transparent firewall, as shown in Figure 3-3, eliminates the need to run a dynamic routing protocol on the FWSM. Because the FWSM doesn’t support a dynamic IGP routing protocol in multiple-context mode, this is a great solution. Using a dynamic routing protocol also allows the IGP to quickly determine whether the path through the FWSM is operational. Taking advantage of multi-VPN routing/forwarding instance (VRF) or MPLS, the 6500 or 7600 Multilayer Switch Feature Card (MSFC) can support routing processes minimizing the need for additional routers.
NOTE Use VRF-lite to create routing instances on the inside and outside. Outside FWSM Host-chassis Outside VLAN (Switch) Inside VLAN (Switch) Inside Outside FWSM Host-chassis Outside VLAN (Switch) Inside VLAN (Switch) Inside Default Gateway Default Gateway Existing Network Existing Network
Working with Transparent Mode 39
Figure 3-3 Transparent Mode IGP Support
NOTE Intermediate System to Intermediate System (IS-IS) and Cisco Discovery Protocol (CDP) are not supported with transparent firewalls.
If you are supporting traffic types other than IP (for example, IPX or allowing multicast through the FWSM with minimal configuration), transparent mode is an easy solution. Other options could include Policy-Based Routing (PBR), generic routing encapsulation (GRE), Multi-Topology Routing (MTR), and so on; however, these might require additional hardware and make the network configuration more difficult to manage.
Outside FWSM Host-chassis Outside VLAN (Switch) Inside VLAN (Switch) Inside VRF Outside VRF Inside