Policy Order and a Missing VLAN on the Trunk
A regional campus has 400 wired access ports on Cisco Catalyst 9200 and FortiSwitch 448D switches. FortiNAC-F uses network access policies to place unknown devices in VLAN 200 for registration, registered BYOD in VLAN 210, and corporate laptops in VLAN 10. A new uplink between the access switch and the core is a trunk that allows only VLAN 10 and VLAN 210; VLAN 200 was omitted. Helpdesk reports that unknown devices get an IP address in VLAN 10 and can reach internal file shares before registration. The policy log shows an unknown device matched Corporate-Laptop because the profiler detected a Windows OS, and the Unknown policy is below it. On a test port, the FortiNAC enforcement log says VLAN 200 applied, but the port still shows VLAN 10. The Cisco switch does not yet have VLAN 200 created in its VLAN database.
1. Why did the unknown device reach VLAN 10 before registration?
Read the worked answer
Because policy evaluation is top-down and first match wins, and the device matched the Corporate-Laptop policy before the Unknown policy was evaluated. The profiler saw a Windows OS and produced a profile that the corporate rule accepts, even though the device had not registered. The missing VLAN 200 on the trunk is a separate fault; it did not cause this device to land in VLAN 10, because the policy never selected VLAN 200. To fix the logic, move the registration or unknown policy above the corporate policy, and make the corporate rule require registration status or a stronger identity signal, not just an OS profile. Also review the profiler rule that classified the device as corporate Windows; a broad Windows signature can create false positives. Test with a fresh unregistered laptop and confirm it matches Unknown first.
2. The enforcement log says VLAN 200 applied, but the port stayed in VLAN 10. What are the likely causes?
Read the worked answer
The log records the intent or the attempt, not necessarily the switch's final state. The most likely cause is that VLAN 200 does not exist in the Cisco VLAN database, so the access-port command fails or is rejected. The second is that the uplink trunk does not allow VLAN 200, which would break connectivity but should still show the access port in VLAN 200; because the port still shows VLAN 10, look first at the local VLAN and CLI result. Check the FortiNAC device read/write status, the switch AAA authorization for the VLAN command, and the port configuration. Run show vlan brief and show interfaces switchport on the switch, and compare with the FortiNAC enforcement detail. If the CLI command failed, the FortiNAC event log should show the returned error.
3. What changes do you make, and in what order, to restore correct enforcement?
Read the worked answer
First create VLAN 200 on every access switch and allow it on the uplink trunk; without that, even a correct policy cannot pass traffic. Second, fix the policy order so registration or unknown is evaluated before corporate, and tighten the corporate rule with registration or identity conditions. Third, correct the profiler rule that falsely identified the unknown Windows device, or lower its confidence so it does not satisfy the corporate policy. Then test on one lab port with a fresh endpoint: confirm it matches Unknown, the port moves to VLAN 200, DHCP works, and internal file shares are unreachable. Finally, test a registered BYOD device for VLAN 210 and a corporate laptop for VLAN 10. Clear stale endpoint records and monitor the policy log for a day before rolling out to all 400 ports.