Multiple ESSID Mapping

The following configuration example shows how to create three ESSIDs and map them to three different VLANs to separate guest users, corporate users, and retail traffic.

The first ESSID, guest-users, is mapped to a VLAN named guest. This ESSID is configured to use the default security profile, which requires no authentication method or encryption method. The VLAN IP address is 10.1.1.2/24 with a default gateway of 10.1.1.1. The DHCP server IP address is 10.1.1.254. This ESSID is configured so that it is added to each access point automatically and is also part of a Virtual Cell. (All access points on the same channel with this ESSID share the same BSSID.)

The second ESSID, corp-users, is mapped to a VLAN named corp. This ESSID is configured to use a security profile called corp-access, which requires 64-bit WEP for an  authentication/ encryption method. The static WEP key is set to corp1. The VLAN IP address is 10.1.2.2/24 with a default gateway of 10.1.2.1. The DHCP server IP address is 10.1.2.254. This ESSID is configured so that it is added to each AP automatically and is also part of a Virtual Cell.

The third ESSID, retail-users, is mapped to a VLAN named retail. This ESSID is configured to use a security profile called retail-access, which requires 802.1X as an authentication method.

Multiple ESSID Mapping

The 802.1X rekey period is set to 1000 seconds. The primary RADIUS server IP address is set to 10.1.3.200, the primary RADIUS port is set to 1812, and the primary RADIUS secret is set to secure-retail. The VLAN IP address is set to 10.1.3.2/24 with a default gateway of 10.1.3.1. The DHCP server IP address is 10.1.3.254. This ESSID is configured so that it is added to the access point with node id 1 only. Also, the broadcasting of this ESSID value in the beacons from the access point is disabled, and the ESS is given a BSSID of 00:0c:e6:02:7c:84.

Use the show vlan command to verify the VLAN configuration:

controller# show vlan

VLAN Configuration

VLAN Name   Tag  IP Address      NetMask          Default Gateway guest       1    10.1.1.2        255.255.255.0    10.1.1.1        corp        2    10.1.2.2        255.255.255.0    10.1.2.1        retail      3    10.1.3.2        255.255.255.0    10.1.3.1

Now that the VLANs and security profiles have been created, the new ESSIDs can be created and configured.

controller# configure terminal controller(config)# essid guest-users controller(config‐essid)# security-profile default controller(config‐essid)# vlan guest controller(config‐essid)# exit controller(config)# essid corp-users

controller(config‐essid)# security-profile corp-access controller(config‐essid)# vlan corp controller(config‐essid)# exit controller(config)# essid retail-users

controller(config‐essid)# security-profile retail-access controller(config‐essid)# vlan retail controller(config‐essid)# no ap-discovery join-ess controller(config‐essid)# no publish-essid controller(config‐essid)# ess-ap 1 1 controller(config‐essid‐ess‐ap)# bssid 00:0c:e6:03:f9:a4 controller(config‐essid‐ess‐ap)# exit controller(config‐essid)# exit controller(config)# exit controller#

To verify the creation of the new ESSIDs, use the show essid command.

To view detailed configuration for each of the new ESSIDs, use the show essid essid-name command.

Multiple ESSID Mapping

To verify that the guest-users and corp-users ESSIDs were automatically joined to both access points connected to the controller and that the retail-users ESSID was only joined to

AP 1, use the show ess-ap ap ap-node-id or the show ess-ap essid essid-name commands.

controller# show ess-ap ap 1

ESS‐AP Configuration

AP ID: 1

ESSID                   AP Name        Channel  BSSID guest‐users             AP‐1            6       00:0c:e6:01:d5:c1 corp‐users              AP‐1            6       00:0c:e6:02:eb:b5 retail‐users            AP‐1            6       00:0c:e6:03:f9:a4

controller# show ess-ap ap 2

ESS‐AP Configuration

AP ID: 2

ESSID                   AP Name        Channel  BSSID guest‐users             AP‐2            6       00:0c:e6:01:d5:c1 corp‐users              AP‐2            6       00:0c:e6:02:eb:b5 controller# show ess-ap essid retail-users

ESS‐AP Configuration

ESSID: retail‐users

AP ID   AP Name        Channel  BSSID

1       AP‐1            6       00:0c:e6:03:f9:a4 controller# show ess-ap essid corp-users

ESS‐AP Configuration

ESSID: corp‐users

AP ID   AP Name        Channel  BSSID

• AP‐1 6       00:0c:e6:02:eb:b5
• AP‐2 6       00:0c:e6:02:eb:b5

Bridged AP300 in a Remote Location

When bridged mode is configured in an ESSID, an AP using that ESSID can be installed and managed at a location separated from the controller by a WAN or ISP, for example at a satellite office. The controller monitors remote APs with a keep‐alive signal. Remote APs exchange control information, including authentication and accounting information, with the controller but cannot exchange data. Remote APs exchange data with other APs within their subnet.

Because Remote APs cannot exchange data-plane traffic (including DHCP) with the controller, certain Fortinet Wireless LAN features are not available for remote AP configurations. These include:

• QoS
• Captive Portal
• L3 mobility

The features that are available are:

Multiple ESSID Mapping

• VLAN
• Virtual Cell
• 1X authentication
• High user density
• Multiple ESSIDs
• Dataplane encryption for backhoe on L3 tunnel

Configure Bridged Mode with the Web UI

Configure bridged mode when you add or modify an ESS with the Web UI; for directions, see “Add an ESS with the Web UI” on page 137.

Configure Bridged Mode with the CLI

This example creates the ESSID abcjk, sets its mode to bridged, assigns a tag, and then gives top priority to abcjk.

test (config‐essid)# test# configure terminal test (config)# essid abcjk

test (config‐essid)# dataplane bridged test (config‐essid)# ap‐vlan‐tag 11 test (config‐essid)# ap‐vlan‐priority test (config‐essid)# end

For details of the commands used here, see the Command Reference Guide.

Utilizing Multiple IPs on a Single MAC

In current implementations, a typical client machine (or station) is granted a single IP Address per wireless adapter in use. However, with the growing use of Virtual Machine models (provided by VMware, Parallels, etc.), a single station can run multiple Operating Systems from a single client. With this release of Fortinet FortiWLC (SD), each Virtual Machine can now be provided with an individual IP Address, making it much easier to troubleshoot packet transmissions.

To support this function, the FortiWLC (SD) ESS Profile screen has a new function labeled MIPS, which is disabled by default. With this function enabled, packets are bridged across from the “host”, or main, Operating System to the “guest”, or virtual, system(s) as needed. The following notes apply:

• All data packets sent from the client will have the host OS MAC address as their source address.

Utilizing Multiple IPs on a Single MAC

• All data packets sent to the client will have the host OS MAC address as their destination address. Each OS has a different client hardware address that is transmitted as part of the DHCP payload. • “Guest” OS hardware devices have MAC addresses that start “00:0c:29”; this is the global standard OUI for VMware. This hardware address is used by the DHCP server to identify guest OSes, allowing them to be provided separate IP addresses.
• Grat ARP packets transmitted by any IP will have their corresponding unique client hardware addresses.
• All broadcast packets received by the host OS will also be delivered to the guest OS(es).
• All unicast packets received by the host OS will be delivered to the guest OS(es) based on the packets’ destination IP address.

In order to support this capability, a command has been added to the CLI:

• show station multiple-ip—Displays all IP addresses provided by each individual station along with MAC addresses (labeled ‘vmac’ for virtual devices). Note that for the host device, the Client MAC and Virtual MAC will be identical.
• IPv4 and IPv6 address types are supported.
• All IP addresses belonging to a single station are assumed to be part of the same VLAN.
• IP addresses provided to Virtual OSes are always dynamic; static addresses are not supported.
• ICR is not supported when this feature is enabled.

Time Based ESS

You can schedule the availability of an ESS based on pre-define time intervals. By default, ESS profiles are always ON and available to clients/devices. By adding a timer, you can control the availability of an ESS profile based on pre-defined times during a day or across multiple days.

To create a time based ESS profile, you must first create a timer profile and then associate the timer profile to the ESS profile.

Creating a Timer Profile

You can create timer profile using WebUI or CLI.

Time Based ESS

Using WebUI

Go to Configuration > Timer and click the Add button.

In the Add Timer Profile pop up window, enter Timer Profile Name and select Timer Type:

• Absolute timer profiles can enable and disable ESS visibility for time durations across multiple days. You can create up to 3 specific start and end time per timer profile. To enter start of the end time, click the Date picker box. See label 1 in figure 1.
• Periodic timer profiles are a set of start and end timestamp that can be applied across multiple days of a week. To create a period timer profile, enter the time in hh:mm format. Where hh, represent hours in 2-digits and mm represent minutes in 2-digits. Figure 2, illustrates a timer profile that will be applied on Sunday, Monday, Tuesday, and Thursday from 08:10 a.m. or 14:45 (2.45 p.m).

