First Boot on a Routed Management VLAN
A financial services customer deploys FortiNAC-F as a VM on a management network. The management interface is 10.20.5.10/24 with gateway 10.20.5.1, DNS 10.20.5.53, and an internal NTP server at 10.20.5.123. The estate has 600 endpoints, 24 FortiSwitch 448D access switches, and two FortiGate 600E firewalls. The administrator can reach the admin UI over HTTPS, but endpoint browsers never receive the captive portal. FortiSwitch RADIUS accounting shows requests sent to 10.20.5.10 with no response, and the FortiNAC event log contains 'certificate not yet valid' warnings plus timestamps from 2019. Endpoints sit in VLAN 120, while the FortiNAC management interface is in VLAN 20; inter-VLAN routing is allowed but no firewall policy exists between VLAN 120 and VLAN 20. A test laptop in VLAN 120 can ping 10.20.5.1 but not 10.20.5.10. The customer wants to avoid opening unnecessary ports.
1. Before changing switch or firewall configuration, which three checks do you run first, and what evidence tells you each has passed or failed?
Read the worked answer
Start with time, certificate, and path, because each can produce the same symptom without a switch problem.
- Time: the 'not yet valid' warning and 2019 timestamps point to clock skew. Check that the NTP service is enabled, the configured server is 10.20.5.123, and a peer is selected. Pass means the offset is small and the certificate dates fall inside the validity window; fail means no selected peer or a large offset.
- Certificate: compare the portal and RADIUS certificate subject alternative name with the FQDN clients use. Pass means the SAN matches, the chain is complete, and the certificate is currently valid; fail means a name mismatch, missing intermediate, or expired certificate.
- Path: from the test laptop, test TCP 443/8443 to 10.20.5.10 and UDP 1812/1813 from a switch. The ping result already shows routing to the gateway but not to the FortiNAC host, so check the FortiNAC default route and the firewall policy between VLAN 120 and VLAN 20. Pass means the specific ports open; fail means a drop or missing route. Only then change switch configuration.
2. The NTP server is reachable by ping, but FortiNAC still shows the wrong year after you configure it. What do you check next, and how do you prove the fix?
Read the worked answer
Reachability is not synchronization. Check four things: whether the NTP client service is actually enabled; whether the correct server address was saved; whether UDP 123 is permitted in both directions; and whether the selected peer is usable. A server that answers ping but is stratum 16, unreachable on UDP 123, or not selected will leave the clock unchanged. Also check the timezone: a correct UTC clock can still display the wrong local time, but it would not produce a certificate 'not yet valid' error if UTC were correct.
Prove the fix by checking the selected peer and offset, then wait for the clock to step and re-check the certificate validity window. Restart the portal service only after time is correct. Finally, confirm with a browser or an OpenSSL client that the certificate is valid now. If the offset remains large, capture UDP 123 from FortiNAC to 10.20.5.123 to see whether requests leave and replies return.
3. Time and certificate are fixed, but users in VLAN 120 still do not get the portal. What is your next diagnostic step?
Read the worked answer
Now isolate whether the failure is routing, firewall, DNS, or portal binding. From the VLAN 120 laptop, resolve the portal FQDN and try HTTP and HTTPS to the resolved address. If DNS returns a public or wrong address, fix the record. If the TCP connection times out, check the FortiNAC route back to 10.20.5.0/24 and the firewall policy for 443/8443; the earlier ping test proved routing to the gateway, not to FortiNAC. If TCP connects but no redirect appears, check whether the switch is sending HTTP redirects or whether the portal is bound to the correct interface. Also verify that the FortiNAC portal service is running and that the VLAN 120 subnet is included in the portal configuration. A packet capture on FortiNAC showing SYN arriving with no SYN-ACK points to a local service or firewall problem; no SYN points to routing or an upstream policy.