Policy Enforcement Module

The optional Policy Enforcement Module feature makes it possible to control network content by dropping/allowing traffic based on configured policies applied on a firewall tag associated with a user group. This includes Captive Portal users in release 3.7 and later.

Policy Enforcement Module

Fortinet’s firewall is generic, and can be used to prevent any subnet to subnet communication, for specific ports or all ports. With the Filter ID, we can also prevent any user from any SSID from accessing specific subnets.

The per-user firewall filtering is implemented either by:

• A RADIUS-returned filter-id attribute, that is created on the RADIUS server and assigned to users
• A configured firewall filter-id parameter that is part of the Security profile configuration and is applied to clients associated with an ESS

For the RADIUS-based per-user firewall, the returned filter-id attribute is part of AccessAccept message returned for a user, and is used as the firewall tag. The filtering action is determined by the configured firewall polices for this firewall tag.

In the absence of a RADIUS configuration, a configured firewall tag in the Security profile can be used for defining the filtering based on the configured firewall polices. In this case, all users connecting to a given ESS profile are allocated the same firewall tag as configured for the profile.

For successful operation using a RADIUS configuration, the Filter-id attribute that is configured on the RADIUS Server must match that used on the controller. In some RADIUS Servers, a Filter ID must be created.

The policies that filter the traffic are created using the standard QoS qosrule configuration, and the inherent priorities and configuration parameters are described in detail in Chapter 15 of this manual as well as in the qosrule entry in the FortiWLC (SD) Command Reference.

Configure Firewall Policies with the CLI

Begin the Policy Enforcement Module configuration by configuring a set of qosrule policies to manage the traffic.

The following example shows the creation of qosrule 200 as a policy for Firewall filter-id 1:

default# configure terminal default(config)# qosrule 200 netprotocol 6 qosprotocol none default(config)# netprotocol‐match default(config‐qosrule)# dstport 80 default(config‐qosrule)# dstport‐match on default(config‐qosrule)# action drop default(config‐qosrule)# firewall‐filter‐id 1 default(config‐qosrule)# firewall‐filter‐id‐match on default(config‐qosrule)# qosrule‐logging on default(config‐qosrule)# qosrule‐logging‐frequency 30

Policy Enforcement Module

default(config‐qosrule)# exit default(config)# exit

To check the configuration of the policy, use the show qosrule command:

default# show qosrule

ID    Dst IP          Dst Mask        DPort Src IP          Src Mask        SPort Prot QoS   Action   Drop  Firewall Filter

• 0.0.0 0.0.0.0         1720  0.0.0.0         0.0.0.0         0     6    h323  capture  head       
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         1720  6    h323  capture  head                 
• 0.0.0 0.0.0.0         5060  0.0.0.0         0.0.0.0         0     17   sip   capture  head                 
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         5060  17   sip   capture  head                 
• 0.0.0 0.0.0.0         5200  0.0.0.0         0.0.0.0         0     17   none  forward  head                 
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         5200  17   none  forward  head                 

200   0.0.0.0         0.0.0.0         80    0.0.0.0         0.0.0.0         0     6    none  drop     tail  1              

        QoS Rules(7 entries) default#

The following commands are required to apply the example filter ID 1 to the Security Profile.

default(config‐security)# firewall‐capability configured default(config‐security)# firewall‐filter‐id  1 default(config‐security)# security‐logging off

Once you create a firewall rule, you cannot modify the rule to enable or disable firewall logging. As a workaround, either create the firewall rule with the required option or delete the rule and re-apply it with the required option.

Troubleshooting Per-User Firewall

• Turn on the QoS rule logging feature available in QoS rule page. If the client traffic hits the rule, the same will be displayed in the syslog server or via the CLI command show syslogfile firewall.

Policy Enforcement Module

For command details, see the FortiWLC (SD) Configuration Guide.

RSA SecurID Authentication

RSA SecurID is two-factor authentication mechanism. This authentication mechanism primarily involves three components: • RSA SecurID Authenticator token (hardware based or software based) that generates a unique authentication code

• RSA SecurID Server (Authentication Manager)
• RSA Authentication Agent

RSA SecurID Authenticator Token and Code

Each RSA SecurID token includes a factory-encoded, unique ‘seed.’ The token uses this unique seed to generate an authentication code at fixed intervals (for example 60 seconds). By utilizing the built-in-clock time and the unique seed, the authentication code keeps changing at fixed intervals. Since the token’s clock and the server’s clock are synchronized. the server generates authentication codes at the same fixed intervals as the token. Possession of the resulting code is then combined with knowledge of a PIN number to produce secure authentication.

RSA SecurID Server

Users are authenticated against the RSA SecurID Server with the username and the passcode, which is the combination of the authentication code generated/displayed by the token and the PIN (see above).

The first time a user uses the token, they are asked to choose a new PIN. The server also requests a new time-synchronous PIN regularly or whenever the timing between a token and a server ‘drifts.’ If the drift is more than 3 minutes, then the Server requests the user to enter the next authentication code generated by the token in the next interval to verify the possession of the token. If the next authentication mode has the same clock drift, then token is assumed valid by the Server.

RSA SecurID Agent

This authentication is similar to the standard username-passcode authentication, but the passcode is not a single word. It is a numeric combination of the authentication code in the token and the PIN known to the user.

The RSA SecurID can be achieved two ways:

• EAP-RSA based authentication – implemented currently
• Native SecurID Authentication – not in use at this time

RSA SecurID Authentication

Configure RSA SecurID

Communication between an RSA server and a controller is the same as communication between a controller and any other RADIUS server (IAS or Free RADIUS). The only difference is in the way the client authenticates to the RSA Server, by means of two factor authentication in which Fortinet does not interfere. Configure an RSA server on a controller using the CLI command radius-profile. For example:

default# configure terminal default(config)# radius‐profile <RSA>

default(config‐radius)# ip‐address <IP of the RSA server> default(config‐radius)# key secure‐secret default(config‐radius)# exit

Configure MAC Filtering

MAC filtering controls a user station’s access to the WLAN by permitting or denying access based on specific MAC addresses. A MAC address is unique to each IEEE 802-compliant networking device. In 802.11 wireless networks, network access can be controlled by permitting or denying a specific station MAC address, assigned to its wireless NIC card, from attempting to access the WLAN.

The Wireless LAN System provides MAC filtering using the following methods:

• Locally on the Controller, through the administration of an Access Control List (ACL) that permits or denies access for specific stations based on their unique MAC addresses. Two ACLs are available for MAC filtering:
• Permit ACL, which limits access to only those MAC addresses on the permit list
• Deny ACL, which specifically disallows access to those addresses (clients) on the deny

list

The following flowcharts illustrate how MAC filtering works:

MAC Filtering Behaviour

If ACL environment is Deny list

If ACL environment is Permit

If ACL environment is Disabled

Changes made to the local access/deny ACL are implemented in real time.

• Remotely, in conjunction with the RADIUS Server, which is configured to authorize access to a set of MAC addresses. The user authentication follows the procedure shown in RADIUS Authentication, but a MAC address is used for user validation.

If the Controller Deny ACL is enabled, those addresses on the Deny list overrule MAC addresses on the RADIUS Server. Changes made to the MAC addresses on the RADIUS Server are not implemented in real time.

• Per ESS, which allows MAC filtering to be enabled or disabled in the associated Security Profile, overriding the MAC filtering setting on the controller, or on the RADIUS server.

The state that is set for the MAC filtering option determines the type of access control in use, with the precedence in the order of ESS Security Profile setting, local MAC filtering list, and then the RADIUS Server state:

• For Controller ACL administration, the valid states are: disabled: (default) both the permit and deny ACLs are inactive, even if they contain MAC addresses
• permit: permit ACL is enabled and deny ACL (if it exists) is disabled
• deny: deny ACL is enabled and permit ACL (if it exists) is disabled
• For remote RADIUS Server administration, the valid states are:
• enabled
• disabled

The following table summarizes the controller/RADIUS Server settings.

Configure MAC Filtering

MAC filtering can be set up for both the controller and the RADIUS Server. By default, MAC filtering is disabled. Enable MAC filtering before adding MAC addresses. MAC filtering provides the following features:

• Enforced per security profile.
• Simultaneously use permit and deny list.
• Specify the same MAC address in both permit and deny list.
• Ability to simultaneously use global permit and deny list along with RADIUS based MAC-filtering per ESS level.

To change the state of MAC filtering so that the permit list is enabled, use the mac‐filterstate permit command

Add addresses to a permit ACL list by specifying them as command arguments, or by importing them from a prepared list. To add one or more MAC addresses to the permit access control list along with a brief description, type the following:

controller(config)# access‐list permit 00:40:96:51:eb:2b 00:40:96:51:eb:22 controller(config‐acl‐permit)# descr MyClient controller(config‐acl‐permit)# end

To import a list of MAC addresses to permit, create a text file listing all the MAC addresses, and import the text file. When creating the text file to be imported, only include one MAC address, in hexadecimal format (xx:xx:xx:xx:xx:xx), per line. For example, the contents of a text file to be imported might look like the following:

00:04:23:87:89:71

00:06:25:a7:e9:11

00:07:e9:15:69:40

00:0c:30:be:f8:19 00:0c:e6:09:46:64

00:0c:e6:12:07:41

After creating the text file, transfer the file to the controller’s /images directory. Use the CLI copy command to transfer the file to the controller. Check that the file has been copied using the dir command. The following example shows the command to import a text file named acl that adds the MAC addresses to the permit ACL list: controller(config)# access-list permit import acl

00:04:23:87:89:71

00:06:25:a7:e9:11

