Configuring a Transparent Firewall on the ASA

We learned the first lesson of transparent-mode firewalls the hard way, live, mid-command. Typing firewall transparent on our ASAv did not politely switch a mode setting. It cleared our interface, policy, and management configuration, and because our SSH access and routing were part of that configuration, it dropped our management session on the spot. One command, one disconnected engineer. If you take nothing else from this article, take this: switching firewall mode is destructive, and you do it from the console with a saved config, never remotely on a box you cannot physically reach. This is part of our Cisco ASA series and it goes deeper than our routed versus transparent overview, with the reference configuration and a new run in my home lab proving traffic through the bridge.

The gotcha that bites everyone: firewall transparent wipes the config

The firewall transparent command changes more than a mode setting. In the new ASAv 9.24(1) run, it reset the hostname and removed the interface addressing and management configuration; management access had to be rebuilt. Default CA configuration remained, so “every line disappears” would overstate the reset. Treat the change as destructive: save the configuration and use the console.

On our box, that meant the SSH session we were typing into simply ended. The command took effect, the config that defined our access evaporated, and the connection died mid-stream. We rebuilt FW1 from a fresh transparent-mode day-zero configuration afterward, from the console, which is the only sane way to do it. The takeaway is procedural and non-negotiable: back up your config first, get to the console (physical or out-of-band), switch the mode there, and rebuild from a prepared transparent-mode config. Doing this over the network on a production firewall is how you turn a maintenance window into a site visit.

What transparent mode actually is

A transparent firewall operates at Layer 2. Instead of routing between subnets, it bridges between them, sitting in the path like a bump in the wire. Both data interfaces live in the same IP subnet and the same bridge group, and the firewall forwards frames between them while applying its security policy. To the devices on either side, there is no router hop; traffic appears to pass straight through, and a traceroute across the firewall shows nothing where the ASA sits.

That invisibility is the entire appeal. You can drop a transparent firewall into an existing segment without renumbering anything, without changing default gateways, and without the endpoints ever knowing a firewall was inserted. It is the classic way to add inspection and filtering to a network you are not allowed to re-architect. Where a routed firewall is a visible Layer 3 hop with its own interface subnets, a transparent firewall is a silent Layer 2 device that filters what passes through it. Our routed versus transparent article compares the two modes side by side; this one shows the transparent build in detail.

The transparent config: bridge-group and BVI

Here is the shape of a minimal transparent configuration. The data interfaces have no separately configured IP addresses; they join a bridge group, and a Bridge Virtual Interface (BVI) carries the group’s address. This reference example uses the BVI for management. The home-lab test below also has a separate management interface.

firewall transparent
interface GigabitEthernet0/0
 nameif outside
 security-level 0
 bridge-group 1              <-- interfaces are bridged, NOT routed
interface GigabitEthernet0/1
 nameif inside
 security-level 100
 bridge-group 1
interface BVI1
 ip address 10.20.10.5 255.255.255.0   <-- ONE management IP for the whole bridge group
access-list OUT-IN extended permit ip any any
access-group OUT-IN in interface outside

Read the structure. Both physical interfaces get a nameif and a security level, but no IP; they join bridge-group 1. The BVI1 interface carries the one management IP for the entire bridge group, 10.20.10.5. Because both data interfaces are in the same bridge group and the same subnet, the firewall bridges frames between them rather than routing packets. The extended ACL still governs IP traffic exactly as it would in routed mode, so your familiar permit and deny logic is unchanged; what changes is the plumbing underneath it.

This is the mental model to copy: two bridged data interfaces, one BVI management IP, no per-interface Layer 3, and your IP ACLs applied on top. The firewall becomes a filtering bridge.

Real proof: the BVI is reachable at Layer 2

The earlier router test established that ISP1 could ARP for the BVI and reach it as a neighbor on the outside segment. That checks reachability to the firewall itself. To prove forwarding through the bridge, we also need endpoint traffic crossing from one member interface to the other, as in the new lab below.

