ASA Transparent Firewall Behavior

I posted a couple of questions to Twitter this morning as both a challenge and a learning experience for myself and others.

These two questions were as follows:

  1. How does the ASA in transparent mode know which interface remote networks should be reached through?
  2. What is permitted at layer 2 disregarding- layer 3 restrictions?

In addition, I’d like to pose one more question:

  1. In what case does the ASA in Transparent mode drop the first packet?

I promised an answer, but Twitter just didn’t allow enough characters to describe the behavior well.  First of I have always assumed that the ASA in transparent mode acted like a bridge.  In other words if a frame was received at interface A, it must be destined to interface B.  While that seems logical, that is incorrect.  The ASA has a CAM table like a switch, but does not behave the same way as a switch when an entry is missing.  On a CAM miss, a switch floods the frames out all ports except the port the frame arrived on.  When the ASA has a CAM table miss, it does not flood the traffic.

So how does an ASA build its CAM table?  The first way is exactly the same way a switch does.  This is by recording the source MAC address from frames received.  This passive method is quite logical and makes perfect sense.  However, in the case of a CAM table miss, this passive method of learning must be augmented in a way that is more conservative than the flooding method employed by a switch.  The second way the CAM table is built in the ASA is by issuing an ARP Request using its own MAC and IP address.  The third way is in the case that the destination IP address is on a remote network is to send an ICMP echo and see what interface the response arrives on.

To be completely honest I had a hard time believing this when I read it, so I decided to see for myself.  So the process is as follows.  Any frames having been received by the ASA will cause their source MAC Addresses to be recorded in the CAM table and associated with the receive port.  The aging-time defaults to 5 minutes but can be changed.  If the CAM table is complete, then there will not be a miss and no need for any active discovery by the ASA.

However in the case of a CAM table miss; things work a bit differently than they do with a switch.  One of two things happens when a frame traveling through the device has a destination MAC in which the egress interface is not known.  If based on the IP Address (remember we need an IP address on a transparent ASA prior to passing IP Traffic) of the ASA and the Netmask the frame is found to be local, an ARP will be sent using the IP address and MAC of the ASA.  The interface that receives the ARP Reply is assumed to be the destination interface.   If the frame is remote based on the above criteria, an ICMP echo will be sent to the destination address and an ARP will be sent to the next hop address (again from the ASA).  The interface receiving the ICMP Echo reply will be associated as the egress interface and the CAM table will be built with the MAC address.  If there is no response received, the CAM table will not be populated.  One more note, though not documented, and ICMP Unreachable will allow the CAM table to be populated.

To restate, an ICMP Echo and an ARP are sent when the following conditions are met:

  1. A frame is destined to a remote network
  2. There is a route in the route table for the destination
  3. The MAC address associated with the next hop is not in the CAM table

When these three conditions are met, the ASA actually sends an ICMP to the destination host.  So if that IP address fails to respond, there will be communication issues until the CAM table is populated through communication with a host that does respond, or another device sending traffic through the ASA to the router (also populating the CAM table).

This behavior is documented in the following location.  For the link to go to the correct location in the page, it may require you already being logged in to CCO.

Information About the MAC Address Table

The second question I posed is what type of traffic is permitted at Layer 2 by default.  In other words, what traffic do we not have to manually allow with an EtherType ACL.  The short answer is any traffic equal to or greater than 0x600.  This is documented in a excerpt at the following location

Allowed MAC Addresses

Passing Traffic Not Allowed in Routed Mode


One concern I have is that both of those seem to say that BPDU’s are supported.  However reading further, it is apparent that BPDU’s should be permitted using and EtherType ACL.  Additionally, the document below clearly states that BPDU’s are denied without an EtherType ACL.  I will confirm this behavior as well the next time I have some access to lab gear (my ASA5505 with an integrated switch might behave differently than an enterprise ASA with regards to BPDU’s).

Adding EtherType Access Lists

Now we know that the CAM table on the ASA has some interesting mechanics when it comes to learning.  Additionally, we have seen that we typically need to permit traffic with an EtherType below 0x600.  So now back to my final question…

When does an ASA in transparent mode drop the first packet?

Answer:  When the CAM table is not populated

This behavior is documented in the URL below:

How Data Moves through the Transparent Firewall

So if you are like me and have always made an assumption that the ASA simply behaves like a bridge, that is a slightly incorrect assumption.  Although in practice, it will usually seem to behave exactly like a bridge at layer two.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Design and tagged . Bookmark the permalink.