00:07:e9:15:69:40

00:0c:30:be:f8:19 00:0c:e6:09:46:64

00:0c:e6:12:07:41

00:0c:e6:bd:01:05

Successfully Added : 7

Duplicate Entries  : 0 Invalid Format     : 0

Entries Processed  : 7

Configure a Deny MAC Filtering List

To set up a Deny MAC Filtering List, enable the ACL deny state and then either configure a Deny ACL or import a Deny ACL.

A Deny ACL takes precedence over RADIUS Server access, so you can use it to immediately deny access to a station or black-list certain clients (for example, if they have a virus or are attacking other devices).

By default, MAC filtering is disabled. To change the state of MAC filtering so that the deny list is enabled, use the mac‐filter‐state deny command.

Add client addresses to a deny ACL list by either specifying them as command arguments, or by importing them from a prepared list. This command specifies them as command arguments and enters a brief description:

controller(config)# access‐list deny 00:40:96:51:eb:2b 00:40:96:51:eb:10 controller(config‐acl‐deny)# descr DenyStation controller(config‐acl‐deny)# end controller(config)#

To import a list of MAC addresses to deny, create a text file listing all the MAC addresses, and import the text file. When creating the text file to be imported, only include one MAC address, in hexadecimal format (xx:xx:xx:xx:xx:xx), per line. For example, the contents of a text file to be imported might look like the following:

00:04:23:87:89:71

00:06:25:a7:e9:11

00:07:e9:15:69:40

00:0c:30:be:f8:19

00:0c:e6:09:46:64

00:0c:e6:12:07:41

After creating a text file for import, transfer the file to the controller’s /images directory using the CLI copy command. Ensure that the file has been copied using the dir command. Then, import the file.

The following example imports a text file named denyacl that adds the MAC addresses to the deny ACL list:

controller(config)# access-list deny import denyacl

00:04:23:87:89:71

00:06:25:a7:e9:11

00:07:e9:15:69:40

00:0c:30:be:f8:19

00:0c:e6:09:46:64

00:0c:e6:12:07:41

Successfully Added : 6

Duplicate Entries  : 0 Invalid Format     : 0

Entries Processed  : 6

Active connections do not get disconnected if the ACL environment is changed from Permit to Deny.

However, during successive connection the MAC entry is filtered against deny or permit list.

Configure a Remote RADIUS Server for MAC Filtering

When RADIUS Server MAC filtering is enabled, station MAC addresses are set up and managed by a remote RADIUS Server. When a new station attempts to join the WLAN, the Controller queries the RADIUS server with the MAC address to determine whether the client is

permitted. If the RADIUS server does not respond, or responds that the client is not authorized, the client is blocked from entering the WLAN.

RADIUS Server configuration with the CLI is performed using the mac‐filter‐radius‐server   command in the security profile where you specify the configuration profile for the primary (and optional secondary) RADIUS Server (includes IP address, secret key, port, and the delimiter used between MAC addresses in its authorization table).

This radius server is used only in one of the following conditions:

• If ACL environment is set to deny list and the MAC entry is not in the deny list then the packet is forward to the radius server.
• If ACL environment is set to permit list and the MAC entry is not in the permit list then the packet is forwarded to the radius server.

For more information on configuring a RADIUS profile, see “Configure 802.1X RADIUS Security With the CLI” on page 226.

Configure an Security Profile for MAC Filtering

Control is provided per security profile via settings to turn off or on MAC Filtering settings. For example, if controller-based MAC filtering or if RADIUS Server MAC Filtering is enabled, the command no macfiltering disables those settings for the ESS. To enable global MAC filtering again, use the macfiltering command.

Security Certificates

Certificates provide security assurance validated by a Certificate Authority (CA). This chapter describes the process to obtain and use certificates. For a Custom Certificate to work properly, you must import not only the Server Certificate, but the entire chain of trust starting with the issuer certificate all the way up to the Root CA (see Figure 46).

Server certificates are generated based on a specific CSR (see Figure 45) and, along with the server certificate, you should get the entire chain of trust (see Figure 46).

Figure 45: Sample CSR Sent to CA

Figure 46: Sample Certificates Returned by CA (Server, Intermediate, and Root)

Generate a CSR on a Controller

To create a Certificate Request, follow these steps from the controller that needs a certificate:

1. Click Configuration > Certificates > Controller Certificates. The Controller Certificate window displays.
2. Click Add. The Certificate Add window displays.
3. Provide the requested information in this window.
4. Click Apply.
5. The CSR is generated and appears in a window.
6. Either copy this Certificate PEM for pasting into a submittal form or click Save to save the CSR as a file.
7. Click Close.
8. Send the CSR to the Certificate issuer to be processed. If the CA asks for the operating system type, select Open SSL (if available) or Other.

The Certificate entry now displays in the Server Certificates page under “Pending CSR.” This entry will be matched to the certificates when they arrive and imported, ensuring that the controller that requested certificates is the only one to use those certificates.

Generate a Wildcard Certificate

The SD support wildcard certificate for both tunnel and bridge mode captive portal. To create a Wildcard Certificate Request, follow these steps:

1. Click Configuration > Certificates > Controller Certificates. The Controller Certificate window displays.
2. Click Add. The Certificate Add window displays.
3. Enter the details in the General section.
4. Enter the Common Name as *.name in Distinguished Name (DN) section. For example *.merunetworks.com.
5. Click Apply.
6. The CSR is generated and appears in a window.
7. Either copy this Certificate PEM for pasting into a submittal form or click Save to save the CSR as a file.
8. Click Close.
9. Send the CSR to the Certificate issuer to be processed. If the CA asks for the operating system type, select Open SSL (if available) or Other.

The Certificate entry now displays in the Server Certificates page under “Pending CSR.” This entry will be matched to the certificates when they arrive and imported, ensuring that the controller that requested certificates is the only one to use those certificates.

Import the Certificate

Remember that you MUST add the Root Certificate and ALL Intermediate Certificates in the chain of trust before you install the signed Server Certificate; if you don’t install in order, you get an error.

To import a Trusted Root CA and the entire chain of trust that you receive from a CA, follow these steps:

1. Click Configuration > Certificates> Trusted Root CA.
2. Click Import.
3. Browse to the Root CA file and select it.
4. Click Open and give the Certificate an appropriate alias name.

You can also open the certificate in any text editor and copy/paste the Certificate’s PEM text into the “Certificate PEM” blank text area shown below.

5. Click Import.

You should see a message indicating that the import was successful.

6. Click OK > Close.
7. Repeat steps 2 – 6 for all certificates.

You should now see all certificates imported into the controller

8. Import the Server Certificate by clicking Configuration > Certificates > Controller Certificates > Pending CSR > Import.
9. Browse to the server certificate, select it and click Import > Open > Import.

10.Click OK > Close > Close.

11.Restart the web server by navigating to Maintenance > Reboot System and checking the Reboot Controller box located towards the top of the window. Click Reboot to perform the action.

You are finished importing the certificates.

Assign a Server Certificate to an Application

Certificates can be used for security purposes (i.e., for RADIUS termination) as well as by Captive Portal or Web Administration tools. To assign the Server Certificate:

1. Select the certificate in the Controller Certificates table.
2. Click Applications. The Applications dialog displays.

Figure 47: Applications to Use Certificate

a

3. Use the drop-down menus provided to specific the certificates to be used for the desired applications.
4. Click Apply.
5. Click Close.
6. To ensure that the certificate is applied and activated correctly, use the reload-security command from the system’s CLI.

The Apache Web Server needs to be restarted after successfully assigning a certificate to be used by Captive Portal and/or Management Applications.

AP Certificates

VPN applications require a security certificate to be installed on both the AP and the controller before secure communication between the two can proceed. Follow the instructions provided in the following sections in order to properly set up an AP for VPN connectivity.

Some AP models come with the certificate pre-installed and therefore do not need one to be generated for them. If your AP already shows “Certificate Installed” in the VPN AP table (see “Adding VPN APs” on page 253), you do not need to go through this process.

Generating an AP CSR

Prior to installing an AP certificate, a Certificate Signing Request (CSR) specific to the desired AP must be generated via the FortiWLC (SD) WebUI. Perform the following steps to create and submit a CSR for a specific AP.

1. From the WebUI, navigate to Configuration > Certificates > AP Certificates. The AP Certificates table appears.

Figure 48: AP Certificates Table

2. Select the desired AP in the AP table and click Create CSR. The CSR dialog appears. Figure 49: CSR Configuration
3. In the resulting dialog, the “Valid Till” field specifies the duration of the certificate. Enter the number of days for which the certificate should be valid and click Apply.

The AP table will refresh a few times as the CSR generation proceeds. The “User Req Status” column will display its progress, ranging from “CSR Generation in Progress” to “CSR Generated”. If the column doesn’t refresh, click Refresh.

4. Once you see “CSR Generated”, you are ready to proceed to export the CSR so that it may be submitted to a Certificate Authority.

Exporting the CSR

After the CSR has been generated, it can be exported into an individual file so that it may be provided to a Certificate Authority server for verification.

1. From the AP Certificates table, click the desired AP (if not already selected) and click Export.
2. Download the resulting exported file to your local machine.
3. Upload the exported file to your Certificate Authority server. The server should provide two files in return:
   • An AP certificate generated using the CSR
   • A Root CA certificate

If you have not already installed the Certificate Authority’s Trusted Root CA certificate on the system, do so by following the steps detailed in “Import the Certificate” on page 245 earlier in this chapter. Note that this must be done prior to installing the certificate on the AP.

Installing the AP Certificate

