Configure a RADIUS Server for Captive Portal Authentication

Configure a RADIUS Server with Web UI for Captive Portal Authentication

You can, for authentication purposes, set up the identity and secret for the RADIUS server. This takes precedence over any configured User IDs but if RADIUS accounting fails over, the local authentication guest user IDs are used. To do this, follow these steps:

1. Click Configuration > Security > RADIUS to access the RADIUS Profile Table.
2. Click Add.
3. Provide the RADIUS server information.
4. Save the configuration by clicking OK.
5. Enable a security profile for use with a Captive Portal login page by clicking Configuration > Security > RADIUS > Add.
6. Provide the required information, such as the name of the RADIUS profile. L2MODE must be clear to use Captive Portal. Set the Captive Portal to WebAuth and adjust any other parameters as required.

The identity and secret are now configured.

Configure a RADIUS Server with CLI for Captive Portal Authentication

The CLI command ssl-server captive-portal authentication-type configures the controller to use either local authentication, RADIUS authentication, or both. If both is selected, local authentication is tried first; if that doesn’t work, RADIUS authentication is attempted.

Controller(config)# ssl‐server captive‐portal authentication‐type ? local                  Set Authentication Type to local. local‐radius           Set Authentication Type to Local and RADIUS. radius                 Set Authentication Type to RADIUS.

The following example configures an authentication RADIUS profile named radius-auth-pri.

/* RADIUS PROFILE FOR AUTHENTICATION */ default# configure terminal

default(config)# radius‐profile radius‐auth‐pri default(config‐radius)# ip‐address 172.27.172.3 default(config‐radius)# key sept20002 default(config‐radius)# mac‐delimiter hyphen default(config‐radius)# password‐type shared‐secret default(config‐radius)# port 1812 default(config‐radius)# end

Configure a RADIUS Server for Captive Portal Authentication

default#

default# sh radius‐profile radius‐auth‐pri

RADIUS Profile Table

RADIUS Profile Name   : radius‐auth‐pri

Description           :

RADIUS IP             : 172.27.172.3

RADIUS Secret         : *****

RADIUS Port           : 1812

MAC Address Delimiter : hyphen

Password Type         : shared‐secret

The following example configures a security RADIUS profile named radius-auth-sec.

default# configure terminal default(config)# radius‐profile radius‐auth‐sec default(config‐radius)# ip‐address 172.27.172.4 default(config‐radius)# key sept20002 default(config‐radius)# mac‐delimiter hyphen default(config‐radius)# password‐type shared‐secret default(config‐radius)# port 1812 default(config‐radius)# end default#

default# sh radius‐profile radius‐auth‐sec

RADIUS Profile Table

RADIUS Profile Name   : radius‐auth‐pri

Description           :

RADIUS IP             : 172.27.172.4

RADIUS Secret         : *****

RADIUS Port           : 1812

MAC Address Delimiter : hyphen Password Type         : shared‐secret

OAuth Authentication Support

FortiWLC (SD) along with Fortinet Connect (MCT) 14.10.0.2 supports OAuth authentication for captive portal users. In a typical scenario if a user (for example: a hotel guest) tries to access an external web site, they are re-directed to a captive portal page for authentication. In

OAuth Authentication Support

the captive portal page, the user must register with a username, password, e-mail etc and complete the authentication process after receiving confirmation from the hotel captive portal.

• OAuth support must be enabled in the Fortinet Connect
• Only wireless clients that access SSL3 enabled (HTTPS) destination can use this feature
• If the wireless client uses a proxy server located on the wired network, then the client will be granted access to the internet till the login timeout expires.
• Supported only for ESS profiles in tunneled mode.
• Supported only for IPv4 clients.

By enabling OAuth, users can use any of the social media (Facebook, Google, Twitter, OpenID, etc) login credentials that support OAuth for captive portal authentication. For your users, this alleviates the need to spend time to register or remember passwords for repeated authentication.

Social Authentication Support

The captive portal authentication process now supports Fortinet Presence as an external CP authentication server that allows users to authentication using social media accounts like Facebook or Gmail OAuth.

Supported APs: AP122, AP822, AP832, OAP832, FAP-U421EV and FAP-U423EV.

Before proceeding, note the following:

• Enable location service in the controller(See “Configuring FortiPresence API” on page 86. for more details).
• Assign the AP in the data analytics store.
• Not supported in “Bridge mode”.

To enable social authentication support, do the following:

1. Create captive portal exemptions profile
2. Configure captive portal profile to use Fortinet Presence
3. Enable this captive portal profile in security profile and add this security profile in the ESS profile.

Social Authentication Support

Create Captive Portal Exemptions Profile

To enable social login, create a profile with the list of exempted URLs and in the captive portal profile and select FortiPresence as the external authentication server.

1. Go to Configuration > Security > Captive Portal > Captive Portal Exemptions.
2. Click the Add button to create a profile with the list of URLs that will be allowed for social authentications. To add multiple URLs to a profile, enter a space after each URL entry. You can add up to 32 URLs

Social Authentication Support

Configure Captive Portal Profile to use Fortinet Presence

1. Go to Configuration > Security > Captive Portal > Captive Portal Profiles page
2. Create a captive portal profile with local or radius as authentication type.
   • If Authentication type is Local, then create a guest user with the following credentials: username: gooduser
   • password:good. If Authentication type is RADIUS, then in that RADIUS server, create a user with the following credentials: • username: gooduser
   • password:good.
3. Make the following changes to External Portal Settings:
4. Select Fortinet-Presence as the external server (1).
5. Select the profile (2) created with the exempted URLs.
6. Enter http://socialwifi.fortipresence.com/wifi.html?login as URL (3) in the external portal

URL.

Social Authentication Support

For Fortinet Presence server configuration and account, see the FortiPresence configuration guide: http://docs.fortinet.com/d/fortipresence-analytics-configuration-guide

Enable this captive portal profile in security and ESS profiles

Enable the captive portal profile in the security profile and map the security profile in the ESS Profile.  In the security profile, make the following changes to the CAPTIVE PORTAL SETTINGS section:

1. Set Captive Portal to Webauth.
2. Select the captive portal created for enabling social wifi login.
3. Set Captive Portal Authentication Method as External.

Configuring Rogue AP Detection Using the CLI

These CLI commands configure rogue detection; for a complete explanation of the commands, see the FortiWLC (SD) Command Reference.

Configuring Rogue AP Detection Using the CLI

Adding APs to Scan List

default(15)# configure terminal default(15)(config)# rogue‐ap detection‐ap 1 default(15)(config)# rogue‐ap detection‐ap 3 default(15)(config)# exit

Show Output default(15)# sh rogue‐ap detection‐ap‐list

