In this blog I’d like to examine the behavior of a transparent firewall in greater detail. Before we get to this, however, it may be a good idea to recall what happens when the ASA is running in the default firewall mode – routed. In routed mode, the ASA is considered to be a router hop in the network. We have many interfaces and each of them requires an IP address from a different subnet. Routing configuration can be simplified since the firewall supports multiple dynamic routing protocols. Also most of the other features are supported on the routed ASA.
In transparent mode, things change a bit. Transparent firewall is more of a Layer 2 device that acts like a “bump in the wire,” or a “stealth firewall,” and is not seen as a router hop to connected devices (ASA is “invisible” at Layers 2 and 3). ASA’s interfaces belong to a single Bridge Group (different VLANs on the switch side) but all devices (including the firewall) are part of a single L3 subnet. Certain features (like routing protocols, multicast routing) are not supported in this mode, few features were added (e.g. ARP Inspection, CAM Table protection) and almost any traffic can pass through the device (IP & EtherType access-lists).
Alright so now when have gone through a short comparison of the two firewall modes, let’s think about specifics – and what I want to focus on here are the operational differences from the routed mode. This mode is probably well-understood by most of you since it is very similar to the way routers operate – before a packet is forwarded routing table is looked up to find the longest match (for the destination IP address from the packet), then an egress interface is found (or next-hop and egress interface), packet is switched, re-enacpsulated with new L2 information (L2 source and destination) and finally serialized onto the wire.
What’s different in the Transparent mode? First of all – the outgoing interface of a packet is determined by performing a MAC address lookup instead of a route lookup. This is because the firewall simply switches the frame based on L2 information instead of trying to route it (it looks up the frame’s destination MAC in the CAM). There are only three exceptions to this rule :
- Traffic originated by the ASA to a non-local (remote) destination
- Traffic that is at least one hop away from the ASA with NAT enabled
- Voice over IP (VoIP) and DNS traffic with inspection enabled when the endpoint is at least one hop away from the ASA
In the above-mentioned cases routing table lookup is necessary for successful traffic forwarding.
OK, but let’s start with the beginning. How does the ASA populate its CAM table? It learns and builds a MAC address table in a similar way as a normal bridge or switch – when a device sends a packet through the ASA (e.g. a data packet), the ASA adds the source MAC address to its CAM. It also associates the MAC address with the source interface.
Next is traffic forwarding. It is when the populated CAM table is used to find the outgoing interface for the frames (after firewall-enabled features were applied, like for example inspection).
Let’s quickly take a look at this using the topology below :
After all devices were powered on, the ASA learnt four MACs – two on the inside and two on the outside:
Two of these addresses belong to the directly connected switch (ports connected to the ASA), one belongs to R2 and one to R5. These addresses were learnt by the ASA from the Control Plane packets such as BPDUs and ARP. So when I ping from R2 to R5, we should see a frame destined to 001b.d50f.f2f8 and when a reply comes back we should see it with destination 001b.d4a9.e400. This way ASA knows that packet #1 should be sent via outside, packet #2 via inside (both packets are shown as seen by the ASA on the inside and outside) :
Pay attention to L2 and L3 addresses – none was changed by the ASA. Also TTL was not decremented meaning the ASA was completely invisible to the routers.
Now what would change if I were to reach a remote destination from R2? Like if I send a packet to 5.5.5.5 ? Nothing even that ASA does not have any route in the RIB :
Also notice that in both cases ARP cache on the ASA is blank – it would be only used if ASA itself wanted to send a packet :
OK so does it mean that transparent ASA operates exactly like a regular bridge/switch all the time? No, there is one difference. When there is no matching entry for the frame in the CAM (i.e. destination MAC was not found) the ASA will do the following :
- If a packet is L3-destined to the local (ASA’s) subnet, firewall generates an ARP request (out of every enabled interface) for the destination IP address, so that it can learn the MAC and outgoing interface
- If a packet is for a remote device (L3), the ASA generates a TTL 1 ping to the destination IP address (keeping the original, unknown L2 destination). The Echo packet is sent out every interface except the one where the original packet was received on hoping to get a TTL-Exceed message to figure out the correct port. Note that you don’t need a L3 route so that ASA can generate those Echos
To test this behavior we will have to make some changes on R2 – I am going to add a static ARP entry for a non-existing device 172.3.245.6 :
Take a look at the MAC addresses of the ASA and observe a debug (l2-indication) :
Two ARP Requests were sent, one via inside and one via outside, received by R2 and R5, respectively. In our case there is no 172.3.245.6 device so nothing replies – the original packets are dropped.
To finish, let’s look at the second case, when a L3 destination is non-local :
Note that only one Echo was generated, through the outside port. If we had more interfaces, like e.g. 3, we would see 2 Echos (it does not generate a packet for the interface where it got the original frame).
Happy Labbing! – Piotr Kaluzny CCIE #25665 (Security) / CCIE Security Instructor – iPexpert, Inc.
About Piotr: Piotr, a MSc in Computer Science, has been in the networking industry for over seven years working in several different capacities within enterprise Cisco environments. His responsibilities included, but were not limited to, implementation, design, and level three technical support. Piotr already has an extensive background as a Technical Instructor – he has been designing and developing Cisco training solutions and teaching CCIE classes for the past four years.
Currently, he’s the author / instructor for iPexpert’s CCNA VOD, CCNP VOD, CCIE Written VOD, CCIE Security Lab Prep VOD, CCIE Security Workbook Volume 1, CCIE Security Workbook Volume 2, and he teaches iPexpert’s CCIE Security 5-Day Bootcamp and CCIE Security 10-Day Lab Preparation Bootcamps.