Once all the previous steps are completed, you are ready to install the certificate on the AP itself.

1. From the AP Certificates table (Configuration > Certificates > AP Certificates), select the desired AP and click Import.
2. In the resulting pop-up window, enter the certificate alias name in the field provided.
3. Click Choose File and browse to the AP certificate provided by the Certificate Authority.
4. Click Save. After a few seconds, a message displays stating “Certificate imported successfully” and the “Certificate Status” column will show “Cert Installed”. If these messages don’t seem to display properly, click Refresh to update the table.

The AP is now certified and ready for use.

It is recommended that all AP certificates be installed on their APs prior to configuring and deploying them for VPN use. Once all certificates have been installed, refer to “Configuring the VPN” on page 252 for instructions.

Troubleshooting Certificates

.The following errors can occur during the certificate process.

WAPI Configuration

The WLAN Authentication and Privacy Infrastructure (WAPI) is a Chinese national standard for WLANs. There are two authentication models used for WAPI functionality: certificatebased and PSK-based. For WAPI certificate configurations, the controller must have the IP and port communication details for the central Authentication Service Unit (ASU), which will verify that the wireless communication is permitted.

FortiWLC (SD) implements WAPI configurations in release 5.2 and later.

WAPI Configuration

Specifying WAPI Authentication Mode

As mentioned above, users can specify whether the deployment will use certificate-based or PSK-based WAPI authentication. This is done via the Security Profile configuration.

1. From the WebUI, navigate to Configuration > Security > Profile.
2. Create a new profile by clicking the Add button.
3. In the L2 Modes Allowed section, specify the desired WAPI option:
   • WAI: for certificate-based models
   • WAI-PSK: for PSK models
4. Make the remaining selections as desired. If using the PSK option, be sure to set an appropriate entry in the Pre-shared Key field.

If your deployment is making use of the WAI option (certificate-based), you will need to configure a WAPI server and import a WAPI certificate as well. Proceed to the following sections for these details.

Importing a WAPI Certificate

In order to properly authenticate WAPI communications, a certificate must be imported into the system. Follow the instructions below.

1. From the WebUI, navigate to Configuration > Certificates > Controller Certificates.
2. Click WAPI Cert Import.
3. Browse to the location of the WAPI certificate and click Import. Note that the system only supports one WAPI certificate to be configured at any given time.
4. After the certificate is imported, click the WebTerm link to open a CLI console.
5. Log into the console and execute the reload-wapi command to reload WAPI service.
6. Proceed to the next section in order to configure communication with the WAPI Authentication Service Unit.

Configuring a WAPI Server

The WAPI server needs to be configured only when using certificate-based WAI authentication. This configuration is used to authenticate the WAPI certificate after it has been imported into the system.

To configure the WAPI Server:

1. From the WebUI, navigate to Configuration > Security > WAPI Server.

WAPI Configuration

2. Enter the following information:

• WAPI Server IP—The IP address for the Authentication Service Unit. • WAPI Server Port—Enter the port number used for WAPI communication (default:

3810).

Integration with Palo Alto Networks Firewall

FortiWLC (SD) supports syslog based integration with User ID Agent solution of the Palo Alto Networks Firewall solution. This allows for setting up firewall rules on the Palo Alto Firewall when a user login into the network.

Configuring VPN Connections

In System Directer version 5.2 and later, users have the ability to configure supported APs to connect to the corporate controller via VPN connections, allowing a secure remote wireless signal. This can be of particular use in telecommuting applications, as a user can simply take an AP that has been configured for VPN access to another Internet-accessible location and quickly set up a secure line back to the corporate network. In the VPN implementation, the controller acts as a TLS/SSL VPN server while the APs act as TLS/SSL VPN clients.

In order to configure an AP for VPN access, it must first be connected to the corporate network so that it can be populated into the controller AP table. The AP’s secure VPN connection requires the use of a security certificate, which for some modes comes pre-installed, while others require it to be installed by the user. The following sections provide instructions on how to configure a VPN connection and add APs for VPN access.

VPN functionality is currently available on the AP110, AP332e, AP332i, AP832, 822, FAP-U421EV, FAP-U423EV and AP1014i models, and is supported on all physical and virtual controllers.

Activating Controller Certificates for VPN

If a certificate has already been installed on the controller (i.e., for Captive Portal access—see

“Sample Certificates Returned by CA (Server, Intermediate, and Root) Generate a CSR on a Controller” on page 243), the same certificate can be used for VPN access; however, it must be configured for this use before it will allow VPN connections.

To enable a certificate for VPN use:

3. From the WebUI, navigate to Configuration > Certificates > Controller Certificates. The Controller Certificates table appears.
4. Select the desired certificate and click Used By…. A list of applications will appear.

Integration with Palo Alto Networks Firewall

5. Click VPN to enable the certificate for VPN use.
6. A dialog message will appear stating that you need to execute a command from the CLI to load the changes. Execute the command by performing the following:
   • Click the WebTerm link in the upper-right portion of the WebUI.
   • Log in using your controller credentials.
   • Type reload-vpn and press Enter. The VPN service will relaunch.

Now that the controller certificate has been added, it is recommended that you add and install all required AP security certificates as well. Following this sequence of events will provide best VPN results. See “AP Certificates” on page 246 for instructions on installing AP certificates.

Configuring the VPN

Prior to configuring specific APs, the system administrator must first configure the VPN connection settings on the controller.

To configure the VPN:

1. From the WebUI, navigate to Configuration > Security > VPN Server. The VPN Configuration screen appears.

Figure 50: Configuring the VPN

2. Enter the desired configuration for the VPN server. Refer to the following table for details:

3. Click OK to save the changes. The controller is now configured for VPN service.

Adding VPN APs

Once the VPN server is configured, APs can be added for VPN access. To do so, follow the steps below.

1. From the VPN screen (Configuration > Security > VPN Server), click the VPN APs tab. The screen refreshes. See Figure 51.

Configuring VPN Connections

Figure 51: Selecting VPN APs

2. Check the box alongside the AP(s) that shall be configured for VPN access and click Next to proceed to the Activate tab.

The new table displays the VPN-readiness of the selected APs. If your AP already has a security certificate installed, the table will indicate that no further action is required. However, if any of the selected APs require a certificate to be installed, the Action Required column will provide a link that navigates automatically to the Certificates screen where you can install one for it. Figure 52 shows two APs, one which has already had a certificate configured and one which requires additional steps.

Figure 52: Activation Table

3. When all APs have “No Action Required” in the Action Required column, you are ready to activate the VPN devices. Click Activate to proceed to the VPN Status tab. The APs should automatically appear and are now ready to be deployed.

The show vpn-ap CLI command can be used to view the APs currently configured for VPN access.

This command can be executed from the WebTerm link in the upper-right portion of the WebUI.

Configuring VPN Client Connections

In addition to allowing VPN AP connections, FortiWLC (SD) can be configured to use VPN connectivity to its E(z)RF Network Manager as well. In this configuration, the Network Manager appliance acts as a VPN server and the controller acts as a client. Note that this must also be configured on the Network Manager appliance for full VPN communication.

To configure VPN Client connection:

1. From the FortiWLC (SD) WebUI, navigate to Configuration > Security > VPN Client.
2. Use the State drop-down to select Enable.

Configuring VPN Connections

3. In the VPN Server IP address field, enter the IP of your Network Manager appliance. Note that VPN must be configured on the Network Manager device prior to attempting to associate VPN controllers with it.
4. In the VPN Server Port field, enter the port used for VPN service. By default, this is 1194.
5. Click OK to save the changes.

RADIUS Authentication

Conceptual 802.1X Model for RADIUS Authentication

The conceptual model for 802.1X authentication looks like this:

Figure 53: Conceptual Model for 802.1X RADIUS Server Authentication

802.1X RADIUS authentication works like this:

1. Depending on the EAP type, you may first need to obtain a digital certificate from the Certificate Server.
2. Using EAP as end user, contact the AP in order to be authenticated.
3. The AP forwards the request to the controller.
4. The controller acts as a RADIUS client and sends the request to the RADIUS server.
5. Depending on the EAP type, the RADIUS server may challenge the end user for a password, or the user may present a digital certificate that they have previously obtained from a Certificate Server.
6. The RADIUS server authenticates the end user and the access point, and opens a port to accept the data from the end user.

Configure RADIUS Authentication for Users With the Web UI

To use RADIUS authentication for guests and employees on the network,

1. Add the controller IP address and shared secret in the RADIUS server.
2. Create a RADIUS Profile (use the same shared secret as in step 1).
3. Include that RADIUS Profile in a Security Profile.
4. Include the Security Profile in an ESS Profile.

Configuring RADIUS authentication for administrators is a different, simpler process. Follow these steps to add a RADIUS profile:

1. Click Configuration > Security > RADIUS.
2. Provide a name, description, IP address, secret key, and port number (1812 is default).
3. Select a MAC address delimiter (Hyphen, Single Hyphen or Colon) from the list.
4. Select a password type (Shared Key or MAC Address) from the list.
5. Select a called station ID type (Default, MacAddress, or MacAddress:SSID) from the list.
6. Select CoA Status. To process, CoA requests from this RADIUS server, set this to ON.
7. Click OK.

Indicate when the RADIUS server should be used. There are two ways to do this. One way is a two-step process that creates a Security Profile to call the RADIUS Profile, and then creates an ESS Profile to call the Security Profile. This process is described in steps 6 and 7.

8. Click Configuration > Security > Profile. Here you see all security profiles that have been created on this controller. You can either modify an existing security profile to use the RADIUS server or you can add a new security profile. Either way, the security profile includes a drop-down list for Primary RADIUS Profile Name and Secondary RADIUS Profile Name; all configured RADIUS servers are listed and you can select one from the list.