AP ID

1    

3    

        Rogue Device Detecting APs(2)

Deleting APs from Scan list

default(15)# configure terminal           default(15)(config)# no rogue‐ap detection‐ap 1 default(15)(config)# no rogue‐ap detection‐ap 3 default(15)(config)# end

Show Output default(15)# show rogue‐ap detection‐ap‐list

AP ID

        Rogue Device Detecting APs(No entries)

Configuring the AP Access and Block Lists with the CLI

The feature uses an Access Control List (ACL) containing a list of allowed BSSIDs and a list of Blocked BSSIDs. By default, all Fortinet ESS BSSIDs in the WLAN are automatically included in the allowed ACL. A BSSID cannot appear in both lists.

To add an access point with a BSSID of 00:0e:cd:cb:cb:cb to the access control list as an authorized access point, type the following:

controller (config)# rogue‐ap acl 00:0e:cd:cb:cb:cb controller (config)#

Configuring Rogue AP Detection Using the CLI

To see a listing of all BSSIDs on the authorized list, type the following:

controller# show rogue-ap acl

Allowed APs

BSSID

00:0c:e6:cd:cd:cd 00:0e:cd:cb:cb:cb

A BSSID cannot be on both the blocked list and the access list for rogue AP detection at the same time. Suppose 00:0c:e6:cd:cd:cd is to be placed on the blocked list. If this BSSID is already on the authorized list, you must remove the BSSID from the authorized list, and then add the BSSID to the blocked list, as follows:

controller (config)# no rogue‐ap acl 00:0c:e6:cd:cd:cd controller (config)# controller (config)# rogue‐ap blocked 00:0c:e6:cd:cd:cd                                 controller (config)# exit controller# show rogue-ap acl

Allowed APs

BSSID

00:0e:cd:cb:cb:cb controller# show rogue-ap blocked

BssId               Creation Date   Last Reported

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐   ‐‐‐‐‐‐‐‐‐‐‐‐‐‐  ‐‐‐‐‐‐‐‐‐‐‐‐‐‐

00:0c:e6:cd:cd:cd   11/02 01:05:54   11/02 01:06:20

The commands to enable and confirm the rogue AP detection state are as follows:

controller (config)# rogue‐ap detection controller# show rogue-ap globals

Global Settings

Detection                              : on

Mitigation                             : none

Rogue AP Aging (seconds)               : 60

Number of Candidate APs                : 3

Number of Mitigating APs               : 5

Scanning time in ms                    : 100

Operational time in ms                 : 400

Max mitigation frames sent per channel : 10

Scanning Channels                      :

1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165 RSSI Threshold for Mitigation          : ‐100

Use the CLI command show rogue-ap-list to display all rogue clients and APs in the network.

Rogue Mitigation Example

Rogue AP mitigation for APs in the blocked list is enabled and confirmed as follows:

Configuring Rogue AP Detection Using the CLI

controller# configure terminal controller (config)# rogue‐ap detection controller (config)# rogue-ap mitigation selected controller (config)# exit controller# show rogue-ap globals

Global Settings

Detection                              : on

Mitigation                             : selected

Rogue AP Aging (seconds)               : 60

Number of Candidate APs                : 3

Number of Mitigating APs               : 5

Scanning time in ms                    : 100

Operational time in ms                 : 400

Max mitigation frames sent per channel : 10

Scanning Channels                      :

1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165 RSSI Threshold for Mitigation          : ‐100

Configuring Rogue AP Mitigation with Web UI

To prevent clients of unauthorized APs from accessing your network, enable the options for both scanning for the presence of rogue APs and mitigating the client traffic originating from them. These features are set globally, with the controller managing the lists of allowable and blocked WLAN BSSIDs and coordinating the set of APs (the Mitigating APs) that perform mitigation when a rogue AP is detected.

Configuring Rogue AP Mitigation with Web UI

You can create a white-list of APs that will perform rogue detection. Other APs that are not added to this white-list will not scan for rogue AP/clients.

When rogue AP scanning (detection) is enabled, for any given period, the AP spends part of the time scanning channels (determined by the setting Scanning time in ms), and part of the time performing normal AP WLAN operations on the home channel (determined by the setting Operational time in ms). This cycle of scan/operate repeats so quickly that both tasks are performed without noticeable network operation degradation.

The channels that are scanned by a particular AP are determined by the model of the AP. As a result of the channel scan, a list of rogue APs is compiled and sent by the controller to a number of Mitigating APs that are closest to the rogue AP. Mitigating APs send mitigation (deauth) frames to the rogue AP where clients are associated to remove those clients from the network. This presence of the rogue AP generates alarms that are noted on the Web UI monitoring dashboard and via syslog alarm messages so the administrator is aware of the situation and can then remove the offending AP or update the configuration list.

As well, if a rogue device seen on the wired interface of the AP and if the device is in the AP’s discovered list of stations a wired rogue notification will be sent via the Web UI monitoring dashboard and syslog alarm message. If the rogue client is associated with the AP, that client is also classified as a rogue.

Alter the List of Allowed APs with the Web UI

To change the list of allowed APs, follow these steps:

1. From the Web UI, Enable rogue detection from Configuration > Security > Rogue APs > Global Settings page.

Configuring Rogue AP Mitigation with Web UI

Alter the List of Blocked APs with the Web UI

To change the list of allowed APs, follow these steps:

Configuring Rogue AP Mitigation with Web UI

1. From the Web UI click Configuration > Security > Rogue APs > Blocked APs. The table shows information about access points listed as blocked BSSIDs in the access control list (ACL).
2. To see an updated list of the APs blocked in the WLAN, click Refresh.
3. To add an AP to the blocked list, click Add.
   • In the BSSID box, type the BSSID, in hexadecimal format, of the access point. Add the BSSID to the ACL, by clicking OK.
4. The blocked BSSID now appears on the list with the following information:
   • BSSID The access point’s BSSID.
   • Creation Time The timestamp of when the blocked AP entry was created.
   • Last Reported Time The time the AP was last discovered. If this field is blank, the AP has not been discovered yet.
5. To remove a blocked BSSID from the ACL, select the checkbox of the blocked AP entry you want to delete, click Delete, and then click OK.

Configure Scanning and Mitigation Settings with the Web UI

To configure rogue AP scanning and mitigation settings, follow these steps:

1. From the Web UI click Configuration > Security > Rogue APs > Global Settings.

The Rogue AP screen appears with the Global Settings tab selected. See Figure 62.

Figure 62: Web UI Rogue AP Global Settings

2. In the Detection list, select one of the following:

Configuring Rogue AP Mitigation with Web UI

• On: Enables scanning for rogue APs. Off: Disables rogue detection.