Time Based ESS

Using CLI

A new CLI command timer-profile with various options is available to create a timer profile.

Syntax

#(config‐mode) timer‐profile <profile‐name>

#(timer‐config‐mode) <timer‐type> <timer‐slot> start‐time <“mm/dd/yyyy hh:mm”> end‐time <“mm/dd/yyyy hh:mm”>

• timer‐type is either absolute‐timer or periodic timer
• Absolute timer profile allows creation of 3 timer slots.
• Time must be specified within double quotes in this format: mm/dd/yyyy <space> hh:mm

Example: Creating an absolute timer profile default# configure terminal default (config)# timer‐profile monthly‐access

default (config‐timer)# absolute‐timer time‐slot‐1 start‐time “01/01/2014 10:10” end‐time “02/02/2014 08:45”

Redundant Ethernet

When operating an MC1500, Ethernet redundancy can be enabled at any time by simply following the steps outlined in the following sections. However, for the following controller models enable dual port bonding before activating Ethernet redundancy:

• MC3200
• MC4200
• MC5000 (with accelerator card)
• MC6000

To enable dual bonding, enter the following commands and reboot the controller:

Redundant Ethernet

default# configure terminal default(config)# bonding dual default(config)# exit default# copy running‐config startup‐config

Configure Redundant Ethernet Failover With the CLI

The following commands configure Ethernet interface 2 on a controller as a backup to Ethernet interface 1:

default# configure terminal default(config)# interface FastEthernet 2 default(config‐if‐FastEth)# type redundant default(config‐if‐FastEth)# exit default(config)# exit

default# copy running‐config startup‐config

In the redundant configuration, the IP address for the second Ethernet interface cannot be configured. It will receive the IP address of the primary Ethernet interface when the failover occurs.

The system requires a reboot for the change to become effective. Reboot the system now, and then check the redundant second interface configuration with the show second_interface_status command: default# show second_interface_status

Recovering From Redundant Ethernet Failover

Once Dual Ethernet Redundant mode configuration is complete, the controller needs to be rebooted – see directions above. After the reboot, if the first Ethernet interface link goes down, then the second Ethernet interface takes over the controller connectivity. Redundant Ethernet failover is based on LinkID and does not require any spanning-tree configuration. When a LinkID is missing, the failover will occur in under one second. This failover will be transparent to the access points. The second interface remains active and serving all APs, even if the first interface comes up again. Verify this with the CLI command show second-interface-status. Only when the second interface goes down will the first interface (if it is up) take over the controller connectivity.

In hardware controllers bringing the switch port down will be detected as interface down and a link down alarm will be generated, rather in a virtual controller bringing the switch port down will not be detected as interface down and hence no link down alarm will be generated.

An alarm will be generated when the mapped interface in the VMWare client software is configured as disconnected.

When N+1 or L3 redundancy is also configured and controller 1 fails, the APs move to controller 2. When controller 1 comes back online, the APs immediately begin to move back to controller 2. Also see Recovering From N+1 with Dual Ethernet Failover.

Redundant Ethernet

N+1 Redundancy

The optional N+1 redundancy software feature, when implemented, allows a standby N+1 slave controller in the same subnet to monitor and seamlessly failover more than one master controller.

A set of master controllers and a standby slave controller are configured via static IP addressing to reside in the same subnet, and are considered to be an N+1 cluster. The standby slave monitors the availability of the master controllers in the cluster by receiving advertisement messages sent by the masters over a well known UDP port at expected intervals. If four successive advertisements are not received, the standby slave changes state to an active slave, assumes the IP address of the failed master, and takes over operations for the failed master. Because the standby slave already has a copy of the master’s latest saved configuration, all configured services continue with a short pause while the slave switches from standby to active state.

N+1 Fallback

While in the active slave role, the slave controller’s cluster monitoring activities are put on hold until the failed master rejoins the cluster. An active Slave detects the restart of a master through ARP. When the active slave is aware of the master’s return (via the advertisement message) it will continue to remain as active slave and the original master moves to passive state. The now passive master is assigned with original slave’s IP address. To move passive master to active master status, use the nplus1 revert command in active slave.

NP‐MC4200‐master(15)(config)# nplus1 revert

NP‐MC4200‐master(15)(config)# end

NP‐MC4200‐master(15)# sh nplus1

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

            Current State : Active‐>Passive Slave

         Heartbeat Period : 1000 milliseconds

      Heartbeat Threshold : 4 threshold

                Master IP : 172.19.215.31

          Master Hostname : NP‐MC4200‐master                  Slave IP : 172.19.215.32

           Slave Hostname : NP1‐MC4200‐slave              License Type : Demo

License Usage (Used/Tot) : 1/1

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

             Master Controllers

            Hostname       IP Address  Admin    Status

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

    NP‐MC4200‐master    172.19.215.31  Enable   Passive‐>Active

If it is necessary for the failed master to be off-line for a lengthy interval, the administrator can manually set the active slave back to the standby slave, thereby ensuring the standby slave is able to failover for another master.

Auto Fallback

After a failover, the passive master listens to advertisements (at time intervals specified using the nplus1 period command) from active slave. If the passive master does not receive advertisements from active slave within the time period the passive master initiates auto-fallback.

Auto Revert

When the master controller goes down, the slave controller takes over as active slave controller. When the master controller that was down became active, it continues to stay as passive controller till the nplus1 revert command is executed on the active slave controller. You can enable auto revert so that after the master controller come online, it takes over as the original master controller.

By default this option is disabled. To enable auto-revert, use the nplus1 autorevert enable command. By enabling auto revert; the active slave controller triggers a fallback by itself.

Failover Scenarios

In most cases with a cluster of N+1 Masters, the APs all have to be in L3 Connectivity mode, but if you only have one Master and one Slave unit (N=1) the APs can be in L3 only connectivity mode. However, if the APs are in L2 mode, then they will move to reboot after failover.

Heartbeat Period and Heartbeat Timeout Recommendations

Various factors in your network environment including latency can impact the N+1 failover. In networks with high latency, missing heartbeats between master and slave controller can trigger N+1 failover. We recommend that if your network experiences high latency, you should set the heartbeat period and heartbeat timeout to higher values.

The default heartbeat period is 1000ms and heartbeat timeout is 4 timeouts. Use the following commands to set high values:

# nplus1 timeout 40 # nplus1 period 100

The failure detection time (to initiate failover) is calculated as Heartbeat Period x Heartbeat Timeout.

Default timeout and period:

• Heartbeat Period (HP): Default 1000 ms, Range 100 – 30,000 (ms)
• Heartbeat Timeout (HT): The lost heartbeat threshold is the number of consecutive heartbeat packets. Default 4 timeouts, Range 4 – 60 (timeouts)
• Actual Failure Detection Time (AFDT) = HP (1000 ms) x HT (4) = 4000 ms = 4 Seconds

Preparing the Network

The N+1 cluster must be configured within a set of guidelines to operate as described in the previous section. While configuring your network for N+1 redundancy, the following guidelines must be followed:

• The following table lists the supported pairing (master and slave) of controller models in an N+1 cluster, with the MC series as the master.

• The following table lists the supported pairing (master and slave) of controller models in an N+1 cluster, with the FWC series as the master.

• All master and slave controllers must use static IP addressing to ensure consistency and control of N+1 clustering. (DHCP addresses are not supported for controllers participating in the N+1 cluster).
• Master and slave controllers must be on the same IP subnet.
• All APs in the network should be configured for Layer 3 connectivity with the controller.
• Spanning tree should be disabled on the switch port to which the controllers are connected. To disable spanning tree on the port, refer to your switch configuration documentation.
• Set same date and time on the master and slave controller. Mismatch in date and time between master and slave will result in incorrect AP uptime information after a failover. You can also configure NTP on the master to avoid incorrect AP uptime information.

Configuring the N+1 Clusters shows a simplified network diagram of a recommended N+1 deployment.

Figure 37: Example N+1 Redundancy Network Deployment

Configuring the N+1 Clusters

This can only be configured using the CLI and up to five masters and one slave. You will need passwords for all controllers involved in the N+1 configuration. A summary of the steps to configure and start N+1 follows:

Starting N+1 on Master Controllers

N+1 must first be started on the Master Controllers.

To configure a master controller:

1. On each master controller, enter configuration mode and start the N+1 software:

NP‐MC4200‐master(15)# configure terminal

NP‐MC4200‐master(15)(config)# nplus1 start master

2. Exit configuration mode and check that the N+1 software has been started on that controller:

NP‐MC4200‐master(15)(config)# exit

NP‐MC4200‐master(15)# sh nplus1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐Master controller

Master IP : 172.19.215.31

Master Hostname : NP‐MC4200‐master

Master Status : Active

Slave IP : 172.19.215.32 <– This is not displayed if Slave is not started