ISP1# show arp | include 10.20.10.5
Internet  10.20.10.5   1   5254.004e.feaa  ARPA   Ethernet0/1     <-- BVI MAC learned via the transparent FW

ISP1# ping 10.20.10.5 repeat 3
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 2/2/4 ms

ISP1 learned the BVI MAC by ARP and received three ping replies. The BVI was reachable on that segment. That result alone does not establish inside-to-outside transit forwarding; the endpoint tests below provide that evidence.

Data path update: forwarding verified in my home lab

The earlier virtual topology did not produce a clean inside-to-outside forwarding result after the mode change. The new five-node run in my home lab does: an ASAv 9.24(1) bridge between two IOL switches passed ICMP and HTTP in both directions between same-subnet endpoints. A held TCP connection also appeared in the ASA connection table.

That new result replaces the earlier data-path limitation. It does not establish the cause of the old failure, so the earlier attribution to virtual-switch state should not be treated as a diagnosis. The lab before “Key Takeaways” covers the working bridge, ARP inspection, and a BPDU fault that successful application probes alone missed.

Routed and transparent, structurally

The two modes differ in where the intelligence lives, and seeing the structural contrast side by side makes the transparent config above click into place.

What transparent mode gives up

Transparency is not free, and knowing the trade-offs keeps you from choosing it for the wrong job. Because the firewall does not route through-traffic, it does not participate in your routing protocols for the data path the way a routed-mode firewall can; it simply bridges the frames that carry those protocols. Features that depend on the firewall being a Layer 3 hop behave differently or are unavailable, and NAT in transparent mode is more constrained than the full routed-mode NAT toolset. The BVI is for management reachability, not for routing user traffic between subnets, so if your requirement is genuinely to route between two different subnets, transparent mode is the wrong tool and you want routed mode.

What you gain in return is the ability to insert security into a segment you are forbidden from re-addressing, and to filter traffic types a routed firewall never even sees, which is the subject of the EtherType-ACL article next in this series. The decision comes down to a single question: do you need the firewall to be a router, or do you need it to be an invisible filter on an existing wire? If the answer is invisible filter, transparent mode is exactly right, provided you respect the destructive mode switch and verify both the transit data path and the intended BPDU behavior.

Design notes for a real deployment

A few things to plan for when you build this outside a lab. Give the BVI a management IP in the same subnet as the segment you are inserting into, and make sure whatever needs to manage the firewall can reach that subnet at Layer 2. Keep the security levels meaningful: the outside interface at 0 and the inside at 100 preserves the usual higher-to-lower default logic, which still governs IP traffic even though the firewall is bridging. And remember that because the firewall is invisible as a hop, your endpoints keep their existing gateways and addressing; you are inserting a filter, not a router, and nothing on either side needs to be renumbered.

Check spanning tree before and after inserting the firewall. In this ASAv 9.24(1) run, BPDUs crossed without an EtherType ACL. An explicit BPDU deny then separated the two switches’ root elections while their IP traffic continued to pass. EtherType policy and IP policy need separate checks: verify the intended root on both switches, the ASA-facing port roles, and BPDUs on both data links.

Plan the maintenance window around the config wipe. Because switching to transparent mode removes the existing interface and management configuration, the cleanest procedure is to prepare the full transparent-mode configuration in advance as a text file, get console access, issue firewall transparent, and paste the prepared config. That turns a potentially session-killing surprise into a controlled, scripted change. It is the same discipline that separates a smooth firewall insertion from a two-hour outage, and it flows directly from the lesson we learned the hard way at the top of this article.

Home lab: bridge group, ARP inspection, and the BPDU gotcha

Ping and HTTP worked while the switches disagreed about the STP root. That was the useful failure in this five-node home-lab run: the ASA still forwarded IP traffic, but an explicit BPDU deny separated the spanning trees on either side.