3. In the Mitigation list, select one of the following:
   • No mitigation: No rogue AP mitigation is performed.
   • Block all BSSIDs that are not in the ACL: Enables rogue AP mitigation of all detected BSSIDs that are not specified as authorized in the Allowed APs list.
   • Block only BSSIDs in blocked list: Enables rogue AP mitigation only for the BSSIDs that are listed in the Blocked APs list.
   • Block Clients seen on the wire: Enables rogue mitigation for any rogue station detected on the wired side of the AP (the corporate network, in many cases). When Block clients seen on the wire is selected, clients seen on the corporate network are mitigated. When Block clients seen on the wire is selected and the BSSID of the wired rogue client is entered in the blocked list (see “Alter the List of Blocked APs with the Web UI” on page 310) only listed clients are mitigated.
4. In the Rogue AP Aging box, type the amount of time that passes before the rogue AP alarm is cleared if the controller no longer detects the rogue. The value can be from 60 through 86,400 seconds.
5. In the Number of Mitigating APs text box, enter the number of APs (from 1 to 20) that will perform scanning and mitigation of rogue APs.
6. In the Scanning time in ms text box, enter the amount of time Mitigating APs will scan the scanning channels for rogue APs. This can be from 100 to 500 milliseconds.
7. In the Operational time in ms text box, enter the amount of time Mitigating APs will spend in operational mode on the home channel. This can be from 100 to 5000 milliseconds.
8. In the Max mitigation frames sent per channel text box, enter the maximum number of mitigation frames that will be sent to the detected rogue AP. This can be from 1 to 50 deauth frames.
9. In the Scanning Channels text box, enter the list of channels that will be scanned for rogue APs. Use a comma separated list from 0 to 256 characters. The complete set of default channels are

1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165.

10.In the RSSI Threshold for Mitigation text box, enter the minimum threshold level over which stations are mitigated. The range of valid values is from to -100 to 0.

11.Click OK.

Rogue AP Detection and Mitigation

Rogue APs are unauthorized wireless access points. These rogues can be physically connected to the wired network or they can be outside the building in a neighbor’s network or they can be in a hacker’s parked car. Valid network users should not be allowed to connect to the rogue APs because rogues pose a security risk to the corporate network. Rogue APs can appear in an enterprise network for reasons as innocent as users experimenting with WLAN technology, or reasons as dangerous as a malicious attack against an otherwise secure network. Physical security of the building, which is sufficient for wired networks with the correct application of VPN and firewall technologies, is not enough to secure the WLAN. RF propagation inherent in WLANs enables unauthorized users in near proximity of the targeted WLAN (for example, in a parking lot) to gain network access as if they were inside the building.

TABLE 19: Fortinet Support of Rogue Detection and Mitigation

Regardless of why a rogue AP exists on a WLAN, it is not subject to the security policies of the rest of the WLAN and is the weak link in an overall security architecture. Even if the person who introduced the rogue AP had no malicious intent, malicious activity can eventually occur. Such malicious activity includes posing as an authorized access point to collect security information that can be used to further exploit the network. Network security mechanisms typically protect the network from unauthorized users but provide no means for users to validate the authenticity of the network itself. A security breach of this type can lead to the collection of personal information, protected file access, attacks to degrade network performance, and attacks to the management of the network.

To prevent clients of unauthorized APs from accessing your network, enable the options for both scanning for the presence of rogue APs and mitigating the client traffic originating from them. These features are set globally from either the CLI or Web UI, with the controller managing the lists of allowable and blocked WLAN BSSIDs and coordinating the set of APs (the mitigating APs) that perform mitigation when a rogue AP is detected.

As a result of the channel scan, a list of rogue APs is compiled and sent by the controller to a number of mitigating APs that are closest to the rogue AP. Mitigating APs send mitigation

307

(deauth) frames to the rogue AP where clients are associated to remove those clients from the network. This presence of the rogue AP generates alarms that are noted on the Web UI monitoring dashboard and via syslog alarm messages so the administrator is aware of the situation and can then remove the offending AP or update the configuration list.

Rogue Scanning can be configured so that it is a dedicated function of a radio on a dual radio AP or a part time function of the same radio that also serves clients. When rogue AP scanning (detection) is enabled, for any given period, an AP spends part of the time scanning channels and part of the time performing normal AP WLAN operations on the home channel. This cycle of scan/operate, which occurs on a designated AP or an AP interface without assigned stations, ensures there is no network operation degradation.

For AP400 and AP1000, each radio is dual band (supports both 2.4GHz and 5.0GHz) and capable of scanning for all channels and all bands when configured as a dedicated scanning radio. As access points are discovered, their BSSID is compared to an AP access control list of BSSIDs. An access point might be known, blocked, or nonexistent on the access control list. A “known” AP is considered authorized because that particular BSSID was entered into the list by the system administrator. A “selected” AP is blocked by the Wireless LAN System as an unauthorized AP. The Fortinet WLAN also reports other APs that are not on the access control list; these APs trigger alerts to the admin console until the AP is designated as known or selected in the access control list. For example, a third party BSS is detected as a rogue unless it is added to the access control list.

Fortinet APs also detect rogue APs by observing traffic either from the access point or from a wireless station associated to a rogue. This enables the system to discover a rogue AP when the rogue is out of range, but one or more of the wireless stations associated to it are within range.

Modifying Detection and Mitigation CLI Settings

The default settings that are configured for the rogue AP detection and mitigation features are adequate for most situations. However, many default settings can be changed if your network requires lighter or heavier scanning and/or mitigation services. The following is the list of rogue-ap commands:

controller (config)# rogue‐ap ?

acl                    Add a new rogue AP ACL entry. aging                  Sets the aging of alarms for rogue APs. assigned‐aps           Number of APs assigned for mitigation. blocked                Add a new rogue AP blocked entry. detection              Turn on rogue AP detection. min‐rssi               Sets RSSI Threshold for Mitigation. mitigation             Set the rogue AP mitigation parameters.

mitigation‐frames      Sets the maximum number of mitigation frames sent out per channel.

operational‐time       Sets the APs time on the home channel during scanning. scanning‐channels      Sets the global Rogue AP scanning channels. scanning‐time          Sets the APs per channel scanning time

As a general rule, unless the AP is in dedicated scanning mode, the more time that is spent scanning and mitigating, the less time is spent by the AP in normal WLAN operating services. Some rules determine how service is provided:

• The controller picks the APs that will scan and mitigate; those that mitigate are dependant on their proximity to the rogue AP and the number of mitigating APs that have been set.
• To preserve operational performance, APs will mitigate only the home channel if they have clients that are associated.
• Settings are administered globally; there is no way to set a particular AP to mitigate.
• Mitigation is performed only on clients associated to rogue APs; the rogue APs themselves are not mitigated. It is the network administrator’s responsibility to remove the rogue APs from the network.
• AP mitigation frames are prioritized below QoS frames, but above Best Effort frames.
• To reduce network traffic, you may configure the scanning channels list that contains only the home channels

Changing the Number of Mitigating APs with the CLI

By default, three Mitigating APs are selected by the controller to perform scanning and mitigation. This number can be set to a high of 20 APs or down to 1 AP, depending on the needs of your network. To change the number of mitigating APs to 5:

controller (config)# rogue-ap assigned-aps 5

Changing the Scanning and Mitigation Settings with the CLI

When rogue AP scanning is enabled, for any given period, the AP spends part of the time scanning channels, and part of the time performing normal AP WLAN operations on the home channel. This cycle of scan/operate repeats so quickly that both tasks are performed without noticeable network operation degradation.

If scanning is enabled, the rogue-ap operational-time command sets the number of milliseconds that are spent in operational time, performing normal wireless services, on the home channel. This command is related to the rogue-ap scanning-time command. The channels that are scanned are determined by the rogue-ap scanning channels command. The complete set of default channels are 1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165.

The following command changes the operational time from the default 400 to 2500 milliseconds: controller (config)# rogue-ap operational-time 2500

The following command changes the scanning time from the default 100 to 200 milliseconds: controller (config)# rogue-ap scanning-time 200

The following command sets the scanning channels to 1, 6, 11, 36, 44, 52, 60:

controller (config)# rogue-ap scanning-channels 1,6,11,36,44,52,60 controller (config)# exit

To verify the changes, use the show rogue-ap globals command:

controller# show rogue-ap globals

Global Settings

Detection                              : on

Mitigation                             : selected

Rogue AP Aging (seconds)               : 60

Number of Candidate APs                : 5

Number of Mitigating APs               :5

Scanning time in ms                    : 200

Operational time in ms                 : 2500

Max mitigation frames sent per channel : 10

Scanning Channels                      : 1,6,11,36,44,52,60

RSSI Threshold for Mitigation          : ‐100

Changing the Minimum RSSI with the CLI

RSSI is the threshold for which APs attempt to mitigate rogues; if the signal is very week (distant AP), APs won’t try to mitigate it.

The command to change the minimum RSSI (Received Signal Strength Indication) level, over which a station will be mitigated is rogue-ap min-rssi. A level range of 0 of -100 is supported, with -100 being the default setting.

The following command sets the minimum RSSI level to -80:

controller (config)# rogue-ap min-rssi -80 controller (config)#

TABLE 20: CLI Commands for Rogue Mitigation

Rogue Mitigation Example

Rogue AP mitigation for APs in the blocked list is enabled and confirmed as follows:

controller# configure terminal controller(config)# rogue‐ap detection controller(config)# rogue-ap mitigation selected controller(config)# exit controller# show rogue-ap globals

Global Settings

Detection                              : on

Mitigation                             : selected

Rogue AP Aging (seconds)               : 60

Number of Candidate APs                : 3

Number of Mitigating APs               : 5

Scanning time in ms                    : 100

Operational time in ms                 : 400

Max mitigation frames sent per channel : 10

Scanning Channels                      :

1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165 RSSI Threshold for Mitigation          : ‐100

Modify Rogue Detection and Mitigation Settings with the CLI

The default settings that are configured for the rogue AP detection and mitigation features are adequate for most situations. However, many default settings can be changed if your network requires lighter or heavier scanning and/or mitigation services. The following is the list of rogue-ap commands:

controller(config)# rogue‐ap ?

acl                    Add a new rogue AP ACL entry. aging                  Sets the aging of alarms for rogue APs. assigned‐aps           Number of APs assigned for mitigation. blocked                Add a new rogue AP blocked entry. detection              Turn on rogue AP detection.

min‐rssi               Sets RSSI Threshold for Mitigation. mitigation             Set the rogue AP mitigation parameters.

mitigation‐frames      Sets the maximum number of mitigation frames sent out per channel.

operational‐time       Sets the APs time on the home channel during scanning. scanning‐channels      Sets the global Rogue AP scanning channels. scanning‐time          Sets the APs per channel scanning time

As a general rule, unless the AP is in dedicated scanning mode, the more time that is spent scanning and mitigating, the less time is spent by the AP in normal WLAN operating services. Some rules determine how service is provided:

• The controller picks the APs that will scan and mitigate; those that mitigate are dependant on their proximity to the rogue AP and the number of mitigating APs that have been set. To preserve operational performance, APs will mitigate only the home channel if they have clients that are associated.
• Settings are administered globally; there is no way to set a particular AP to mitigate.
• Mitigation is performed only on clients associated to rogue APs; the rogue APs themselves are not mitigated. It is the network administrator’s responsibility to remove the rogue APs from the network.
• AP mitigation frames are prioritized below QoS frames, but above Best Effort frames.
• To reduce network traffic, you can configure the scanning channels list that contains only the home channels.

Changing the Number of Mitigating APs with the CLI

By default, three mitigating APs are selected by the controller to perform scanning and mitigation. This number can be set to a high of 20 APs or down to 1 AP, depending on the needs of your network, although we do not recommend assigning a high number of APs for mitigation because they can interfere with each other while mitigating the rogue. To change the number of mitigating APs to 5: controller(config)# rogue‐ap assigned‐aps 5

Changing the Scanning and Mitigation Settings with the CLI

When rogue AP scanning is enabled, for any given period, the AP spends part of the time scanning channels, and part of the time performing normal AP WLAN operations on the home channel. This cycle of scan/operate repeats so quickly that both tasks are performed without noticeable network operation degradation.

If scanning is enabled, the rogue-ap operational-time command sets the number of milliseconds that are spent in operational time, performing normal wireless services, on the home channel. This command is related to the rogue-ap scanning-time command. The channels that are scanned are determined by the rogue-ap scanning channels command. The complete set of default channels are 1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165.

The following command changes the operational time from the default 400 to 2500 milliseconds: controller(config)# rogue-ap operational-time 2500

The following command changes the scanning time from the default 100 to 200 milliseconds: controller(config)# rogue-ap scanning-time 200

The following command sets the scanning channels to 1, 6, 11, 36, 44, 52, 60:

controller(config)# rogue-ap scanning-channels 1,6,11,36,44,52,60 controller(config)# exit

To verify the changes, use the show rogue-ap globals command:

controller# show rogue-ap globals

Global Settings

Detection                              : on

Mitigation                             : selected

Rogue AP Aging (seconds)               : 60

Number of Candidate APs                : 5

Number of Mitigating APs               : 5