Slave Status : Passive <– This is displayed as Unknown if slave is not started

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

Configuring N+1 on the Slave Controller

After starting N+1 on each of the Master Controllers, start N+1 on the Slave Controller, and then add each Master Controller to the Slave Controller.

The Slave Controller must be the last controller in the cluster to start N+1. All Master Controllers must be added to the cluster before starting N+1 on the Slave Controller.

To configure N+1 on the slave controller, follow these steps:

1. Enter configuration mode and start the N+1 software:

NP1‐MC4200‐slave(15)# configure terminal

NP1‐MC4200‐slave(15)(config)# nplus1 start slave

Setting up this controller as a Passive Slave controller

2. Check that the software has started on the slave with the show nplus1 command (note that no masters display in the Master Controllers list):

NP1‐MC4200‐slave(15)(config)# show nplus1

Current State : Passive

Heartbeat Period : 1000 milliseconds

Heartbeat Threshold : 4 threshold Slave IP : 172.19.215.32

Slave Hostname : NP1‐MC4200‐slave

License Type : Demo

License Usage (Used/Tot) : 0/1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐        Master Controllers

Hostname  IP Address  Admin Status Switch  Reason Missed Adverts SW Version ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

3. Supply the hostname and IP address of each master controller in the cluster. You will be prompted for the controller’s password to complete the addition:

NP1‐MC4200‐slave(15)# configure terminal

NP1‐MC4200‐slave(15)(config)# nplus1 add NP‐MC4200‐master  172.19.215.31 admin@172.19.215.31 Password:

4. Exit configuration mode and check that the master controller has been enabled (the Admin status is now Enable):

NP1‐MC4200‐slave(15)#sh nplus1

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

            Current State : Passive

         Heartbeat Period : 1000 milliseconds

      Heartbeat Threshold : 4 threshold

                 Slave IP : 172.19.215.32

           Slave Hostname : NP1‐MC4200‐slave

             License Type : Demo

 License Usage (Used/Tot) : 1/1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐                       Master Controllers

                                                                                          Hostname   IP Address  Admin  Status Switch  Reason  MissedAdverts  SW Version

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

NP‐MC4200‐master 172.19.215.31  Enable  Active  Yes     ‐    0        6.1‐2‐15

Monitoring the N+1 Installation

The show nplus1 command allows you to check the current controller configuration and show the status of the controller. Some sample output displays are included to show the information displayed in the various controller states.

• N+1 on master—displays both basic master and slave controller identification information

NP‐MC4200‐master(15)# sh nplus1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐Master controller

Master IP : 172.19.215.31

Master Hostname : NP‐MC4200‐master

Master Status : Active

Slave IP : 172.19.215.32

Slave Status : Passive

• N+1 on a standby slave—basic slave controller identification information plus the status for the master control-lers in the cluster (accompanying table describes status fields)

NP1‐MC4200‐slave(15)#sh nplus1

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

            Current State : Passive

         Heartbeat Period : 1000 milliseconds

      Heartbeat Threshold : 4 threshold

                 Slave IP : 172.19.215.32

           Slave Hostname : NP1‐MC4200‐slave

             License Type : Demo

 License Usage (Used/Tot) : 1/1

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐                       Master Controllers

                                                                                          Hostname   IP Address  Admin  Status Switch  Reason  MissedAdverts  SW Version

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

NP‐MC4200‐master 172.19.215.31  Enable  Active  Yes     ‐    0        6.1‐2‐15 The descriptions of the display fields are provided in the following table:

• N+1 on an active slave—the master IP address, hostname, and status are added to the display. Passive status indicates the original master is UP, Down status indicates the original master is not reachable.

NP‐MC4200‐master(15)# sh nplus1

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

            Current State : Active Slave

         Heartbeat Period : 1000 milliseconds

      Heartbeat Threshold : 4 threshold

                Master IP : 172.19.215.31

          Master Hostname : NP‐MC4200‐master                  Slave IP : 172.19.215.32

           Slave Hostname : NP1‐MC4200‐slave

             License Type : Demo

 License Usage (Used/Tot) : 1/1

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

              Master Controllers

            Hostname       IP Address  Admin    Status

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

    NP‐MC4200‐master    172.19.215.31  Enable   Passive  

Managing the N+1 Installation

The tasks to manage an N+1 installation include:

• Syncing Running Configuration
• Disabling and Deleting N+1 Master Controllers
• Stopping N+1 Installations
• Replacing a Master Controller
• Working with N+1 Syslog

Syncing Running Configuration

Running configuration between master and slave are automatically synced every 30 minute.

Disabling and Deleting N+1 Master Controllers

To disable N+1 operation on a master controller, but still maintain its configuration in the cluster, from the slave controller, use the nplus1 disable command, with the IP address of the controller you are deleting:

NP1‐MC4200‐slave# configure terminal

NP1‐MC4200‐slave(config)# nplus1 disable 10.1.1.10 NP1‐MC4200‐slave(config)# end

To remove an N+1 master controller from the cluster, from the slave controller, use the nplus1 delete command, with the IP address of the controller you are deleting:

NP1‐MC4200‐slave# configure terminal

NP1‐MC4200‐slave(config)# nplus1 delete 10.1.1.10

NP1‐MC4200‐slave(config)# end

Stopping N+1 Installations

N+1 Slave and N+1 Master Controllers must be stopped separately.

Stopping N+1 Slave Controllers

To stop N+1 on a Slave Controller:

NP1‐MC4200‐slave# configure terminal

NP1‐MC4200‐slave(config)# nplus1 stop

Making this a normal controller.

NP1‐MC4200‐slave(config)# exit NP1‐MC4200‐slave#

Stopping N+1 Master Controllers To stop N+1 on a Master Controller:

3000‐1# configure terminal

3000‐1(config)# nplus1 stop

3000‐1(config)# exit

The following commands cannot be executed in an active slave controller and if executed on an active master, these commands will not trigger failover.

• poweroff controller
• reload
• reload default
• reload default factory

Replacing a Master Controller

To replace a a new master controller, do the following:

1. Power off the original master controller. The slave controller becomes the active controller.
2. Replace the new controller. Ensure that the new controller contains the same configuration for bonding, interface mode, and IP address(es) as the original master controller.
3. Run “nplus1 start master” command on the new controller in order to make this new controller the master controller.
4. Run “nplus1 slave <slave’s IP address>” command on the the new master controller in order to detect slave controller. The new master controller takes passive role.
5. Run “nplus1 access <slave’s IP address>” command on active slave controller in order to generate authorized key on the new passive master controller.
6. Then, copy the latest running configuration to the new passive master controller after executing the “nplus1 revert” command on the active slave controller

The the new active master controller automatically runs with the latest running configuration.

Working with N+1 Syslog

The show nplus1 debugloglevel command shows the level of verboseness set for the N+1 log messages.

NP1‐MC4200‐slave# sh nplus1 debugloglevel nplus1 Debug Logging Level: 0 NP1‐MC4200‐slave#

Setting the syslog Debug Level

The nplus1set debugloglevel command sets the level of verboseness for the N+1 log messages. The level can be set from 0 to 3, where 1 is the least verbose. The default 0 setting disables syslog messaging.

NP1‐MC4200‐slave(config)# nplus1 setdebugloglevel 1

N+1 Syslog Messages

Syslog messages are generated and sent to a log file on the syslog server configured with the syslog-host command. These message are sent by a standalone N+1 slave controller when an error condition occurs. A sample syslog message follows:

Oct 26 14:02:45 slave nplus1_Slave: <error message> The list of syslog messages are as follows:

Upgrading

Controllers in a N+1 network can be upgraded like any controller in a standalone deployment. However, only active master and standby slave controllers can be upgraded. Controllers in failover mode cannot be upgraded.

Recovering From N+1 Failover

When an N+1 master controller goes down, the slave controller transitions from passive slave to active slave (failover) and starts acting as the master controller. When the original master comes back up, the active slave continues to be active slave and the original master becomes passive master. The APs (if in L2 mode) will now reboot.

Recovering From N+1 with Dual Ethernet Failover

On the Master controller, when the first Ethernet interface goes down, the controller fails over to second interface of the same controller. If the second interface goes down, Nplus1 failover takes place and the N+1 passive slave becomes an active slave with Dual Ethernet redundant configuration.

The active slave is now in control. If the first active slave Ethernet interface goes down, the slave controller fails over to the second Ethernet interface.

To revert the failover, verify that the first interface on the Slave controller is up and running. Then, bring up the first interface of the original Master controller. The N+1 active slave continues to be active slave and the original N+1 master becomes passive.

Option 43

Option 43 is not part of any Fortinet product; it is a method for mapping controllers. With DHCP Option 43, you can specify a primary and backup controller for APs. With this configuration, the backup controller can be in a different subnet from the primary controller. Option 43 implements redundancy by specifying which controllers (primary and secondary) an AP should associate to. This feature is supported across all access points. A backup controller can be configured using either DHCP or DNS.

