Transparent Mode ACLs: EtherType Rules and What Bridges Through

Every ACL you have ever written on a firewall operates on IP: source address, destination address, port, protocol. A routed firewall never sees anything else, because anything that is not IP is simply not its concern. A transparent firewall is different. Because it bridges at Layer 2, it can see and filter non-IP frames that a routed firewall never touches, and the tool for that is the EtherType ACL. This is the one security capability that is genuinely unique to transparent mode, and it is part of our Cisco ASA series. If you have not seen how a transparent firewall is built, start with our transparent firewall configuration article first, because everything here assumes that bridged-mode foundation.

An EtherType ACL filters frames by their Layer 2 EtherType value, the field in the Ethernet header that says what kind of payload the frame carries. IP is one EtherType. But so are spanning-tree BPDUs, PPPoE, MPLS, and a long list of other non-IP frame types. A routed firewall drops or ignores most of these because it only forwards IP. A transparent firewall bridges them, which means it can also filter them, and that is a control no routed device can offer.

The EtherType ACL syntax

The syntax mirrors a normal ACL but matches on frame types instead of IP tuples. You build the access-list, then apply it to an interface with an access-group, exactly as you would an IP ACL.

access-list PLZ-ETHER ethertype permit bpdu           <-- allow spanning-tree BPDUs to bridge through
access-list PLZ-ETHER ethertype deny 0x8863           <-- block PPPoE discovery, for example
access-list PLZ-ETHER ethertype permit ip
access-group PLZ-ETHER in interface inside

Read each line. The first permits bpdu, letting spanning-tree frames bridge across the firewall. The second denies EtherType 0x8863, the PPPoE Active Discovery type, as an example of blocking a specific non-IP protocol by its hex EtherType value. The third permits ip, so ordinary IP frames continue to bridge (your IP ACL still governs what happens to them at Layer 3). The access-group applies the list inbound on the inside interface. Note that EtherType ACLs are applied per-interface and per-direction, just like IP ACLs, so you place them precisely where you want the filtering to happen.

Three things you need to understand

EtherType ACLs are simple to type and easy to misjudge. Three points separate someone who copies the syntax from someone who understands what it does.

1. By default, a transparent ASA does not bridge BPDUs

This is the big one. Out of the box, a transparent firewall does not pass spanning-tree BPDUs between its bridged segments unless you explicitly permit them with an EtherType ACL. That default is a design decision handed to you: you get to choose whether spanning tree spans the firewall or not.

Permit bpdu and the two Layer 2 domains on either side of the firewall participate in a single spanning tree, sharing loop-prevention state across the bridge. Leave BPDUs blocked, which is the default, and the two domains run independent spanning trees, isolated from each other at the STP level. Neither is universally correct. In some designs you want a single, unified topology; in others you deliberately want the firewall to segment the loop-prevention domains so a spanning-tree event on one side cannot ripple to the other. The point is that it is your call, and the EtherType ACL is the lever. Getting this wrong is a classic way to either merge two topologies you meant to keep separate or split one you meant to keep whole.

2. EtherType ACLs act on frame types, and ARP is handled separately

An EtherType ACL matches the frame's type field, not addresses inside a payload. That is a fundamentally different axis from an IP ACL, and it is the capability a routed firewall simply does not have, because a routed firewall does not bridge non-IP frames in the first place.

One important exception to know: ARP is not filtered by EtherType ACLs. Even though ARP is a non-IP EtherType, the ASA handles it through a separate mechanism called ARP inspection, which validates ARP frames against static mappings to prevent spoofing. So you do not permit or deny ARP in an EtherType ACL; you control it with ARP inspection instead. Keeping these two straight matters, because a reasonable person assumes ARP would fall under EtherType filtering, and it does not.

3. The EtherType ACL is evaluated before the IP ACL

Order of operations decides outcomes. On a transparent firewall, the EtherType ACL is evaluated before the IP ACL. The frame's type is checked first: if the EtherType ACL denies it, the frame is dropped at Layer 2 and never reaches IP processing at all. Only frames that the EtherType ACL permits, including IP frames, go on to be evaluated by the IP ACL.

