AuthHound

RADIUS attribute 81 · type string

Tunnel-Private-Group-Id

Tunnel-Private-Group-Id (attribute 81) is the RADIUS attribute that tells the switch or access point which VLAN to put an authenticated device on. It is the payload of dynamic VLAN assignment.

Also searched as: VLAN attribute, Tunnel-Private-Group-ID, dynamic VLAN attribute. Defined in RFC 2868 / RFC 3580.

What it means

When RADIUS returns an Access-Accept, Tunnel-Private-Group-Id carries the VLAN the NAS should place the port or client on. On its own it does nothing: RFC 3580 requires it to arrive alongside Tunnel-Type = VLAN (13) and Tunnel-Medium-Type = IEEE-802 (6). If any of the three is missing, most switches silently ignore the VLAN assignment and fall back to the port's native VLAN — the authentication succeeds, but the device lands on the wrong network and nobody sees an error.

How it's used

The value is the VLAN *name or number as the switch expects it*, sent as a string. On most switches that is the numeric VLAN ID written as text ("20"), but some platforms match on the VLAN name instead. The tag byte prefix (RFC 2868's optional Tag field) is where a lot of one-vendor-works, other-vendor-doesn't confusion comes from.

Common gotchas

  • It must travel with Tunnel-Type (13) and Tunnel-Medium-Type (6). A policy that returns only attribute 81 is the single most common reason "the VLAN attribute is set but the device stays on the default VLAN."
  • The value is a string, not an integer. Returning the VLAN as an integer attribute, or with a stray tag byte, makes the switch parse the wrong value — sometimes VLAN 0, sometimes nothing.
  • The VLAN must actually exist and be allowed on the port/trunk. RADIUS returning VLAN 20 to a switch that has no VLAN 20 is an accept that ends in a dead port, not a reject.

FAQ

What attributes are required with Tunnel-Private-Group-Id for VLAN assignment?

Three attributes must travel together: Tunnel-Type = VLAN (13), Tunnel-Medium-Type = IEEE-802 (6), and Tunnel-Private-Group-Id = the VLAN ID or name. Returning attribute 81 alone makes most switches ignore the assignment and use the port's native VLAN, with no error logged.

Is Tunnel-Private-Group-Id a number or a string?

It is a string (RADIUS type 'string'), even when the value is a numeric VLAN ID like "20". Sending the VLAN as an integer attribute, or with an unexpected RFC 2868 tag byte, causes the switch to parse the wrong VLAN.

Read the Access-Accept from the client side: the open-source authhound-probe prints the authorization attributes the server returned and asserts the VLAN — --expect-vlan turns a wrong or missing VLAN into a hard FAIL. 

export AUTHHOUND_RADIUS_SECRET='shared-secret'   # not in argv or shell history
authhound-probe radius test --server radius.corp.com --peap alice --expect-vlan 20

Recipe: verify users land on the right VLAN

Seeing this attribute in a reject or an accept that behaves wrong? Paste the full log into the analyzer — it runs in your browser, nothing is uploaded, and it ranks the likely causes for your specific output.

Related

When a NAS quietly stops honoring an attribute across a fleet, nobody sees it until users complain. AuthHound is building monitoring that tracks the attributes your servers actually return — early access:

No spam, no sharing — one email when it's ready, and you can reply to be removed anytime.