FCSS_LED_AR-7.6 Fortinet NSE 6 - LAN Edge 7.6 Architect Questions and Answers

From the exhibits:

FortiSwitch Ports viewshows:

port2

Mode: Static

Native VLAN: Students

Allowed VLANs: quarantine.fortilink (quarantine)

NAC policy “Training”:

Switch FortiLink: fortilink

Category:Device

Matching criteria:

MAC Address: 70:88:6b:8c:4b:0e (enabled)

Operating System:Linux(enabled)

Switch Controller Action:

Assign VLAN = Students

Bounce Port = enabled

Design intent:

Device with that MAC + OS Linux, when plugged intoport2, should be dynamically moved to VLANStudentsby the NAC policy.

Why it doesn’t work now

On FortiLink NAC,dynamic NAC decisions only apply on ports whose “Access Mode” is set to NAC:

NAC mode = FortiGate controls theonboarding VLAN, evaluates NAC policies, and then dynamically reassigns the switch port VLAN (access, quarantine, etc.).

Static mode(what we see on port2) means the port just uses its configurednative/allowed VLANs, andno NAC classificationhappens.

Right now:

port2 is astatic access portwith Native VLAN = Students.

The NAC policy exists, butFortiSwitch is not in NAC enforcement mode on that port, so the policy is never evaluated for traffic on port2.

Therefore, themissing configurationis:

Setport2toNAC mode(sometimes called “Access mode: NAC” or “NAC LAN edge port”).

Once port2 is changed to NAC mode:

Device initially lands in the onboarding/quarantine VLAN.

FortiGate collects device info (MAC, OS, etc.).

NAC policy “Training” matches MAC + Linux.

Switch controller actionAssign VLAN = Studentsis applied.

Port is bounced (if configured), bringing the device back up in VLAN Students.

Why the other options are wrong

B. MAC or OS misconfigured

Possible in general, but the question asks forwhich configuration is missing, and the exhibits clearly focus on port mode. Also, even with wrong MAC/OS, the port would still be in NAC mode; here NAC isn’t even active.

C. Port Policy mode

Port policy (edge/trunk) is separate from NAC; NAC requires the specificNAC access mode.

D. Students VLAN should be Allowed VLANs instead of Native VLAN

For an access port, having Students as thenative VLANis correct. NAC policy’s Assign VLAN will set that as access VLAN; no need to make it an allowed trunk VLAN.

When FortiAPs connect to FortiGate overIPsec tunnels, this is treated similarly to WAN/MPLS deployments.

In these scenarios, FortiGate must know that CAPWAP must traverse anon-L2transport.

FortiAP profiles include:

set mpls-connection enable

This setting is required so that:

FortiGate can encapsulate CAPWAP inside the transport tunnel

Remote FortiAPs can establish CAPWAP even when behind routed/IPsec networks

Without this option, the FortiGate detects the AP butcannot bring CAPWAP UP, leaving the AP in “discovered/unauthorized” or “offline” state.

Why others are wrong

A. Static route→ Discovery already succeeds, so routing is not the issue.

C. Reduce MTU→ Sometimes useful for IPsec, but not required for CAPWAP establishment.

D. Firmware upgrade→ Firmware mismatch would show “Managed (upgrade required),” not CAPWAP tunnel failure.

Therefore,set mpls-connection enableis the required fix.

In FortiLink NAC for LAN Edge:

When a device first connects, it is placed into theonboarding VLAN.

NAC policies then classify the device (by MAC, OS, user, EMS tag, etc.).

If a NAC policy matches, the device may be moved to anaccess VLANorquarantine VLAN.

Ifno NAC policy matches, the device simplystays in the onboarding VLAN.

FortiOS / LAN Edge documentation describes the onboarding VLAN as thedefault VLAN for unknown or unclassified devices, until NAC policy evaluation moves them elsewhere.

The SSL-VPN configuration hasRequire Client Certificateenabled. When this is enabled, FortiOS performs two checks:

Normal user authentication(username/password or PKI user)

Additional client certificate check– the client certificatemust be signed by a CA that FortiGate trusts

FortiOS documentation for “SSL VPN with certificate authentication” states:

“The client certificate only needs to be signed by a known CA in order to pass authentication.”

“The CA certificate is the certificate that signed both the server certificate and the user certificate… The CA certificate is available to be imported on the FortiGate.”

The debug output shows key lines:

__quick_check_peer-CA does not match.

Issuer of cert depth 0 is not detected in CMDB.

This tells us:

FortiGatedoes see the user’s certificate,

Butcannot find the issuing CAin its local CA certificate store (“CMDB” = configuration database).

This means theCA that signed the user certificate has not been importedinto FortiGate.

Now evaluate the options:

A. Enable Redirect HTTP to SSL-VPN– affects only redirection from HTTP to HTTPS; it has nothing to do with certificate validation.

B. Import the CA that signed the SSL VPN Server Certificate– the server certificate is already working (the portal comes up) and its CA is not what the debug complains about; the error is about thepeer (user) certificate. Often the same CA signs both, but the failing check specifically says the issuer of the client cert is not in CMDB.

C. Set the user certificate as the Server Certificate– incorrect; server and client certificates serve different roles.

D. Import the CA that signed the user certificate to FortiGate– this directly addresses the debug error and aligns with the documented requirement that the CA which issued the user certificate must be known to FortiGate.

The correct answer is D.

The LAN Edge 7.6 Architect study guide states: “Note that suppression of rogue APs is becoming increasingly more difficult, because new wireless security standards are beginning to mandate management frame protection (802.11w). This requires that clients authenticate management frames as being legitimate, preventing spoofing attacks. Because rogue suppression is a form of spoofing attack, an AP that the client is not connected to is trying to send deauthentication frames and, as a result, 802.11w prevents the client from taking notice of the dedicated monitoring AP.”

This exactly matches option D. Rogue AP suppression relies on spoofed deauthentication behavior, and 802.11w protects management frames, making that suppression method less effective.

Why the other options are incorrect:

A. Incorrect. The study guide does not say 802.11w makes suppression harder because of processing overhead. It specifically points to management frame protection and spoofing prevention

B. Incorrect. The study guide does not mention reduced wireless range as the reason.

C. Incorrect. The issue is not data traffic encryption. The study guide specifically refers to authentication of management frames, not general traffic encryption

The LAN Edge 7.6 Architect Study Guide identifies the following communication mechanisms between FortiGate and FortiSwitch:

C — FortiLink Protocol (Primary Management Protocol): The study guide states: " FortiLink, also known as the switch controller function, allows FortiGate firewalls to remotely manage FortiSwitch devices. FortiLink defines the management interface and remote management protocol between FortiGate and FortiSwitch, enabling seamless control and integration. " FortiLink is the foundational protocol for the entire management relationship.

B — HTTPS (REST API): The study guide confirms: " FortiGate applies the quarantine-related configuration for the quarantined device to FortiSwitch using the FortiSwitch REST API. " FortiGate communicates with FortiSwitch via HTTPS-based REST API calls for specific configuration pushes such as quarantine enforcement, port configuration, and security policy application.

A — SNMP: SNMP is referenced in the study guide as a management protocol used by FortiGate to monitor and gather status information from FortiSwitch devices. SNMP is a standard network management protocol used for monitoring switch status, which aligns with its role in FortiSwitch management.

Why the other options are wrong:

D is incorrect — CAPWAP (UDP 5246/5247) is the protocol used between FortiGate and FortiAP for wireless AP management, NOT between FortiGate and FortiSwitch. The study guide explicitly states: " FortiGate manages FortiAPs using the CAPWAP protocol. "

E is incorrect — IGMP is an IP multicast group management protocol. It plays no role in the management or control channel between FortiGate and FortiSwitch. It is not mentioned in the LAN Edge 7.6 study guide in the context of FortiSwitch management.

From the FortiManager NAC policy:

Category =Device

Match criteria includeMAC addressandOperating System = Linux

Action =Assign VLAN “Students”

From the FortiGate CLI:

diagnose switch-controller switch-info mac-table ...

MAC: 70:88:6b:8c:4a:ce VLAN: 4089 Port: port2

diagnose switch-controller mac-device mac onboarding

VLAN 4089 MAC 70:88:6b:8c:4a:ce

So the device is stuck inVLAN 4089, which is theonboarding VLAN. No NAC policy is matched.

For a NAC policy to match, FortiGate needsdevice-identity information, which comes fromdevice detection on the VLAN / FortiLink interfaceplus theattributes that the policy expects(OS, MAC, etc.).

A. Device detection is not enabled on VLAN 4089.

If device detection is disabled on the interface/VLAN where the endpoint lives, FortiGate cannot learn OS / device info.

Without this, the NAC engine cannot compare against the NAC policy (which relies on OS and other attributes), so the device remains in the onboarding VLAN.✅This is a valid root cause.

B. The device operating system detected by FortiGate is not Linux.

The NAC policy explicitly requiresOperating System = Linux.

If the endpoint is actually Windows/macOS, or the OS fingerprint is still “Unknown”, the policy will never match, and the device stays in onboarding.✅Also a valid reason.

C. Management communication between FortiGate and FortiSwitch is down.

CLI output (switch-info mac-table and mac-device) proves FortiGate is talking to the switch and sees MAC/VLAN/port information.❌Not a valid reason.

D. The MAC address configured on the NAC policy is incorrect.

The exhibits show the MAC in the NAC policy matches the MAC appearing in the MAC table.❌Not the cause here.

Goal: enforce captive portal authentication overHTTPSfor guests.

On FortiGate/FortiAuthenticator captive portal setups:

HTTP redirectis used so that when a guest browses to any HTTP site, their request is redirected to theportal URL.

Theportal URLitself must beHTTPSif you want a secure login page.

FortiOS captive portal and firewall authentication guidelines recommend:

EnablingHTTP redirectso unauthenticated HTTP traffic is transparently sent to the portal.

Configuring theportal URL with HTTPS, often referencing a certificate on FortiGate or FortiAuthenticator.

Therefore:

A. Enable HTTP redirect in the user authentication settings.✔This ensures unauthenticated HTTP requests are redirected to the (now HTTPS) portal.

D. Update the captive portal URL to use HTTPS on FortiGate and FortiAuthenticator.✔This makes the login itself secure (TLS-protected).

Incorrect:

B– You don’t need a new SSID; the same SSID can use HTTPS portal.

C– Disabling HTTP admin access on the SSID doesn’t control the captive portal scheme; HTTPS enforcement is done by the portal configuration and redirect, not by admin-access flags.

The correct answer is D.

The LAN Edge 7.6 Architect study guide directly explains this exact behavior for SSIDs configured on FortiManager.

The study guide states:

“In central management mode, profiles are created and stored on FortiManager. An AP profile is distributed to a controller when at least one of its supported APs is assigned the profile and the device settings are installed. SSID profiles are delivered only when you select Manual in the SSID field.”

It further says:

“If you create an SSID profile centrally and configure all the AP profiles to be tunnel or bridge, the SSID profile is not delivered to FortiGate. FortiManager does not know which of the SSID profiles to distribute to which FortiGate.”

And the guide gives the exact fix:

“A manual SSID explicitly tells FortiManager which SSID profile to broadcast on the AP and, as a result, the required SSID profile is delivered to the controller.”

Another extract from the same section confirms:

“When you want to broadcast an SSID, you must configure the AP profile that is being used by the APs that are to transmit it... Manual: You can select a mix of SSIDs to broadcast.”

So in this scenario, the AP profile must be changed from Bridge or Tunnel to Manual, and then the required SSIDs must be explicitly selected.

Why the other options are incorrect:

A. Incorrect. The issue is not the AP platform. The study guide identifies the problem as SSID delivery and mapping from FortiManager to FortiGate, not AP hardware support