This has a practical consequence. If you write an EtherType ACL and forget to permit ip, or if an implicit deny catches IP frames, your carefully crafted IP policy never even runs, because the frames were dropped one layer earlier. When you apply an EtherType ACL to an interface, make sure IP is still permitted unless you specifically intend to block it, and remember that the EtherType decision happens first in the flow.

What you would actually filter

The syntax supports well-known keywords like bpdu and ip, and it also accepts raw hex EtherType values for anything without a keyword, which is how we blocked PPPoE discovery with 0x8863 above. A few of the frame types that come up in real transparent-mode designs:

• BPDU - spanning-tree control frames. The decision to bridge or block these defines whether STP spans the firewall, which is the single most consequential EtherType choice you will make.
• PPPoE (0x8863 discovery, 0x8864 session) - block these to stop rogue PPPoE from crossing a segment where it has no business being.
• MPLS unicast and multicast - relevant when a transparent firewall sits inside a provider or datacenter path carrying label-switched traffic.
• IP - permit it so your Layer 3 policy still runs; deny it only if you deliberately want a segment that carries no IP at all.

The common thread is that every one of these is invisible to a routed firewall. You would never write a rule about a BPDU or a PPPoE discovery frame on a Layer 3 device, because it never bridges them. On a transparent firewall these become first-class policy objects, and the EtherType ACL is how you express intent about them. In practice the most valuable use is the STP decision, followed by blocking stray non-IP protocols that should not leak between two segments you are bridging together.

Why this is unique to transparent mode

Step back and the significance is clear. A routed firewall lives entirely in the IP world. It cannot filter BPDUs, cannot block PPPoE discovery, cannot make a decision about MPLS frames, because it does not bridge any of them; those frame types die at its interfaces or are irrelevant to it. A transparent firewall bridges Layer 2, so all of those frame types pass through it, and passing through means it can filter them.

That is the one real security capability that transparent mode has and routed mode does not. Everything else the two modes share: IP ACLs, application inspection, connection limits, TCP normalization, all the MPF-based features from the rest of this series work in both modes. EtherType filtering is the genuine differentiator. If your reason for choosing transparent mode is that you need to control non-IP Layer 2 traffic between two segments, the EtherType ACL is the feature you came for, and it does not exist anywhere else in the ASA feature set.

An honest scope note

This article is concept and syntax, and we want to be clear about that. The EtherType filtering described here was not exercised end-to-end in our virtual lab. As covered in the transparent firewall configuration article, the data path across our transparent ASA did not come up cleanly in the virtual switch topology after the destructive mode change, so we did not have a clean bridged data plane on which to demonstrate live BPDU or PPPoE filtering. Rather than fabricate a capture, we are presenting the EtherType ACL as what it reliably is: a well-documented, per-interface, frame-type filter that is evaluated before the IP ACL and that only transparent mode makes possible. The syntax and the three teaching points above are what you carry into a real deployment, ideally on the physical two-node segment shape we recommended for demonstrating the transparent data path in the first place.

Key Takeaways

• EtherType ACLs filter non-IP Layer 2 frames. They match on the frame's EtherType, a capability only a bridging, transparent firewall has, and one a routed firewall cannot offer.
• BPDUs are not bridged by default. Permit bpdu to let spanning tree span the firewall, or leave it blocked to keep the two L2 domains as independent STP topologies. Your choice, your lever.
• ARP is filtered separately. Use ARP inspection for ARP, not an EtherType ACL, even though ARP is a non-IP EtherType.
• EtherType is evaluated before IP. A frame denied at Layer 2 never reaches the IP ACL, so remember to permit ip unless you mean to block it.
• This is the one capability unique to transparent mode. Every other ASA security feature works in both modes; EtherType filtering is the genuine differentiator.

EtherType ACLs are the reason transparent mode exists as a distinct tool rather than just a variation on routing. For the full build that this filtering sits on top of, read the transparent firewall configuration article, and explore the rest of the Cisco ASA series for the inspection, normalization, and packet-flow features that round out the platform.