Option 43

For example, using Option 43, if “wlan-controller” is mapped to P1 (and P1 has a redirect to P2) and “wlan-controller-2” is mapped to S1 (and S1 has a redirect to S2), the discovery order would be P1, P2, S1, S2. If a controller has both a DNS entry and Option 43 enabled, the AP will first use the host address as configured on the AP (default value = wlan-controller). If the host address is configured as 0.0.0.0 or if the host is a name and the name cannot be resolved using DNS, only then will the AP look at the DHCP Option 43 value. For specific Option 43 configuration directions, see the Support Portal How-To 4062-125.

AP Aware Redundancy using DHCP Option 43

• Configure APs with L3 preferred and the controller name as 0.0.0.0
• On the DHCP server, Option 43 values need to be configured with primary and secondary controller IPs and/or hostnames. Then, when an AP contacts the DHCP server to obtain an IP address, it also receives primary and secondary controller IP information using the Option 43 value from the DHCP server.

AP Aware Redundancy using DNS

• Configure APs with L3 preferred and the controller name as the hostname of the controller.
• Configure a DNS entry to resolve the primary hostname on the DNS server. Configure a DNS entry to resolve the secondary hostname on the DNS server.
• Configure the hostname of the primary controller on the AP with L3 preferred mode.

Configuring Basic Networking for the Interface

Use the following commands to configure network parameters, if necessary:

• To change the parameters of the FastEthernet port, use the interface FastEthernet command.
• To set up a dynamic IP address assignment for the wireless clients using the DHCP relay server, use the ip dhcp-server ip-address command.
• To set the IP address of the controller, use the ip address ip-address netmask command.
• To set the default gateway, use the ip default-gateway ip-address command.
• To set the domain name, use the ip domainname name command.
• To add one or more DNS name servers, use the ip dns-server ip-address command.

For additional information about configuring network information, see the FortiWLC (SD) Getting Started Guide. For more information about the listed commands, see the FortiWLC (SD) Command Reference.

802.11d Support

The original 802.11 standard defined operation in only a few regulatory domains (countries). 802.11d added the ability for 802.11 WLAN equipment to operate in additional countries by advertising the country code in the beacon. Devices pick up the country code and adjust com-

Configuring Basic Networking for the Interface                                                                                                                      199

munication accordingly. You do not have to configure or enable this feature; the Fortinet implementation currently works automatically for all countries listed in setup. There is no show command that displays this feature. Validate 802.11d in the 802.11 Beacons and Probe Response, Country code IE field.

Dual-Ethernet Operation

Dual-Ethernet support enables the controller’s second Ethernet port and provides the ability for it to work either as a redundant interface or a second active interface.

If the second interface is configured as redundant, it will serve as a backup interface to the first interface. This means that it will be idle as long as the first interface is functional and will perform all functions of the first interface if the first interface fails. In a redundant configuration, the first interface can have static or DHCP IP address.

If the second interface is configured as active, it can be configured as a separate interface that can support an additional configuration, for example to support GRE tunneling while the first interface is configured for VLANs.

The first Ethernet interface is treated as the default interface. The responsibility of the default interface is to pass wireless tunnel traffic between the APs and the controller. In addition to the general support of GRE and VLAN, the default interface is also the designated management interface for the controller, providing support for management access traffic via SSH and HTTPS.

It is implicit in the configuration of redundant mode that the second Ethernet interface should be connected to a switch port in which it can perform the same functions as the default Ethernet interface.

Note that when changing from redundant to dual active operation, a controller reboot is required.

Configuring Dual Ethernet

The second Ethernet interface can be configured as either redundant or active. An active interface can be used to support a VLAN or GRE (Generic Routing Encapsulation) tunneling. A redundant interface is a backup interface in case the primary interface fails.

Dual-Ethernet Operation

Configuring a Redundant Interface

See the chapter Implementing Redundancy.

Configuring an Active Interface

The following commands configure Ethernet port 2 as an active interface that can be used to support a VLAN or GRE (Generic Routing Encapsulation) tunneling. The ip address specifies the IP address of the VLAN or GRE local endpoint followed by the associated netmask. The gw command specifies the gateway address, and is a mandatory field.

default# configure terminal default(config)# interface FastEthernet 2

default(config‐if‐FastEth)# ip address 172.26.16.200 255.0.0.0 default(config‐if‐FastEth)# gw 172.26.16.1 default(config‐if‐FastEth)# type active default(config‐if‐FastEth)# exit default(config)# exit

After completing the interface configuration above, to configure a GRE tunnel, see Configure GRE Tunnels in the Security chapter.

Viewing FastEthernet Interface Information

To view the FastEthernet interface 1 configuration, use the show interfaces FastEthernet controller or show interfaces FastEthernet ap commands to display information relating to each type of interface.

To view the FastEthernet interface 2 redundant configuration, use the command show second_interface_status.

Interface and Networking Commands

The following interface and networking configuration commands are available.

Dual-Ethernet Operation

TABLE 10: Interface and Networking Commands

Configuring Port Profiles

The Port Profile configuration screen allows you to create custom Ethernet profiles that can be applied to non-primary Ethernet ports on deployed devices. Certain AP models implement multiple Ethernet ports, and while one is always used for wireless service, the remaining ones can be configured by applying a Port Profile to them. If this functionality is not needed, the port can also be disabled via the Port Profile feature.

Each device that is connected to a non-primary port (either directly or through a switch that is wired to the port) can be monitored as a wired station in the controller WebUI (via Monitor > Devices > All Stations). If the interface is configured for tunneled operation and the connected device is a VoIP phone utilizing SIP, the phone will be visible as a SIP phone in the controller’s phone database. Note that the maximum number of wired stations supported per wired interface is 128.

Refer to the following sections for steps on how to configure and apply Port Profiles.

Creating a Port Profile

By default, a default Port Profile is configured in the controller interface. To view the existing Port Profiles, simply open the WebUI and navigate to Configuration > Wired > Port. See Figure 38.

Figure 38: Port Table

Several options can be configured as part of a Port Profile.

Configuring Port Profiles

The following table describes each field displayed.

TABLE 11: Port Profile Options

If desired, the default profile can be modified by checking the box alongside it in the table and clicking Settings. To add a new profile, perform the following steps:

1. From the WebUI, navigate to Configuration > Wired > Port.
2. Click Add. The screen refreshes to display the Port Table – Add page.
3. Configure the profile as desired. Refer to Table 11 for descriptions of the configuration options.
4. When finished, click OK to save the new profile.

Once a profile has been created, it can be applied to the desired port(s) on network devices.

Refer to the following section for instructions.

Enabling a Port Profile on a Specific Ethernet Port

To specify a port profile for a given Ethernet port, you must access the Port AP Table; from the Port Profile Table, select the desired profile and click Configuration. The Port AP Table is the second tab provided on the resulting screen.

By default, the Port AP Table is blank; you can manually add ports as desired. To add a port for the profile:

1. From the Port AP Table screen, click Add. The resulting table will allow you to select the AP and Interface ID to which the port profile will apply.
2. Use the drop-down lists to select the desired AP and Ethernet IDs. Note that if the Ethernet Interface Index specified is an Uplink interface (i.e., the interface is its primary connection to the network), it cannot be configured for a port profile and an error message will appear.
3. Click OK to save the changes.

These steps may be repeated for as many profiles as desired.

Enable 802.1x Authentication

Wired clients can be connected to the AP’s Wired Interface directly or can be connected via an L2 switch. In a deployment that uses L2 switch for multiple wired clients, the L2 switch must be configured to pass through 802.1x packets.

To enable 802.1 x authentication for wired clients, do the following:

1. Create a RADIUS profile and security profile (using 802.1x L2 authentication mechanism with Clear Encryption mode )
2. Attach the security profile to the respective port profile configuration.

Enabling using CLI

Create RADIUS Profile default(15)(config)# default(15)(config)# radius‐profile dot1xport default(15)(config‐radius)# ip‐address 10.10.10.10 default(15)(config‐radius)# key meru2002 default(15)(config‐radius)# port 1812 default(15)(config‐radius)# exit

Create Security Profile default(15)# configure terminal default(15)(config)# security‐profile dotxportauth default(15)(config‐security)# allowed‐l2‐modes 802.1x default(15)(config‐security)# encryption‐modes clear default(15)(config‐security)# radius‐server primary dot1xport

Configuring Port Profiles

default(15)(config‐security)# exit

Create Port Profile default(15)# configure terminal default(15)(config)# port‐profile dot1xauth default(15)(config‐port‐profile)# enable default(15)(config‐port‐profile)# dataplane tunnelled default(15)(config‐port‐profile)# security‐profile dot1xportauth default(15)(config‐port‐profile)# exit default(15)#

Enabling using WebUI

Create RADIUS Profile

Create Security Profile