Before introducing that fault, we verified the transparent data path and tested ARP inspection with a deliberately wrong host MAC. The excerpts below are from the recorded ASAv 9.24(1) run on 18 October 2026. A whole ... line marks omitted output.

A separate address plan for this lab

This topology used one ASAv 9.24(1) guest, two IOL L2 17.18.02 switches, and two Alpine 3.24.2 endpoints. It has one chain of four data links, with no redundant path.

The ASA interface names here are reversed from the earlier reference configuration: Gi0/0 is inside in this lab. All four switch data ports stay in VLAN 10 throughout the fault. The endpoints share a subnet, so reaching each other needs neither an ASA next-hop route nor the BVI as a default gateway. Management uses a separate interface and is outside the traffic tests.

The ASAv boot and first-packet walkthrough covers getting to a usable appliance. Change firewall mode from the console before rebuilding the configuration. This is a functional test, not a throughput benchmark.

Build the bridge and prove transit traffic

At the ASA configuration CLI, these were the applied data-interface, BVI, and IP-policy commands. The two extended ACLs permit only the tested host-to-host ICMP and TCP/8000 flows:

interface GigabitEthernet0/0
description BRIDGE_INSIDE_TO_SW_IN_ETH0_1
nameif inside
security-level 100
bridge-group 1
no shutdown
interface GigabitEthernet0/1
description BRIDGE_OUTSIDE_TO_SW_OUT_ETH0_1
nameif outside
security-level 0
bridge-group 1
no shutdown
interface BVI1
ip address 192.0.2.1 255.255.255.0
exit
access-list INSIDE_IN extended permit icmp host 192.0.2.10 host 192.0.2.20
access-list INSIDE_IN extended permit tcp host 192.0.2.10 host 192.0.2.20 eq 8000
access-list OUTSIDE_IN extended permit icmp host 192.0.2.20 host 192.0.2.10
access-list OUTSIDE_IN extended permit tcp host 192.0.2.20 host 192.0.2.10 eq 8000
access-group INSIDE_IN in interface inside
access-group OUTSIDE_IN in interface outside

On the ASA, show firewall and show bridge-group confirmed the mode and membership. Excerpt:

asa-tfw# show firewall
 show firewall
Firewall mode: Transparent
...
 Bridge Group: 1 
 Interfaces: 
 GigabitEthernet0/0
 GigabitEthernet0/1

From host-in, the test sent three pings to 192.0.2.20 and requested http://192.0.2.20:8000/. Host-out repeated the probes toward 192.0.2.10. Curl used the data addresses and bypassed proxies. The baseline results, in that order, were:

--- 192.0.2.20 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
...
< HTTP/1.0 200 OK
...
--- 192.0.2.10 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
...
< HTTP/1.0 200 OK

A separately held TCP socket also appeared in the ASA connection table. This is a real connection, rather than a packet-tracer simulation:

asa-tfw# show conn
 show conn
1 in use, 5 most used

TCP outside  192.0.2.20:8000 inside  192.0.2.10:52136, idle 0:00:04, bytes 27, flags UO 

ARP inspection: reject the wrong MAC, then restore it

At the ASA configuration CLI, bind host-in's IP to its legitimate MAC and enable inspection on inside:

arp inside 192.0.2.10 0216.6600.0010
arp-inspection inside enable

The inside row from show arp-inspection was:

inside                   enabled                flood

After flushing both endpoints' eth1 neighbor tables, the legitimate host still passed ICMP and HTTP in both directions. The test then changed only host-in's MAC to 02:16:66:00:00:99, flushed both neighbor tables again, and repeated the probes. Both directions lost all three pings; both HTTP connections failed as unreachable. The inside-to-outside ping excerpt was:

--- 192.0.2.20 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Paired data-link captures counted twelve ARPs advertising the wrong host-in MAC on the inside link and none on outside. The ASA's buffered log identified the exact static-binding mismatch:

%ASA-3-322002: ARP inspection check failed for arp request received from host 0216.6600.0099 on interface inside. This host is advertising MAC Address 0216.6600.0099 for IP Address 192.0.2.10, which is statically bound to MAC Address 0216.6600.0010

Here, flood applies to unknown bindings; it did not let a known IP advertise a different MAC. Restoring host-in to 02:16:66:00:00:10 and flushing both eth1 neighbor tables restored three replies and HTTP success in each direction. A learned MAC entry alone was misleading: the wrong MAC briefly remained in the MAC table even though its ARPs were rejected.

No dedicated ARP-inspection counter appeared in show asp drop. Use the log and the paired captures for attribution; a generic L2 drop count does not identify an ARP-inspection failure. The ASA ASP drop walkthrough explains how to tie counters to a specific test.

Baseline BPDUs crossed without an EtherType ACL

Before the BPDU fault, no EtherType ACL was applied. In this image and access-link setup, the captures showed IEEE 802.1w LLC BPDUs addressed to 01:80:c2:00:00:00 crossing the ASA. One decoded baseline frame was:

21:16:13.822535 aa:bb:cc:00:04:10 > 01:80:c2:00:00:00, 802.3, length 39: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id 100a.aa:bb:cc:00:04:00.8002, length 36
	message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 100a.aa:bb:cc:00:04:00, root-pathcost 0, port-role Designated

Eight identical BPDU frames appeared on both ASA data links during that 16-second baseline capture. Both switches selected sw-in, bridge ID 4106 / aabb.cc00.0400, as root; sw-out's ASA-facing Et0/1 was its forwarding root port. This is the observed baseline for this run, not a claim about every ASA image or STP variant.

Block BPDUs while leaving the IP tests green

At the ASA configuration CLI, the deliberate fault added a BPDU deny followed by a permit for other EtherTypes, inbound on both bridge members:

configure terminal
access-list BRIDGE_L2 ethertype deny bpdu
access-list BRIDGE_L2 ethertype permit any
access-group BRIDGE_L2 in interface inside
access-group BRIDGE_L2 in interface outside
end

The separate INSIDE_IN and OUTSIDE_IN IP ACLs stayed applied. ASA normalized the BPDU entry to dsap bpdu. After the recorded 25-second wait, the ACL showed:

access-list BRIDGE_L2; 2 elements
access-list BRIDGE_L2 ethertype deny dsap bpdu(hitcount=23)
access-list BRIDGE_L2 ethertype permit any (hitcount=7)

Both switches now elected themselves root. On sw-in, the root portion of show spanning-tree vlan 10 was:

  Root ID    Priority    4106
             Address     aabb.cc00.0400
             This bridge is the root

On sw-out, the same command showed a different root, and its ASA-facing port had become designated forwarding:

  Root ID    Priority    8202
             Address     aabb.cc00.0500
             This bridge is the root
...
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/1               Desg FWD 100       128.2    P2p 

The fault capture contained eight BPDUs sourced by sw-in on inside and eight sourced by sw-out on outside, with zero identical BPDU copies shared between links. Yet ICMP still passed 3/3 and HTTP returned status 200 in each direction. The fault separated root elections; it did not interrupt the tested IP traffic.

Both switches reported zero inconsistent ports. This chain had no redundant link, and the run did not reproduce a loop, storm, MAC flap, or PVID inconsistency. Check root identities and BPDU sources alongside application probes. For the root-port calculation behind the healthy state, see the worked STP election example.

Repair the saved ACE, then verify both planes

The first repair attempt tried to remove the shorthand deny and add a BPDU permit. ASA rejected that removal:

asa-tfw(config)# no access-list BRIDGE_L2 ethertype deny bpdu
 no access-list BRIDGE_L2 ethertype deny bpdu
Specified access-list does not exist