Scanning time in ms                    : 200

Operational time in ms                 : 2500

Max mitigation frames sent per channel : 10 Scanning Channels                      : 1,6,11,36,44,52,60

RSSI Threshold for Mitigation          : ‐100

Changing the Minimum RSSI with the CLI

RSSI is the threshold for which APs attempt to mitigate rogues; if the signal is very week (distant AP), APs won’t try to mitigate it.

The command to change the minimum RSSI (Received Signal Strength Indication) level, over which a station will be mitigated is rogue-ap min-rssi. A level range of 0 of -100 is supported, with -100 being the default setting.

The following command sets the minimum RSSI level to -80:

controller(config)# rogue-ap min-rssi -80 controller(config)#

Configure Rogue AP Mitigation with the Web UI

To prevent clients of unauthorized APs from accessing your network, enable the options for both scanning for the presence of rogue APs and mitigating the client traffic originating from them. These features are set globally, with the controller managing the lists of allowable and blocked WLAN BSSIDs and coordinating the set of APs (the Mitigating APs) that perform mitigation when a rogue AP is detected.

When rogue AP scanning (detection) is enabled, for any given period, the AP spends part of the time scanning channels (determined by the Scanning time in ms setting), and part of the time performing normal AP WLAN operations on the home channel (determined by the Operational time in ms setting). This cycle of scan/operate repeats so quickly that both tasks are performed without noticeable network operation degradation.

The channels that are scanned by a particular AP are determined by the model of AP. As a result of the channel scan, a list of rogue APs is compiled and sent by the controller to a number of Mitigating APs that are closest to the rogue AP. Mitigating APs send mitigation (deauth) frames to the rogue AP where clients are associated to remove those clients from the network. This presence of the rogue AP generates alarms that are noted on the Web UI monitoring dashboard and via syslog alarm messages so the administrator is aware of the situation and can then remove the offending AP or update the configuration list.

As well, if a rogue device seen on the wired interface of the AP and if the device is in the AP’s discovered list of stations a wired rogue notification will be sent via the Web UI monitoring dashboard and syslog alarm message. If the rogue client is associated with the AP, that client is also classified as a rogue.

Alter the List of Allowed APs with the Web UI

To change the list of allowed APs, follow these steps:

1. From the Web UI, click Configure > Security > Rogue AP > Global settings. The Allowed APs screen appears. See Figure .

Figure 63: Web UI List of Allowed APs

2. To add a BSSID to the list, click Add.

• In the BSSID boxes, type the BSSID, in hexadecimal format, of the permitted access point. • To add the BSSID to the ACL, click OK.

3. To delete a BSSID from the list, select the BSSID, click Delete, then OK.

Alter the List of Blocked APs with the Web UI

To change the list of allowed APs, follow these steps:

1. From the Web UI click Configure > Security > Rogue AP > Blocked APs. The table shows information about access points listed as blocked BSSIDs in the access control list (ACL).
2. To see an updated list of the APs blocked in the WLAN, click Refresh.
3. To add an AP to the blocked list, click Add.
   • In the BSSID box, type the BSSID, in hexadecimal format, of the access point. Add the BSSID to the ACL, by clicking OK.
4. The blocked BSSID now appears on the list with the following information:
   • BSSID The access point’s BSSID.
   • Creation Time The timestamp of when the blocked AP entry was created.
   • Last Reported Time The time the AP was last discovered. If this field is blank, the AP has not been discovered yet.
5. To remove a blocked BSSID from the ACL, select the checkbox of the blocked AP entry you want to delete, click Delete, and then click OK.

Configure Scanning and Mitigation Settings with the Web UI

To configure rogue AP scanning and mitigation settings, follow these steps:

1. From the Web UI click Configuration > Wireless IDS/IPS > Rogue APs.

The Rogue AP screen appears with the Global Settings tab selected. See Figure 62.

Figure 64: Web UI Rogue AP Global Settings

2. In the Detection list, select one of the following:
   • On: Enables scanning for rogue APs.
   • Off: Disables rogue detection.
3. In the Mitigation list, select one of the following:

• No mitigation: No rogue AP mitigation is performed.
• Block all BSSIDs that are not in the ACL: Enables rogue AP mitigation of all detected BSSIDs that are not specified as authorized in the Allowed APs list.
• Block only BSSIDs in blocked list: Enables rogue AP mitigation only for the BSSIDs that are listed in the Blocked APs list.
• Block Clients seen on the wire: Enables rogue mitigation for any rogue station detected on the wired side of the AP (the corporate network, in many cases). When Block clients seen on the wire is selected, clients seen on the corporate network are mitigated. When Block clients seen on the wire is selected and the BSSID of the wired rogue client is entered in the blocked list (see “Alter the List of Blocked APs with the Web UI” on page 310) only listed clients are mitigated.

4. In the Rogue AP Aging box, type the amount of time that passes before the rogue AP alarm is cleared if the controller no longer detects the rogue. The value can be from 60 through 86,400 seconds.
5. In the Number of Mitigating APs text box, enter the number of APs (from 1 to 20) that will perform scanning and mitigation of rogue APs.
6. In the Scanning time in ms text box, enter the amount of time Mitigating APs will scan the scanning channels for rogue APs. This can be from 100 to 500 milliseconds.
7. In the Operational time in ms text box, enter the amount of time Mitigating APs will spend in operational mode on the home channel. This can be from 100 to 5000 milliseconds.
8. In the Max mitigation frames sent per channel text box, enter the maximum number of mitigation frames that will be sent to the detected rogue AP. This can be from 1 to 50 deauth frames.
9. In the Scanning Channels text box, enter the list of channels that will be scanned for rogue APs. Use a comma separated list from 0 to 256 characters. The complete set of default channels are

1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165.

10.In the RSSI Threshold for Mitigation text box, enter the minimum threshold level over which stations are mitigated. The range of valid values is from to -100 to 0.

11.Click OK.

If a station that is already present in the discovered station database (learned wirelessly by the AP) is also discovered via DHCP broadcast on the APs wired interface, it implies that the station is connected to the same physical wired network as the AP. Such a station could potentially be a rogue device and is flagged by the controller as a wired rogue, indicating the rogue was identified as being present on the same wired network as the AP. If mitigation is enabled for wired rogue, mitigation action is performed accordingly on the rogue device.

Configuring VLANs

A virtual local area network (VLAN) is a broadcast domain that can span across wired or wireless LAN segments. Each VLAN is a separate logical network. Several VLANs can coexist within any given network, logically segmenting traffic by organization or function. In this way, all systems used by a given organization can be interconnected independent of physical location. This has the benefit of limiting the broadcast domain and increasing security. VLANs can be configured in software, which enhances their flexibility. VLANs operate at the data link layer (OSI Layer 2), however, they are often configured to map directly to an IP network, or subnet, at the network layer (OSI Layer 3). You can create up to 512 VLANs.