Create Port Profile

Link Aggregation

Link aggregation allows data traffic across both Ethernet ports on AP resulting in increased throughput and redundancy. You can configure LACP only on the second interface of the AP. Before you configure LACP on the second interface of the AP, enable bonding on the switch that terminates AP. When configured for link aggregation, the second interface of the AP will inherit all properties of the first interface. When enabled, LACP is functional on both ports.

The second interface of the AP is disabled by default and when enabled it functions as the bonded pair to the first interface. The second interface cannot be used in standalone mode. However, when LACP is enabled and if one of the interfaces fails, the second interface takes over and passes traffic. During a failover, the second interface will function only if there is an external power supply or if the switch can provide only power via PoE.

Link aggregation is available only on AP832, AP822, FAP-U421, and FAP-U423. If the switch that terminates the AP does not support LACP, the AP will fall back to non-LACP mode with only one interface passing data traffic. Static bonding is not supported.

Pre-requisites

Before you enable LACP on the AP, ensure that you do the following

• Remove port AP entry from the port profile of that AP.
• Enable LACP support for the ports on the switch that terminates the AP.
• AP requires 802.3at power to support LACP.

NOTE: If the switch does not support LACP, the AP will work in non-LACP mode.

Link Aggregation

Enabling LACP in CLI

Use the lacp enable command on an AP’s ethernet interface to enable LACP.

controller(15)# config terminal controller(15)(config)# interface ap 108 2 controller(15)(config‐if‐WiredEth)# lacp enable

Verifying LACP Status

The Uplink Type and LACP column in the show interfaces ap <ap-id> command displays the status of LACP for an AP.

Controller(15)# show interfaces Ethernet ap 108

Type        ID  Name            IfIndex MTU     MAC Address       Admin State Op State  Last Change          Uplink Type LACP     

ap          108 AP‐108          1       1500    00:0c:e6:13:01:a9 Up          Disabled  05/19/2014 20:05:12  Uplink      disable  

ap          108 AP‐108          2       1500    00:0c:e6:13:01:a9 Up          Disabled  05/20/2014 23:51:48  Uplink‐lacp enable   

        Ethernet Table(2 entries)

For additional diagnostics, you can view the Tx and Rx errors of AP interface using the show interfaces Ethernet statistics <ap-ID> command.

Controller(15)# show interfaces Ethernet statistics ap 13

 IfIndex   Node ID Node Name       Type        In Octets     In Errors     Out Octets    Out Errors   

• 13 AP‐13           ap          78217745      0             4637677       0            
• 13 AP‐13           ap          0             0             0             0            

LACP      13      AP‐13           ap          78217745      0             4638109       0            

        Ethernet Statistics(3 entries)

Enabling LACP in WebUI

1. Goto Configuration > Devices > AP, select the AP.

Link Aggregation

2. Goto Ethernet Interface tab, and select the second Ethernet Interface and set LACP to Enable.

To batch enable LACP on multiple APs.

1. Goto Configuration > Wired > Ethernet, select all APs and click the Bulk Update button.
2. Set LACP to Enable.

Configuring Management Interfaces

The Management Interfaces table (Configuration > Devices > System Settings > Management Interfaces) allows the user to control how traffic is sent from the controller to the wireless network. Refer to the following sections for each tab in the table.

Physical Interfaces

The Physical Interfaces table is where the user may configure the IP information for the physical Ethernet ports on the controller. The number of ports that may be configured will vary depending on the controller model purchased.

Add a Physical Interface

To configure a new physical interface, follow the steps below:

1. From the Physical Interfaces table, click Add. The Management Interface-Add window appears.

Configuring Management Interfaces

Figure 39: Adding a Physical Interface

2. Add in the required data as described in the table below.

3. Click Save to save the interface. Note that the controller must be rebooted in order to apply the changes.

VLAN Interfaces

VLAN Interfaces allow the user to specify VLANs that are to be used specifically for Management traffic on the network. This traffic includes:

• Communications between the controller and APs or controller to controller Access to the WebUI or CLI

Configuring Management Interfaces

• SNMP traffic
• Communications to the Network Management server and any additional Fortinet applications (SAM, Spectrum Manager, etc)
• Syslog messages
• Authentication server traffic (RADIUS, TACACS+, etc)
• NTP communications

Using this functionality, users can isolate management traffic from the rest of the network and route it specifically to the devices for which it is intended. Follow the steps in the section below to create a VLAN interface.

Add a Management VLAN Interface

1. From the VLAN Interfaces table, click Add. The Management Interface-Add window appears.

Figure 40: Adding a VLAN Interface

2. Add in the required data as described in the table below.

Configuring Management Interfaces

3. Click Save to save the VLAN. The new VLAN will appear in the VLAN Interfaces table.

Using Static Routes

Static routes allow the system administrator to manually define the adapters that are permitted access to configured subnets. This is of particular use in smaller deployments where only a few routes are needed, or in larger ones where certain subnets must be kept separate from each other. Static routing can also be advantageous in that it doesn’t require the processing power that dynamic routes (in which the network router automatically determines the best delivery path for packets) can.

To view the static route table, access the WebUI and navigate to Configuration > Devices > System Settings > Management Interfaces > Static Route. Figure 41: Static Route Table

Adding a Static Route

To create a new static route, access the Static Route Table and click Add. The Static Route Configuration – Add screen appears.

Configuring Management Interfaces

Figure 42: Creating a Static Route

Provide the required details as described in the following table.

TABLE 12: Static Route Fields

Once the fields are filled in, click OK to save the route. Repeat this process for as many routes as desired.

Virtual Interfaces

When operating in L3 Routing mode, Virtual Interfaces can be configured in order to act in much the same way as the standard physical interfaces on a device: they can be assigned an IP (or range of IPs), subnet, and gateway, and can be used to isolate clients in their own pri-

Virtual Interfaces

vate IP range. Once a Virtual Interface is created, it can be mapped to a DHCP scope (see Feature Group) and an ESS in order to service clients.

To view the virtual interface table, access the WebUI and navigate to Configuration > Wired > Virtual Interface. Note that until at least one interface has been created, the table will be blank.

Adding a Virtual Interface

To create a new virtual interface, access the Virtual Interface Table and click Add. The Virtual Interface – Add screen appears. See Figure 43.

Figure 43: Creating a Virtual Interface

Provide the required details as described in the following table.

TABLE 13: Virtual Interface Fields

Once the fields are filled in, click OK to save the interface. Repeat this process for as many interfaces as desired. After the interfaces have been created, you can assign them a DHCP scope. Refer to Feature Group for further instructions.

Configuring Wireless LAN Security

In Wireless LAN System, Layer 2 and Layer 3 security options are enforced by creating Security Profiles that are assigned to an ESSID. As such, they can be tailored to the services and the structure (virtual Port, Virtual Cell, etc.) offered by the ESSID and propagated to the associated APs. Security profiles for a controller can also be configured from E(z)RF Network Manager. You can tell where a profile was configured by checking the read-only field Owner. The Owner is either E(z)RF or controller. The general security configuration tasks are as follows:

1. Create VLANs to keep the client traffic in each SSID secure and separate from clients in other SSIDs. See the chapter
2. Set up the Certificate Server or RADIUS server configuration (see the RADIUS server documentation for instructions).
3. Configure Security Profiles based on the type of security required (continue with the following sections).
4. Configure one or more ESSIDs (see the chapter Configuring an ESS for directions) and assign the VLAN and Security Profile to them.

Configure a Security Profile With the Web UI

To configure Security Profile parameters, follow these steps:

1. Click Configuration > Security > Profile.
2. In the Security Profile Name box, type the name of the security profile. The name can be up to 32 alphanumeric characters long and cannot contain spaces.
3. In the L2 Modes Allowed area, select one of the following Layer 2 security modes: Clear: The WLAN does not require authentication or encryption, and the WLAN does not secure client traffic. This is the default setting.
   • 1X: Can provide 802.1X authentication and WEP64 or WEP128 encryption.
   • Static WEP keys: Requires that stations use a WEP key (see step 6).
   • WPA2: Requires 802.1x RADIUS server authentication with one of the EAP types (see step 4 to select a pre-configured RADIUS server profile). For more information, see “WiFi Protected Access (WPA2)” on page 220. WPA2 PSK: Uses the CCMP-AES encryption protocol and requires a pre-shared key (see step 12 to enter the pre-shared key).
   • WPA2-TKIP
   • MIXED: Allows WPA2 clients using a single security profile.
   • MIXED PSK: Allows pre-shared key clients to use a single security profile.
   • WAI: Uses the WPI-SMS4 encryption protocol. WAI PSK: Uses the WPI-SMS4 encryption protocol and requires a shared key.