Indicate which ESS Profile should use the Security Profile.

9. Click Configuration > Wireless > ESS. Here you see all ESS profiles that have been created on this controller. You can either modify an existing ESS profile to use the Security Profile or you can add a new ESS Profile. Either way, there is a drop-down list for Security Profile Name; all configured Security Profiles are listed and you can select one from the list.

You can also skip step 6 above and select the Primary RADIUS Profile Name and Secondary RADIUS Profile Name directly from the ESS as part of step 7. In addition, you can configure server timeout and retries:

• RADIUS Server Timeout: This is the time interval (in seconds) between which the RADIUS authentication with primary RADIUS server is retried.
• RADIUS Server Retries: This is the number of attempts to reach the primary RADIUS server. After the retries limit is reached, the authentication workflow is sent to the secondary server. All new clients will be authenticated via the secondary RADIUS server.

COA Support

FortiWLC (SD) provides the following support for change of authorization messages:

• Only 1x and Captive Portal user sessions supported.
• Both Primary/Secondary RADIUS Profiles supported.
• Controller listens to COA messages on UDP port 3799
• User sessions in a COA messages can be identified using MAC-address and/or username.
• Disconnect or CoA requests can be sent from any configured RADIUS server in the controller.
• CoA requests on UDP 1700, to enable Cisco ISE Interoperability.
• For Disconnect Message, only station mac-address is required. When disconnected, the client is completely disconnected from the network and its session data, 1x, PMK Cache is also cleared. In case of captive portal session, session aging timer is also cleared. After a disconnect, the client must be go through complete authentication sequence to reconnect.
• While sending a CoA message, only the change of Filter-ID is supported.
• RADIUS based filter-ID and CoA for filter-ID change for MAC authenticated (RADIUS) clients is supported.
• CoA disconnection requests are honoured when a user maps a security profile which is configured for WPA-PSK with MAC filtering enabled, to an ESS profile is implemented. CoA disconnect requests for Captive Portal Bypass and MAC filtering enabled stations have the stations go through the complete MAC and CP authentication while re-connecting. • If you create more than one RADIUS profile using the same server IP address, ensure that the shared secret is the same across profiles.

RADIUS Disconnect Message and Filter-ID Support

802.1x                MAC Auth            Captive Portal

Y                            Y                              Y

RADIUS Disconnect

Y    x              Y CoA (Filter-ID)

Configure RADIUS Authentication for Administrators With the Web UI

Configure RADIUS authentication for all administrators by following these steps:

1. Click Configuration > User Management.
2. Select RADIUS for Authentication Type at the top of the screen. See Figure 55.
3. There are three tabs for admin authentication (see m), RADIUS, Tacacs+ and Local Admins. The RADIUS tab is the default.

Figure 54: Configure a User for RADIUS Authentication

4. Provide the IP address of the primary RADIUS server.
5. Provide a primary RADIUS port number; the default is 1812.
6. Provide the secret key for RADIUS server access.
7. Optionally repeat steps 4, 5 and 6 for a secondary RADIUS server.
8. Click OK.
9. Add administrators on the RADIUS server using these three levels.

Configure RADIUS Authentication for Administrators With the CLI

Commands to configure all controller administrators for RADIUS authentication mode:

• authentication mode global
• primary-radius-ip
• primary-radius-port
• primary-radius-secret
• authentication type radius
• secondary-radius-ip
• secondary-radius-port
• secondary-radius-secret

For command details, see the FortiWLC (SD) Command Reference.

CLI Example for Setting Authentication Mode to RADIUS

ramcntrl(0)# configure terminal ramcntrl(0)(config)# authentication‐mode global ramcntrl(0)(config‐auth‐mode)# authentication‐type radius ramcntrl(0)(config‐auth‐mode)# primary‐radius‐

primary‐radius‐ip      primary‐radius‐port    primary‐radius‐secret  ramcntrl(0)(config‐auth‐mode)# primary‐radius‐ip 172.18.1.3 ramcntrl(0)(config‐auth‐mode)# primary‐radius‐secret RadiusP ramcntrl(0)(config‐auth‐mode)# secondary‐radius‐

secondary‐radius‐ip      secondary‐radius‐port    secondary‐radius‐secret  ramcntrl(0)(config‐auth‐mode)# secondary‐radius‐ip 172.18.1.7 ramcntrl(0)(config‐auth‐mode)# secondary‐radius‐secret RadiusS ramcntrl(0)(config‐auth‐mode)# exit ramcntrl(0)(config)# exit

ramcntrl(0)# sh authentication‐mode Administrative User Management

AuthenticationType           : radius

Primary RADIUS IP Address    : 172.18.1.3

Primary RADIUS Port          : 1812

Primary RADIUS Secret Key    : *****

Secondary RADIUS IP Address  : 172.18.1.7

Secondary RADIUS Port        : 1812

Secondary RADIUS Secret Key  : *****

Primary TACACS+ IP Address   : 0.0.0.0

Primary TACACS+ Port         : 49

Primary TACACS+ Secret Key   : *****

Secondary TACACS+ IP Address : 0.0.0.0

Secondary TACACS+ Port       : 49

Secondary TACACS+ Secret Key : ***** ramcntrl(0)#

RADIUS Authentication Attributes

Attributes for 802.1X

The RADIUS 802.1X message attributes are:

MESSAGE: Access-Request

ATTRIBUTES:

• User-Name(1)
• NAS-IP-Adress(4)
• NAS-Port(5)
• Called-Station-Id(30) = <mac of Controller>:<ssid string>
• Calling-Station-Id(31)
• Framed-MTU(12)
• NAS-Port-Type(61) = Wireless-802.11(19)
• Connect-Info(77)
• Message-Authenticator(80)

OPTIONAL ATTRIBUTES (depends on EAP type):

• EAP-Message(79)
• State(24)

OPTIONAL ATTRIBUTES (depends on RADIUS based User Management)

• Service-Type(6) = Value:Login(1)
• User-Password(2) = Value:<password string>

MESSAGE: Access-Accept

ATTRIBUTES:

• Framed-Protocol(7) = PPP(1)
• Service-Type(6) = Framed-User(2)
• Class(25)
• Message-Authenticator(80)

OPTIONAL ATTRIBUTES (depends on EAP type):

• EAP-Message(79)
• OPTIONAL ATTRIBUTES (required for RADIUS-assigned VLAN):
• Tunnel-Medium-Type(65) = 802(6)
• Tunnel-Type(64) = VLAN(13)
• Tunnel-Private-Group-Id (81) = <the VLAN ID>

OPTIONAL ATTRIBUTES (depends on RADIUS based User Management)

• Filter-Id(11) = Value:<Privilege Level>:<1-15>

RADIUS Accounting for Clients

If you have a RADIUS accounting server in your network, you can configure the controller to act as a RADIUS client, allowing the controller to send accounting records to the RADIUS accounting server. The controller sends accounting records either for clients who enter the wireless network as 802.1X authorized users or for the clients that are Captive Portal authenticated.

When using RADIUS accounting, set up a separate RADIUS profile for the RADIUS accounting server and point the ESS profile to that RADIUS profile. So, for example, you could have a RADIUS profile called radiusprofile1 that uses UDP port 1645 or 1812 (the two standard ports for RADIUS authentication) and your security profiles would point to radiusprofile1. To support RADIUS accounting, configure a new RADIUS profile (like radiusprofile1_acct) even if the RADIUS accounting server is the same as the RADIUS authentication server. Set its IP and key appropriately and set its port to the correct RADIUS accounting port (1646, 1813 for example). Then point ESS profiles) to this new RADIUS profile radiusprofile1_acct.

Accounting records are sent for the duration of a client session, which is identified by a unique session ID. You can configure a RADIUS profile for the primary RADIUS accounting server and another profile for a secondary RADIUS accounting server, which serves as a backup should the primary server be offline. The switch to the backup RADIUS server works as follows. After 30 seconds of unsuccessful Primary RADIUS server access, the secondary RADIUS server becomes the default. The actual attempt that made it switch is discarded and the next RADIUS access that occurs goes to the Secondary RADIUS server. After about fifteen minutes, access reverts to the Primary RADIUS Server.

In every RADIUS message (Start, Interim Update and Stop), the following attributes are included:

TABLE 17: RADIUS Accounting Attributes

TABLE 17: RADIUS Accounting Attributes

TABLE 18: RADIUS Authentication Attributes

TABLE 18: RADIUS Authentication Attributes

RADIUS-Based ESS Profile Restriction

This feature gives a controller the capability to restrict wireless clients attempting connection through RADIUS based ESS profiles; the clients can connect only to certain SSIDs as returned in a RADIUS Accept message.

With this system, there is one RADIUS server and multiple ESS profiles with 802.1X security using this RADIUS Server. In absence of the RSSID feature, all wireless clients provisioned in the RADIUS Server have access to all ESS profiles and hence all associated VLANS. With SSID restriction, the RADIUS server can be further configured for each of these wireless clients specifying the SSIDs they can connect with.

You can use a RADIUS server to restrict SSID connection using VSA in the RADIUS Accept message. There are three possible conditions for an SSID:

The RADIUS server should return the allowed SSID(s) in a Vendor-specific attribute (VSA) with Vendor code 9 and attribute number 1 in the Access-Accept message. The attribute value should be string format.

The string should say ssid=<ssid-string> where <ssid-string> is replaced by the actual SSID (also known as the ESSID).

