Dev Blog
MAB · MAC Authentication Bypass · Device profiling · 802.1X · Closed mode · Low-impact mode · DHCP fingerprinting · Fingerbank · NAC · RADIUS · CoA · Filter-Id · Endpoint visibility · Zero trust · Cloud NAC

The MAB profiling chicken and egg situation: how to profile a device when traffic is blocked

06 July 2026 11 min read

In closed mode, an unknown MAB device cannot send DHCP until RADIUS authorizes it. But DHCP is one of the main sources of profiling data. This creates a problem: the device needs to communicate before Arbiter has enough information to classify it.

Arbiter resolves it by authorizing the unknown endpoint into a DHCP-only role rather than rejecting it. The endpoint completes a DHCP exchange and nothing else. That exchange supplies the profiling data and a CoA then applies the policy for the resulting classification. Every other IPv4 packet is denied until then.

Why a MAC address is not enough

Device profiling requires traffic from the endpoint. DHCP options, hostname and other discovery data cannot be collected from a device that is completely blocked.

For a laptop or a phone this is fine. It runs an 802.1X supplicant, it proves an identity with a certificate or credentials and it earns full access. Profiling is a nice-to-have on top.

The problem is everything else. Printers, IP cameras, door controllers, building sensors, medical devices, industrial kit. Most of it has no supplicant and never will. For those devices the only lever the switch has is MAB, MAC Authentication Bypass: the switch reads the source MAC off the port and hands it to the RADIUS server as the identity.

A MAC address is a weak identity. The first three bytes (the OUI) hint at a manufacturer and manufacturers reuse and randomise them, so even that is soft. The MAC does not tell you whether this is a printer or a PLC. So on the very first sighting of an unknown device you have almost nothing to base a policy on.

Why closed mode creates this issue

In closed mode, the switch port stays shut until RADIUS returns an Access-Accept. No ordinary endpoint traffic such as DHCP or ARP flows before authentication. This is the correct default posture: a port does not carry traffic for a device the network has not vetted.

Now trace the loop for an unknown MAB device:

  • Device links up. Port is closed. Nothing flows.
  • Switch does MAB, sends the MAC to Arbiter.
  • Arbiter has never seen this MAC. It has no profile, so no class, so no policy match beyond “unknown”.
  • With closed mode and a deny-by-default stance, the only safe verdict is Access-Reject.
  • Port stays closed. The device never gets to DHCP.
  • Because it never DHCPs, it is never fingerprinted, so it is never profiled, so the loop gives the same answer forever.

DHCP fingerprinting is one of the richest profiling signals available and closed mode puts it on the far side of the gate that profiling is supposed to open.

"Just let some traffic flow first" is not the answer

One common approach is to let some traffic flow before authentication completes. In fully open or monitor deployments, that may mean meaningful network access for an unknown endpoint. Low-impact deployments reduce that exposure with a pre-authentication ACL, but the permitted access is statically defined on the switch and exists before RADIUS has made a decision.

A static pre-auth ACL applies to every device that connects to the port. The DHCP holding role is different: RADIUS explicitly authorizes the unknown endpoint into that role and the ACL only permits DHCP.

If RADIUS never makes that decision, the endpoint remains blocked.

The third option: a DHCP-only holding role

An unknown device does not need full access to be profiled. It needs the ability to complete a DHCP exchange and nothing else. The full path:

Unknown MAB endpoint
  -> Access-Request
  -> Access-Accept
       Filter-Id          = DHCP_Only.in
       Session-Timeout    = 600
       Termination-Action = RADIUS-Request
  -> DHCP exchange
  -> profiling
  -> classification
  -> Arbiter re-evaluates policy
  -> CoA-Request
       Filter-Id          = <class ACL>.in
  -> normal policy

With a holding role configured, Arbiter answers an unknown MAB endpoint with Access-Accept into an Unprofiled Endpoints authorization instead of Access-Reject:

  • A DHCP-only ACL on the port. Permit DHCP client traffic (UDP 68 to UDP 67, which covers the broadcast DISCOVER) and deny all other IPv4 traffic. This is enforced through the standard RADIUS Filter-Id attribute, referencing a DHCP-only ACL pre-staged on the NAD. The policy intent remains consistent across vendors, while the local ACL syntax is handled by the appropriate switch template.
  • A Session-Timeout with Termination-Action = RADIUS-Request, so that when the timer expires the switch reauthenticates the session rather than ending it. The CoA (below) can promote the device sooner, but the timer does not depend on that CoA being sent or accepted, so keep it on every holding role: the example profile below uses 600 seconds.

You build this holding role as an ordinary Arbiter access profile: result Access-Accept, a Filter-Id naming your DHCP-only ACL and a Session-Timeout with Termination-Action = RADIUS-Request. A Tier-2 access policy then routes unprofiled endpoints to it. Nothing about it is a special code path: it is the same profile machinery every other role uses, pointed at one deliberately narrow ACL. The access policy guide walks through building access profiles and the policies that select them.