4. In the Data Encrypt area, select one of the following (available choices are determined by the L2 Mode selected):
   • Clear: The WLAN does not require encryption.
   • WEP64: A 64-bit WEP key is used to encrypt packets. For more information, see “WEP Security Features” on page 220.
   • WEP128: A 128-bit WEP key is used to encrypt packets. For more information, see “WEP Security Features” on page 220. CCMP-AES: A 128-bit block key is used to encrypt packets with WPA2. For more information, see “CCMP-AES” on page 220.
   • WPI-SMS4: Encryption algorithm used with WAI and WAI PSK.

Configure a Security Profile With the Web UI

If you select WEP64 or WEP128, you need to specify a WEP key, as described in step 6. If you specify CCMP-AES for WPA2-PSK, a pre-shared key must be set, as described in step 12.

5. From the Primary RADIUS Profile Name list, select one of the configured RADIUS Server Profiles for use as the primary server or select the No RADIUS option. If no RADIUS

Server Profiles have been configured, the selectable list is unavailable and the text “No Data for Primary RADIUS Profile Name” displays. To configure a RADIUS Server Profile, click Configuration > Security > RADIUS.

6. From the Secondary RADIUS Profile Name list, select one of the configured RADIUS Server Profiles for use as the secondary server or select the No RADIUS option. If no RADIUS Server Profiles have been configured, the selectable list is unavailable and the text “No Data for Primary RADIUS Profile Name” displays. To configure a RADIUS server profile, click Configuration > Security > RADIUS.
7. In the WEP Key box, specify a WEP key. If you selected Static WEP Keys in step 2, you need to specify a WEP key in hexadecimal or text string format.

A WEP64 key must be 5 octets long, which you can specify as 10 hexadecimal digits (the hexadecimal string must be preceded with 0x) or 5 printable alphanumeric characters (the ! character cannot be used). For example, 0x619B947A3D is a valid hexadecimal value, and wpass is a valid alphanumeric string.

A WEP128 key must be 13 octets long, which you can specify as 26 hexadecimal digits (the hexadecimal string must be preceded with 0x) or 13 printable alphanumeric characters (the ! character cannot be used). For example, 0xB58CE2C2C75D73B298A36CDA6A is a valid hexadecimal value, and mypass8Word71 is a valid alphanumeric string.

8. In the Static WEP Key Index box, type the index number to be used with the WEP key for encryption and decryption. A station can have up to four static WEP keys configured. The static WEP key index must be an integer between 1 through 4 (although internal mapping is performed to handle wireless clients that use 0 through 3 assignments).
9. In the Re-Key Period box, type the duration that the key is valid. Specify a value from 0 to 65,535 seconds. The default re-key value is zero (0). Specifying 0 indicates that re-keying is disabled, which means that the key is valid for the entire session, regardless of the duration.

10.In the BKSA Caching Period (seconds), the duration that the key is valid. Specify a value from 0 to 65,535 seconds. The default value is 43200.

11.In the Captive Portal list, select one of the following:

• Disabled: Disables Captive Portal.
• WebAuth: Enables a WebAuth Captive Portal. This feature can be set for all L2 Mode selections.

12.If you want to use a third-party Captive Portal solution from a company such as Bradford,

Avenda, or CloudPath change the value for Captive Portal Authentication Method to

Configure a Security Profile With the Web UI

external. For more information, see Captive Portal (CP) Authentication for Wired Clients.

13.To use 802.1X, select one of the following in the 802.1X Network Initiation list: • On: The controller initiates 802.1X authentication by sending an EAP-REQUEST packet to the client. By default, this feature is enabled.

• Off: The client sends an EAP-START packet to the controller to initiate 802.1X authentication. If you select this option, the controller cannot initiate 802.1X authentication.

14.Tunnel Termination: Tunnel-Termination is provided by IOSCLI and Controller GUI, to perform configuration on per-security profile basis. Select one of the following in the Tunnel Termination list:

• PEAP: PEAP (Protected Extensible Authentication Protocol) is a version of EAP, the authentication protocol used in wireless networks and Point-to-Point connections. It is designed to provide more secure authentication for 802.11 WLANs (wireless local area networks) that support 802.1X port access control. It authenticates the server with a public key certificate and carries the authentication in a secure Transport Layer Security (TLS)
• TTLS: TTLS (Tunneled Transport Layer Security) is a proposed wireless security protocol.

Note that when Tunnel Termination is enabled, Fortinet’s default certificate is used. In this case, the certificate must be “trusted” on the wireless client end in order for authentication to be successful. Refer to Security Certificates for details on how to import a certificate.

15.If the Static WEP Key mode is used, in the Shared Key Authentication list, select one of the following:

• On: Allows 802.1X shared key authentication. Off: Uses Open authentication. By default, this feature is off.

16.In the Pre-shared Key text box, enter the key if WPA2-PSK was selected in step 2 above. The key can be from 8 to 63 ASCII characters or 64 hex characters (hex keys must use the prefix “0x” or the key will not work).

17.In the Group Keying Interval text box, enter the time in seconds for the interval before a new group key is distributed.

18.In PMK Caching, select On or Off.

19.In the Key Rotation drop-down list, select whether to enable or disable this feature.

20.The timeout value for Backend Authentication Server Timeout can be 1-65535 seconds.  Configure a Security Profile With the Web UI

21.For Re-authentication, select one of the following: • On: Causes the controller to honor and enforce the “Session-timeout” RADIUS attribute that may be present in a RADIUS Access-Accept packet. A customer would use this option if the Session-timeout attribute is used to require stations to re-authenticate to the network (802.1X) at a specified period. If “Session-timeout” is not used, there is no reason to enable re-authentication.

• Off: Disables re-authentication for this security profile.

22.In the MAC Filtering list, select one of the following:

• On: Enables MAC Filtering for this security profile. Off: Disables MAC Filtering for this security profile.

23.In the MAC Auth Primary RADIUS Profile Name list, select the name of a previously configured authentication server profile.

24.In the MAC Auth Secondary RADIUS Profile Name list, select the name of a previously configured authentication server profile.

25.In the MAC Accounting Primary RADIUS Profile Name list, select the name of a previously configured RADIUS accounting server profile or the No RADIUS option.

26.In the MAC Accounting Secondary RADIUS Profile Name list, select the name of a previously configured RADIUS accounting server profile or the No RADIUS option.

27.In the Firewall Capability drop-down list, select one of the following: • Configured: The controller defines the policy through configuration of the Firewall filterid.

• RADIUS-configured: The RADIUS server provides the policy after successful 802.1X authentication of the user. This option requires the RADIUS server have the filter-id configured. If this is not configured, the firewall capability is not guaranteed.
• None: Disables the Firewall Capability for this security profile.

28.In the Firewall Filter ID text box, enter the firewall filter-id that is used for this security profile. The filter-id is an alphanumeric value that defines the firewall policy to be used on the controller, when the firewall capability is set to configured. For example, 1.

29.In the Security Logging drop-down list, select one of the following:

• On: Enables logging of security-related messages for this security profile.
• Off: Disables logging of security-related messages for this security profile

30.In the Passthrough Firewall Filter ID text box, enter a firewall filter ID that was created using Configuration > QoS > System Settings > QoS and Firewall Rules > Add. The filter ID is an alphanumeric value that defines the firewall policy to be used on the controller for a Captive Portal-enabled client that has no authentication.

31.Click OK.

Configure a Security Profile With the Web UI

Wi-Fi Protected Access (WPA2)

Fortinet Wireless LAN System supports both WPA2 and 802.1x protocols that have been presented by the Wi-Fi Alliance as interim security standards that improve upon the known vulnerabilities of WEP until the release of the 802.11i standard.

In WPA2, the WPA Message Integrity Code (MIC) algorithm is replaced by a message authentication code, CCMP, that is considered fully secure and the RC4 cipher is replaced by the Advanced Encryption Standard (AES), as described in “CCMP-AES” on page 220.

If 802.1X authentication is not available (in a SOHO, for example), WPA2-Personal can be implemented as alternatives and provide for manual key distribution between APs and clients.

To achieve a truly secure WPA2 implementation, the installation must be “pure,” that is, all APs and client devices are running WPA2-Enterprise. Implement this for Wireless LAN System with an ESS that uses a Security Profile that configures WPA2, leverages the site’s 802.1X user authentication and includes TKIP or CCMP encryption. Once associated with this profile, users and enterprises can be assured of a high level of data protection.

Encryption Support

Wireless LAN System offers CCMP-AES for WPA2. WPA2 uses CCMP/AES as encryption method. Descriptions of these technologies are provided in this section. Fortinet also supports the original 802.11encryption protocols provided by WEP64 and WEP128.

We recommend using the more secure CCMP-AES encryption solution if your site’s client hardware cannot support CCMP.

CCMP-AES

AES is the Advanced Encryption Standard and is used by the US Department of Defence as a replacement for older encryption standards. As such, it is very secure. AES can be used in several modes, and CCMP is the mode used by WPA2. Both terms are commonly used interchangeably.

