Fortinet FCP_FWF_AD-7.4 - FCP - Secure Wireless LAN 7.4 Administrator

Scenario Analysis:

The wireless client is redirected to a captive portal for authentication.

The authentication settings (see second exhibit) show:

Captive portal type: FQDN is selected.

Certificate: Fortinet_Factory (the default self-signed certificate).

The browser is reporting a certificate validation error when the redirection to the captive portal occurs.

Certificate Validation and Captive Portals:

When FQDN is used for captive portal redirection, the browser expects the SSLcertificate to be valid for the FQDN (e.g., “captive.company.com”).

If the certificate is self-signed or does not match the FQDN (common when using the Fortinet factory default certificate), the browser will trigger a certificate error.

This is a common issue when FQDN-based portals are used without a publicly trusted certificate matching the FQDN.

Option Analysis:

A. The FortiGate IP address in the POST parameters is using a numerical IP address

Not relevant; the browser validates the page being loaded, not the POST parameters.

B. The external server address is not the FQDN address

In this case, the external captive portal URL is using FQDN, as set in the authentication setting.

C. The used credential is not embedded in the captive portal parameters

Credential handling is not related to certificate errors; it would result in login/authentication failures, not browser SSL warnings.

D. The captive portal setting in the authentication setting is set to use FQDN as the captive portal type

Correct. When FQDN is used, the SSL certificate presented must be trusted and match the FQDN. The factory certificate will not match (it is not publicly trusted), so clients will see a validation error.

Summary:

Certificate validation fails because the captive portal is accessed via FQDN, but the FortiGate presents its self-signed factory certificate, which does not match the FQDN or is not trusted by browsers.

FortiAP and Rogue AP Detection:

Background Scanning:

FortiAPs can perform background scanning for rogue APs while actively servicing clients (broadcasting SSIDs). This means they periodically switch from client service to scan the air for unauthorized APs.

This enables detection of threats without a dedicated radio, using periodic scans on service radios.

Manual Suppression:

Suppression of rogue APs (for example, sending de-auth frames to clients of a rogue) must be triggered manually by an administrator from the FortiGate/FortiAP interface.

Automatic Suppression:

FortiAPs do NOT offer automatic suppression of rogue APs by default. Suppression is an explicit administrative action.

Dedicated Monitoring Radios:

Some APs (higher-end models) may have dedicated radios, but this is not the case for all FortiAPs; background scanning is the standard.

Option Breakdown:

A. FortiAP offers automatic suppression of rogue APs when broadcasting SSIDs

Incorrect. Suppression is manual.

B. FortiAP scans rogue APs in the background while broadcasting SSIDs

Correct. Background scanning is supported.

C. FortiAP detects rogue APs on dedicated monitoring radios

Incorrect for most deployments. Dedicated monitoring radios are available only in some models.

D. FortiAP suppresses detected rogue APs manually

Correct. Manual suppression is available via the management interface.

When a FortiAP is directly cabled to a FortiGate interface, it sends out a broadcast CAPWAP discovery packet.

The FortiGate listens for these on its interfaces and then discovers/provisions the FortiAP automatically.

Control traffic (CAPWAP control) is crucial for AP configuration, updates, monitoring, and management between FortiAP and FortiGate.

Data traffic carries user/client data, but management/configuration relies on control traffic.

Exhibit Review:

The diagnostics panel for FortiAP FP231FTF2001 shows:

Tx bandwidth label: 150.54 Mbps (likely the negotiated or theoretical maximum).

Bandwidth graph (actual traffic): Transmit (Tx) bandwidth peaked at only ~3 Mbps over the last 5 minutes—far below the maximum.

Radio 1 (2.4 GHz) shows 10 interfering SSIDs and 40% channel utilization.

Radio 2 (5 GHz) is not the focus in the current graph.

Interpretation:

The significant difference between the potential (label) and actual (graph) throughput indicates that something is preventing the AP from delivering full speed.

This could be resource overload (e.g., too many clients, too much interference, CPU/memory constraints), leading to overall reduced throughput for all users.

The graph represents real-time/actual usage, not just the theoretical capability.

Option Breakdown:

A. Resources on FortiAP are overloaded which limits speed rates for all users

Correct. Overload (either due to too many clients, high interference, or hardware resources) is a logical reason why actual throughput is far below the possible maximum.

B. Label values are historical and provide average bandwidth

