Transparent Firewalls and VPNs

Configuration of Transparent Firewall

Implementing a transparent firewall increases design flexibility and network scalability. However, you need to consider some limitations before you implement a transparent firewall. This section discusses the configuration guidelines and configuration steps for a successful implementation of transparent firewalls in a network.

Configuration Guidelines

The following guidelines are useful if you are introducing a new ASA firewall into an environment where renumbering an existing network is not possible. They are also relevant if you are inspecting non-IP traffic through the firewall for improved security.

• Setting the Cisco ASA to either routed or transparent mode is a global feature. Thus, if you use multiple contexts and you set the ASA to transparent mode, all security contexts will use transparent mode to forward traffic between the interfaces.

• Switching from routed to transparent mode or vice versa clears the running configuration. Save active configurations prior to making this change.

• There is no support for dynamic routing protocols like RIP or OSPF in either SMTFs or MMTFs. All OSPF- and RIP- related commands are disabled.

• There is no support for NAT on the ASA if transparent mode is enabled. If address translation is required, it is recommended that you configure an Internet- facing router to provide address translation, as previously shown in Figure 10-2. Consequently, the "global" statement is disabled in the command-line interface (CLI).

• The static and nat commands are used to specify the embryonic and maximum connection limit. They can also be used to disable TCP sequence number randomization.

• Currently, only two interfaces—inside and outside—are used to pass traffic through the ASA transparent firewall running it either in SMTF or MMTF. These interfaces use different security levels.

• The ASA transparent firewall is implemented to inspect and filter out traffic traversing a subnet. This requires both inside and outside interfaces to be on the same subnet. The global IP address must belong to the same subnet as the directly connected interfaces.

• In an MMTF, interfaces cannot be shared between the contexts. Unique interfaces (either physical or logical) are required to segregate traffic between the security contexts.

• For traffic filtering, Layer 3 or EtherType ACLs can be used to allow IP or non-IP traffic to pass through the ASA.

• In transparent mode, the ASA does not support DHCP-relay and reverse- path forwarding features.

Configuration Steps

The following steps can be taken to configure Cisco ASA for transparent firewalls:

Step 1: Enabling Transparent Firewalls

The default routed mode can be changed to transparent mode by using the firewall transparent command, as shown in Example 10-1.

Example 10-1. Enabling Transparent Firewall

Sydney(config)#

firewall transparent

Switched to transparent mode

After switching modes, the ASA clears the running configuration because most of the routed mode commands are not compatible in transparent mode. Example 10-2 illustrates how to revert to routed mode.

Example 10-2. Enabling Routed Firewall

Sydney(config)#

no firewall transparent

Switched to router mode

Use the show firewall command to verify in which mode your firewall is running, as illustrated in Example 10-3.

Example 10-3. Verifying Firewall Mode

Sydney(config)#

show firewall

Firewall mode: Transparent

Step 2: Setting Up Interfaces

After you turn on the transparent firewall on the security appliance, you can define the inside and outside interfaces. You do so by assigning a name and a security level on an interface. Example 10-4 shows how to define an inside interface with security level 100, and an outside interface with security level 0. By default, all interfaces are in the shutdown state, which can be enabled by using the no shutdown command.

Example 10-4. Setting Up Interfaces

Sydney(config)#

interface GigabitEthernet0/0

Sydney(config-if)#

no shutdown

Sydney(config-if)#

nameif outside

INFO: Security level for "outside" set to 0 by default.

Sydney(config-if)#

security-level 0

Sydney(config-if)#

exit

Sydney(config)#

interface GigabitEthernet0/1

Sydney(config-if)#

no shutdown

Sydney(config-if)#

nameif inside

INFO: Security level for "inside" set to 100 by default.

Sydney(config-if)#

security-level 100

Note

Transparent firewall mode on the security appliance allows only two interfaces to pass through traffic. However, you can set up a dedicated management interface, which can be either a physical interface or a subinterface, as a third interface. This interface must be set up for the management-only command.

Step 3: Configuring an IP Address

Unlike routed mode, the ASA in transparent mode does not allow you to configure IP addresses on the interfaces. Rather, an IP address is assigned in global configuration mode. This IP address is used exclusively for management purposes, such as SSH, Telnet, PDM, SNMP traps and polling, AAA, and ARP resolution. Here is the command syntax to configure an IP address:

ip address


ip_address

[

mask

] [

standby


sby_ip_addr

]

ip_address is the configured IP address on the ASA, and mask is the network mask of the assigned IP address. Optionally, a standby IP address can be used for the appliance failover. This is covered in Chapter 11, "Failover and Redundancy."

Example 10-5 shows how to configure an IP address of 192.168.1.10 with a 27-bit mask on the ASA running in transparent mode.

