Cisco ASA can run in two firewall modes: routed mode, where the firewall is a Layer 3 hop with its own IP address on each interface, and transparent mode, where the firewall behaves like a Layer 2 bridge with a single management IP and no routing of its own. Most ASAs in the field run routed mode, because that is what the default configuration ships with and what every walkthrough on this site assumes. Transparent mode is a deliberate choice that solves a specific class of problem: dropping a firewall into an existing subnet without re-IP'ing anything. This article covers both modes, the trade-offs, the configuration commands, and the things that quietly break when you flip the global mode flag.
If you arrived here from the cluster index, see Cisco ASA: The Complete Reference for the full reading order. If you are coming back to it later, the short version is: pick routed unless you have a hard requirement that forces transparent, and never flip the mode flag on a production firewall without a maintenance window.
What Firewall Mode Actually Controls
Firewall mode is a global configuration switch. It changes the entire forwarding model of the box. In routed mode, every data interface needs an IP address and a security level, and the ASA participates in routing decisions like any other Layer 3 device. The ASA can run static routes, OSPF, EIGRP, or BGP, advertise its connected interfaces, and act as the next hop for the hosts behind it.
In transparent mode, the ASA does not own IP addresses on data interfaces. Instead, two or more interfaces are paired into a bridge group with a single shared BVI (Bridge Virtual Interface) IP that exists only for management traffic sourced from the ASA itself (syslog, SNMP, AAA, NTP). Hosts on the inside and outside interfaces stay in the same subnet; their default gateway remains the upstream router; the ASA simply inspects the frames as they pass through.
That fundamental difference cascades through every feature on the platform. NAT, ACLs, inspection engines, and packet capture all work in both modes, but routing protocols, dynamic VPN client pools, and a handful of inspection engines are routed-mode-only. The reverse is not true: anything that works in transparent mode also works in routed mode.
When Each Mode Fits
The decision is almost always settled by the surrounding network, not by the firewall itself.
| Use case | Mode that fits | Why |
|---|---|---|
| Greenfield internet edge with NAT | Routed | NAT to a public pool, default route to ISP, BGP or static. All routed-mode bread and butter. |
| Site-to-site VPN concentrator | Routed | Crypto map and VTI both terminate on a routed interface with its own IP. |
| AnyConnect remote-access VPN | Routed | VPN-POOL handed out to clients lives on a routed interface and needs return routing on the inside. |
| Drop-in firewall on an existing subnet (no re-IP) | Transparent | The hosts and their gateway stay where they are; the ASA inspects the frames between them. |
| "Bump in the wire" for a database tier you cannot disturb | Transparent | Same VLAN on both sides, the ASA is invisible to the application. |
| Compliance overlay (PCI segmentation, HIPAA enclave) | Transparent | Auditor wants stateful inspection between two existing subnets without changing the topology. |
| Multi-context with shared interfaces in service-provider style | Routed | Each context gets its own IP per interface; transparent contexts cannot share an interface. |
If the question is "can I make it work in transparent mode," the answer is usually yes; if the question is "should I," the answer is usually no, unless the IP-preservation requirement is real and immovable.
Check Which Mode You Are In Today
Before you change anything, confirm the current mode.
ASA-PERIM# show firewall
Firewall mode: Router
ASA-PERIM# show mode
Security context mode: single
Two separate switches, two separate show commands. show firewall tells you routed vs transparent. show mode tells you single vs multiple context. The two are independent: you can have a single-context routed firewall, a single-context transparent firewall, a multi-context routed firewall, or a multi-context transparent firewall (with limits on which features each combination supports).
Routed Mode Config: Quick Reference
This is the default and what most walkthroughs on the site (including Cisco ASA Inside/Outside/DMZ Configuration Walkthrough) assume. Each data interface gets a name, a security level, and an IP.
ASA-PERIM(config)# interface GigabitEthernet0/0
ASA-PERIM(config-if)# nameif outside
ASA-PERIM(config-if)# security-level 0
ASA-PERIM(config-if)# ip address 203.0.113.2 255.255.255.252
ASA-PERIM(config-if)# no shutdown
ASA-PERIM(config-if)# interface GigabitEthernet0/1
ASA-PERIM(config-if)# nameif inside
ASA-PERIM(config-if)# security-level 100
ASA-PERIM(config-if)# ip address 10.10.0.254 255.255.255.0
ASA-PERIM(config-if)# no shutdown
ASA-PERIM(config)# route outside 0.0.0.0 0.0.0.0 203.0.113.1 1
From there, NAT, ACLs, and VPN are all standard. See Cisco ASA NAT Explained and Cisco ASA ACL Configuration for the next steps.
Switching to Transparent Mode (Destructive)
This is the command that scares people, and rightly so:
ASA-PERIM(config)# firewall transparent
WARNING: This action will clear all configuration commands except access list, capture, established,
file, ip address management-only, ipv6 address management-only, mac-address, mtu, nameif,
nat-pool, network object, object-group, password-policy, pim, route-map, route, snmp,
ssh, telnet, vlan, and the ones used to manage features such as logging, snmp, ntp, etc.
"Will clear all configuration commands" is not hyperbole. The ASA dumps NAT rules, dynamic routing, VPN configuration, and most service-policy maps. Saved-config you have on a TFTP server is not portable to transparent mode without rework. Run write erase, switch the mode, then load the transparent-style config.
Reverse it with no firewall transparent. Same destructive behavior in the other direction.
Transparent Mode Config: Bridge Group + BVI
In transparent mode, two or more data interfaces are joined into a bridge group. The BVI (Bridge Virtual Interface) carries a single management IP that the ASA uses to source its own traffic and for SSH/HTTPS access.
ASA-EDGE(config)# firewall transparent
ASA-EDGE(config)# interface GigabitEthernet0/0
ASA-EDGE(config-if)# nameif outside
ASA-EDGE(config-if)# security-level 0
ASA-EDGE(config-if)# bridge-group 1
ASA-EDGE(config-if)# no shutdown
ASA-EDGE(config-if)# interface GigabitEthernet0/1
ASA-EDGE(config-if)# nameif inside
ASA-EDGE(config-if)# security-level 100
ASA-EDGE(config-if)# bridge-group 1
ASA-EDGE(config-if)# no shutdown
ASA-EDGE(config-if)# interface BVI 1
ASA-EDGE(config-if)# ip address 10.10.0.250 255.255.255.0
ASA-EDGE(config)# route outside 0.0.0.0 0.0.0.0 10.10.0.1 1
Notice that there are no IPs on the data interfaces. The BVI sits at 10.10.0.250, which is in the same subnet that the inside hosts already use. Their default gateway stays at 10.10.0.1 (the upstream router), and the ASA quietly bridges those frames toward outside.
The static route outside is for traffic that the ASA itself originates: syslog to a remote server, NTP to time.example.com, SNMP traps to a NMS. Hosts behind the ASA still route via their existing gateway.
Verify the bridge group:
ASA-EDGE# show bridge-group
Bridge Group: 1
Interfaces:
GigabitEthernet0/0 (outside)
GigabitEthernet0/1 (inside)
Management System IP Address: 10.10.0.250 255.255.255.0
Static mac-address entries: 0
Dynamic mac-address entries: 14
ASA-EDGE# show mac-address-table
interface mac address type Time Left
-----------------------------------------------------------------------
outside aabb.cc00.0100 dynamic 5
inside aabb.cc00.0200 dynamic 5
inside aabb.cc00.0201 dynamic 5
The MAC address table is the transparent-mode equivalent of the routing table: it tracks which interface each MAC is reachable through, and it expires entries that go silent.
What You Lose in Transparent Mode
Transparent mode preserves a lot, but not everything. Plan around the following before you flip the switch.
| Feature | Status in transparent mode |
|---|---|
| Dynamic routing protocols (OSPF, EIGRP, BGP, RIP) | Not supported. Static routes only, and only for ASA-sourced traffic. |
| DHCP relay | Supported only on bridge-group interfaces; DHCP server on the ASA is supported but rarely used here. |
| QoS | Limited. |
| Multicast routing | Multicast bridging works (just forwarded across the bridge); multicast routing as a feature does not. |
| VPN termination on the data plane (RA VPN, S2S terminating on a transparent interface) | Not supported on the bridged side. Management-IP-terminated S2S is supported with restrictions. |
| NAT | Supported, but only between bridge-group members on the same bridge group, and use cases are narrow. |
| Multiple context with shared interfaces | Each context gets its own bridge group; you cannot put one interface in two transparent contexts. |
| ARP inspection | Supported and very useful in transparent mode; arp-inspection inside enable. |
| BPDU forwarding | By default, the ASA forwards BPDUs. Disable with caution; STP loops upstream of a transparent ASA are awful to debug. |
The biggest practical loss is dynamic routing. If you need OSPF or BGP at the firewall, transparent mode is off the table.
ACLs Work the Same in Both Modes
One pleasant surprise: ACL syntax, NAT object syntax, and inspection-engine syntax are identical between routed and transparent modes. An access-list OUTSIDE_IN extended permit tcp any object DMZ-WEB eq https means the same thing in both. The pillar's ACL configuration guide and NAT explained walkthroughs both apply.
Transparent mode adds one extra capability: EtherType ACLs. These let you filter non-IP frames (IPX, MPLS, ARP). They are configured separately from extended ACLs and bound with access-group the same way.
ASA-EDGE(config)# access-list ALLOW-MPLS ethertype permit mpls-unicast
ASA-EDGE(config)# access-list ALLOW-MPLS ethertype permit mpls-multicast
ASA-EDGE(config)# access-group ALLOW-MPLS in interface inside
Routed mode does not understand EtherType ACLs (it never sees the EtherType, only the IP packet). If you need to filter at the L2 frame level, transparent is the only mode that can do it.
Diagnostic Commands by Mode
Some show commands behave differently. Use the right ones for the mode you are in.
| Command | Routed mode | Transparent mode |
|---|---|---|
show route | Full RIB with connected, static, dynamic | Only ASA-sourced static routes; thin output |
show interface ip brief | Each data interface has an IP | Data interfaces show "unassigned"; only BVI has an IP |
show bridge-group | Empty / no output | Lists bridge groups, member interfaces, and BVI IP |
show mac-address-table | Available but rarely used | Primary forwarding table |
show arp | Standard ARP cache for connected subnets | Standard ARP cache for the BVI subnet only |
show conn | Same flag legend | Same flag legend |
packet-tracer | Full pipeline including UN-NAT and NAT | Same phases; routing phase shows BVI/bridge-group output |
packet-tracer still works in transparent mode, which is great because diagnosing a transparent firewall by sight is harder than diagnosing a routed one (the firewall is invisible to the data plane).
Mode Interacts with Multi-Context
The two global flags (firewall transparent and mode multiple) are independent, but their interaction has rules. In multi-context mode, every context is either routed or transparent, set on a per-context basis. You can mix and match: a perimeter routed context that does NAT and VPN, plus a separate transparent context that protects a database tier on the inside. Shared interfaces are not supported between transparent contexts.
See Cisco ASA Multiple Context Mode for the full configuration model. Switching between single and multi-context is also destructive; treat both global flags with the same caution.
What I Actually See in the Field
Across the ASA fleets I have worked on, transparent mode is rare. The cases where it shows up are real but narrow: a bank that needed to slot a firewall between its trading floor and the rest of the LAN without renumbering anything; a hospital that needed PCI-style segmentation between a payment-card subnet and the same VLAN that ran the rest of the office; an MSP that inherited a customer environment where re-IP was politically impossible. In every case, the team that built it understood that they were giving up dynamic routing and accepting a thinner toolset in exchange for not touching the existing IP plan.
For everything else (internet edge, VPN concentrator, DMZ publishing), routed mode is the default for good reason. Most of the rest of this cluster covers routed-mode tasks: static routing, NAT, ACLs, AnyConnect, and failover.
Key Takeaways
Routed mode is the default, supports the full feature set, and is what every other article on this site assumes. Transparent mode is a deliberate choice that solves the "drop a stateful firewall into an existing subnet without re-IP" problem and accepts the loss of dynamic routing, VPN data-plane termination, and a handful of other features.
Confirm the current mode with show firewall before changing anything. Switching modes is destructive: firewall transparent wipes most of the running configuration. If you need transparent mode, plan a maintenance window, save the existing config off-box, switch the mode, and reload the transparent-style config from scratch.
For the next step in the cluster, see Cisco ASA Interfaces, Subinterfaces, and VLAN Trunks, which covers the underlying interface configuration that both modes depend on. And the Cisco ASA pillar has the full reading order for the rest of the platform.