B. Incorrect. The study guide explicitly says Manual can be used to “select a mix of SSIDs to broadcast,” so a mix is supported when Manual is chosen

C. Incorrect. Transmit Power Mode affects RF behavior, not whether FortiManager delivers SSID profiles to FortiGate. The problem here is SSID assignment and profile distribution, not radio power.

Extra confirmation from FortiGate Cloud administration guidance:

“To configure the SSID that you created select Manual for SSIDs then select the SSID from the dialog.”

Final verified conclusion:

Because the SSIDs were created on FortiManager and are not being broadcast, the AP profile must use Manual in the SSIDs field and the intended SSIDs must be explicitly selected.

So the correct answer is D.

From the exhibits:

Interface“APs”is a VLAN sub-interface onfortilinkwith IP10.10.100.254/24and a DHCP server scope 10.10.100.1–10.10.100.253.

This VLAN is assigned toport1on the managed FortiSwitch for FortiAPs.

The interface config showsonly allowaccess ping—Security Fabric Connection is not enabled.

In LAN Edge designs, FortiAPs connected through FortiSwitch are discovered and managed asLAN edge devices of the Security Fabric. FortiOS documentation states that FortiAPs and FortiSwitches appear in the Fabric topologyonly when connected on an interface with Security Fabric Connection enabled.

If the VLAN/AP management interface lacksSecurity Fabric Connection:

FortiGate does not treat that network as aFabric connection segment.

CAPWAP discovery from FortiAPs on that VLAN will not result in the AP being onboarded and shown for management.

Therefore the key misconfiguration is:

✔A – Security Fabric is disabled on the VLAN interface used for AP management.

Why the others are not the root cause:

B. Firmware incompatibility– would usually show as a “Managed (upgrade required)” or similar status after discovery, not complete non-detection. The scenario specifically points to a configuration issue, not firmware.

C. VLAN not tagged correctly on uplink– The FortiSwitch uplink to FortiGate is the FortiLink trunk, and the VLAN sub-interface APs is already bound to fortilink, so tagging on the uplink is correct by definition.

D. CAPWAP ports not open– CAPWAP (UDP 5246/5247) is terminated locally on FortiGate and does not depend on any firewall policy; these ports are open on the FortiGate itself by default.

The correct answer is D.

The LAN Edge 7.6 Architect study guide explains that when using an external captive portal, configuring the portal URL and exempt destinations on the SSID is not enough by itself. FortiGate must also have a matching firewall policy that allows the unauthenticated client traffic path to the external portal.

The guide states: “If you are using an external captive portal server, you must configure a firewall policy and exempt web traffic to the external captive portal IP address.”

It also states: “Just selecting and applying the address object and selecting the services is not enough to allow the traffic to pass through FortiGate. You must also have a corresponding firewall policy in place that allows the pinhole traffic to pass through FortiGate.”

In the exhibit, the SSID already includes FortiAuthenticator and WindowsAD as exempt destinations/services, so option C is already configured. However, the wireless clients are connecting through the AP on port4, and the visible firewall policy shown is from the guest SSID interface to port1 for internet access. There is no policy shown that permits the required pre-authentication traffic path from the wireless side toward the external portal resources through the relevant source path. Therefore, the missing fix is the firewall policy using port4 as source.

Why the other options are incorrect:

A. Incorrect. External captive portal authentication is designed to work with an open SSID plus captive portal. WPA2-Enterprise is a different authentication model and is not required here

B. Incorrect. The study guide does not identify NAT on that policy as the reason users cannot reach the external captive portal login page. The key requirement is the exempt/pinhole firewall policy, not NAT behavior

C. Incorrect. Those address objects are already present in the SSID configuration under exempt destinations/services, so this is not the missing change.

Final verified conclusion:

Because the exempt destinations are already configured, the missing requirement is the corresponding firewall policy permitting the captive portal pinhole traffic from the wireless source path.

So the correct answer is D.