IEEE 802.1Q is the predominant protocol used to tag traffic with VLAN identifiers. VLAN1 is called the default or native VLAN. It cannot be deleted, and all traffic on it is untagged. A trunk port is a network connection that aggregates multiple VLANs or tags, and is typically used between two switches or between a switch and a router. VLAN membership can be portbased, MAC-based, protocol-based, or authentication-based when used in conjunction with the 802.1x protocol. Used in conjunction with multiple ESSIDs, VLANs support multiple wireless networks on a single Access Point using either a one-to-one mapping of ESSID to VLAN, or mapping multiple ESSIDs to one VLAN. By assigning a security profile to a VLAN, the security requirements can be fine-tuned based on the use of the VLAN, providing wire-like security or better on a wireless network.

VLAN assignment is done for RADIUS-based MAC filtering and authentication. VLAN assignment is not done in Captive Portal Authentication by any of the returned attributes. Because VLANs rely on a remote switch that must be configured to support trunking, also refer to the Fortinet Wi-Fi Technology Note WF107, “VLAN Configuration and Deployment.” This document contains the recommended configuration for switches as well as a comprehensive description of VLAN configuration and deployment.

Configure and Deploy a VLAN

VLANs can be configured/owned either by E(z)RF Network Manager or by a controller. You can tell where a profile was configured by checking the read-only field Owner; the Owner is either nms-server or controller.

In order to map an ESSID to a VLAN, the VLAN must first be configured. To create a VLAN from the CLI, use the command vlan name tag id. The name can be up to 16 alphanumeric characters long and the tag id between 1 and 4,094.

For example, to create a VLAN named guest with a tag number of 1, enter the following in global configuration mode:

controller (config)# vlan guest tag 1 controller (config‐vlan)#

As shown by the change in the prompt above, you have entered VLAN configuration mode, where you can assign the VLAN interface IP address, default gateway, DHCP Pass-through or optional DHCP server (if specified, this DHCP server overrides the controller DHCP server configuration).

In the following example, the following parameters are set:

• VLAN interface IP address: 10.1.1.2 with a subnet mask of 255.255.255.0
• Default gateway: 10.1.1.1
• DHCP server: 10.1.1.254

controller (config‐vlan)# ip address 10.1.1.2 255.255.255.0 controller (config‐vlan)# ip default-gateway 10.1.1.1 controller (config‐vlan)# ip dhcp-server 10.1.1.254 controller (config‐vlan)# exit controller (config)#

To create a VLAN from the GUI, click Config > Wired > VLAN > Add.

Bridged APs in a VLAN

When creating an ESS, AP400/AP822/AP832, FAP-U421EV, FAP-U423EV and AP1000 can be configured to bridge the traffic to the Ethernet interface. This is called bridged VLAN dataplane mode (per ESSID); it is also sometimes known as Remote AP mode. These two AP models also have the capability to tag the Ethernet frames when egressing the port, using 802.1Q VLAN tags, and setting the 802.1p priority bit. Bridging is configured setting the Dataplane Mode parameter in the ESS profile to Bridged (default is Tunneled).

Configure and Deploy a VLAN

In Tunneled mode, all traffic in an ESS is sent from the AP to the controller, and then forwarded from there. This is configured on a per ESS profile basis. In Bridged mode, client traffic is sent out to the local switch. Fortinet control and coordination traffic is still sent between the AP and the controller.

Remote AP400s can use VLANs with FortiWLC (SD) 4.0 and later. When configuring an ESS, the Dataplane Mode setting selects the type of AP/Controller configuration:

Bridged VLANs support:

• Non-Virtual Cell
• Virtual Port
• RADIUS profile for Mac Filtering/1x/WPA/WPA2
• Standard DSCP/802.1q to AC mapping defined in WMM
• RADIUS profile for Mac Filtering/1x/WPA/WPA2
• RADIUS assigned VLANs (even with 802.1x)
• QoS Rules

See the ESSID chapters in this guide for more information on configuring an ESSID.

VLAN Tagging in Bridge Mode for Wired Ports

You can enable VLAN tagging for wired ports in bridged mode. VLAN tagging for wired ports provide four VLAN policies:

• No VLAN
• Static VLAN: VLAN tag shall be configured for a valid range of 0-4094.

Configuring VLAN Tagging

Using CLI

In the port profile configuration, use the following commands to specify the policy and the VLAN tag.

• default (config-port-profile)# port-ap-vlan-policy
• default(config-port-profile)# port-ap-vlan-tag

VLAN Tagging in Bridge Mode for Wired Ports

Dynamic VLAN support in Bridge mode

Stations can receive IP dynamically when the AP is in tunneled and bridged mode with the RADIUS server dynamically assigning the VLAN’s.

Delete a VLAN

You cannot delete a VLAN if it is currently assigned to an ESSID (see Chapter , “” on page 137). You cannot delete a VLAN created by E(z)RF Network Server; that must be done from Network Server. To delete a VLAN created on a controller, use the following command in global configuration mode:

no vlan name

For example, to delete the VLAN name vlan1, enter the following:

controller (config)# no vlan vlan1 controller (config)#

More About VLANs

FortiWLC (SD) provides commands for configuring both virtual LAN (VLANs) and Generic Routing Encapsulation (GRE) tunnels to facilitate the separation of traffic using logical rather than physical constraints. As an alternative to VLANs, GRE Tunneling can be configured on the either Ethernet interface, as described in Configure GRE Tunnels in the Security chapter. VLANs and GRE tunnels can coexist within any given network, logically segmenting traffic by organization or function. In this way, all systems used by a given organization can be interconnected, independent of physical location. This has the benefit of limiting the broadcast domain and increasing security.

VLANs, when used in conjunction with multiple ESSIDs, as discussed in Chapter , “,” allow you to support multiple wireless networks on a single access point. You can create a one-toone mapping of ESSID to VLAN or map multiple ESSIDs to one VLAN.

Customized security configuration by VLAN is also supported. By assigning a VLAN a Security Profile, you can fine-tune the security requirements based on the use of the VLAN (see Chapter , “,” for details).

Dynamic VLAN support in Bridge mode

VLAN Pooling

To reduce big broadcast or risking a chance of running out of address space, you can now enable VLAN pooling in an ESS profile.

VLAN pooling essentially allows administrators to create a named alias using a subset of VLANs thereby creating a pool of address. By enabling VLAN pool, you can now associate a client/device to a specific VLAN. This allows you to effectively manage your network by monitoring appropriate or specific VLANs pools.