The ACL the Filter-Id points at is short. This is the one from our lab Catalyst 9200:

ip access-list extended DHCP_Only
 10 remark Arbiter holding role: permit DHCP client traffic only
 10 permit udp any eq bootpc any eq bootps
 20 deny   ip any any log

One permit and an explicit deny. Over IPv4 the endpoint can send DHCP client traffic and nothing else. The log keyword on the deny has no effect here: a Catalyst 9000 logs ACL matches only on router ACLs, not on an ACL that RADIUS assigns to a session. To prove the role behaves, run show access-session interface <port> details and check that the session is Authorized and that Server Policies lists the Filter-ID. Cisco documents Filter-Id for numbered ACLs, so use the same check to confirm your release applies a named one.

The same flow in three moves.

First, initial authorization into the holding role. The unknown MAC hits the port and the switch does MAB. Arbiter has no profile, so it accepts the endpoint into the Unprofiled Endpoints role rather than rejecting it. The DHCP-only ACL and the reauth timer come down in that Access-Accept and the port opens for DHCP and nothing else.

Second, profiling and classification. The device DHCPs and the access VLAN relays that traffic to Arbiter Edge alongside the production DHCP service, so Arbiter reads option 55, option 60 and option 12 without Edge becoming the lease authority. Fingerbank infers a likely device class from option 55, option 60 and the MAC's OUI. The endpoint record then updates from unknown to, say, an “Axis network camera” or a “Brother laser printer”.

That is just extra helper addresses on the SVI:

interface Vlan10
 description ### DATA ###
 ip address 10.0.10.1 255.255.255.0
 ip helper-address 10.0.20.3     ! production DHCP server
 ip helper-address 10.0.20.10    ! Arbiter Edge 1
 ip helper-address 10.0.20.11    ! Arbiter Edge 2

The relay sends a copy to each address, so the production server still issues the lease and Edge sees the same DISCOVER and REQUEST. Arbiter never answers, which is what keeps it out of the lease path.

Third, promotion into final policy. That classification can trigger an automatic CoA (see the next section). Arbiter matches the now-profiled endpoint to its class-based rule and sends that rule's attributes to the switch in a CoA-Request for the live session: a Filter-Id naming a printer ACL in place of DHCP_Only.in, for example. If the rule denies the device, Arbiter sends a Disconnect-Request instead. The DHCP-only ACL stays until the switch applies that CoA or, failing that, until the Session-Timeout reauthenticates the session.

DHCP is a good exception to make because it is narrow and well understood. The holding-role ACL permits DHCP client traffic (UDP 68 to UDP 67) and denies all other IPv4 traffic. Over IPv4 a device in this role can send to UDP port 67 and nothing else: no other port on the gateway, on another endpoint or on the internet. If it is compromised, the reachable attack surface is whatever listens on UDP 67 (in practice the DHCP relay and servers), where DHCP snooping, client rate limiting and the usual infrastructure protections still apply. An IPv4 ACL does not filter ARP or IPv6. The device can still ARP for its neighbours. On a VLAN that carries IPv6, the holding role needs an IPv6 filter as well.

It also matches how these devices behave. A printer or a camera DHCPs the instant its link comes up, with no user interaction, so the profiling window opens on its own. You are not waiting on a human to log in. The device is never fully exposed: the IPv4 default-deny holds the entire time and the single exception carved out of it is the exact packet class profiling needs.

The promotion trigger: an automatic CoA, with a timer backstop

The first time a MAB endpoint goes from unprofiled to profiled, Arbiter queues a CoA for it (the “Device is classified” trigger, which is on by default). The default action is “Apply current policy”: Arbiter evaluates the endpoint's policy again with the same code FreeRADIUS runs, using the endpoint's last Access-Request and the new profile. The result goes to the switch through Arbiter Edge as an RFC 5176 CoA-Request that carries the new policy's attributes, so the switch must list the Edge appliances as dynamic-authorization clients. The CoA-Request identifies the session by NAS-IP-Address and by the User-Name, Calling-Station-Id and NAS-Port from the switch's last Access-Request. If that request carried Cisco's audit-session-id, the CoA-Request carries it too. If the new policy denies the device, Arbiter sends a Disconnect-Request instead.

A CoA-Request changes only the attributes it carries. Under RFC 5176 an attribute the CoA-Request omits keeps its current value and an attribute it includes replaces all existing values of that attribute. The class policy therefore needs its own Filter-Id to replace DHCP_Only.in. A class policy that returns only a VLAN leaves the DHCP-only ACL in place. A class policy that returns a plain Access-Accept has no attributes to send, so Arbiter sends no CoA and the device stays in the holding role until the Session-Timeout expires.