WEP Security Features

Wired Equivalent Privacy (WEP64 and WEP128) is a Layer 2 security protocol specified in the IEEE Wireless Fidelity (Wi-Fi) standard, 802.11. WEP is designed to provide a wireless LAN with comparable level of security and privacy to what is usually expected of a wired LAN. A wired LAN is generally protected by physical security mechanisms, such as controlled access to a building, that are effective for a controlled physical environment. However, such security

Encryption Support

mechanisms do not apply to WLANs because the walls containing the network do not necessarily bind radio waves. WEP seeks to establish protection similar to that offered by the wired network’s physical security measures by encrypting data transmitted over the WLAN. Data encryption protects the vulnerable wireless link between clients and access points. Once this measure has been taken, other typical LAN security mechanisms such as authentication, password protection, and end-to-end encryption, can be put in place to protect privacy.

With the WEP protocol, all access points and client radio NICs on a particular wireless LAN must use the same encryption key. Each sending station encrypts the body of each frame with a WEP key before transmission, and the receiving station decrypts it using an identical key. This process reduces the risk of someone passively monitoring the transmission and gaining access to the information contained within the frames.

The WEP implementation allows the Security Profile configuration to specify one of four possible WEP keys that can be configured by a user station key management program.

Operation of the WEP Protocol

If a user activates WEP, the NIC encrypts the payload, which consists of the frame body and cyclic redundancy check (CRC), of each 802.11 frame before transmission using an RC4 stream cipher provided by RSA Security. The receiving station, such as an access point or another radio NIC, performs decryption when it receives the frame. As a result, 802.11 WEP only encrypts data between 802.11 stations. Once the frame enters the wired side of the network, such as between access points, WEP no longer applies.

As part of the encryption process, WEP prepares a key schedule (“seed”) by concatenating the shared secret key supplied by the user of the sending station with a randomly-generated 24-bit initialization vector (IV). The IV lengthens the life of the secret key because the station can change the IV for each frame transmission. WEP inputs the resulting “seed” into a pseudo-random number generator that produces a key stream equal to the length of the frame’s payload plus a 32-bit integrity check value (ICV).

The ICV is a checksum that the receiving station later recalculates and compares to the one sent by the sending station to determine whether the transmitted data underwent any form of tampering while in transit. In the case of a mismatch, the receiving station can reject the frame or flag the user for potential security violations.

With WEP, the sending and receiving stations use the same key for encryption and decryption. WEP specifies a shared 40- or 104-bit key to encrypt and decrypt data (once the 24-bit IV is added in, this matches FortiWLC (SD)’s 64- or 128-bit WEP specification, respectively). Each radio NIC and access point, therefore, must be manually configured with the same key.

Before transmission takes place, WEP combines the key stream with the payload and ICV through a bit-wise XOR process, which produces cipher text (encrypted data). WEP includes

Encryption Support

the IV in the clear (unencrypted) within the first few bytes of the frame body. The receiving station uses this IV along with the shared secret key supplied by the user of the receiving station to decrypt the payload portion of the frame body.

Limitations of the WEP Protocol

WEP is vulnerable because the relatively short IVs and keys remain static. Within a short amount of time, WEP eventually uses the same IV for different data packets. For a large busy network, the same IVs can be used within an hour or so. This results in the transmitted frames having key streams that are similar. If a hacker collects enough frames based on the same IV, the hacker can determine the shared values among them (the key stream or the shared secret key). This can allow to the hacker to decrypt any of the 802.11 frames.

A major underlying problem with the existing 802.11 standard is that the keys are cumbersome to change. The 802.11 standard does not provide any functions that support the exchange of keys between stations. To use different keys, an administrator must manually configure each access point and radio NIC with a new common key. If the WEP keys are not updated continuously, an unauthorized person with a sniffing tool can monitor your network and decode encrypted frames.

Despite the flaws, you should enable WEP as a minimum level of security. Many hackers are capable of detecting wireless LANs where WEP is not in use and then use a laptop to gain access to resources located on the associated network. By activating WEP, however, you can at least minimize this from happening. WEP does a good job of keeping most honest people out.

Configure GRE Tunnels

The GRE tunneling provides packet isolation from one endpoint to another, encapsulated within an IP tunnel to separate user traffic.

GRE Tunneling facilitates configurations as shown in Figure 44, where guest users who are logged into a guest ESS are given “guest” Internet access at Level 1 and have their traffic separated from corporate users who are on a common shared link to the corporate campus. Contract users have similar connection as corporate users but are restricted in access to certain sites by user firewall policies.

GRE tunneling provides an option to segregate users’ traffic by allowing an ESS profile to be tied to a GRE profile. This provides an alternative to VLANs for segregating traffic.

Configure GRE Tunnels

Figure 44: Example GRE Tunneling Configuration

To configure GRE tunneling, create the GRE tunnel profile as well as an ESSID that specifies the GRE tunnel and also references a Security Profile. GRE can also be configured from E(z)RF Network Manager.

All IP addresses configured for the tunnel must be unique; these IP addresses define the endpoints of the tunnel, with the controller FastEthernet IP address defining the local endpoint and the ip remote-external-address specifying the remote endpoint.The ip tunnel-ip-address defines the tunnel network.

If the GRE Tunnel is to be configured on the second interface of a Dual-Ethernet configuration, be sure to configure the second Ethernet interface, as described in the section “Configuring an Active Interface” on page 201”.

The following example shows the commands for configuring a GRE tunnel profile on the second FastEthernet interface, where the IP address of the tunnel’s local endpoint is 13.13.13.13 and the remote endpoint is 172.27.0.206, and the DHCP server is at 10.0.0.12:

default(config)# gre guest default(config‐gre)# interface FastEthernet controller 2 default(config‐gre)# ip tunnel‐ip‐address 13.13.13.13 255.255.255.0 default(config‐gre)# ip remote‐external‐address 172.27.0.206 default(config‐gre)# ip dhcp‐override    default(config‐gre)# ip dhcp‐server 10.0.0.12 default(config‐gre)# end

Configure GRE Tunnels

To check the configuration of the GRE tunnel, use the show gre command:

default# show gre

GRE Name   Remote External Address   Tunnel IP address   Tunnel IP Netmask

LocalExternal

vlan1      172.27.0.162               12.12.12.12          255.255.0.0

1

gre1       172.27.0.206               13.13.13.13          255.255.0.0

2

         GRE Configuration(2 entries)

To configure the GRE ESSID, specify the GRE profile name, a tunnel-type and Security Profile, as shown in the following example:

default(config)# essid guest default(config‐essid)# gre name guest default(config‐essid)# tunnel‐type gre default(config‐essid)# security‐profile default default(config)# exit

• The GRE ESSID name must be the same as the GRE Tunnel Profile name specified in the preceding GRE Configuration procedure (for example, guest). The GRE Tunnel Profile name is specified in the gre name.
• For the tunnel-type, the gre parameter must be specified for GRE Tunnel configuration.
• Specify the Security Profile name with the security-profile command—typically the default profile is used.

To check the status of the a GRE tunnel, use the command: default# test gre gre_name ip_address

where gre_name is the GRE Profile name and ip_address is the IP address of the machine that is connected behind the tunnel (optional).

The following points should be noted when configuring a GRE tunnel:

• The DHCP relay pass-through flag always should be off for a GRE tunnel. This ensures the

DHCP relay is always on and hence the DHCP request packets are forwarded to the DHCP Server specified by DHCP Server IP Address.

• DHCP traffic associated with users connecting to a GRE tunnel are relayed to the configured DHCP Server located at the remote location through the associated GRE tunnel.

Configure GRE Tunnels

• Only IPv4 support is provided for GRE tunneling.

Configure a Security Profile With the CLI

The controller supports the ability to define multiple Security Profiles that can be assigned to different wireless LAN extended service sets (ESS) according to the level and type of security required. A Security Profile is a list of parameters that define how security is handled within an ESS. With Security Profiles, you can define the Layer 2 security method, including the cipher suite, primary and secondary RADIUS server, static WEP key entries and key index position, and other parameters. The various Security Profiles you create allow you to support multiple authentication and encryption methods within the same WLAN infrastructure.

The controller is shipped with OPEN authentication, meaning that there is no authentication, and that any wireless client can connect to the controller. These setting are defined in the default Security Profile named default.

You can view the default Security Profile using the show security-profile default command.

default# show security-profile default

Security Profile Table

Security Profile Name                                  : default

L2 Modes Allowed                                       : clear

Data Encrypt                                           : none

Primary RADIUS Profile Name                            :

Secondary RADIUS Profile Name                          :

WEP Key (Alphanumeric/Hexadecimal)                     : *****

Static WEP Key Index                                   : 1

Re‐Key Period (seconds)                                : 0

Captive Portal                                         : disabled

802.1X Network Initiation                              : off

Tunnel Termination                                     : PEAP, TTLS