Adding the permit was accepted and saved in normalized form:

asa-tfw(config)# access-list BRIDGE_L2 ethertype permit bpdu
 access-list BRIDGE_L2 ethertype permit bpdu
INFO: ethertype bpdu is saved to config as ethertype dsap bpdu

But the deny still came first. After the wait, deny hits rose while the permit stayed at zero:

access-list BRIDGE_L2; 3 elements
access-list BRIDGE_L2 ethertype deny dsap bpdu(hitcount=16)
access-list BRIDGE_L2 ethertype permit dsap bpdu(hitcount=0)
access-list BRIDGE_L2 ethertype permit any (hitcount=0)

The successful correction removed the exact saved deny at the ASA configuration CLI. This sequence depends on the BPDU permit already added by the preceding attempt:

configure terminal
no access-list BRIDGE_L2 ethertype deny dsap bpdu
end

The resulting bindings and ACL showed both IP policies still present, the BPDU permit first, and twelve permit hits after the recorded 15-second wait:

access-group BRIDGE_L2 in interface inside
access-group INSIDE_IN in interface inside
access-group BRIDGE_L2 in interface outside
access-group OUTSIDE_IN in interface outside
...
access-list BRIDGE_L2; 2 elements
access-list BRIDGE_L2 ethertype permit dsap bpdu(hitcount=12)
access-list BRIDGE_L2 ethertype permit any (hitcount=41)

Sw-in remained root. On sw-out, show spanning-tree vlan 10 again identified sw-in as root and Et0/1 as the forwarding root port:

  Root ID    Priority    4106
             Address     aabb.cc00.0400
             Cost        100
             Port        2 (Ethernet0/1)
...
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/1               Root FWD 100       128.2    P2p 

The repaired 16-second capture had seven identical BPDU copies on both links, all sourced by sw-in. Counts belong to their individual capture windows; eight before and seven after do not measure convergence time or packet loss. The repeated real probes still passed, inside-to-outside and then outside-to-inside:

--- 192.0.2.20 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
...
< HTTP/1.0 200 OK
...
--- 192.0.2.10 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
...
< HTTP/1.0 200 OK

Later ASA verification recorded 25 BPDU-permit hits and three successful packet-tracers: inside ICMP and TCP, plus outside TCP. On this image, transparent packet-tracer syntax places the destination MAC before the destination IP. The working commands were:

packet-tracer input inside icmp 192.0.2.10 8 0 0216.6600.0020 192.0.2.20 detailed
packet-tracer input inside tcp 192.0.2.10 41000 0216.6600.0020 192.0.2.20 8000 detailed
packet-tracer input outside tcp 192.0.2.20 42000 0216.6600.0010 192.0.2.10 8000 detailed

The final check is a shared STP root plus real endpoint traffic. A successful ping alone would have missed the BPDU fault entirely.

Key Takeaways

• Switch firewall mode from the console. The mode change removes interface and management configuration; prepare the replacement configuration and save the old one first.
• The data path is verified. In the new ASAv/IOL run in my home lab, same-subnet hosts passed ICMP and HTTP in both directions through bridge-group 1.
• BVI reachability and transit forwarding are separate checks. The earlier router test reached the BVI; the new endpoint tests crossed the bridge.
• ARP inspection rejected the known IP with the wrong MAC. Twelve mismatched ARPs reached inside and none crossed to outside; restoring the legitimate MAC restored traffic.
• A green ping does not prove a healthy STP domain. The BPDU deny split the root election while IP traffic passed. Removing the exact normalized deny restored a shared root and sw-out’s forwarding root port.

Transparent mode is a powerful way to insert a firewall without touching Layer 3, as long as you respect the destructive mode switch and plan the insertion. Continue in the Cisco ASA series with the one capability transparent mode has that routed mode never will: filtering non-IP frames with EtherType ACLs, and revisit the routed versus transparent comparison for when to choose each mode.