802.1X Dynamic VLAN Works on One Switch Only
Two FortiSwitch 424E switches are managed by a FortiGate 100F. Ports 1-20 on each switch use 802.1X with MAC authentication bypass for wired users. Windows NPS returns Tunnel-Private-Group-ID 30 for employee laptops and 99 for contractors. VLANs 10, 30, and 99 are defined on the FortiGate and on switch A, but switch B was staged from an older backup and only has VLANs 10 and 99. The ISL allows VLANs 10, 30, and 99. On switch A, authenticated employees land in VLAN 30. On switch B, the same users authenticate successfully in NPS logs but receive VLAN 1 addresses. Contractors on both switches land in VLAN 99 correctly. The customer wants to add VLAN 40 for printers next month without touching every switch.
1. Why do employees on switch B land in VLAN 1 while contractors on switch B get VLAN 99? What does this tell you about the 802.1X and RADIUS operation?
Read the worked answer
Authentication is succeeding; the difference is whether the switch can honor the VLAN returned by RADIUS. NPS returns VLAN 30 for employees and VLAN 99 for contractors. Switch B has VLAN 99 but not VLAN 30. When the assigned VLAN does not exist locally, the FortiSwitch cannot place the session in that VLAN and falls back to its native or untagged VLAN, which is VLAN 1 here. Contractors succeed on switch B because VLAN 99 exists.
This rules out a shared RADIUS secret problem, a global 802.1X failure, or a supplicant problem, because those would affect both user groups or both switches. It also shows dynamic VLAN assignment is enabled and working on the ports, otherwise contractors would not land in VLAN 99. The fault is data-plane VLAN provisioning on switch B: the RADIUS attribute is accepted, but the target VLAN is missing. Check the switch VLAN table and the port dynamic-VLAN setting before changing NPS.
2. Give the fix and verification steps, including what to check on the ISL and FortiGate.
Read the worked answer
Create VLAN 30 on switch B with the same VLAN ID and intended name as on switch A and the FortiGate. If the switch is FortiLink-managed, define VLAN 30 on the fortilink interface and push it through the switch-controller configuration rather than creating a local-only VLAN that can drift. Confirm the ISL allows VLAN 30 on both ends, even though the setup says it does, because an asymmetric ISL would produce the same symptom after the VLAN is created. Confirm the employee ports have dynamic VLAN assignment enabled and that the native VLAN is not expected to carry authenticated users.
Verify with the switch VLAN table on B, the interface status for an authenticated employee, the NPS success log including the returned tunnel attribute, and a DHCP lease from the VLAN 30 scope. Re-authenticate the test client or disconnect and reconnect it so the switch re-evaluates the session. Check FortiGate logs for VLAN 30 traffic. If the client still lands in VLAN 1, capture the RADIUS accept attributes and confirm the switch is reading Tunnel-Private-Group-ID as a VLAN ID, not as a VLAN name it cannot resolve.
3. How should the design handle VLAN 40 for printers next month, given dynamic VLAN assignment and a mix of switches?
Read the worked answer
Pre-provision VLAN 40 everywhere before assigning it: on both switches, on every ISL, and on the FortiGate fortilink if it is routed. Add the DHCP scope and the firewall policy, then test with a printer or a test laptop. Use the FortiLink switch-controller VLAN object or an automated template so new switches inherit VLAN 40 and the correct allowed lists; do not rely on a local VLAN created only on the switch where the first printer is installed.
For printers, decide whether dynamic VLAN is appropriate. MAC authentication bypass can place known printer MACs into VLAN 40, but printers are long-lived and MAC spoofing is trivial, so many designs use a static printer VLAN with port security instead. If dynamic assignment is used, create a dedicated NPS policy that returns VLAN 40 only for the printer MAB group, and make sure the switch has a fallback plan that does not silently put failed devices into a production VLAN. Document the RADIUS attribute mapping and validate with a show command and a real DHCP lease.