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: - How does the ASA in transparent mode know which interface remote networks should be reached through?
- What is permitted at layer 2 disregarding- layer 3 restrictions?
In addition, I’d like to pose one more question: - 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: - A frame is destined to a remote network
- There is a route in the route table for the destination
- 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. If you found this document useful, please share it with your friends. If you have anything to add, please comment below.
|