Juniper EX and HPE Aruba AOS-CX document Filter-Id as a CoA attribute. Cisco's Catalyst 9000 CoA documentation lists command CoAs (reauthenticate, bounce, disable and terminate) and service templates rather than Filter-Id. On a Catalyst, either confirm that the switch applies a Filter-Id from a CoA before relying on it or use the reauthenticate action below.

If you want the switch to run MAB again instead, set the “Device is classified” trigger to a vendor action. On Cisco that is Arbiter's “Reauthenticate session” action (subscriber:command=reauthenticate with reauthenticate-type last). Cisco documents that the switch then sends a fresh MAB Access-Request and that a successful reauthentication replaces the whole authorization, so the class policy does not need a Filter-Id of its own. For Juniper and HPE Aruba switches Arbiter offers a port bounce instead (see Caveats). The trigger takes one action for the whole tenant, so in a mixed-vendor estate a vendor action also reaches the other vendors' switches, which may refuse it.

The classification is committed before the CoA is built. Arbiter reads the profile fresh when it evaluates the policy and holds the CoA for at least 35 seconds, longer than FreeRADIUS caches a profile (30 seconds), so a switch that reauthenticates in response also sees the updated profile.

A DHCP fingerprint is a classification signal, not proof of identity. DHCP options can be copied or deliberately spoofed, so a device class should not by itself grant broad or sensitive access. Arbiter can combine the fingerprint with other evidence in the same rule: the OUI vendor, endpoint group membership (for known inventory or an operator's approval) or MDM status. Where DHCP classification drives automatic authorization, keep the resulting policy narrowly scoped.

The reauthentication timer is the backstop. It uses Session-Timeout with Termination-Action set to RADIUS-Request, which RFC 3580 describes as the signal to reauthenticate when the session timer expires. Both are standard attributes, but the switch has to use the server's timer: on Cisco that means authentication periodic and authentication timer reauthenticate server on the port or in its interface template. The timer promotes the device whenever the CoA does not: a NAD that refuses or ignores the CoA, a class policy with nothing to replace DHCP_Only.in or a CoA that never arrives. The example profile uses 600 seconds. As with any dynamic authorization feature, check the result on your NAD during deployment (on Cisco, run show access-session interface <port> details before and after the CoA).

Caveats

  • The holding-role ACL has to exist. You pre-stage a named ACL that the Filter-Id points at. This is a one-time piece of switch templating.
  • Promotion that changes VLAN needs a fresh DHCP cycle. The device takes its lease while in the holding authorization. A VLAN change made by CoA or reauthentication leaves the link up, so a headless device such as a printer has no way to notice it and keeps an address that is not valid on the new segment. Cisco, Juniper and HPE Aruba document a port bounce for this case. Arbiter has a bounce action for each of those platforms, which you set on the “Device is classified” trigger in place of “Apply current policy”. A bounce ends every session on the port and the trigger bounces the port of every newly profiled MAB device in the tenant, so avoid it where PCs sit behind MAB-authenticated phones. Where you can, keep the device on its access VLAN and change only the ACL, so the lease stays valid.
  • A device that sends no DHCP is not promoted on a guess. It stays in the DHCP-only holding role until another source profiles it: fail closed, not open. Two other Arbiter sources can still see a held device: an SNMP poll that finds its MAC in a switch's ARP or LLDP table and an nmap sighting from an Edge on the same subnet. Either marks the device profiled without giving it a device class, so the next point applies.
  • Profiled does not always mean classified. The first profiling signal of any kind (a DHCP fingerprint or hostname, an SNMP sighting or an nmap scan) marks a device as profiled even when nothing puts it in a class. The trigger fires on that first change only, so a class found later does not send another CoA. Give a profiled device with no class a policy of its own, below your class rules, with a Session-Timeout and Termination-Action = RADIUS-Request so that a class found later is picked up at reauthentication. Without one it falls through to default-deny: Arbiter sends a Disconnect-Request and in closed mode the switch's next MAB attempt is rejected.
  • This is for MAB, not for user devices. A laptop should be doing 802.1X with a real identity, not being profiled into access. The holding role is for the silent, agentless population where MAC is the only lever.
  • Timer tuning is a trade-off. Too short and you generate reauthentication noise. Too long and any promotion the CoA misses waits for the timer.

Closed mode without the profiling problem

Closed mode does not have to prevent profiling.

An unknown MAB endpoint can be authorized into a DHCP-only role rather than rejected. DHCP provides the profiling data, Arbiter updates the endpoint classification and a CoA applies the policy for the new class.

The endpoint never receives general network access during the process.

The result is a closed-mode deployment with default-deny enforcement and enough access to profile previously unknown devices.