Example 10-5. Assigning an IP Address

Sydney(config)#

ip address 192.168.1.10 255.255.255.224

Note

In an MMTF, an IP address must be configured for each context. The command syntax remains the same as what was just discussed.

Step 4: Configuring Interface ACLs

As discussed in Chapter 5, "Network Access Control," extended ACLs can filter out IP packets by looking at various headers. EtherType-based ACLs can be used to filter IP- and non-IP-based traffic. Here is the command syntax for an EtherType ACL:

access-list


id


ethertype

{

deny


permit

} {

ether-value


bpdu


ipx


mpls-unicast


mpls-multicast


any

}

ether-value is a 2-byte value specified in the Layer 2 datagram under the EtherType code field. For IP-based traffic, the EtherType code value is 0x800. Novell IPX uses 0x8137-8138 and 0xAAAA depending on the NetWare version.

Note

Cisco ASA only supports Ethernet II frames. The IEEE 802.3 frames do not contain an EtherType code field.

The security appliance does not restrict ARP packets to pass through it even if the ACL blocks ARP packets. On the other hand, the security appliance does not allow Cisco Discovery Protocol (CDP) packets to traverse through it, even if the ACL allows them. All other packets, such as DHCP, RIP, OSPF, BGP, BPDU, multicast, and MPLS packets, can be controlled by the ACL entries.

Note

Because the non-TCP and non-UDP packets do not create sessions, the security appliance must be configured for ACLs on both interfaces.

Tip

A list of commonly used EtherType codes is available on the following Cisco.com page:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1818/products_command_reference_chapter09186a00800803a6.html

Figure 10-5 shows an IPX packet captured using Ethereal, a sniffing tool. As you can see, the Ethernet type is 0x8137.

Tip

You can also use the capture command to sniff the IPX or non-IP packets traversing through the security appliance.

Example 10-6 shows how to restrict the LAN segment to allow IPX traffic to pass through, and how to block all other traffic.

Example 10-6. Configuring an IPX-Based EtherType ACL

Sydney(config)#

access-list 100 ethertype permit ipx

Sydney(config)#

access-list 100 ethertype deny any

Note

Cisco ASA does not forward bridge protocol data units (BPDUs) to prevent bridging loops . However, they can be allowed to pass through the security appliance if permitted in the ACL.

Step 5: Adding Static L2F Table Entries (Optional)

As mentioned earlier in this chapter, the L2F entries are learned dynamically when the IP packets traverse through the ASA. However, you can define a host-based static L2F entry to associate a host's MAC address to an interface. This disables the appliance to learn the MAC address and port binding dynamically for that particular host.

Example 10-7 shows how to add the static L2F entry for a router so that the ASA does not have to time out the entry and go through the learning process again.

Example 10-7. Static L2F Entry

Sydney(config)#

mac-address-table static outside 00ff.fff0.003e

Added <00ff.fff0.003e> to the bridge table

Tip

If a static ARP entry is configured, the appliance also adds the corresponding static L2F table entry.

Step 6: Enabling ARP Inspection (Optional)

Cisco ASA, deployed in transparent mode, provides a way to prevent attacks related to ARP spoofing. This feature, called ARP inspection, is disabled by default. Once ARP inspection is enabled, the ASA examines all ARP packets (reply or gratuitous ARP) before forwarding them. ARP inspection can be configured to either flood the packet to other interfaces (by using the flood keyword) or drop the packet and generate a syslog (by using no-flood ).

ARP inspection can be enabled per interface. When the Cisco ASA receives an ARP packet, it checks the static ARP table for a hit. Based on the hit or miss , it takes the following actions:

1. If there is a hit and it finds a matching entry, it forwards the packet to the correct interface.

2. If there is a hit but the entry does not match the interface, the appliance drops the packet and generates a syslog.

3. If there is a miss and the flood option is enabled, the ASA forwards the packet to all interfaces.

4. If there is a miss and no-flood is enabled, the appliance drops the packet and generates a syslog.

The command syntax to enable ARP inspection is

arp-inspection


interface_name


enable

[

flood


no-flood

]

Example 10-8 illustrates how to turn on ARP inspection on the outside interface with no-flood . This will drop the packets if there is a miss on the static ARP table. With this option enabled, the security appliance needs to know the ARP entries of all the hosts that reside on that interface. This way, if an unknown host tries to connect through the security appliance, it will be denied access because there is no static ARP entry and the no-flood option is enabled.

Example 10-8. Enabling ARP Inspection

Sydney(config)#

arp-inspection outside enable no-flood

Note

To set ARP inspection back to the default on all interfaces, use clear configure arp-inspection .

Sydney(config)#

mac-address-table aging-time 60

mac-learn


interface_name


disable

Sydney(config)#

mac-learn outside disable