If a list of multiple allowed SSIDs is used, put each SSID in a separate instance of the attribute. The order of the attributes does not matter. If the SSID to which the station is trying to connect is not among the SSIDs returned by the RADIUS server, the station will be denied access.This feature has no CLI or Web UI commands associated with it. If the RADIUS responds with a list of allowed SSIDs, the list is used to process and limit the user.

Remote RADIUS Server

Network deployments with remote sites that are physically away from their head-quarter (or master data center -DC) can use remote RADIUS server in each of the remote sites for local authentication purposes.

In a typical scenario, a RADIUS server is usually co-located in the DC. Remote sites that required AAA services to authenticate their local clients use the RADIUS server in the DC. This in most cases introduces among other issues high latency between the remote site and its DC. Deploying a RADIUS server within a remote site alleviates this problem and allows remotes sites or branches to use their local AAA services (RADIUS) and not rely on the DC.

Remote RADIUS Server

Before you Begin

Points to note before you begin deploying a remote RADIUS server:

1. Ensure that the Controller and site AP communication time is less than RADIUS timeout.
2. Provision for at least one AP that can be configured as a relay AP.
3. Only Fortinet 11ac APs (AP122, AP822, AP832, and OAP832) in L3-mode can be configured as a relay AP.
4. In case of WAN survivability, no new 802.1x radius clients will be able to join, until relay AP rediscovers the controller.

How It Works

This feature provides local authentication (.1x, Captive Profile, and mac-filtering) services using a RADIUS server set up in the remote site. In addition to the RADIUS server, the remote site must also configure a Fortinet 11ac AP as a relay AP.  The remote RADIUS profile can be created per ESS profile using the controller’s WebUI (Configuration > RADIUS) or CLI. A remote RADIUS profile works like a regular profile and can be used as primary and secondary RADIUS auth and accounting servers.

About Relay AP

• The relay AP primarily is used for communicating between the RADIUS server (in the remote site) and the controller in the head-quarters.
• An AP is set as a relay AP only when it is assigned in the RAIDUS profile. Once an AP is assigned as a relay AP It is recommended that you do not overload the relay AP with client WLAN services. This can result in communication issues between the relay AP and DC. For regular client WLAN services, we recommend the use of a different Fortinet access point. For a remote RAIDUS profile, you cannot configure a secondary relay AP. However, for resilience purposes, we recommend configuring an alternate (backup) RADIUS profile and assigning another AP as a relay AP to this backup RAIDUS profile. In the security profile, set this RADIUS profile as the secondary RADIUS server.

Remote RADIUS Server

The following figure illustrates a simple scenario with local RADIUS deployment.

To configure remote RADIUS via WebUI,

In the Configuration > RADIUS > RADIUS Configuration Table – ADD page, set Remote Radius Server to ON (see 1 in Figure 2).

Select the AP (Remote Radius Relay ApId) to be used as the relay AP (see 2 in Figure 2).

Remote RADIUS Server

Configuring Using CLI

# configure terminal

(config)# radius‐profile RemoteRadius

(config‐radius)# remote‐radius‐server on

(config‐radius)# radius‐relay‐apid XXX

XXX is the AP ID of the relay AP in the remote site.

# configure terminal

(config)# radius‐profile RemoteRadius

(config‐radius)# no remote‐radius‐server

# show radius‐profile <remoteRadius‐profile‐name>

EXAMPLE

# show radius‐profile site‐a   

RADIUS Configuration Table                                                       

RADIUS Profile Name      : site‐a          

Description              : Remote radius profile for Site‐A          

RADIUS IP                : 172.18.1.8     RADIUS Secret            : *****         

RADIUS Port              : 1812          

Remote RADIUS Server

Remote Radius Server     : on            

Remote Radius Relay ApId : 2             

MAC Address Delimiter    : hyphen         Password Type            : shared‐secret  

Called‐Station‐ID Type   : default       

Owner                    : controller    

COA                      : on

TACACS+ Authentication

Terminal Access Controller Access-Control System Plus (TACACS+) is a remote authentication protocol that runs on a TACACS+ server on the network and is similar to RADIUS authentication. There are some differences between the two, however. RADIUS combines authentication and authorization in one user profile, while TACACS+ separates the two operations. Another difference is that TACACS+ uses TCP port 49 while RADIUS uses UDP port 1812. FortiWLC (SD) supports TACACS+ authentication but not accounting; FortiWLC (SD) supports both RADIUS authentication and accounting. Only the Cisco ACS server is supported for Tacacs+ authentication.

The TACACS+ level required, 15 (superuser), 10 – 14 (admin), and 1 – 9 (user), for the activity on the current GUI window is listed in the Help. Click Help on any GUI window of FortiWLC (SD). In the CLI, all command lists also include the required authentication level, which is also now used for both RADIUS and local admin authentication in Release 5.1. TACACS+ actually provides eight levels, but Fortinet only uses the three authentication levels described here. The three levels used are described below:

TACACS+ Authentication

Configure TACACS+ Authentication Mode with the CLI

New commands to configure TACACS+ authentication mode for all administrators on a Cisco ACS server were introduced in FortiWLC (SD) 4.1:

• authentication mode global
• primary-tacacs-ip
• primary-tacacs-port
• primary-tacacs-secret
• authentication type tacacs+
• secondary-tacacs-ip
• secondary-tacacs-port
• secondary-tacacs-secret

For command details, see the FortiWLC (SD) Command Reference.

CLI Example for Setting Authentication Mode to TACACS+

ramcntrl(0)# configure terminal ramcntrl(0)(config)# authentication‐mode global ramcntrl(0)(config‐auth‐mode)# authentication‐type tacacs+ ramcntrl(0)(config‐auth‐mode)# primary‐tacacs‐

primary‐tacacs‐ip      primary‐tacacs‐port    primary‐tacacs‐secret  ramcntrl(0)(config‐auth‐mode)# primary‐tacacs‐ip 172.18.1.5 ramcntrl(0)(config‐auth‐mode)# primary‐tacacs‐secret TacacsP ramcntrl(0)(config‐auth‐mode)# secondary‐tacacs‐

secondary‐tacacs‐ip      secondary‐tacacs‐port    secondary‐tacacs‐secret  ramcntrl(0)(config‐auth‐mode)# secondary‐tacacs‐ip 172.18.1.10 ramcntrl(0)(config‐auth‐mode)# secondary‐tacacs‐secret TacacsS ramcntrl(0)(config‐auth‐mode)# exit

TACACS+ Authentication

ramcntrl(0)(config)# exit

ramcntrl(0)# sh authentication‐mode Administrative User Management

AuthenticationType           : tacacs+

Primary RADIUS IP Address    : 172.18.1.3

Primary RADIUS Port          : 1812

Primary RADIUS Secret Key    : *****

Secondary RADIUS IP Address  : 172.18.1.7

Secondary RADIUS Port        : 1812

Secondary RADIUS Secret Key  : *****

Primary TACACS+ IP Address   : 172.18.1.5

Primary TACACS+ Port         : 49

Primary TACACS+ Secret Key   : *****

Secondary TACACS+ IP Address : 172.18.1.10

Secondary TACACS+ Port       : 49 Secondary TACACS+ Secret Key : ***** ramcntrl(0)#

For command details, see the FortiWLC (SD) Command Reference.

Configure TACACS+ Authentication Mode with the Web UI

To configure TACACS+ authentication on a Cisco ACS server for all admins, follow these steps:

1. Click Configuration > User Management.
2. Select the Authentication Type Tacacs+ at the top of the screen.
3. There are three tabs for admin authentication (see Figure 55), RADIUS, Tacacs+ and Local Admins. Click the Tacacs+ tab.

Figure 55: Setting Authentication for Admins

4. Provide the IP address of the primary TACACS+ server.

TACACS+ Authentication

5. Provide a primary TACACS+ port number; the default is 49.
6. Provide the secret key for TACACS+ server access.
7. Optionally repeat steps 4, 5 and 6 for a secondary TACACS+ server.
8. Click OK.
9. Add administrators on the TACACS+ server using these three levels.

Local Admin Authentication

Local admin authentication takes place on the controller and uses the same three privilege levels as RADIUS and TACACS+, 15 (superuser), 10 (admin), and 1 (user). If administrators are using Local authentication, they cannot use RADIUS or TACACS+.

Configure an Admin for Local Authentication Mode With the CLI

Use these commands, new in release 4.1, to configure local administrators with the CLI:

• authentication-mode global
• authentication-type local
• local-admin
• password
• privilege-level
• show local admins

For command details, see the FortiWLC (SD) Command Reference.

Local Admin Authentication

CLI Example for Configuring a Local Admin

ramcntrl(0)# configure terminal ramcntrl(0)(config)# authentication‐mode global ramcntrl(0)(config‐auth‐mode)# authentication‐type local ramcntrl(0)(config‐auth‐mode)# exit ramcntrl(0)(config)# exit

ramcntrl(0)# sh authentication‐mode Administrative User Management

AuthenticationType           : local

Primary RADIUS IP Address    : 0.0.0.0

Primary RADIUS Port          : 1812

Primary RADIUS Secret Key    : *****

Secondary RADIUS IP Address  : 0.0.0.0

Secondary RADIUS Port        : 1812

Secondary RADIUS Secret Key  : *****

Primary TACACS+ IP Address   : 0.0.0.0

Primary TACACS+ Port         : 49

Primary TACACS+ Secret Key   : *****

Secondary TACACS+ IP Address : 0.0.0.0

Secondary TACACS+ Port       : 49 Secondary TACACS+ Secret Key : ***** ramcntrl(0)#

