Fortinet FCSS_LED_AR-7.6 - Questions & Answers

Observed behavior:

Devices in the VLAN can ping FortiGate # gateway reachability OK.

FortiGate can ping devices in that VLAN # return path OK.

Inter-VLAN routingworks # FortiGate's L3 and policies are fine.

Devices in the same VLAN cannot ping each other# problem is on the L2 switching plane , not L3.

On FortiSwitch (managed by FortiGate), there is a feature called Access VLAN (sometimes described in
NAC /dynamic segmentation context):

When Access VLAN is enabled on a VLAN, the switch does not perform normal L2 forwarding between hosts in that VLAN.

Instead, all traffic from endpoints in that VLAN is forced upstream to FortiGate , as if every frame were destined for the gateway.

This is used for designs where you want all intra-VLAN traffic inspected by the firewall , implementing micro-segmentation.

Resulting behavior:

Host # FortiGate: works (frames are forwarded to FortiGate).

FortiGate # Host: works (routed back).

Host A # Host B (same VLAN):

Frame from A goes to FortiGate.

FortiGate sees source and destination in same subnet ; depending on policy, it may drop or not have a policy allowing that traffic.

Even if allowed, certain designs still break pure L2 expectations.

In the exam scenario, the key point is:

If Access VLAN is enabled local L2 communication within that VLAN is disabled , , so hosts in the same VLAN cannot communicate directly.

That perfectly explains:

Same VLAN hosts can't ping each other

But they can both reach FortiGate and beyond

Why the other options are less likely / incorrect

B. FortiSwitch MAC address table is missing entries

If MAC table were empty/bad, nothing in that VLAN would work properly, including pinging FortiGate.

C. FortiGate ARP table is missing entries

Then FortiGate couldn't ping the devices either; but it can.

D. Native VLAN misconfigured on ports

That would affect connectivity to FortiGate too, not only host-to-host.

Zero-Touch Provisioning (ZTP) for FortiGate devices is handled through FortiDeploy , which automatically connects a FortiGate to FortiManager so the device can download configuration templates and be centrally managed.

For ZTP to work, the newly booted FortiGate must successfully reach FortiManager. One of thecritical requirements is connectivity over the FGFM (FortiGate-FortiManager) management protocol , which uses:

TCP Port 541

This is clearly stated in multiple Fortinet documents:

FortiGate Cloud Admin Guidelists port 541 as the management channel used for FortiGate # FortiManager
/ FortiGate Cloud communications:"Management... Protocol: TCP, Port:541"

FortiOS Administration Guidealso confirms this:"FortiManager provides remote management of FortiGate devices overTCP port 541."

Since ZTP uses FortiDeploy to push the FortiManager IP to the device and relies on FGFM (port 541) for registration and configuration delivery, any failure on this port breaks the entire ZTP workflow.

Why option D is correct

If the FortiGate cannot reach FortiManager on TCP/541 , it cannot register , cannot be authorized, and cannot receive its configuration -- leading to a ZTP failure.

This is the most common cause in real deployments:

Firewall blocking TCP/541

Upstream NAT device not forwarding 541

ISP restrictions

Incorrect FortiManager IP or routing issue

ZTP device behind a network that does not allow outbound 541

Why the other options are incorrect

A. The FortiGate device requires manual intervention to accept the FortiManager connection.

Incorrect.

ZTP is built specifically to avoid manual intervention. Once the FortiDeploy key is used, the device auto-connects to FortiManager without needing local acceptance.

B. ZTP works only when devices are connected using a console cable.

Incorrect.

ZTP requires no console cable -- that's the whole point. It relies on DHCP, WAN connectivity, and FortiDeploy auto-join.

C. The FortiGate device must be preloaded with a configuration file before ZTP can function.

Incorrect.

Preloading configuration defeats the purpose of ZTP.

ZTP delivers the initial configuration automatically from FortiManager using FortiDeploy.

LAN Edge 7.6 Architect Context

LAN Edge deployments often use FortiManager as the central orchestrator for:

FortiSwitch management via FortiLink

FortiAP wireless provisioning

SD-Branch configuration templates

Security Fabric automation

For all of this, ZTP enables remote sites to deploy FortiGate, FortiSwitch, and FortiAP withno on-site expertise .

If TCP/541 to FortiManager is blocked, the entire LAN Edge deployment pipeline fails, making option the D only valid and document-supported answer.

In FortiGate captive portal workflows (local or external):

Client connects to SSID / interface that has captive portal enabled.

Client makes an HTTP/HTTPS request.

FortiGate intercepts and redirects to a login page (local or external URL).

The portal form is submitted via POST back to FortiGate.

To prevent tampering and to tie the POST back to the correct user session , FortiGate includes a special hidden parameter in the redirect and expects it in the POST:

The parameter is named magic .

The magic value:

Is a unique token generated per captive-portal session.

Encodes/session-links the user's IP, interface, and session info.

Allows FortiGate to ensure that:

The POST comes from the user who initiated the original request.

The request is not a random or replayed submission.

When troubleshooting:

If the external portal does not preserve and resend the magic parameter back to FortiGate exactly as received, authentication fails, and you'll see errors like "session not found" or "invalid magic".

Why the other fields are not used for this purpose

A. username - Just the login ID; multiple users can use the same username from different locations, so it
can't uniquely track the browser session.

B. redir - Contains the URL the user originally requested, so they can be sent back there after login. It is
not a session integrity token.

D. email - Optional field used in some guest/registration flows; irrelevant to session validation.

