Access-Accept · VLAN not applied
RADIUS dynamic VLAN not working — device lands on the default VLAN
The login succeeds — the user is authenticated, the port comes up — but the device is on the wrong network. No reject, no error in the RADIUS log, nothing red anywhere. Dynamic VLAN assignment fails quietly, which is exactly why it eats hours. Walk these in order.
1. You’re returning only one of the three VLAN attributes
This is the cause more than half the time. Assigning a VLAN over RADIUS is not one attribute — RFC 3580 requires three, together, in the Access-Accept:
Tunnel-Type= VLAN (13)Tunnel-Medium-Type= IEEE-802 (6)Tunnel-Private-Group-Id= the VLAN ID or name
Return Tunnel-Private-Group-Id on its own and most switches shrug and use the port’s native VLAN. Check: dump the actual reply attributes (radiusd -X on FreeRADIUS shows the Access-Accept contents; on NPS, enable and read the reply attributes in the network policy) and confirm all three are present. If your server sends RFC 2868 tag bytes, all three must share the same tag or the switch won’t correlate them.
2. The VLAN doesn’t exist (or isn’t allowed on the port)
RADIUS returning VLAN 20 to a switch that has no VLAN 20 — or a trunk that doesn’t carry it — is an accept that ends in a dead port, not a reject. The switch got a valid instruction it can’t honor.
Check: show vlan on the switch, and confirm the access port / trunk actually permits that VLAN. On stacked or multi-site estates, the same policy hitting switches with different VLAN databases is a classic partial outage (“works in Building A, dead in Building B”).
3. Wrong data type or a stray tag byte
Tunnel-Private-Group-Id is a string, even when it’s a number. Return the VLAN as an integer attribute, or let a policy tool prepend a tag byte the switch doesn’t expect, and the switch parses garbage — sometimes VLAN 0, sometimes nothing. Check: the value on the wire should be the bare VLAN as text ("20"), matching whether your switch keys on VLAN ID or VLAN name.
4. The switch isn’t configured to accept RADIUS-assigned VLANs
Some platforms require the feature to be turned on before they’ll act on the attributes at all (aaa authorization network, RADIUS-override / dynamic-VLAN settings vary by vendor). Without it, the three attributes arrive and are ignored — silently, again.
The one diagnostic that settles it
Capture the Access-Accept and read its attributes. On FreeRADIUS: radiusd -X and look at the reply block for the three tunnel attributes and their values. On NPS: check the network policy’s configured RADIUS attributes, then confirm on the switch side with the port’s authentication session detail (e.g. show authentication sessions interface ...) — it tells you the VLAN the switch actually applied versus the one you sent. When the sent VLAN and the applied VLAN disagree, you’re in cause 2 or 3; when nothing was sent, cause 1.
Don’t have the server log handy? Read the Access-Accept from the client side instead: the open-source authhound-probe can assert the VLAN and print the returned attributes — --expect-vlan 20 turns a wrong or missing VLAN into a hard FAIL, and --expect-attr checks the companions. Step by step in the recipe: verify users land on the right VLAN.