Features

• You can associate up to 16 VLANs to a pool.
• You can create a maximum of 64 VLAN Pools.
• You can specify the maximum number of clients that can be associated to a VLAN.
• The client/device behaviour does not change after it is associates to a VLAN in a pool. If a VLAN is removed from a VLAN pool, clients/devices connected to the VLAN will continue to be associated to the VLAN. However, if the clients disconnect and reconnect the VLAN will change.

VLAN Pooling

Configuration

Using WebUI

Using CLI

1. Configure VLAN default(config)# vlan vlan10 tag 10 default(config‐vlan)# ip address 10.0.0.222 255.255.255.0 default(config‐vlan)# ip default‐gateway 10.0.0.1

VLAN Pooling

default(config‐vlan)# exit default(config)# exit default# sh vlan vlan10

VLAN Configuration

VLAN Name                             : vlan10

Tag                                   : 10

Ethernet Interface Index              : 1 IP Address                            : 10.0.0.222 Netmask                               : 255.255.255.0

IP Address of the Default Gateway     : 10.0.0.1

Override Default DHCP Server Flag     : off DHCP Server IP Address                : 0.0.0.0

DHCP Relay Pass‐Through               : on

Owner                                 : controller

Maximum number of clients             : 253 2. Configure VLAN Pool default(config)# vlan‐pool vlangroup default(config‐vpool)# tag‐list 10,36 default(config‐vpool)# exit default(config)# exit default# sh vlan‐pool

VLAN Pool Name           Vlan Pool Tag List vlangroup                10,36

VLAN Pool Configuration(1 entry)

Support for CAPWAP

FortiWLC supports Control and Provisioning of Wireless Access Points (CAPWAP) protocol to allow Fortinet access points to discover Fortinet WLAN controllers. In addition to controller discovery, APs can send keep-alive packets to controllers via CAPWAP.

This is a partial implementation of the CAPWAP protocol that is limited to controller discovery, keepalive packets (echo request and response), AP image upgrade, and tunnelled client data packets between AP and controller.

Legacy Discovery Process

There are three types of access point discovery:

• Layer 2 only-Access point is in the same subnet as controller.
• Layer 2 preferred-Access point sends broadcasts to find the controller by trying Layer 2 discovery first. If the access point gets no response, it tries Layer 3 discovery.
• Layer 3 preferred-Access point sends discovery message to the controller by trying Layer 3 discovery first. If the access point gets no response, it tries Layer 2 discovery.
• Layer 3 only-Access point sends discovery message to the controller by trying Layer 3 only.

For Layer 2 and Layer 3 discovery, the access point cycles between Layer 2, Layer 3, and Mesh (if mesh is enabled) until it finds the controller.

An access point obtains its own IP address from DHCP (the default method), or you can assign a static IP address. After the access point has an IP address, it must find a controller’s IP address. By default, when using Layer 3 discovery, the access point obtains the controller’s IP address by using DNS and querying for hostname. The default hostname is “wlan-controller.” This presumes the DNS server knows the domain name where the controller is located. The domain name can be entered via the AP configuration or it can be obtained from the DHCP server, but without it, an Layer 3-configured AP will fail to find a controller. Alternately, you can configure the AP to point to the controller’s IP directly (if the controller has a static IP configuration).

After the access point obtains the controller IP address, it sends discovery messages using UDP port 9393. After the controller acknowledges the messages, a link is formed between the AP and the controller.

Discovery sequence for OAP832 and OAP433

Even if OAP832 and OAP433 are configured in the L3-only mode, the access points will be use L3 preferred mode to find controller. If the L3-preferred mode fails, they will fall back to L2 mode.

Legacy Discovery Process

CAPWAP and Legacy Reference

Port Requirements

Controller and AP Communication Ports

CAPWAP Discovery

The CAPWAP protocol requires the UDP ports 5246 and 5247 to exchange control and data packets respectively

Legacy Discovery Process

Discovery Sequence

The CAPWAP discovery supports the following sequence on port UDP 5246:

1. Unicast Options Controller IP address: AP sends discovery request to a controller based on the configured IP address in the AP.
   • DHCP Option 138: AP sends discover request to the controller configured with DHCP option 138. Alternatively, option 43 is also available for discovering controller.
   • DNS: AP sends discovery request based on the DNS resolution of – _capwap-control._udp.example.com
2. Multicast: AP sends discovery request via multicast address – 224.0.1.140
3. Broadcast: AP sends discovery request via broadcast address on – 255.255.255

Discovery Process

1. In L3 discovery mode, the AP sends discovery request on both port 5246 and port 9292 to the controller.
2. If the controller is already upgraded to 8.3 release, it sends response on port 5246 to complete the AP association.
3. Further the keep-alive and image upgrade message exchange happens on port 5246.
4. Tunnelled client data are sent to controller on port 5247.

Upgrading from Pre-8.3 Release

Using the upgrade controller command with auto‐ap‐upgrade ON

1. The controller is upgraded to 8.3 and will now listen on port 5246 and 9292 for discovery request from access points. During the controller upgrade process, the pre-8.3 access points will continue re-discovery of the controller using the legacy method.

• Once the controller is upgraded, the pre-8.3 APs will associate with the controller using the legacy method.

2. Now, the access points begin the upgrade process. After the upgrade is complete, the access points will send discovery request on port 5246 and port 9292. The controller that is already upgraded to 8.3 will respond on port 5246 to complete AP association.

Legacy Discovery Process

Using the upgrade system command

1. The APs are upgraded first to the 8.3 release. After upgrade the APs will send discovery request using a method sequence as mentioned in the Discovery Sequence section.
2. The controller is upgraded to 8.3 after the APs are upgraded. The 8.3 controller will respond to AP discovery request.

Post Upgrade

Ensure that UDP 5000 is open after the upgrade is complete.

Downgrading

When downgraded to a previous release, the discovery mechanism will switch back to the legacy discovery process. However, we recommend that you open the CAPWAP UDP ports, Kcom (L3) UDP ports, and Ethertypes.

Add and Configure an AP with the Web UI

When you add an AP to a controller, you configure these features:

• AP ID
• AP Name
• Serial Number
• Location, Building, Floor
• Contact
• LED Mode
• Boot script (AP Init Script)
• Dataplane Encryption
• AP Role
• Parent AP ID
• Link Probing Duration
• Power Supply Type
• AP Indoor/Outdoor Type

Meru Access Points can be connected to the controller through a Layer 2 network or a Layer 3 network. To both add and configure an AP, follow these steps:

1. Click Configuration > Devices > APs > Add.

The AP Table Add window displays.

Add and Configure an AP with the Web UI