From the exhibit, LDAP on FortiGate is correctly configured and tested:

diagnose test authserver ldap FAC-LDAP wifi101 password authenticate 'wifi101' against 'FAC-LDAP' succeeded!

Group membership(s) - CN=Domain Users,...

So:

LDAP connectivity works

Bind DN, DN, CNID, and credentials are correct(so option is eliminated). C

Firewall policies do not affect the 802.1X / Wi-Fi authentication step itself, so is not the root cause. A Nothing in the scenario indicates that AD is enforcing LDAPS-only; the LDAP test already succeeds using
the configured parameters, so is also excluded. B

The Wi-Fi supplicant is configured for PEAP with inner authentication = MSCHAPv2.
MSCHAPv2 is a challengeesponse mechanism designed for RADIUS , not for LDAP simple bind.
FortiGate's LDAP implementation uses a simple bind (username/password) over LDAP or LDAPS , and it does not implement MSCHAPv2 against LDAP backends.

In Fortinet's design, if you need PEAP-MSCHAPv2 with Active Directory , you must use:

A RADIUS server (such as Windows NPS or FortiAuthenticator), and Have FortiGate use RADIUS, not LDAP, as the authentication backend for 802.1X / Wi-Fi users.

Because FortiGate cannot process MSCHAPv2 exchanges directly against an LDAP server, authentication fails when the inner method is MSCHAPv2, even though LDAP works when tested with a simple bind from the CLI.

On FortiLink, FortiGate's built-in DHCP server is what gives FortiSwitch its IP so it can come under management. For automatic FortiSwitch onboarding, the DHCP server is usually set with:

set vci-match enable

set vci-string "FortiSwitch" "FortiExtender"

In the exhibit, the DHCP server for fortilink has:

set vci-match enable

set vci-string "FortiExtender"

Because the VCI string doesn't include "FortiSwitch" , DHCP offers are only sent to clients whose Vendor Class Identifier matches FortiExtender . The FortiSwitch never receives an IP, so it stays Offline .

Option is wrong: member "port4" matches the physical cabling in the topology. B

Option is fine: FortiLink can be an C aggregate interface, not only physical.

Option (ip-managed-by-fortiipam) is unrelated; FortiIPAM isn't required here. A

In an SD-Branch deployment (FortiGate + FortiSwitch + FortiAP), FortiAIOps :

Collects telemetry and logs from Fabric devices

Uses machine-learning / AI analytics to:

Spot anomalies (latency, packet loss, RF issues, misconfigurations)

Highlight root causes

Propose optimization recommendations (e.g., channel changes, power tuning, config fixes)

It does not :

Automatically disable devices ( false) A Replace SD-WAN config or all routing ( false) C

Fix all issues with zero human input ( is marketing fantasy, not reality) D

In this design, FortiAuthenticator receives RADIUS accounting (RSSO) messages , looks up the user in LDAP to get group information, then injects FSSO logon events toward all FortiGate devices.

From the exhibits we know:

FortiAuthenticator is receiving RADIUS accounting from the RADIUS server.

LDAP queries are successful and return group membership.

But FortiGate does not receive FSSO logons , so identity-based policies are not applied.

For FortiAuthenticator to create an FSSO logon, the RADIUS accounting record must be correctlyparsed into at least :

Username

Client IP address

These are mapped from the RADIUS attributes in the RADIUS Accounting SSO client configuration (for example, User-Name and Framed-IP-Address). If these are not defined or mapped incorrectly, FortiAuthenticator can see the accounting packet but cannot build a valid FSSO session , so no update is sent to FortiGate.

Thus the most likely root cause is:

# The RADIUS Username and Client IPv4 attributes are not correctly defined for that RADIUS Accounting
SSO client (optionA).

Other options conflict with the scenario:

B. LDAP is already successfully returning groups.

C. FSSO user group attribute is separate; even without it, FSSO logons would still be created (just without
group mapping).

D. The interface receiving RADIUS accounting, so it is clearly enabled. is

FortiGate and FortiSwitch must share synchronized time when operating in FortiLink mode.

Documented reasons in FortiOS:

Accurate time synchronization is required for logs, authentication events, and fabric correlations.

Why it's critical:

802.1X EAP and RADIUS timestamp validation

NAC policy enforcement timestamps

Certificate validation

Log correlation in Security Fabric / FortiAnalyzer

Incorrect options:

A: Firmware synchronization does NOT require NTP.

B: Switch-to-switch communication does not depend on NTP.

D: Standalone mode is unrelated to time sync.

The DHCP configuration shows:

set vci-match enable

set vci-string "FortiSwitch" "FortiExtender"

What this means

VCI = Vendor Class Identifier (DHCP option 60)

When vci-match is enabled, the DHCP server will only respond to DHCP requests from clients whose VCI string matches the configured vendor identifiers.

FortiSwitch and FortiExtender both send DHCP option 60 with:

"FortiSwitch"
"FortiExtender"

This is used in FortiLink deployments so only these devices receive IP addresses on the FortiLink network.

Therefore:

C. To connect, devices must match the VCI string; otherwise, they will not receive an IP address.

#Correct.

This perfectly matches FortiGate FortiLink DHCP behavior.

Summary of incorrect options

A -- Ignore FortiSwitch/FortiExtender

#Opposite behavior.

B -- Restrict based on hostname

#VCI does NOT check hostname.

D -- Reserve IPs

#No reservation occurs; it's filtering, not reserving.