Wi-Fi VLAN Assignment After Authentication: Preserve the Intended Network Boundary

Successful Enterprise Wi-Fi authentication does not prove that a device entered the intended network segment. Trace the authorization decision through the AP’s station binding, bridge or tunnel, wired forwarding boundary and effective access policy. An IP address and an EAP success event are useful observations, but neither identifies the complete enforcement path.

This guide examines a local hostapd 2.11 AP with RADIUS-assigned VLANs, using RFC 3580’s assignment convention. It assumes RADIUS and VLAN support are compiled in. Controller-tunneled products need an equivalent mapping at their actual enforcement point. Certificate enrollment, TTLS identity selection and PMKSA freshness are outside scope; use a proven fresh authentication when testing a changed assignment policy.

Define the expected authorization result

For each dedicated test principal, record the intended policy revision, assigned VLAN, address-service scope and allowed/denied service set. Use synthetic identities and private lab endpoints. Keep authentication secrets, shared RADIUS secrets and complete production identities out of exported traces.

RFC 3580 section 3.31 describes VLAN assignment with Tunnel-Type set to VLAN, Tunnel-Medium-Type set to IEEE 802 and Tunnel-Private-Group-ID containing the VLAN ID as a string. The VLAN range in this convention is 1–4094. Attribute tags group related tunnel attributes; for a single VLAN assignment, the RFC recommends zero tags. Do not treat a text value, an integer field and an attribute tag as interchangeable encodings. RFC 3580, tunnel attributes

Preserve the Access-Accept’s relevant decoded attributes and the AP’s interpretation for the same connection attempt. A policy rule saying “maintenance” is not enough unless its resolved VLAN and enforcement mapping are visible. If the network operator cannot expose this evidence, report assignment as unverified rather than inferring it from a familiar subnet.

Distinguish optional assignment from required assignment

Hostapd 2.11’s dynamic_vlan=1 permits the default interface when RADIUS omits a VLAN. With dynamic_vlan=2, a VLAN is required. The pinned ieee802_1x_update_vlan() path rejects a missing required assignment and rejects VLAN descriptions that fail its configured validity check. An Access-Accept can therefore still fail local authorization. hostapd 2.11, hostapd.conf and ieee802_1x_update_vlan()

Choose the mode from the deployment’s authorization contract. If every successful identity must receive an explicit segment, optional fallback is a meaningful policy decision, not a harmless compatibility default. Conversely, a deliberately configured default segment should be tested as such rather than mislabeled an unexpected error.

Compile-time support also matters. Hostapd’s CONFIG_NO_VLAN removes VLAN support, while CONFIG_FULL_DYNAMIC_VLAN enables automatic bridge and VLAN-interface creation. A configuration file cannot supply a feature omitted from the binary. Record build capabilities and who creates the required interfaces before judging an assignment failure. hostapd 2.11 build configuration

Follow the station to the real forwarding boundary

The 2.11 vlan_file maps assignments to interfaces and can name a bridge. vlan_tagged_interface identifies the wired side used for tagged VLAN traffic in the documented dynamic setup. Inspect the realized interfaces and bridge membership for the current station, not just the intended configuration file. hostapd 2.11 dynamic VLAN interface configuration

For a local AP, correlate the station’s applied assignment with its wireless-side interface, the intended bridge and the appropriate Ethernet VLAN path. Then inspect the connected switch’s allowed VLANs, tagging/native-VLAN arrangement and onward policy using its exact supported management evidence. For a tunneled controller, move these checks to the controller’s tunnel termination and egress instead of expecting local AP bridge entries.

The wireless client ordinarily observes association and IP configuration, not the AP’s complete internal VLAN mapping. Do not require a client-side packet capture to display an Ethernet tag that may be added on another interface. Likewise, a capture taken before or after VLAN offload can display tags differently. Declare the capture point and obtain supporting interface/switch evidence before diagnosing a missing tag.

Addressing is a later check. RFC 3580 explicitly notes that IEEE 802.1X does not itself provide IP address assignment. A valid lease may come from the wrong segment, and overlapping address plans can make the apparent subnet ambiguous. Record the expected address-service context and gateway, then test the actual access boundary. RFC 3580, address-assignment boundary

Run an assignment-specific acceptance matrix

1. Baseline two distinct roles. Authenticate two dedicated principals with different intended segments. Correlate server decision, AP binding and forwarding evidence for each. Confirm that neither inherits the other’s state after reconnect.
2. Omit the assignment deliberately. In the authorized lab policy, return a successful authentication without VLAN attributes. Required mode should reject this path; optional mode should use only its documented default mapping. Verify the observed outcome rather than assuming either mode.
3. Return an unsupported assignment. Use a test VLAN excluded by the AP’s configured mapping. Record local rejection and verify that the station does not silently enter a broader fallback segment.
4. Break the permitted uplink path. In an isolated test, remove the intended VLAN from the approved test trunk configuration. Authentication and local binding may still succeed while addressing or service delivery fails. This case identifies the forwarding boundary instead of blaming credentials.
5. Test access in both directions. Exercise one explicitly allowed service and one explicitly forbidden service, with corresponding enforcement evidence. Also test any required inbound management path. A general Internet request does not validate role isolation.
6. Repeat after reassociation and AP restart. Verify reconstruction of interface membership, assignment and addressing. Preserve attempt identity so stale station or lease records cannot satisfy the new test.

For denial tests, establish that the destination is healthy through an authorized positive control. A timeout from a stopped server is not proof of VLAN isolation. Where VLANs are deliberately routed together, the effective boundary may be a firewall or access-control policy; distinct VLAN numbers alone do not prove that communication is prohibited.

Interpret a hypothetical wrong-segment case

Suppose a test device should enter VLAN 120, but the RADIUS reply omits its assignment and the AP is configured for optional dynamic VLANs. The device receives a lease from the default network and reports online. That is consistent with the configured fallback, even though it violates the intended product policy. The repair is to align assignment requirements and enforcement, not to make the device reject every unfamiliar address.

No authentication, VLAN reconfiguration or isolation experiment was executed here. The pinned configuration and rejection paths were source-checked. A complete release record pairs the resolved authorization attributes with applied station mapping, actual forwarding context and positive/negative access results. That chain explains where the intended network boundary was preserved or lost.