Shared Key Authentication                              : off

Pre‐shared Key (Alphanumeric/Hexadecimal)              : *****

Group Keying Interval (seconds)                        : 0

PMK Caching                                            : disabled

Key Rotation                                           : disabled

Reauthentication                                       : off MAC Filtering                                          : off

Firewall Capability                                    : none

Firewall Filter ID                                     :

Security Logging                                       : off

Passthrough Firewall Filter ID)                        :

The default Security Profile is configured to allow “clear” Layer 2 access with no authentication method, encryption, or cipher suite specified.

The Tunnel Termination is configured separately for PEAP and TTLS.

Configure 802.1X RADIUS Security With the CLI

To allow WLAN access to your site’s 802.1X authorized and authenticated users, set up 802.1X RADIUS authentication. To do this:

• Create a global RADIUS Server Profile that specifies how to communicate with the primary RADIUS server in your network. If an optional secondary RADIUS server is to be used, a separate profile is also created for it.
• Create a Security Profile for the ESS that configures 802.1X Layer 2 security and assigns a primary RADIUS profile and optional secondary RADIUS profile

Refer to your RADIUS server documentation regarding how to configure the type of EAP protocol for your site and the procedure for installing any necessary certificates. The actual RADIUS server configuration is not covered here, only the configuration for enabling the communication between the RADIUS server and the controller is described.

The following commands set up a profile for the primary RADIUS server, main-auth, that specify the server’s IP address and secret key. All other default parameters (such as the port number (1812)) are acceptable, and not changed:

default# configure terminal default(config)# radius‐profile main‐auth default(config‐radius)# ip-address 10.1.100.10 default(config‐radius)# key secure-secret default(config‐radius)# exit

For additional reliability, configure a secondary RADIUS Server Profile to serve as a backup should the primary server become unavailable.

default# configure terminal default(config)# radius‐profile backup‐auth default(config‐radius)# ip-address 10.1.100.2 default(config‐radius)# key secure-secret2 default(config‐radius)# exit

Next, create the Security Profile that enables 802.1X and points to the profiles that describe the RADIUS primary and secondary servers.

Example Security Profile with 802.1X RADIUS

In the following example, the Security Profile 8021x-data is created. It supports 802.1X authentication and uses the RADIUS profile main-auth to enable the primary RADIUS authentication server and the backup-auth profile for the secondary RADIUS server.

default(config)# security-profile 8021x-data default(config‐security)# allowed-l2-modes 802.1x default(config‐security)# radius‐server primary main‐auth default(config‐security)# radius‐server secondary backup‐auth default(config‐security)# exit default(config)# exit

802.1X PTK Rekey

With the 802.1X PTK rekey feature, whenever the rekey interval expires, the Access Point sends a unicast key and a broadcast key to the client. These two key packets are NOT encrypted.

To enable 802.1X PTK rekey, enter the following command from the Security Profile configuration: (n can be from 0 to 65535 (60 minutes), and is specified in seconds) default(config‐security)# rekey period n

To disable 802.1X PTK rekey, enter the following command from the Security Profile configuration:

default(config‐security)# rekey period 0

802.1X GTK Rekey

To configure the 802.1X GTK rekey period, from the Security Profile configuration, add the following command (the rekey period is specified in seconds): default(config‐security)# group-rekey interval n

To disable 802.1X GTK rekey, enter the following command from the Security Profile configuration:

default(config‐security)# no group-rekey interval

802.1X RADIUS Server Command Summary

The following commands are used to configure the RADIUS servers:

TABLE 14: Commands to Configure the 802.1X RADIUS Servers

TABLE 15: Commands Used to Create Security Profiles

TABLE 15: Commands Used to Create Security Profiles

Configure WPA2 With the CLI

The controller supports the WPA2 standard that includes CCMP encryption which is considered extremely secure. Implementing WPA2 provides the highest level of security that the Fortinet Wireless LAN System offers.

Additionally, if 802.1X is implemented at the site, automatic key exchange is provided by the RADIUS server. Existing primary and secondary RADIUS Server Profiles can be assigned from within the Security Profile to leverage the existing 802.1X authentication. Otherwise, the WPA2-PSK configuration can be implemented.

Example WPA2 Configuration

To configure WPA2 security with the Web UI, click Configuration > Security > Profile. Click Help for option details.

The following CLI example creates the profile named wpa2-ccmp that enables WPA2 for Layer 2, sets the encryption mode to CCMP-AES, and names the RADIUS server in the mainauth profile as the primary RADIUS authentication server.

default(config)# security-profile wpa2-ccmp default(config‐security)# allowed-l2-modes wpa2 default(config‐security)# encryption‐modes ccmp default(config‐security)# radius‐server primary main‐auth default(config‐security)# exit default(config)# exit

Example WPA2-PSK Configuration

To configure security with the Web UI, click Configuration > Security > Profile. Click Help for option details.

When setting the PSK key with the CLI, use a key from 8 to 63 ASCII characters (the characters ! \ ” ?  must be escaped with the backslash (\) character; for example \! \?) or 64 hex characters (hex keys must be prefixed with “0x” or the key will not work).

The following example creates the profile named wpa2-psk that enables WPA2-PSK for Layer 2, sets the encryption mode to CCMP, and sets the preshared key to theSecretKeyForNov28.

default(config)# security-profile wpa2-psk default(config‐security)# allowed-l2-modes wpa2-psk default(config‐security)# encryption‐modes ccmp default(config‐security)# psk key theSecretKeyForNov28 default(config‐security)# exit default(config)# exit

Opportunistic PMK Caching for WPA

Opportunistic PMK caching allows the controller, acting as the 802.1X authenticator, to cache the results of a full 802.1X authentication so that if a client roams to any AP associated with that controller, the wireless client needs to perform only the 4-way handshake and determine new pair-wise transient keys. PMK caching is supported only for KDDI phones when using WPA with TKIP and 802.1X authentication.

The system automatically detects the KDDI phone using the KDDI Vendor ID and applies PMK caching if available.

From with the Security Profile configuration, enable or disable PMK caching for KDDI phones. This option is only available when WPA is chosen for L2 encryption.

To enable PMK caching, add the following line to the WPA Security Profile configuration: default(config‐security)# pmkcaching enabled

To disable PMK caching, execute the following command at the WPA Security Profile configuration:

default(config‐security)# pmkcaching disabled

Configure 802.11 WEP Encryption

The controller supports two WEP cypher suites: WEP128 and WEP64.

The key configuration parameters allow the setting of the mutually shared key and the choice of key slot positions from 1 to 4, as allowed by most user key configuration programs.

Example 802.11 WEP Configuration

The following example creates the profile named wep- that supports a static 128-bit WEP encryption for  users. The static WEP key is defined as  and uses the third key index position on a user station’s WEP key definition.

default(config)# security-profile wepdefault(config‐security)# allowed-l2-modes wep default(config‐security)# encryption-modes wep128 default(config‐security)# static-wep key default(config‐security)# static-wep key-index 3 default(config‐security)# exit default(config)# exit default#

802.11 WEP Command Summary

The following summarizes the commands that can be used to configure 802.11 WEP security.

TABLE 16: Commands to Configure 802.11 WEP Security

Checking a CLI Configuration

To view all Security Profiles currently configured, use the show security-profile command.

# sh security‐profile

Profile Name                     L2 Mode        Data Encrypt Firewall Filter

default                          clear          none      captive‐portal                   clear          none         wep                              wep            wep64        802.1x                           802.1x         wep128        wpa                              wpa            tkip         wpapsk                           wpa‐psk        tkip         wpa2                             wpa2           ccmp         wpa2psk                          wpa2‐psk       ccmp        

        Security Profile Table(8)

To view the details of an individual Security Profile, use the show security-profile profile-name command.

default# show security-profile wpa-leap

Security Profile Table

Security Profile Name                                  : wpa‐leap

L2 Modes Allowed                                       : 802.1x

Data Encrypt                                           : none

Primary RADIUS Profile Name                            : ACS‐87‐8#

Secondary RADIUS Profile Name                          :

WEP Key ASCII:(default) 13 chars / 0x:26 chars         : *****

Static WEP Key Index                                   : 1

Re‐Key Period (seconds)                                : 0

Enable Multicast Re‐Key                                : off

Captive Portal                                         : disabled

802.1X Network Initiation                              : on

Tunnel Termination                                     : PEAP, TTLS

Shared Key Authentication                              : off

Pre‐shared Key (Alphanumeric/Hexadecimal)              : *****

Group Keying Interval (seconds)                        : 0

PMK Caching                                            : disabled

Key Rotation                                           : disabled

Reauthentication                                       : off MAC Filtering                                          : off

Firewall Capability                                    : none

Firewall Filter ID                                     :

Security Logging                                       : off

Use the commands show web login-page and show web custom-area to find out what set of web pages are used for Captive Portal and WebAuth.