Enable MAC-Based Access Control on a Cisco ASA (Transparent Mode)

Before you run this

This guide locks down a bridged interface on a Cisco ASA so that only frames from MAC addresses you have explicitly listed are forwarded. You do it by adding static MAC entries for your approved devices and then turning off dynamic MAC learning on that interface, so anything the ASA hasn't been told about is silently dropped.

Two hard prerequisites and one correction before you touch anything:

• This is a transparent (Layer 2) firewall feature. A routed-mode ASA does not filter transit traffic by source MAC. This guide assumes your ASA is already in transparent mode. Converting a routed firewall with firewall transparent erases the running configuration and requires a reload — that is a separate, destructive operation and is out of scope here. If you need it, do it from a wiped-config maintenance plan, not mid-stream.
• Privileges: you need privileged EXEC (enable) and global configuration mode. These are production-changing commands.
• If what you actually want is to exempt certain MACs from cut-through-proxy authentication, that is a different feature — mac-list plus aaa mac-exempt match — not covered here. See the ASA Series CLI configuration guide.

Because the ASA applies configuration commands immediately (there is no PAN-OS-style timed commit or candidate rollback), a single wrong move here can black-hole production traffic across the bridge:

• Keep a separate console (or other out-of-band) session open the whole time. If you lock the bridge, you want a path in that does not depend on the data plane.
• Back up the running configuration first (shown below). On the ASA your "rollback" is restoring that saved config or reloading to the last saved startup-config — there is no snapshot revert.
• Do this in a maintenance window, and read every line before you paste it.
• Do not run write memory until you have verified traffic still flows. As long as the change is only in running-config, a reload recovers you to the known-good startup-config.

Test the exact MAC list on a lab ASA or a test context before you disable learning on a live interface.

What I'm assuming

• ASA software 9.x (procedure confirmed on 9.16; the commands are stable across 9.x).
• Single-context, firewall already in transparent mode, one bridge group with an inside and outside interface.
• CLI access over console or SSH. Interface names (inside, outside) are your nameif values — substitute yours.
• MAC addresses are written in Cisco dotted-triple form, hhhh.hhhh.hhhh.

How MAC access control works on a transparent ASA

In transparent mode the ASA bridges between interfaces and keeps a MAC address table, learning source MACs the way a switch does. By default it forwards frames from any MAC it has learned.

The control knob is MAC learning. When you disable learning on an interface, the ASA stops adding dynamic entries from that interface and will only forward frames whose source MAC it already knows — which, with learning off, means only your static entries. Everything else is dropped. That is your allow-list.

The critical ordering: add the static entries first, then disable learning. You must list every MAC that legitimately sends traffic across the bridge — hosts, printers, and crucially the upstream router/gateway — or you will cut yourself and production off.

Step 1 — Back up the running configuration

Capture it to your terminal and, if you have TFTP, to a file:

show running-config

copy running-config tftp:

The copy command prompts interactively for the TFTP server and filename. Keep this output somewhere safe; it is your restore path.

Step 2 — Confirm you are in transparent mode

show firewall

This reports the current firewall mode. If it does not say transparent, stop — the rest of this does not apply to your firewall as-is.

Step 3 — Inventory the MACs that must pass

Before changing anything, look at what the ASA has already learned on the interface you intend to lock down:

show mac-address-table inside

Write down every MAC you recognise and intend to keep — including the upstream gateway. Treat this as your allow-list source of truth.

Step 4 — Add static entries for approved devices

For each approved MAC, bind it to the interface it arrives on:

configure terminal
mac-address-table static inside 00aa.bbcc.0001
mac-address-table static inside 00aa.bbcc.0002

Replace inside with your interface nameif and the MACs with your real addresses. Add the gateway's MAC on whichever interface faces it (often the outside):

mac-address-table static outside 00aa.bbcc.ffff

Do not skip the gateway. If the ASA can't forward frames to and from the next hop, nothing routes.

Step 5 — Disable dynamic MAC learning on the interface

Only after every needed MAC is static:

mac-learn inside disable

From this point the inside interface forwards frames only from the MACs you listed in Step 4. Anything else is dropped.

If you want both sides filtered, repeat for the other interface — but be certain its static list is complete first:

mac-learn outside disable

Leave config mode:

end

Step 6 — Verify before you commit

Check that your static entries are present and learning is off:

show mac-address-table

Static entries appear with a static/N/A-aging indication rather than a counting age timer; confirm each one you added is listed against the right interface.

Confirm the learning change is actually in the config:

show running-config | include mac-learn

You should see your mac-learn inside disable line.

Now test real traffic: from an approved host, confirm it still reaches across the bridge (ping the gateway, open a known service). From an un-listed MAC (a test laptop), confirm it is now blocked. Watch the drops if you want confirmation:

show mac-address-table

An un-listed source will simply never appear as a forwarded entry.

Step 7 — Save, only once it's proven

When, and only when, approved traffic flows and unknown MACs are blocked:

write memory

Until you run this, a reload returns the ASA to its previous saved state — which is exactly the safety margin you want while testing.

Undo / rollback

If something is wrong and you have not saved yet, the cleanest recovery is to reload to the last good startup config (this reboots the firewall, so expect a traffic interruption):

reload

To reverse the change manually without a reboot, re-enable learning and remove the static entries:

configure terminal
no mac-learn inside disable
no mac-address-table static inside 00aa.bbcc.0001
no mac-address-table static inside 00aa.bbcc.0002
end

Then confirm:

show running-config | include mac-learn
show mac-address-table

With learning back on, the interface returns to normal bridging and relearns MACs dynamically. If you had already saved and want the whole prior config back, restore the backup you took in Step 1 (copy it into place and reload to it rather than merging).

For exact command syntax, interface and bridge-group behaviour, and MAC aging options, see Cisco's ASA Series CLI Configuration Guide, section on the MAC address table and MAC learning for transparent firewall mode — don't guess at variants of these commands against a live firewall.