Friday, June 17, 2011

Cisco ASA Firewall in Transparent Layer2 Mode


Traditionally, a network firewall is a routed hop that acts as a default gateway for hosts that connect to one of its screened subnets. A transparent firewall (or Layer 2 firewall), on the other hand, acts like a “stealth firewall” and is not seen as a Layer 3 hop to connected devices. The appliance connects the same Layer 3 network subnet on its inside and outside ports, but each interface of the firewall resides in a different Layer 2 Vlan. The Cisco ASA firewall can operate both in Routed Firewall Mode (default mode) or in Transparent Firewall Mode.
Routed Firewall Mode:
See the diagram below for a common network topology of a Cisco ASA firewall working in Routed Mode.
As you can see, there are two different network subnets. Inside network (10.20.20.0/24) and Outside Network (10.10.10.0/24). There must be also two different layer2 vlans (Vlan20 for inside network and Vlan10 for outside network). All hosts residing in internal network must belong to subnet 10.20.20.0 and must have default gateway the internal IP of the ASA (10.20.20.1).
Transparent Firewall Mode:
The diagram below shows an example topology using a Cisco ASA in Layer 2 transparent mode.
As you can see, there is only one Layer 3 network (10.10.10.0/24) BUT there MUST be two different Layer 2 Vlans (Vlan20 for inside zone and Vlan10 for outside zone). All hosts must reside in network range 10.10.10.0 and the devices must have as default gateway the IP address of the outside router (10.10.10.2). Also, a management IP address MUST be configured on the ASA firewall (again within the range of 10.10.10.0). DO NOT specify the management IP address of the ASA as the default gateway for connected devices.
[ad#embedded-square]
Characteristics of Transparent Mode
• Transparent firewall mode supports only two interfaces (inside and outside)
• The firewall bridges packets from one VLAN to the other instead of routing them.
• MAC lookups are performed instead of routing table lookups.
• Can run in single firewall context or in multiple firewall contexts.
• A management IP address is required on the ASA.
• The management IP address must be in the same subnet as the connected network.
• Each interface of the ASA must be a different VLAN interface.
• Even though the appliance acts as a Layer 2 bridge, Layer 3 traffic cannot pass through the security appliance from a lower security level to a higher security level interface.
• The firewall can allow any traffic through by using normal extended Access Control Lists (ACL).
Initial Configuration
Asa(config)# firewall transparent
!Configure management IP below
Asa(config)# ip address 10.10.10.1 255.255.255.0
Asa(config)# interface Ethernet0/0
Asa(config-if)# nameif outside
Asa(config-if)# security-level 0
!
Asa(config)# interface Ethernet0/1
Asa(config-if)# nameif inside
Asa(config-if)# security-level 100


PIX/ASA: Transparent Firewall Configuration Example


Introduction

Traditionally, a firewall is a routed hop and acts as a default gateway for hosts that connect to one of its screened subnets. A transparent firewall, on the other hand, is a Layer 2 firewall that acts like a "bump in the wire," or a "stealth firewall," and is not seen as a router hop to connected devices. The security appliance connects the same network on its inside and outside ports. Because the firewall is not a routed hop, you can easily introduce a transparent firewall into an existing network; it is unnecessary to re-address IP.
Maintenance is facilitated because there are no complicated routing patterns to troubleshoot and no NAT configuration.
Even though the transparent mode acts as a bridge, Layer 3 traffic, such as IP traffic, cannot pass through the security appliance unless you explicitly permit it with an extended access list. The only traffic allowed through the transparent firewall without an access list is ARP traffic. ARP traffic can be controlled by ARP inspection.
In routed mode, some types of traffic cannot pass through the security appliance even if you allow it in an access list. Alternatively, the transparent firewall can allow any traffic through with either an extended access list (for IP traffic) or an EtherType access list (for non-IP traffic).
For example, you can establish routing protocol adjacencies through a transparent firewall; you can allow VPN (IPSec), OSPF, RIP, EIGRP, or BGP traffic through based on an extended access list. Likewise, protocols such as HSRP or VRRP can pass through the security appliance.
Non-IP traffic (for example, AppleTalk, IPX, BPDUs, and MPLS) can be configured to go through with an EtherType access list.
For features that are not directly supported on the transparent firewall, you can allow traffic to pass through so that upstream and downstream routers can support the functionality. For example, with an extended access list, you can allow DHCP traffic (instead of the unsupported DHCP relay feature) or multicast traffic, such as that created by IP/TV.
When the security appliance runs in transparent mode, the outbound interface of a packet is determined by a MAC address lookup instead of a route lookup. Route statements can still be configured, but they only apply to security appliance-originated traffic. For example, if your syslog server is located on a remote network, you must use a static route, so the security appliance can reach that subnet.
You can set the adaptive security appliance to run in the default routed firewall mode or transparent firewall mode. When you change modes, the adaptive security appliance clears the configuration because many commands are not supported in both modes. If you already have a populated configuration, be sure to back up this configuration before you change the mode; you can use this backup configuration for reference when you create a new configuration.
For multiple context mode, you can use only one firewall mode for all contexts. You must set the mode in the system execution space. For multiple context mode, the system configuration is erased, which removes any contexts. If you again add a context that has an existing configuration that was created for the wrong mode, the context configuration does not work correctly.
Note: Be sure to create your context configurations for the correct mode before you add them again, or add new contexts with new paths for new configurations.
Note: If you download a text configuration to the security appliance that changes the mode with the firewall transparentcommand, be sure to put the command at the top of the configuration; the adaptive security appliance changes the mode as soon as the command is executed and then continues to read the configuration that you downloaded. If the command occurs later in the configuration, the adaptive security appliance clears all previous lines in the configuration.
In order to configure Multiple Context Mode in Transparent Firewall, refer to Multiple Mode, Transparent Firewall with Outside Access 

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:
  • ASA with version 7.x and later
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Related Products

This configuration can also be used with these hardware and software versions:
  • PIX Security Appliance with 7.x and later

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

Transparent Firewall

Guidelines

Follow these guidelines when you plan your transparent firewall network:
  • A management IP address is required; for multiple context mode, an IP address is required for each context.
    Unlike routed mode, which requires an IP address for each interface, a transparent firewall has an IP address assigned to the entire device. The security appliance uses this IP address as the source address for packets that originate on the security appliance, such as system messages or AAA communications.
    The management IP address must be on the same subnet as the connected network. You cannot set the subnet to a host subnet (255.255.255.255).
  • The transparent security appliance uses an inside interface and an outside interface only. If your platform includes a dedicated management interface, you can also configure the management interface or subinterface for management traffic only.
    In single mode, you can only use two data interfaces (and the dedicated management interface, if available) even if your security appliance includes more than two interfaces.
  • Each directly connected network must be on the same subnet.
  • Do not specify the security appliance management IP address as the default gateway for connected devices; devices need to specify the router on the other side of the security appliance as the default gateway.
  • For multiple context mode, each context must use different interfaces; you cannot share an interface across contexts.
  • For multiple context mode, each context typically uses a different subnet. You can use subnets that overlap, but your network topology requires router and NAT configuration to make it possible from a routing standpoint.
  • You must use an extended access list to allow Layer 3 traffic, such as IP traffic, through the security appliance.
    You can also optionally use an EtherType access list to allow non-IP traffic through.

Allowed MAC Addresses

These destination MAC addresses are allowed through the transparent firewall. Any MAC address not on this list is dropped.
  • TRUE broadcast destination MAC address equal to FFFF.FFFF.FFFF
  • IPv4 multicast MAC addresses from 0100.5E00.0000 to 0100.5EFE.FFFF
  • IPv6 multicast MAC addresses from 3333.0000.0000 to 3333.FFFF.FFFF
  • BPDU multicast address equal to 0100.0CCC.CCCD
  • AppleTalk multicast MAC addresses from 0900.0700.0000 to 0900.07FF.FFFF

Unsupported Features

These features are not supported in transparent mode:
  • NAT /PAT
    NAT is performed on the upstream router.
    Note: Starting with ASA/PIX 8.0(2), NAT/PAT is supported in the transparent firewall.
  • Dynamic routing protocols (such as RIP, EIGRP, OSPF)
    You can add static routes for traffic that originates on the security appliance. You can also allow dynamic routing protocols through the security appliance with an extended access list.
    Note: IS-IS is IP protocol 124 (is-is over ipv4). IS-IS transient packets can be allowed through the transparent mode by the form of an ACL that permits protocol 124. The transparent mode supports all 255 IP protocols.
  • IPv6
  • DHCP relay
    The transparent firewall can act as a DHCP server, but it does not support the DHCP relay commands. DHCP relay is not required because you can allow DHCP traffic to pass through with an extended access list.
  • Quality of Service (QOS)
  • Multicast
    You can allow multicast traffic through the security appliance if you allow it in an extended access list. In a transparent firewall, access-lists are required to pass the multicast traffic from higher to lower, as well as from lower to higher security zones. In normal firewalls, higher to lower security zones are not required. For more information, refer to thePass Through Traffic section in the Firewall Service Module Transparent Firewall Configuration Example.
  • VPN termination for through traffic
    The transparent firewall supports site-to-site VPN tunnels for management connections only. It does not terminate VPN connections for traffic through the security appliance. You can pass VPN traffic through the security appliance with an extended access list, but it does not terminate non-management connections.
Note: The transparent mode security appliance does not pass CDP packets or any packets that do not have a valid EtherType greater than or equal to 0x600.

Configure

In this section, you are presented with the information to configure the features described in this document.
Note: Use the Command Lookup Tool (registered customers only) to obtain more information on the commands used in this section.

Network Diagram

The network diagram shows a typical transparent firewall network where the outside devices are on the same subnet as the inside devices. The inside router and hosts appear to be directly connected to the outside router.
/image/gif/paws/97853/Transparent-firewall-1.gif

Configurations

ASA 8.x
ciscoasa#show running-config 
: Saved
:
ASA Version 8.0(2)
!

!--- In order to set the firewall mode to transparent mode

firewall transparent
hostname ciscoasa
enable password 8Ry2YjIyt7RRXU24 encrypted
names
!
interface Ethernet0/0
 nameif outside
 security-level 0
!
interface Ethernet0/1
 nameif inside
 security-level 100
!
interface Ethernet0/2
 shutdown
 no nameif
 no security-level
!
interface Ethernet0/3
 shutdown
 no nameif
 no security-level
!
interface Management0/0
 shutdown
 no nameif
 no security-level
 management-only
!
passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
pager lines 24
mtu outside 1500
mtu inside 1500


!--- IP Address for the Management. 
!---  Avoid using this IP Address as a default gateway.
!---  The security appliance uses this address as the source address
!---  for traffic originating on the security appliance, such as system 
!---  messages or communications with AAA servers. You can also use this 
!---  address for remote management access. 


ip address 192.168.1.1 255.255.255.0
no failover
icmp unreachable rate-limit 1 burst-size 1



!--- Output Suppressed



service-policy global_policy global
prompt hostname context
Cryptochecksum:d41d8cd98f00b204e9800998ecf8427e
: end
ciscoasa(config)#

Data Moves Across the Transparent Firewall in Different Scenarios

An Inside User Accesses the Outside Email Server

The user on the inside network accesses the email server placed in the Internet (outside). The security appliance receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies that the packet is allowed in accordance with the terms of the security policy (access lists, filters, or AAA).
Note: For multiple context mode, the security appliance first classifies the packet in accordance with a unique interface.
The security appliance records that a session is established. If the destination MAC address is in its table, the security appliance forwards the packet out of the outside interface. The destination MAC address is that of the upstream router, 192.168.1.2. If the destination MAC address is not in the security appliance table, the security appliance attempts to discover the MAC address when it sends an ARP request and a ping. The first packet is dropped.
The email server responds to the request; because the session is already established, the packet bypasses the many lookups associated with a new connection. The security appliance forwards the packet to the inside user.

An Inside User Visits a Web Server with NAT

If you enable NAT in the Internet router, the flow of the packet across the Internet router is slightly changed.
The user on the inside network accesses the email server placed in the Internet (outside). The security appliance receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies that the packet is allowed in accordance with the terms of the security policy (access lists, filters, or AAA).
Note: For multiple context mode, the security appliance first classifies the packet in accordance with a unique interface.
The Internet router translates the real address of Host A (192.168.1.5) to the mapped address of the Internet router (172.16.1.1). Because the mapped address is not on the same network as the outside interface, make sure that upstream router has a static route to the mapped network that points to the security appliance.
The security appliance records that a session is established and forwards the packet from the outside interface. If the destination MAC address is in its table, the security appliance forwards the packet out of the outside interface. The destination MAC address is that of the upstream router, 172.16.1.1. If the destination MAC address is not in the security appliance table, the security appliance attempts to discover the MAC address when it sends an ARP request and a ping. The first packet is dropped.
The email server responds to the request; because the session is already established, the packet bypasses the many lookups associated with a new connection. The security appliance performs NAT when it translates the mapped address to the real address, 192.168.1.5.

An Inside User Visits an Inside Web Server

If Host A tries to access the inside web server (10.1.1.1), Host A (192.168.1.5) sends the request packet to the Internet router (since it is a default gateway) through the ASA from the inside to the outside. Then the packet is redirected to the web server (10.1.1.1) through ASA (outside to inside) and the internal router.
/image/gif/paws/97853/Transparent-firewall-1.gif
Note: The request packet returns to the web server only if the ASA has an access list to allow the traffic from the outside to the inside.
In order to resolve this, change the default gateway for Host A (10.1.1.1) to be the internal router (192.168.1.3) instead of the Internet router (192.168.1.2). This avoids any unnecessary traffic sent to the outside gateway and redirects occurrences on the outside router (Internet router). It also resolves in the reverse way, that is, when the web server or any host (10.1.1.0/24) present on the inside of the internal router tries to access Host A (192.168.1.5).

An Outside User Visits a Web Server on the Inside Network

These steps describe how data moves through the security appliance:
A user on the outside network requests a web page from the inside web server. The security appliance receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies that the packet is allowed in accordance with the terms of the security policy (access lists, filters, or AAA).
Note: For multiple context mode, the security appliance first classifies the packet in accordance with a unique interface.
The security appliance records that a session is established only if the outside user has the valid access to the internal web server. The access list must be configured to allow the outside user to get the access for the web server.
If the destination MAC address is in its table, the security appliance forwards the packet out of the inside interface. The destination MAC address is that of the downstream router, 192.168.1.3.
If the destination MAC address is not in the security appliance table, the security appliance attempts to discover the MAC address when it sends an ARP request and a ping. The first packet is dropped.
The web server responds to the request; because the session is already established, the packet bypasses the many lookups associated with a new connection. The security appliance forwards the packet to the outside user.

An Outside User Attempts to Access an Inside Host

A user on the outside network attempts to reach an inside host. The security appliance receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies whether the packet is allowed in accordance with the terms of the security policy (access lists, filters, or AAA).
Note: For multiple context mode, the security appliance first classifies the packet in accordance with a unique interface.
The packet is denied, and the security appliance drops the packet because the outside user does not have the access to the inside host. If the outside user attempts to attack the inside network, the security appliance employs many technologies to determine whether a packet is valid for an already established session.

Verify

Use this section to confirm that your configuration works properly.
The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.
ciscoasa(config)# sh firewall
Firewall mode: Transparent

Troubleshoot

There is currently no specific troubleshooting information available for this configuration.


------------------------------------------------

As I am sure you have already seen from the blog on setting up the security device as a Layer 2 device, there are many interesting changes that occur on a PIX or ASA when configured for transparent operations. This blog highlights the major changes and guidelines that you should keep in mind when you opt for this special mode of operation.
  • Number of interfaces – perhaps on of the biggest things you will want to keep in mind is the fact that you are going to be limited on the number of traffic forwarding interfaces you can use when in Layer 2 mode. When you switch to transparent mode, you are limited to the use of two traffic forwarding interfaces. On some ASA models, you may also use your dedicated management interface, but of course, the use of this port is limited for management traffic. Remember also, when in multiple context mode, you cannot share interfaces between contexts like you can when in routed mode.
  • IP addressing – here is another major difference of course. In Layer 2 mode, you will assign a single IP address to the device in Global Configuration mode. This address is for remote management purposes and is required before the device will forward traffic. Once the address is assigned, all interfaces start “listening” on this address to ensure the device is responsive to its administrator. This global IP addressed assigned to the device must be in the same subnet that the forwarding interfaces are participating in. Remember, the transparent firewall is not adding a new network (subnet) to your topology.
  • Default gateway – for traffic sourced from the security device itself, you can configure a default gateway on the transparent device. You can do this with the route 0 0 command.
  • IPv6 support - the transparent firewall does not support IPv6.
  • Non-IP traffic – you can pass non-IP traffic through the Layer 2 Mode device. Note that this is not possible on a security appliance in its default Layer 3 mode.
  • More unsupported features – the Layer 2 mode device does not support – Quality of Service (QoS) or Network Address Translation (NAT).
  • Multicast – the transparent mode device does not offer multicast support, but you can configure Access Control Lists (ACLs) in order to pass multicast traffic through the device.
  • Inspection – with the Layer 2 mode device you can inspect traffic at Layer 2 and above. With the classic routed mode configuration, you can only inspect at Layer 3 and above.
  • VPN support – the transparent mode device does support a site to site VPN configuration, but only for its management traffic.
----------------------------------------------

Firewall Service Module Transparent Firewall Configuration Example


Introduction

Traditionally, a firewall is a routed hop and acts as a default gateway for hosts that connect to one of its screened subnets. A transparent firewall, on the other hand, is a Layer 2 firewall that acts like a bump in the wireor a stealth firewall and is not seen as a router hop to connected devices. The Firewall Service Module (FWSM) connects the same network on its inside and outside interfaces. Because the firewall is not a routed hop, you can easily introduce a transparent firewall into an existing network. IP readdressing is unnecessary.
Maintenance is facilitated because there are no complicated routing patterns to troubleshoot and no NAT configuration.
Even though transparent mode acts as a bridge, Layer 3 traffic (such as IP traffic) cannot pass through the FWSM unless you explicitly permit it with an extended access list. The only traffic allowed through the transparent firewall without an access list is ARP traffic. ARP traffic can be controlled by ARP inspection.
In routed mode, some types of traffic cannot pass through the FWSM even if you allow it in an access list. Alternatively, the transparent firewall can allow any traffic through with either an extended access list (for IP traffic) or an EtherType access list (for non-IP traffic).
For example, you can establish routing protocol adjacencies through a transparent firewall. You can allow VPN (IPSec), OSPF, RIP, EIGRP, or BGP traffic through based on an extended access list. Likewise, protocols such as HSRP or VRRP can pass through the FWSM.
Non-IP traffic (for example, AppleTalk, IPX, BPDUs, and MPLS) can be configured to go through with an EtherType access list.
For features that are not directly supported on the transparent firewall, you can allow traffic to pass through so that upstream and downstream routers can support the functionality. For example, with an extended access list, you can allow DHCP traffic (instead of the unsupported DHCP relay feature) or multicast traffic, such as that created by IP/TV.
When the FWSM runs in transparent mode, the outbound interface of a packet is determined by a MAC address lookup instead of a route lookup. Route statements can still be configured, but they only apply to FWSM-originated traffic. For example, if your syslog server is located on a remote network, you must use a static route, so the FWSM can reach that subnet.
An exception to this rule is when you use voice inspections and the endpoint is at least one hop away from the FWSM. For example, if you use the transparent firewall between a CCM and an H.323 gateway, and there is a router between the transparent firewall and the H.323 gateway, then you need to add a static route on the FWSM for the H.323 gateway for successful call completion.
Note: The transparent mode FWSM does not pass CDP packets or any packets that do not have a valid EtherType greater than or equal to 0x600. For example, you cannot pass IS-IS packets. An exception is made for BPDUs, which are supported.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on FWSM with version 3.x.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

Transparent Firewall

Bridge Groups

If you do not want the overhead of security contexts, or want to maximize your use of security contexts, you can configure up to eight pairs of interfaces, called bridge groups. Each bridge group connects to a separate network. Bridge group traffic is isolated from other bridge groups. Traffic is not routed to another bridge group within the FWSM, and traffic must exit the FWSM before it is routed by an external router back to another bridge group in the FWSM. Although the bridging functions are separate for each bridge group, many other functions are shared between all bridge groups. For example, all bridge groups share a system log server or AAA server configuration. For complete security policy separation, use security contexts with one bridge group in each context.
Because the firewall is not a routed hop, you can easily introduce a transparent firewall into an existing network. IP readdressing is unnecessary. Maintenance is facilitated because there are no complicated routing patterns to troubleshoot and no NAT configuration.
Note: Each bridge group requires a management IP address. The FWSM uses this IP address as the source address for packets that originate from the bridge group. The management IP address must be on the same subnet as the connected network.

Guidelines

Follow these guidelines when you plan your transparent firewall network:
  • A management IP address is required for each bridge group.
    Unlike routed mode, which requires an IP address for each interface, a transparent firewall has an IP address assigned to the entire bridge group. The FWSM uses this IP address as the source address for packets that originate on the FWSM, such as system messages or AAA communications.
    The management IP address must be on the same subnet as the connected network. You cannot set the subnet to a host subnet (255.255.255.255). The FWSM does not support traffic on secondary networks; only traffic on the same network as the management IP address is supported. Refer to Assigning an IP Address to a Bridge Group for more information about management IP subnets.
  • Each bridge group uses an inside interface and an outside interface only.
  • Each directly connected network must be on the same subnet.
  • Do not specify the bridge group management IP address as the default gateway for connected devices. Devices need to specify the router on the other side of the FWSM as the default gateway.
  • The default route for the transparent firewall, which is required to provide a return path for management traffic, is only applied to management traffic from one bridge group network. This is because the default route specifies an interface in the bridge group as well as the router IP address on the bridge group network, and you can only define one default route. If you have management traffic from more than one bridge group network, you need to specify a static route that identifies the network from which you expect management traffic.
  • For multiple context mode, each context must use different interfaces. You cannot share an interface across contexts.
  • For multiple context mode, each context typically uses different subnets. You can use overlapping subnets, but your network topology requires router and NAT configuration to make it possible from a routing standpoint.
    You must use an extended access list to allow Layer 3 traffic, such as IP traffic, through the FWSM. You can also optionally use an EtherType access list to allow non-IP traffic through.

Allowed MAC Addresses

These destination MAC addresses are allowed through the transparent firewall. Any MAC address not on this list is dropped.
  • TRUE broadcast destination MAC address equal to FFFF.FFFF.FFFF
  • IPv4 multicast MAC addresses from 0100.5E00.0000 to 0100.5EFE.FFFF
  • IPv6 multicast MAC addresses from 3333.0000.0000 to 3333.FFFF.FFFF
  • BPDU multicast address equal to 0100.0CCC.CCCD
  • AppleTalk multicast MAC addresses from 0900.0700.0000 to 0900.07FF.FFFF

Unsupported Features

These features are not supported in transparent mode:
  • NAT /PAT
    NAT is performed on the upstream router.
    Note: NAT/PAT is supported in the transparent firewall for FWSM version 3.2 and later releases.
  • Dynamic routing protocols (such as RIP, EIGRP, OSPF)
    You can add static routes for traffic that originates on the FWSM. You can also allow dynamic routing protocols through the FWSM with an extended access list.
  • IPv6 for the bridge group IP address.
    However, you can pass the IPv6 EtherType using an EtherType access list.
  • DHCP relay
    The transparent firewall can act as a DHCP server, but it does not support the DHCP relay commands. DHCP relay is not required because you can allow DHCP traffic to pass through with an extended access list.
  • Quality of Service (QOS)
  • Multicast
    You can allow multicast traffic through the FWSM if you allow it in an extended access list. Refer to the Pass Through Traffic section for more information.
  • VPN termination for through traffic
    The transparent firewall supports site-to-site VPN tunnels for management connections only. It does not terminate VPN connections for traffic through the FWSM. You can pass VPN traffic through the FWSM with an extended access list, but it does not terminate non-management connections.
  • LoopGuard on the switch
    Do not enable LoopGuard globally on the switch if the FWSM is in transparent mode. LoopGuard is automatically applied to the internal EtherChannel between the switch and the FWSM, so after a failover and a failback, LoopGuard causes the secondary unit to be disconnected because the EtherChannel goes into the err-disable state.

Configure

In this section, you are presented with the information to configure the features described in this document.
Note: Use the Command Lookup Tool (registered customers only) to obtain more information on the commands used in this section.

Network Diagram

The network diagram shows a typical transparent firewall network where the outside devices are on the same subnet as the inside devices. The inside router and hosts appear to be directly connected to the outside router.
/image/gif/paws/100773/transparent-firewall.gif

Configurations

You can set each context to run in routed firewall mode (the default) or transparent firewall mode.
When you change modes, the FWSM clears the configuration because many commands are not supported for both modes. If you already have a populated configuration, be sure to back up your configuration before you change the mode. You can use this backup for reference when creating your new configuration.
If you download a text configuration to the FWSM that changes the mode with the firewall transparent command, be sure to put the command at the top of the configuration. The FWSM changes the mode as soon as it reads the command and then continues reading the configuration that you downloaded. If the command is later in the configuration, the FWSM clears all the preceding lines in the configuration.
In order to set the mode to transparent, enter this command in each context:
hostname(config)#firewall transparent
In order to set the mode to routed, enter this command in each context:
hostname(config)#no firewall transparent

Data Moves Across the Transparent Firewall in Different Scenarios

An Inside User Accesses the Outside Email Server

The user on the inside network accesses the email server placed in the Internet (outside). The FWSM receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies that the packet is allowed in accordance with the terms of the security policy (access lists, filters, or AAA).
Note: For multiple context mode, the FWSM first classifies the packet in accordance with a unique interface.
The FWSM records that a session is established. If the destination MAC address is in its table, the FWSM forwards the packet out of the outside interface. The destination MAC address is that of the upstream router, 192.168.1.2. If the destination MAC address is not in the FWSM table, the FWSM attempts to discover the MAC address when it sends an ARP request and a ping. The first packet is dropped.
The email server responds to the request. Because the session is already established, the packet bypasses the many lookups associated with a new connection. The FWSM forwards the packet to the inside user.

An Inside User Visits a Web Server with NAT

If you enable NAT in the Internet router, the flow of the packet across the Internet router is slightly changed.
The user on the inside network accesses the email server placed in the Internet (outside). The FWSM receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies that the packet is allowed in accordance with the terms of the security policy (access lists, filters, or AAA).
Note: For multiple context mode, the FWSM first classifies the packet in accordance with a unique interface.
The Internet router translates the real address of Host A (192.168.1.5) to the mapped address of the Internet router (172.16.1.1). Because the mapped address is not on the same network as the outside interface, make sure that upstream router has a static route to the mapped network that points to the FWSM.
The FWSM records that a session is established and forwards the packet from the outside interface. If the destination MAC address is in its table, the FWSM forwards the packet out of the outside interface. The destination MAC address is that of the upstream router, 172.16.1.1. If the destination MAC address is not in the FWSM table, the FWSM attempts to discover the MAC address when it sends an ARP request and a ping. The first packet is dropped.
The email server responds to the request. Because the session is already established, the packet bypasses the many lookups associated with a new connection. The FWSM performs NAT when it translates the mapped address to the real address, 192.168.1.5.

An Inside User Visits an Inside Web Server

If Host A tries to access the inside web server (10.1.1.1), Host A (192.168.1.5) sends the request packet to the Internet router (since it is a default gateway) through the ASA from the inside to the outside. Then the packet is redirected to the web server (10.1.1.1) through ASA (outside to inside) and the internal router.
/image/gif/paws/100773/transparent-firewall.gif
Note: The request packet returns to the web server only if the ASA has an access list to allow the traffic from the outside to the inside.
In order to resolve this issue, change the default gateway for Host A (10.1.1.1) to be the internal router (192.168.1.3) instead of the Internet router (192.168.1.2). This avoids any unnecessary traffic sent to the outside gateway and redirects occurrences on the outside router (Internet router). It also resolves in the reverse way, that is, when the web server or any host (10.1.1.0/24) present on the inside of the internal router tries to access Host A (192.168.1.5).

An Outside User Visits a Web Server on the Inside Network

These steps describe how data moves through the FWSM:
  1. A user on the outside network requests a web page from the inside web server. The FWSM receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies that the packet is allowed in accordance with the terms of the security policy (access lists, filters, or AAA).
    Note: For multiple context mode, the FWSM first classifies the packet in accordance with a unique interface.
  2. The FWSM records that a session is established only if the outside user has the valid access to the internal web server. The access list must be configured to allow the outside user to get the access for the web server.
  3. If the destination MAC address is in its table, the FWSM forwards the packet out of the inside interface. The destination MAC address is that of the downstream router, 192.168.1.3.
  4. If the destination MAC address is not in the FWSM table, the FWSM attempts to discover the MAC address when it sends an ARP request and a ping. The first packet is dropped.
  5. The web server responds to the request. Because the session is already established, the packet bypasses the many lookups associated with a new connection. The FWSM forwards the packet to the outside user.

An Outside User Attempts to Access an Inside Host

A user on the outside network attempts to reach an inside host. The FWSM receives the packet and adds the source MAC address to the MAC address table, if required. Because it is a new session, it verifies whether the packet is allowed in accordance with the terms of the security policy (access lists, filters, or AAA).
Note: For multiple context mode, the FWSM first classifies the packet in accordance with a unique interface.
The packet is denied, and the FWSM drops the packet because the outside user does not have the access to the inside host. If the outside user attempts to attack the inside network, the FWSM employs many technologies to determine whether a packet is valid for an already established session.

Verify

Use this section to confirm that your configuration works properly.
The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.
ciscoasa(config)#show firewall
Firewall mode: Transparent

Troubleshoot

Pass Through Traffic

In transparent firewall, to pass multicast traffic from high to low and low to high access-lists are required. In normal firewalls from high to low is not required.
Note:  Multicast address (224.0.0.9) can never be source address for return traffic, so it wont be allowed to come back in, that's why we need ACL's from in to out and out to in.
For example, in order to pass through Rip traffic, the transparent firewall access list would be similar to this example:
RIP
Outside ACL (from out to in):
access-list outside permit udp host (outside source router) host 224.0.0.9 eq 520 
access-group outside in interface outside
Inside ACL (from inside to outside):
access-list inside permit udp host (inside source router) host 224.0.0.9 eq 520 
access-group inside in interface inside
EIGRP to run:
access-list inside permit eigrp host (inside source) host 224.0.0.10
 access-group inside in interface inside 
access-list outside permit eigrp host (outside source) host 224.0.0.10 
access-group outside in interface outside
For OSPF:
access-list inside permit ospf host ( inside source ) host 224.0.0.5 
( this access-list is for hello packets ) 
access-list inside permit ospf host ( inside source ) host 224.0.0.6 
( dr send update on this port ) 
access-list inside permit ospf host ( inside source ) host ( outside source ) 
access-group inside in interface inside
 access-list outside permit ospf host ( outside source ) host 224.0.0.5 
access-list outside permit ospf host ( outside source ) host 224.0.0.6 
access-list outside permit ospf host ( outside sourec ) host ( inside source ) 
access-group outside in interafce outside

MSFC VLAN vs FWSM VLAN

In transparent mode, it is not necessary to have the same VLANs in MSFC interface and FWSM, since it is a type of bridging.

Cisco Support Community - Featured Conversations

Cisco Support Community 
is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers. Below are just some of the most recent and relevant conversations happening right now.




PACKET TRACER AND CAPTURE ON ASA

Firewall configurations can be tricky to debug. Especially when you think you have all the proper NAT statements, route statements, and access control lists in place, and it’s still not working quite as you had planned. Have no fear, Packet Trace is here!
The Cisco ASA Packet Trace feature is a wonderful tool for finding out just how a packet will be handled by your ASA in its current configuration. The Packet Trace feature allows you to select an interface, then supply a couple of IP addresses and ports, and it will then trace the path that packet will take through your firewall and provide detailed results.
This tool can be accessed in a couple of different places via the Cisco ASDM. One of these places is in the Firewall’configuration screen on the NAT Rules tab. You’ll see it near the top on the right-hand display.

Here is a screen shot of the initial packet trace setup.

Figure A

NOTE: Click to enlarge.
In Figure B, I’ve set up a trace for an internal IP going to an external Web site. As the packet is processed by the firewall, the individual steps are displayed in real time if you have the Show Animation box selected. These steps are further detailed in the Phase portion of the display. In the example, the results show that the firewall rules will allow this traffic as each step of the process is given a green check mark and the final results are reported as “The packet is allowed.”

Figure B

NOTE: Click to enlarge.
You can drill down into each phase of the process to see exactly what steps were taken, which ACLs were used in processing the packet, what route was used, etc. Figures CD, and E show the actual packet path and processing of our example flow.
In Figure C, we see the packet go through an access list check, a check for any existing matching traffic flows, and a valid route check.

Figure C

NOTE: Click to enlarge.
In Figure D, we see the NAT translation rules that are applied to this packet and the resulting dynamic translation (PAT) that is used.

Figure D

NOTE: Click to enlarge.
In Figure E, you can see that a Flow is created, its flow ID number, and the route that has been selected as well as the final result.

Figure E

NOTE: Click to enlarge.
The final example shows a flow that was not allowed through the firewall.

Figure F

NOTE: Click to enlarge.
As you can see from the above information, this simply wonderful tool can provide a wealth of information. This comes in handy whether you are debugging a critical issue, checking an access control list, or settling your curiousity about how your firewall is actually processing packets.

Easy packet captures straight from the Cisco ASA firewall

Whether you are troubleshooting a difficult problem or chasing some interesting traffic, sometimes you need to pull a packet capture. Of course, you could configure and deploy a sniffer, but that is not the only solution you have at your fingertips. You can pull the packet capture directly from the Cisco ASA firewall. The Cisco ASA makes this an easy process.
There are at least two ways to configure your ASA to capture packets. If you prefer the GUI interface of the ASDM, you can use the Packet Capture Wizard tool by selecting it from the wizard menu.
However, I’ve found that if you don’t mind getting your hands dirty, so to speak, the CLI interface is the way to go. You can identify the traffic you are looking for with an ACL and then set your interface to capture based on the ACL results. Here’s an example of how easy it is to do this.
In this example, I want to capture all IP packets between a host at 192.168.80.51 and the test ASA at 192.168.81.52.
The first step is to set a quick ACL:
access-list testcap extended permit ip host 192.168.80.51 host 192.168.81.52
Then, we set up the capture using the capture command. We’ll reference our ACL (testcap) as our “interesting” traffic, and we’ll specify which interface we want to look at:
myasa# capture testcap interface inside
Admittedly, this is probably the command in its simplest form. There are many options you can configure as part of this command, including setting buffer sizes, setting a circular-buffer that overwrites itself when full, and selecting webvpn or isakmp traffic. The point is, with two quick commands, we’ve got a packet capture going! It just doesn’t get much easier than that.
A quick show capture command verifies my capture is running.

myasa# sh capture
capture testcap type raw-data interface INSIDE [Capturing - 4314 bytes]
To stop the capture, use the no form of this command.
myasa # no capture testcap
Now let’s look at the results. Here again, we have choices. We can look at the traffic via a browser directly from the ASA by opening an http link (Figure A) like the following:
https://192.168.81.52/admin/capture/testcap

Figure A

Click to enlarge.
While we see the traffic and much of the information, we cannot see all the detail of a regular packet capture. However, we can save this info as a libpcap file with the following command, and then open this file with Wireshark or such.
https://192.168.81.52/capture/testcap/pcap
Figure B shows this file when opened with Wireshark.

Figure B

Click to enlarge.
The command line also provides options for looking at your data.
myasa# show capture testcap ?
  access-list    Display packets matching access list
  count          Display <number> of packets in capture
  decode         Display decode information for each packet
  detail         Display more information for each packet
  dump           Display hex dump for each packet
  packet-number  Display packet <number> in capture
  trace          Display extended trace information for each packet
  |              Output modifiers
  <cr>
Let’s look at the first nine packets.
myasa# show capture testcap count 9
4532 packets captured
   1: 13:46:31.052746 192.168.81.52.22 > 192.168.80.51.2057: P 1290581619:1290581687(68) ack 941116409 win 8192
   2: 13:46:31.052884 192.168.80.51.2057 > 192.168.81.52.22: . ack 1290581687 win 65207
   3: 13:46:38.374583 arp who-has 192.168.80.219 tell 192.168.82.51
   4: 13:46:38.521655 arp who-has 192.168.80.204 tell 192.168.82.51
   5: 13:46:39.803120 192.168.81.52.443 > 192.168.80.51.3968: P 787673978:787675438(1460) ack 3043311886 win 8192
   6: 13:46:39.803150 192.168.81.52.443 > 192.168.80.51.3968: P 787675438:787675589(151) ack 3043311886 win 8192
   7: 13:46:39.803257 192.168.81.52.443 > 192.168.80.51.3968: P 787675589:787677049(1460) ack 3043311886 win 8192
   8: 13:46:39.803272 192.168.81.52.443 > 192.168.80.51.3968: P 787677049:787677200(151) ack 3043311886 win 8192
   9: 13:46:39.803287 192.168.81.52.443 > 192.168.80.51.3968: P 787677200:787677883(683) ack 3043311886 win 8192
9 packets shown
We can also look at an entire packet from the CLI.
myasa# show capture testcap detail packet-number 5 dump
4532 packets captured
   5: 13:46:39.803120 0022.5597.25b9 0014.3815.89fb 0x0800 1514: 192.168.81.52.443 > 192.168.80.51.3968: P [tcp sum ok] 787673978:787675438(1460) ack 30                   43311886 win 8192 (ttl 255, id 54032)
0x0000   4500 05dc d310 0000 ff06 c052 c0a8 5134        E..........R..Q4
0x0010   c0a8 5033 01bb 0f80 2ef2 f37a b565 410e        ..P3.......z.eA.
0x0020   5018 2000 5488 0000 1703 0106 4654 db31        P. .T.......FT.1
0x0030   b3d4 0a5b 3295 f719 d82a 8767 6b8b dae1        ...[2....*.gk...
0x0040   0a54 0ea8 c8c4 1c61 c45c e321 452e 6ab6        .T.....a.\.!E.j.
0x0050   ba80 4e94 3801 d973 b4fe 97d4 8b2f 9e77        ..N.8..s...../.w
*Only a partial result is displayed.
So save your hardware or laptop sniffers for other parts of your network. Use your ASA to gather those snippets of network traffic that you need. But remember: in general, be kind to your ASA. When possible, create specific ACLs to refine the traffic you want to capture. Monitor your ASA while capturing packets and adjust the buffers if you need to. And, as always, refer towww.cisco.com for more detailed information.