Why a RADIUS VLAN Reply Does Nothing for a VPN User

You add the VLAN attribute to the NPS policy, the VPN user connects, and the laptop still lands on the default pool. The RADIUS server is returning what you asked for, which makes the failure look like a caching problem. It usually is not. An Access-Accept carries authorization hints, and only the network access server that received them can turn one into a network assignment.

Start at the gateway, not at the policy

Walk the chain from the client inward before changing anything. The client asks the gateway for a session, the gateway asks RADIUS whether the user may have one, and RADIUS answers with a result and a set of attributes. The gateway then applies whatever it knows how to apply.

Your walkthrough starts at step four, which is why the first three look healthy. Nothing in the exchange obliges the gateway to implement an attribute it received. The reply is a request to the gateway, not a fact about the client.

What the switch does that the VPN cannot

An 802.1X access switch is an authenticator with ports, and dynamic VLAN assignment moves one of those ports into a VLAN the switch already carries. The RADIUS tunnel attributes describe that intent in a form the switch understands. A routed VPN terminates tunnels, not switch ports, and its clients usually get an address and a route rather than membership in a broadcast domain. There is no port to move, so the same attribute has nothing to act on.

This is a model difference, not a vendor bug. Some gateways add their own group policy, pool selection or filter mechanism that looks similar in a screenshot. Others implement none of it, and the attribute is logged and ignored. Read the documentation for the remote-access mode you actually enabled, not the one in the screenshot.

Read the reply the server actually sent

Confirm what RADIUS returned instead of what the policy editor displays. A test request with the same username and a known password prints the reply attributes in readable form, which settles the question in one step.

radtest alice secret 10.0.0.10 0 testing123

If the VLAN attributes are missing from that reply, fix the policy match first. If they are present, the server has done its part and the gap is downstream.

Prove the session policy, then the reachability

Now look at the session the gateway built. The active session list shows the pool, the assigned address and any group policy the gateway attached, which is the only evidence that matters for enforcement. Compare that with what the user can reach rather than with what the policy intended.

swanctl --list-sas

Then test one permitted and one denied resource from the client, because an address from the right pool does not prove isolation. If the gateway has no mechanism for the assignment you want, more copies of the attribute will not create one. An address from the expected pool can coexist with full access to every other pool. Choose a supported policy mechanism or change the network design on purpose.