ramcntrl(0)(config)# local‐admin LocalUser ramcntrl(0)(config‐local‐admin)# privilege‐level 15 ramcntrl(0)(config‐local‐admin)# password LocalUser ramcntrl(0)(config‐local‐admin)# exit ramcntrl(0)(config)# exit ramcntrl(0)

Configure Local Authentication and Add an Admin with the Web UI

To configure Local authentication for admins and optionally add a local administrator, follow these steps:

1. Click Configuration > User Management.
2. Select the Local radio button at the top of the screen.

To actually add a local administrator, continue with Step 3.

3. There are three tabs for admin authentication (see Figure 55), RADIUS, Tacacs+ and Local Admins. Click the Local Admin tab.
4. Click Add. The Local Admins – Add window displays – see Figure 56.

Local Admin Authentication

Figure 56: Setting Local Authentication for Admins

5. Provide the user name for a local administrator.
6. Provide a password for that local administrator.
7. Enter a privilege level, 15 (Superuser), 10 (Admin), or 1 (Operator); see the descriptions for each level below.
8. Click OK.

802.1X Authentication

Authentication in the 802.11 standard is focused more on wireless LAN connectivity than on verifying user or station identity. For enterprise wireless security to scale to hundreds or thousands of users, an authentication framework that supports centralized user authentication must be used in addition to the WEP type specified by 802.11, or by using WPA/WPA2, which incorporates TKIP/CCMP-AES and 802.1X authentication.

The use of IEEE 802.1X offers an effective framework for authenticating and controlling user traffic to a protected network, as well as dynamically varying encryption keys if WPA/WPA2 is configured. 802.1X ties a protocol called EAP (Extensible Authentication Protocol) to both the wired and wireless LAN media and supports multiple authentication methods, such as token cards, Kerberos, one-time passwords, certificates, and public key authentication.

802.1X Components

There are three basic pieces to 802.1X authentication:

1. Supplicant—a software client running on the wireless station
2. Authenticator—the access point and the controller
3. Authentication Server—an authentication database, traditionally a RADIUS server such as Cisco ACS, Steel Belt RADIUS server (Juniper), or Microsoft IAS.

Extensible Authentication Protocol (EAP) is used to pass the authentication information between the supplicant (the wireless station) and the authentication server (RADIUS, MS IAS, or other). The actual authentication is defined and handled by the EAP type. The access point (and the controller in the configuration) acts as the authenticator. The authenticator is a client of the server that allows the supplicant and the authentication server to communicate.

802.1X Authentication

About the EAP Types

The EAP type you choose, and whether you choose to implement authentication in your organization, depends on the level of security you require. Some of the most commonly deployed EAP authentication types include the following, all of which are supported by the controller:

• EAP-TLS
• EAP-PEAP
• EAP-TTLS
• Cisco LEAP

EAP-TLS

EAP-TLS (Transport Layer Security) provides certificate-based mutual authentication between the client and the network. It relies on client and server certificates to provide authentication and can be used to dynamically generate user-based and session-based encryption keys to secure subsequent communications between the WLAN client and the access point. This type of authentication mechanism requires the administrator install a Certificate Server to store and distribute user and computer certificates. Each client will need the certificate to be downloaded and installed on the wireless client before attempting to use the WLAN. For a large WLAN installation, this can be a cumbersome task.

EAP-TTLS (Tunneled Transport Layer Security)

EAP-TTLS (Tunneled Transport Layer Security) was developed by Funk Software and Certicom, as an extension of EAP-TLS. This security method provides for certificate-based, mutual authentication of the client and network through an encrypted channel (or tunnel), as well as a means to derive dynamic, per-user, per-session encryption keys. Unlike EAP-TLS, EAP-TTLS requires only server-side certificates.

LEAP (Lightweight Extensible Authentication Protocol)

LEAP (Lightweight Extensible Authentication Protocol), is an EAP authentication type used primarily in Cisco Aironet WLANs. It encrypts data transmissions using dynamically generated WEP keys, and supports mutual authentication. Cisco has recently licensed LEAP to a variety of other manufacturers enabling the usage of other than Cisco adapters with LEAP.

PEAP (Protected Extensible Authentication Protocol)

PEAP (Protected Extensible Authentication Protocol) provides a method to securely transport authentication data, including legacy password-based protocols, via 802.11 wireless networks. PEAP accomplishes this by using tunneling between PEAP clients and an authentication server. Like the competing standard Tunneled Transport Layer Security (TTLS), PEAP authenticates wireless LAN clients using only server-side certificates, thus simplifying the implementation and administration of a secure wireless LAN. Microsoft, Cisco and RSA Secu-

802.1X Authentication

rity developed PEAP. Note that Cisco’s LEAP authentication server, ACS, recently added support for PEAP.

The following notes apply to the authentication mechanisms above:

1. MD5 is not typically used as it only provides one-way authentication. MD5 does not support automatic distribution and rotation of WEP keys and therefore does nothing to relieve the administrative burden of manual WEP key maintenance.
2. TLS, although very secure, requires the administrator to install client certificates on each wireless station. Maintaining a PKI infrastructure adds additional time and effort for the network administrator.
3. TTLS addresses the certificate issue by tunneling TLS, and thus eliminates the need for a certificate on the client side. This often makes TTLS the preferred option. Funk Software primarily promotes TTLS and there is a charge for supplicant and authentication server software.
4. LEAP has the longest history. Although previously proprietary to Cisco, Cisco now licenses the software. Other vendors are now beginning to support LEAP in their wireless LAN adapters.
5. The more recent PEAP works similar to EAP-TTLS in that it does not require a certificate on the client side. PEAP is backed by Cisco and Microsoft and is available at no additional cost from Microsoft. If you want to transition from LEAP to PEAP, Cisco’s ACS authentication server runs both.

Optionally Customize and Use Your Own HTML Pages

If you want to create custom Captive Portal login and success pages with your own logos and credentials, complete the directions in this section. You do not need to do this if you plan to use all of the default Captive Portal pages provided by Fortinet Networks (see login example in Figure 57 on page 282). If you do want to create custom HTML pages, you can create up to four sets of Captive Portal custom login pages; these are referred to as Captive Portal 1 through 4. Each set has 6 files, but you can only create customized pages for the main login page and the authentication successful page. The remaining four HTML pages are always the default pages. If you create multiple custom files, they must both use the same authentication

(RADIUS or Local) with up to 300 local users (the users can be different for each custom portal).

All Custom Portal pages (HTML, CSS, JS, and graphics) for the default pages and up to four sets of Custom Portal 2 pages that you create are all located in the same folder. This makes it imperative that you use unique names for all custom files. It also means that you can share a file such as a CSS file used for both CP1 and CP2 custom pages. This is also how and why any pages that you do not customize will use default HTML files. Here are the locations for the custom web portal files:

/opt/meru/etc/ws/html.vpn.custom

/opt/meru/etc/ws/Styles.vpn.custom

/opt/meru/etc/ws/Images.vpn.custom

Create Custom Pages

The easiest way to create your own set of custom pages is to download Fortinet default files and use the two customizable ones (Login page and Success page) as templates, giving the two altered HTML pages new names. To do this, follow these steps:

1. Get the template files. Click Maintenance > Captive Portal > Customization > Get Files. A zip file called zip.tar.gz is downloaded to your computer. When the zip.tar.gz file is unzipped, you see the folder html.vpn that contains these six default files: Login page can be customized (default filename is loginformWebAuth.html)
   • Successful login page can be customized (default filename is auth_web_ok.html)
   • Your login failed – try again page (default filename is loginformWebAuthRetry.html)
   • Web authentication succeeded; do you want to log off? (default filename is logoff User.html)
   • You are now logged off page (default filename is loggedoff.html)
   • Your logoff failed – try again page (default filename is logoffUserFailed.html)
2. You can only create two custom files per Captive Portal interface: a replacement for the Login page loginformWebAuth.html and a replacement for the Successful Login page auth_web_ok.html. Locate the two customizable HTML files on your computer and use them as templates to create your own custom HTML files. Use a program such as Notepad, make your changes, and then save the files with unique names.
   • CSS, JavaScript, and HTML are supported.
   • You can upload graphics up to 50K each in the formats .html .gif, .jpg, .png, .bmp .css,

.js.

To replace the first Fortinet logo graphic, look for the line that reads: src=”Images.vpn/img_merulogo.gif” width=133 border=0></A></TD>

Change the text “Images.vpn/img_merulogo.gif” to “Images.vpn.custom/your_image.gif” (Note that you are specifying a new directory for the .gif file, which is Images.vpn.custom).

To replace the second graphic (the mountain), look for the line that reads: src=”Images.vpn/img_aboutmeru.jpg” width=326 border=0></TD></TR>

Change the text “Images.vpn/img_aboutmeru.jpg” to “Images.vpn.custom/your_image2.gif” (Note that you are specifying a new directory for the .gif file, which is Images.vpn.custom).

Possible edits include changing logos, text, and formatting. The only lines that cannot be altered are the login communication process between the controller and the RADIUS server in the file loginformWebAuth.html.

3. Import all new Captive Portal files (HTML, CSS, JS, and graphics) to the controller one by one. Click Maintenance > Captive Portal > Import File > enter the location/file in the text box > Import File. Be sure that the files have unique names; they will all be placed in the same directory.

Tell the controller to use custom pages. Click Configuration > Captive Portal and select the radio button Customization.

The custom HTML, CSS, JS, and graphic files are now on the controller.