Figure 65: Add an AP to the Network

2. Provide the following values and then click OK.

Add and Configure an AP with the Web UI

Add and Configure an AP with the Web UI

Configure an AP’s Radios with the Web UI

After you “Add and Configure an AP with the Web UI” on page 337, the AP’s radios will be listed in FortiWLC (SD). Follow these steps to configure the radios:

1. Click Configuration > Wireless > Radio.
2. Select one of the radios by clicking the pencil icon in the first column; remember that most APs have two radios. In that case, you will want to configure both of them.
3. There are three tabs of settings for a radio, Wireless Interface, Wireless Statistics, and Antenna Property. Wireless Interface is the default tab. Here you see the existing interface settings for the radio. Any setting that is greyed out cannot be changed. Make any of the changes listed in the following chart, and then click OK.

Configure an AP’s Radios with the Web UI

Configure an AP’s Radios with the Web UI

AP1000 radios always have Virtual Cell enabled, but there is a way to use AP1000 in non-Virtual Cell mode. See Adding an ESS with the CLI.

The FAP U42xEV and FAP U32xEV Access Points can support up to 256 clients per radio interface. The 256 client support per radio is only for a native cell environment. In a virtual cell environment, the maximum clients supported per interface are 170.

Configure an AP’s Radios with the Web UI

Add and Configure an AP with the CLI

To configure an AP with the CLI, first enter AP configuration mode (first command shown below) and then use the rest of the AP configuration commands:

Add and Configure an AP with the CLI

Configure a Layer 3 AP with the CLI

The following commands can be used to set up a Layer 3 configuration for an AP not in the same subnet as the controller. It specifies the AP will obtain its IP address from DHCP, which allows it to use a DNS server for obtaining its IP address. If the network administrator has added to the DNS server the IP address for the controller hostname “wlan-controller,” DNS can return the IP address of the controller with the hostname “wlan-controller:”

default# configure terminal default(config)# ap 1

default(config‐ap)# connectivity l3‐preferred default(config‐ap‐connectivity)# ip address dhcp

default(config‐ap‐connectivity)# controller hostname wlan‐controller default(config‐ap‐connectivity)# end default#

The following table presents the commands available within the ap-connectivity mode. TABLE 21: Summary of Connectivity Mode Commands

Add and Configure an AP with the CLI

TABLE 21: Summary of Connectivity Mode Commands

Configure AP Power Supply, Channel Width, and MIMO Mode with CLI

Set the power supply type, channel width, and MIMO mode by following these steps:

1. Open a terminal session on the controller.
2. Enter configuration mode by with the command terminal configuration at the CLI prompt.
3. Select the AP with the command ap #, for example, AP1: default(config)# ap 1
4. Set the power supply value to 5V-DC for AP Power, 802.3af Power Over Ethernet, 802.3at Power Over Ethernet with the CLI command power-supply. default(config‐ap)# power‐supply 5V‐DC
5. Exit ap configuration mode. default(config‐ap) # exit
6. Enter radio configuration submode with the command interface Dot11Radio node-id interface_ID. For example, for AP1, interface 1: default(config)# interface Dot11Radio 1 1
7. Change channel width from 20 MHz (default) to 40 MHz (either 40-mhz-extension-channel-above or 0-mhz-extension-channel-below 40) with the command channel-width. This command also sets channel bonding. default(config‐if‐802)# channel‐width above 40 MHz Extension channel
8. Change MIMO Mode from 2×2 (default) to 3×3 with the mimo-mode 3×3 command and exit.

default(config‐if‐802)# mimo‐mode 3×3 default(config‐if‐802)# end

Add and Configure an AP with the CLI

The AP is now configured.

Configure an AP’s Radios with the CLI

Before you can configure any radio settings, you need to enter radio interface configuration mode. To do this, follow these steps:

TABLE 22: Entering Radio Interface Configuration Mode

Summary of Radio Interface Configuration Commands

The following is a summary of the commands available in radio interface configuration mode: TABLE 23: Commands available in Radio Interface Configuration Mode

Configure an AP’s Radios with the CLI

TABLE 23: Commands available in Radio Interface Configuration Mode

Set Radio Transmit Power with the CLI

The radio transmit power changes the AP’s coverage area; this setting helps manage contention between neighboring access points. Transmit power for Fortinet APs is defined as the EIRP1 (Effective Isotropic Radiated Power) at the antenna and includes the antenna gain.

(This is important to remember; transmit power is not the power at the connector.) Power level settings are dependent on the country code and the radio band (and for 802.11a, the channel) in use.

For example, if the transmit power, configured with the command localpower, is set to 20 dBm2, and the antenna gain is set 3 to 2 dBm, then the actual transmitted power at the connector is 18 dBm.

If an external antenna with an 8dBi (isotropic) gain is used, then adjust the gain value to the same value, 8. If the desired EIRP after the antenna is the same, then keep the transmit power set to the same value, 20. For higher or lower EIRP values, adjust the transmit power to the desired value.

The maximum power setting is an integer between 4-30dBm for 802.11/bg radios.

The Maximum Transmit Power for the 802.11a band is based on the channel in use, as detailed in the following table, which shows the levels for the United States:

Configure an AP’s Radios with the CLI

Use the localpower command in the Dot11Radio interface configuration mode to configure the maximum power level. localpower max‐level

For example, to set the 802.11a radio maximum power to 15, type

localpower 15

Enable and Disable Short Preambles with the CLI

The radio preamble, also called the header, is a section of data at the head of a packet that contains information that the access point and client devices need when sending and receiving packets. By default, a short preamble is configured, but you can set the radio preamble to long or short:

• A short preamble improves throughput performance.
• A long preamble ensures compatibility between the access point and some older wireless LAN cards. If you do not have any older wireless LAN cards, you should use short preambles.

To disable short preambles and use long preambles, type: no preamble-short

To enable short preambles, type: preamble-short

Configure an AP’s Radios with the CLI

Set a Radio to Scan for Rogue APs with the CLI

To configure radios to constantly scan for rogue APs, use this command from the Dot11Radio interface configuration mode: mode scanning

To set the radio back to servicing clients, use the command: mode normal

Enable or Disable a Radio Interface with the CLI

To temporarily disable a radio interface, use this command from Dot11Radio interface configuration mode: admin‐mode Down

To later enable the off-line interface, use the command: admin‐mode Up

Set a Radio to Support 802.11n Only with the CLI

To set an AP radio interface to support only 802.11n clients, and thus improve throughput, from the Dot11Radio interface configuration mode use the command: n‐only‐mode

To disable the 802.11n-only support, use the command: no n‐only‐mode

Note that All APs on the same channel in a Virtual Cell must have the same setting for n-only mode.