FCP_FWF_AD-7.4 FCP - Secure Wireless LAN 7.4 Administrator Questions and Answers

The scenario involves employees connecting via remote FortiAP (FAP) devices, with a requirement to enforce corporate security policies for all wireless stations at branch/remote sites.

Teleworker topology (also called remote AP, or split-tunnel mode) is designed exactly for this:

FortiAP at remote sites connects to the main office FortiGate via a secure tunnel (CAPWAP over VPN or DTLS).

Traffic destined for corporate resources is tunneled back to the main office for full security inspection and policy enforcement.

Local internet-bound traffic can be split off locally (split-tunnel) or tunneled back as well (full-tunnel), based on policy.

This ensures all employee wireless sessions accessing corporate resources are subject to central security policies, without requiring local IT staff.

Option A (VPN tunnels) is part of the teleworker topology but doesn't by itself ensure wireless security enforcement or policy application for wireless stations—teleworker/split-tunnel is more precise.

Option B is impractical and unnecessary.

Option C moves resources to the cloud, but this does not ensure security enforcement for wireless clients over remote links.

Summary: Teleworker topology on FortiAP allows secure, policy-enforced connectivity from remote sites back to HQ for all wireless stations.

For advanced wireless troubleshooting:

Capturing air traffic (B): This means performing a wireless packet capture (sniffing), usually via the FortiAP's diagnostic tools (e.g., cw_diag sniff), to see low-level association/authentication issues, interference, or protocol errors.

Reviewing event logs (C): Check event logs on the FortiGate and FortiAP to find authentication failures, disconnections, roaming events, or system messages specific to the wireless station.

A (creating/assigning a new profile) is not typically an advanced troubleshooting step; it's more of a configuration or workaround.

D (collecting power management info) is rarely required except for specific power-saving issues, and is not a primary advanced troubleshooting step.

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.

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.

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.

Channels 52 through 144 in the 5 GHz band (shown as UNII-2, UNII-2-Extended, and some adjacent channels) are marked in regulatory domains as DFS (Dynamic Frequency Selection) channels.

DFS channels must be monitored for radar activity (such as weather radar). If radar is detected, the AP must switch channels to avoid interference.

These channels can be used, but only if the AP supports DFS and performs the necessary checks before use.

WIDS can scan these channels but that’s not the defining characteristic.

Regulatory restrictions (B) apply only if DFS is not supported, which is rare on modern equipment.

Radio Resource Provisioning (C) is unrelated to DFS usage.