4. If you want to remove the word Fortinet or make any other changes in the four remaining files loginformWebAuthRetry.html, logoff User.html, loggedoff.html, or logoffUserFailed.html, alter the default files that you downloaded in Step 1 and import them as you did in Step 3. All five sets of Portal pages (default, CP1, CP2, CP3, and CP4) will then use the default files that you altered. These four files have only one version. See Figure 59.

Figure 59: Captive Portal HTML Pages (maximum)

Next, tell FortiWLC (SD) which custom files to use under what circumstances. Either Implement New Custom HTML Files Using the CLI or Implement New Custom HTML Files Using the GUI.

Implement New Custom HTML Files Using the CLI

Implement custom Captive Portal pages with the CLI by indicating which subset of users should see the new login and success pages; when a user logs in from this subnet, they will see the corresponding custom pages. You can implement up to two sets of Captive Portal pages at a time. For example, students in a library might see the Custom Captive Portal 1 login and success pages while visitors to the football stadium see the Custom Captive Portal 2 login and success pages. See Figure 59.

Determine who will see which pages. Point to two custom Captive Portal pages with the CLI command web custom CaptivePortal[1|2] landing-file-name <landing.html> success-file-name <success.html>. Then, point to the network or subnet for the custom captive portal pages with web custom CaptivePortal[1|2] subnet <x.x.x.x> mask <x.x.x.x>. For example:

MC3K‐1# configure terminal MC3K‐1(config)# web custom ?

CaptivePortal1         Custom configuration for captive portal 1

CaptivePortal2         (10) Custom configurations for captive portal2.

CaptivePortal3         (10) Custom configurations for captive portal3.

CaptivePortal4         (10) Custom configurations for captive portal4.MC3K‐

1(config)# web custom captiveportal2 ? landing‐file‐name subnet

MC3K‐1(config)# web custom CaptivePortal1 landing‐file‐name landing.html success‐file‐name success.html

MC3K‐1 (config) web custom CaptivePortal1 subnet 1.1.1.0 mask 255.255.255.0

MC3K‐1(config)# exit

MC3K‐1# show web ?

custom                 Displays IP range for captive portal custom mode. custom‐area            Lists the files in the custom area for web‐auth and captive portal.

login‐page             Displays the type of login page used for web‐auth and captive portal.

MC3K‐1# show web custom‐area

Html Files total 16

‐rw‐rw‐rw‐    1 root     root         2607 Jul 13 16:26 page2OK.html

‐rw‐rw‐rw‐    1 root     root         4412 Jul 13 16:26 page2LOGIN.html

‐rwx‐‐‐‐‐‐    1 root     root         2607 Jul 13 16:04 auth_web_ok.html

‐rw‐rw‐rw‐    1 root     root         4412 Jul 13 16:04 loginformWebAuth.html

‐rwx‐‐‐‐‐‐    1 root     root            0 Jun 30 00:31 empty.html

Image Files total 9

‐rwx‐‐‐‐‐‐    1 root     root            0 Jun 30 00:31 empty.gif

‐rw‐rw‐rw‐    1 root     root         8574 Oct 29  2008 Sample.jpg

MC3K‐1# show web login‐page custom

Implement New Custom HTML Files Using the GUI

Implement custom Captive Portal pages with Web UI by first directing Captive Portal to use custom HTML files; those HTML files will then reference the CSS, JS and graphic files you imported. Second, indicate which subset of users should see the new login and success pages by providing a subnet and a mask; when a user logs in from this subnet, they will see the corresponding custom pages. For example, students in a library might see the Custom Captive Portal 1 login page while visitors to the football stadium see the Custom Captive Portal 2 login page.

Direct Captive Portal to use custom HTML files by following these steps:

1. Click Maintenance > Customization > select a controller > Change Mode 2. Scroll down and select Customized.

indicate which subset of users should see the custom pages by following these steps:

1. Make sure that security logging is set to on by clicking Configuration > Security > Profile and then selecting a security profile from the list. The security logging setting is near the bottom of the Security Profile Table. This setting must be set to on for Captive Portal configuration to work.
2. Click Maintenance > Captive Portal > Custom CP. The Custom Captive Portal page is displayed.

Figure 60: Custom Captive Portal Page

3. Provide the names of the new HTML Login Page and Success Page for CP1. Since they are on the controller now, you do not have to indicate a location. Click Save Page Info.
4. Provide at least one subnet location by clicking Add, providing a Subnet IP and a Network Mask, then clicking OK. Users logging in from this subnet will see these custom pages.
5. Create a corresponding Security Profile for this portal by clicking Configuration > Security > Profile > Add. Be sure that the setting for Captive Portal is set to webauth in this profile, then save it.
6. Click Configuration > Security > Captive Portal. In this window, identify the RADIUS server, whether or not to adjust the session, and idle timeouts. Session timeout and idle timeout are indicated in minutes.

The L3 User Session Timeout field is used for specific clients that have issues in which they get deauthenticated upon entering sleep mode. This field specifies that the controller will retain these clients in memory for the specified number of minutes before the client is dropped from the captive portal authentication state.

7. Click OK.

The custom HTML files are now configured. You can configure up to four sets of custom files, Captive Portal 1, Captive Portal 2, Captive Portal 3, and Captive Portal 4; or, you can use the default files. See Figure 59.

Configure Captive Portal with the CLI

• radius-profile defines the primary and secondary Captive Portal authentication servers.
• accounting-radius-profile defines the primary and secondary Captive Portal accounting servers.
• captive-portal > activity-timeout determines one timeout value. If a client is idle for this many minutes, the client is asked to reauthenticate. captive-portal > session-timeout determines one timeout value. If a client session lasts this long (minutes), the client is asked to reauthenticate.
• change_mac_state
• ssl-server captive-portal-external-URL directs Captive Portal to use a third-party solution located at the named URL.
• captive-portal-auth-method sets authentication to internal (default for Fortinet) or external for third-party solutions.

Captive Portal CLI Examples

This example configures Captive Portal with the CLI by completing these tasks:

• Create a guest user ID (Guest) and password.
• Enter the service start time (01/01/2010 00:00:00).
• Enter the service end time (01/01/2011 00:00:00).
• Show the Captive Portal.

MC3K‐1(config)# guest‐user ?

<guestname> Enter the name of the guest user.

MC3K‐1(config)# guest‐user Guest ?

<password> Enter the password of the guest user.

MC3K‐1(config)# guest‐user Guest XXXXX ?

<start‐time> Enter the service start‐time (mm/dd/yyyy hh:mm:ss) in double quotes.

MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” ?

<end‐time> Enter service end‐time (mm/dd/yyyy hh:mm:ss) in double quotes. MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” “01/01/2011 00:00:00” ?

<CR>

MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” “01/01/2011

00:00:00″

MC3K‐1(config)# exit

MC3K‐1#

MC3K‐1# show guest‐user

Guest User  Name Service Start Time              Service End Time               

Guest 01/01/2010 00:00:00             01/01/2011 00:00:00            

        Guest User Table(1 entry)

The commands in this section show how to configure Captive Portal. The RADIUS server user configuration is performed separately, and is vendor-specific. (Check the Customer Service website for applicable Application Notes.) The Microsoft Internet Explorer and Netscape 7 browsers are both supported for the client application.

1. Create the Security Profile for the WebAuth Captive Portal:

default# configure terminal default(config)# security-profile web_auth default(config‐security)# captive‐portal webauth default(config‐security)# exit default(config)# exit

2. Bind the web_auth Security Profile to an ESSID:

default# configure terminal default(config)# essid WebAuth-meru-WIFI default(config‐essid)# security-profile web_auth default(config‐essid)# exit

3. Set the SSL server to use the primary RADIUS authentication server profile:

default(config)# ssl-server radius-profile primary main-auth default(config)# end

4. Save the configuration:

default(config)# copy running‐config startup‐config

When users are authenticated, they can be moved into a corporate VLAN, and can have QosRules applied to their session. Each user will have a supplied default session timeout, which if nothing is supplied, will be the default of 33 minutes. If a user disconnects and connects back to same SSID on the same controller within 60 seconds, no re-authentication will be required.The session time returned from the RADIUS server takes priority. If the RADIUS server doesn’t return the session time, configured values are used.

Create Captive Portal Guest User IDs Locally

For authentication purposes, you can set up guest user IDs instead of using RADIUS authentication. (This is also a backup for RADIUS authentication; if RADIUS fails, this list is then used.) Releases 3.6 and later support user IDs. Be sure that the field Captive Portal Authentication is set as Local when using Guest IDs (click Configuration > Security > Captive Portal).

The guest user features of both releases are as follows.

CLI Example – Create Guest User ID

This CLI example creates the guest user named Guest:

MC3K‐1 configure terminal

MC3K‐1(config)# guest‐user ?

<guestname>            Enter the name of the guest user.

MC3K‐1(config)# guest‐user Guest ?

<password>             Enter the password of the guest user.

MC3K‐1(config)# guest‐user Guest XXXXX ?

<start‐time>           Enter the service start‐time (mm/dd/yyyy hh:mm:ss) in double quotes.

MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” ?

<end‐time>             Enter service end‐time (mm/dd/yyyy hh:mm:ss) in double quotes.

MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” “01/01/2011 00:00:00” ?

<CR>

MC3K‐1(config)# guest‐user Guest XXXXX “01/01/2010 00:00:00” “01/01/2011

00:00:00″

MC3K‐1(config)# exit

MC3K‐1#

MC3K‐1# show guest‐user

Guest User Name Service Start TimeService End Time         

Guest 01/01/2010 00:00:00 01/01/2011 00:00:00            

        Guest User Table(1 entry) MC3K‐1#

There is an additional option for Local Authentication so that when local authentication for a