8 Responses to ASA Transparent Firewall Behavior

  1. Don_C says:

    Hi, I have been trying to configure an ASA 5505 in transparent mode and a web server behind it but with a public ip address. Setup is Internet —->transparent 5505—>Web Server with (publicIP) However, the ASA is not blocking any traffic. I have tried setting up acl’s including making all deny but everything appears to be open, can you help?

    firewall transparent interface Ethernet 0/0 switchport access vlan 2 no shutdown interface Ethernet 0/1 switchport access vlan 1 no shutdown interface Ethernet 0/2 switchport access vlan 2 no shutdown interface Ethernet 0/3 switchport access vlan 1 no shutdown interface Ethernet 0/4 switchport access vlan 1 no shutdown interface Ethernet 0/5 switchport access vlan 1 no shutdown interface Ethernet 0/6 switchport access vlan 1 no shutdown interface Ethernet 0/7 switchport access vlan 1 no shutdown interface bvi 1 ip address 192.168.1.1 255.255.255.0

    interface bvi 2 ip address public ip 255.255.255.252
    interface vlan 2 nameif outside security-level 0 bridge-group 1 no shutdown interface vlan 1 nameif inside security-level 100 bridge-group 1 no shutdown http server enable http 192.168.1.0 255.255.255.0 inside

    • Paul Stewart says:

      I’ve not went through the configuration of this after the bvi’s were introduced (8.4). However, it looks to me like your configuration has only one relevant bridge group. Both VLANs are attached to bridge-group one. If you are looking at other configurations of this on the internet, the “VLANs” are equivalent to the physical interface on all other ASA’s. I just mention that for perspective.

      Now the way I see your configuration, I would expect ports 0/0 and 0/2 to be able to communicate to each other unrestricted. I would also expect ports 0/1 and 0/3 – 0/7 to communicate with each other unrestricted. However I would not expect 0/0 or 0/2 to be able to interact with 0/1 or 0/3 – 0/7. I would first confirm that is how it is working. If so, then you’d just need to make sure things are connected as desired and write any applicable acl’s to permit traffic.

  2. Arunava Roy says:

    Thanks for the above explanation….but still am not able to understand why to create 2 diferent vlan and assign outside interface of the ASA to one vlan and the inside interface in to another ….please help

    • Paul Stewart says:

      The way this happens depends on the model of ASA you have. The 5505 is like a switch with SVI interfaces. The others are more like a router. You may post the specifics of your question over at the url below. They have a pretty active community over there (including me). Alternatively, you can post it here.

      https://learningnetwork.cisco.com/threads

      • Arunava Roy says:

        Sir Thank you very much for your reply which is truly helpful…..now my question is 5510 and other models of ASA are more likely a router as far as interface is concern, but instead of routing they are bridging trafic we need to create separate vlan in 5505 model so that the trafiic can’t bypass the ASA when it is in transparent mode .In 5510 and other model of ASA both inside and outside interface of the ASA are in the same subnet and also we are not suppose to create any vlan so please tell me how ASA is able to arrest the trafic. To fully understand ASA in transparent mode one should understand how a bridge actually bridges trafic and i dont have any good knowledge about it….please give me some information

      • Paul Stewart says:

        The vlan interfaces on the 5505 is just how you do it. On the 5510 and up, each interface is a physical interface or a 802.1q sub interface. The other concepts are the same. In transparent mode, frames flow through the ASA. In routed mode packets flow through the ASA. That is a little bit of a misnomer, but is true from a transit perspective. Obviously, the frames in transparent mode operation may contain packets.

        When the ASA goes to session flows and maintain state, the inspection happens at layer 3 and 4. This is typically true regardless of mode. There are some minor nuances. However, I think that frame of reference is a starting point.

  3. techuser says:

    Thanks for this post, but I have a question or a problem , I configured my ASA 5510 in transparent mode , after connecting it to the network , Outlook on local PCs started having connection problems (disconnect and reconnect to exchange every 1 min or so), Exchange is configured as cluster on VM using MS NLB , I have noticed that when shutting down ASA the problem stops, I disconnected the router and ASA and left the ASA connected to the switch I have noticed that I still have logs from and to the exchange cluster!! why this is happening and why I have loggs in first place on ASA although the traffic from local PCs to exchange cluster shouldn’t even go to ASA because there are on the same subnet ??

    • There are a few points I can make about this. However, fully troubleshooting this may beyond the scope of what we can reasonably do in an online forum. Fully resolving this may require one or more of the following processes:

      • Working with Microsoft Support to understand what is going on with the Outlook/Exchange connections
      • Working with TAC on the ASA Support
      • Digging into Wireshark Captures to see what is different when the ASA is added to the network

      My initial thought it is really hard to troubleshoot this without a little bit of topology information. In my experience, Exchange has also had a tendency to do some strange thing. Microsoft load balancing has different methods of handling the shared IP address. These methods may also be impacted by how the ASA works in transparent mode.

Comments are closed.