Incorrect. The label reflects the maximum link rate or negotiated data rate, not an average or historical usage value.

C. FortiAP is dual band and is transmitting data faster with a higher frequency band

Not supported by the evidence. The current data is for Radio 1 (2.4 GHz) and does not show high usage on either band.

D. Bandwidth is shared with other SSID signals broadcasting for nearby AP devices

While interference does share airtime, the drastic drop in throughput strongly suggests an overload or other limiting factor on this AP.

Summary:

The large gap between the expected maximum (label) and the actual throughput observed suggests that resource overload is the root cause of poor wireless speeds for all users.

Analysis of the Exhibits and Scenario:

The DHCP server configuration is correct for dynamic assignment within a specified IP range for the interface “WLAN01”.

The RADIUS configuration for user1 includes:

Tunnel-Type (should be set to VLAN, but value is missing)

Tunnel-Medium-Type (set to IEEE-802, which is correct for Ethernet/WiFi)

Tunnel-Private-Group-Id (set to “infrastructure” as a string)

The problem described: Dynamic VLAN assignment is not working for user1.

How Dynamic VLAN Assignment Works in 802.1X/EAP (with FortiGate/FortiAP):

When a user authenticates, the RADIUS server returns attributes specifying the VLAN that should be assigned.

The critical attributes are:

Tunnel-Type (must be set to value “VLAN”, which is integer 13)

Tunnel-Medium-Type (must be “IEEE-802”, integer 6)

Tunnel-Private-Group-Id (can be the VLAN name or VLAN ID, depending on your configuration)

Problem in the Exhibit:

The Tunnel-Type value is missing!

It must be set to 13 (for VLAN).

The Tunnel-Medium-Type and Tunnel-Private-Group-Id are correctly set.

Corrective Action:

Update user1’s RADIUS attributes so that Tunnel-Type is set to the correct value for VLAN (integer 13).

Without this, FortiGate/FortiAP will not know to interpret the returned VLAN name or ID for dynamic assignment.

Review of Options:

Disable the DHCP server on ONBOARD to allow VLAN assignment.

Irrelevant; DHCP server presence does not affect dynamic VLAN assignment.

Add user1 in one of the VLAN names

This is not how dynamic VLAN assignment works. The RADIUS response must include the correct VLAN assignment.

Update user1 RADIUS attributes to include a VLAN ID attribute ID

Correct. You must set Tunnel-Type (13) and possibly provide the VLAN ID in Tunnel-Private-Group-Id.

Create a new VLAN name infrastructure' with a VLAN ID associated with it

Not the root cause; you must first ensure the correct attributes are present in the RADIUS response.

Summary:

The missing “Tunnel-Type” attribute value is the reason dynamic VLAN assignment is not working. The correct configuration requires setting Tunnel-Type = 13 (VLAN) for user1 in the RADIUS server.

The logs show repeated client-association-failure events followed by RADIUS authentication failure messages for client

This means the station successfully associated at Layer 2 but failed at the RADIUS authentication step (802.1X/EAP), typically due to invalid credentials or a misconfiguration on the RADIUS server.

Eventually, the log shows a successful authentication, indicating the credentials or RADIUS issue was resolved on a later attempt.

Scenario:

The IT department wants to prevent direct communication between wireless stations.

There is one SSID configured in bridge mode (all clients on the same SSID/VLAN, directly bridging to the wired network).

Correct Action:

Block intra-SSID traffic (sometimes called “client isolation” or “intra-SSID privacy”).

This feature prevents wireless clients connected to the same SSID from communicating directly with each other at Layer 2.

Each station can reach the network but cannot reach other wireless clients on the same SSID.

This is the industry-standard method to achieve the stated security goal in a wireless environment, especially in bridge mode.

Why Other Options Are Incorrect:

A. Create unique SSIDs for each FortiAP device

Impractical and unnecessary for user isolation; users on the same SSID but different APs can still be isolated with intra-SSID blocking.

B. Add an upstream layer 3 device on each FortiAP device

Overkill and not required; this does not directly solve intra-SSID traffic.

D. Drop all local traffic in the wireless network

Too broad; you only want to prevent client-to-client communication, not all local traffic (such as traffic to the gateway).

Summary:

Block intra-SSID traffic is the intended and correct configuration to prevent wireless stations from communicating directly while sharing the same SSID in bridge mode.