Captive Portal user fails, RADIUS authentication is automatically checked; this option is called Local and RADIUS. From the Web UI, configure this by clicking Configuration > Security > Captive Portal.

Figure 61: Local Captive Portal Authentication Has Two Options

The corresponding CLI command ssl-server captive-portal authentication-type configures the controller to use both local and RADIUS authentication.

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.

Optionally Configure Pre-Authentication Captive Portal Bypass

Not all users or traffic types need to be authorized and authenticated by Captive Portal; users of VPN software can pass through the portal without authentication. To enable this passthrough firewall filter ID, follow these steps:

1. Click Configuration > Security > Profile.
2. Enter the name of the Passthrough Firewall Filter ID.
3. Click Configuration > QoS > System Settings to see the QosRule section of the Configuration menu (a license for PPF is required to enter the passthrough rules).
4. Add a rule. Remember that rules are stored in the order they are entered and can not be modified once they are entered.
5. At the bottom of the screen enter the QoS Filter ID.

The last entry in the filter should be a rule that drops all other traffic, so that traffic other than the passthrough will not be allowed to transverse the Captive Portal without authentication.

Bypass Apple Captive Network Assistant (CNA)

You can bypass or disable the CNA. When enabled, the auto-login pop-up is not displayed in a captive portal authentication (in tunneled mode) using an Apple device or Android devices running Android 5.0 or later.

Using GUI

To enable CNA bypass, Go to Configuration > Captive Portal > Advanced Settings section and select ON for Bypass Apple CNA.

Using CLI

Use the cna‐bypass option in the ssl‐server command to enable or disable CNA bypass.

mc3200(15)# configure terminal master(15)(config)# ssl‐server cna‐bypass on master(15)(config)# exit master(15)# sh ssl‐server

Captive Portal

Name                                         : Captive Portal

Server Port                                  : 10101

User Authentication Protocol                 : None

Server Lifetime                              : 100

Server IP                                    : 172.18.34.177

Certificate                                  :

Authentication Type                          : radius

Primary Profile                              :

Secondary Profile                            :

Primary Profile                              :

Secondary Profile                            :

Accounting Interim Interval (seconds)        : 60

CaptivePortalSessionTimeout                  : 0

CaptivePortalActivityTimeout                 : 0 Protocol                                     : https

Portal URL                                   : CaptivePortal External URL                   :

CaptivePortal External IP                    : 172.18.34.177

L3 User Session Timeout(mins)                : 1

Apple Captive Network Assistant (CNA) Bypass : on

Captive Portal With N+1

Captive Portal changes are propagated in an Nplus1 environment as follows. When a slave takes over a master, it uses the master’s Captive Portal pages. If changes are made on that active slave, that change is not automatically propagated to the master.

Troubleshooting Captive Portal

• The same subnet should not be entered for both CaptivePortal1 and CaptivePortal2. If you do this, only the CaptivePortal1 configured splash page will be displayed.

Captive Portal With N+1

• Custom pages have to imported properly before making use of this feature. See “Optionally Customize and Use Your Own HTML Pages” on page 282.
• To check if the pages and images have been properly imported into the controller use the command show web custom-area
• To check if the imported page is coming up properly use the CLI https://<controller ip>/vpn/ <page Name>
• To ensure that Captive Portal authentication is taking place, look at the access-accept message from the RADIUS server during Captive Portal authentication.
• Even when using custom CP pages, four default HTML files are used; only two are actually customized. The only way to change this is to alter the four default files which are used for both CP1 and CP2.

Captive Portal Profiles

Captive portal profiles feature that allows you to create individual captive portal profiles with distinct configuration settings. Such captive portal profiles can be mapped to security profiles for fine control over captive portal user access.

A captive portal profile is created from the Configuration > Security > Captive Portal page. The Captive Portal Profile tab is used to specify the captive portal profile settings. Once created, this captive profile can be enabled in a security profile. The following screen-shots illustrate the process to create and assign a captive profile.

Captive Portal Profiles

1. Creating a Captive Portal Profile
2. Assigning a Captive Portal Profile to a Security Profile

Captive Portal Profiles

Captive Portal (CP) Authentication for Wired Clients

Wired clients connected via port profile (tunnelled and bridged) will require CP authentication to pass external traffic. Wired Clients can have CP Authentication with Security Profile configured with L2 mode in Clear profile or L2 mode in 802.1X Clear profile.

Supported access points: AP122, AP822v2, AP822, OAP832, AP832, AP332 (only supports G1/G2 port in mesh configuration), AP433 (only supports G1 port in mesh configuration), FAPU421EV, and FAP-U423EV

To allow wired clients to pass external traffic, do the following:

1. Create a captive portal (CP)profile
2. In the security profile, map the CP profile to the security profile. In the security profile ensure that at least one of the (802.1x, WebAuth, Mac Authentication, or CP Bypass) security option is enabled.
3. In the port profile, map the security profile to port profile

NOTES

Captive Portal (CP) Authentication for Wired Clients

• CP authentication is available only when VLAN trunk is disabled.
• Dynamic VLAN is not supported.\
• Wired clients connected to a leaf AP should be in bridge mode port profile.
• Re-authentication will fail, If the Ethernet cable is disconnected and reconnected from the wired client’s port.

Station log for wired client

2015‐Dec‐2 14:31:55.075109 | 08:9e:01:28:64:25 | Station Assign | wired Assigned to <AP_ID=2>(v0)

CP Bypass for MAC Authenticated Clients

Wired and wireless clients that are successfully authenticated by their MAC address (MAC Filtering) are considered as captive portal authenticated clients. Both RADIUS-based MAC filtering and local MAC filtering is supported for CP bypass. However, to intentionally block a client, add its MAC address only to the local ACL deny list.

To bypass CP authentication, do the following in a security profile:

1. Enable Captive Portal and MAC Filtering in the same security profile. 2. Enable the “Captive Portal Bypass For MAC Authentication”
2. Use this security profile for the ESSID.

NOTES

• Captive Portal must be enabled.
• If MAC-filtering authentication fails then the client is redirected for Web Authentication

CP Bypass for MAC Authenticated Clients

Configuring using CLI

Use the captive‐portal‐bypass‐mac command to enable or disable this functionality.

The following station logs provide information on client status:

Wireless Station: MAC-filtering Success and CP is bypassed:

2016‐May‐ 1 04:24:53.030415 | 00:73:8d:b9:e6:bf | Mac Filtering | Mac in permit list ‐ accept client

2016‐May‐ 1 04:24:53.030895 | 00:73:8d:b9:e6:bf | Mac Filtering | Mac‐Filtering is Success and Captive Portal is Bypassed for Wireless Client <00:73:8d:b9:e6:bf>

CP Bypass for MAC Authenticated Clients

Wired Station: MAC-filtering Success and CP is bypassed:

2016‐May‐ 1 04:38:06.888828 | f0:1f:af:33:cd:4e | Mac Filtering | Mac in permit list ‐ accept client

2016‐May‐ 1 04:38:06.890213 | f0:1f:af:33:cd:4e | Mac Filtering | Mac‐Filtering is Success and Captive Portal is Bypassed for Wired Client <f0:1f:af:33:cd:4e>

The following flowchart illustrates the flow of CP bypass for MAC authenticated clients.

Third-Party Captive Portal Solutions

Instead of using the Fortinet Captive Portal solution, you can use a third-party solution; you cannot use both. Companies such as Bradford, Avenda, and CloudPath all provide Captive Portal solutions that work with FortiWLC (SD) 4.1 and later. There are two places that you need to indicate a third-party captive portal solution, in the corresponding Security Profile and in the Captive Portal configuration.

Configure Third-Party Captive Portal With the Web UI

Indicate that a third-party Captive Portal solution will be used in the Security Profile by setting Captive Portal Authentication Method to external. For complete directions, see Configure a Security Profile With the Web UI.

Indicate that a third-party Captive Portal solution will be used in the Captive Portal configuration by setting Captive Portal External URL to the URL of the Captive Portal box:

Third-Party Captive Portal Solutions

1. Click Configuration > Security > Captive Portal.
2. Change the value for CaptivePortal External URL to the URL of the third-party box.
3. Click OK.

Configure Third-Party Captive Portal With the CLI

Configure an SSL server before configuring third-party captive portal in the security profile. For example, example of SSL server configuration:

controller1# show ssl‐server Captive Portal

Name                                         : Captive Portal

Server Port                                  : 10101

User Authentication Protocol                 : None

Server Lifetime                              : 100

Server IP                                    : 172.18.37.223

Certificate                                  :

Authentication Type                          : radius Primary Profile                              : IDAU1721946201

Secondary Profile                            :

Primary Profile                              : IDAC1721946201 Secondary Profile                            :

Accounting Interim Interval (seconds)        : 60

CaptivePortalSessionTimeout                  : 0 CaptivePortalActivityTimeout                 : 0 Protocol                                     : https

Portal URL                                   :

CaptivePortal External URL                   : https://172.19.46.201/portal/

172.18.37.223?meruInitialRedirect

CaptivePortal External IP                    : 172.18.37.223

L3 User Session Timeout(mins)                : 1

Apple Captive Network Assistant (CNA) Bypass : on Example of configuring SSID with external captive portal:

controller1# configure terminal  controller1(config)# security‐profile CPExternal

controller1(config‐security)# captive‐portal‐auth‐method external controller1(config‐security)# passthrough‐firewall‐filter‐id IDMAUTH controller1(config)# essid CaptivePortal‐External

controller1(config‐essid)# security‐profile CaptivePortal‐External controller1(config‐essid)# end

Third-Party Captive Portal Solutions