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.

	RADIUS Server Setting disabled                        enabled
MAC Filtering disabled	no MAC filtering	RADIUS MAC filtering only
Permit ACL enabled	allow client in Permit list only	check Permit list first; if not in Permit list, check RADIUS server
Deny ACL enabled	Deny list used only	if not in Deny list, check RADIUS server

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.

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

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.

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

Command	Purpose
radius-profile name	Creates a RADIUS server profile with the specified name and enters RADIUS profile configuration submode (maximum 16 characters).
description text	Configures a description of the profile (maximum 128 characters).
ip-address ip-address	Configures the IP address of the RADIUS profile (required parameter).
key key	Specifies the shared secret text string used by the controller for the RADIUS profile (required parameter if password-type is shared-secret). Maximum 64 characters.
password-type shared-secret | macaddress	Specifies whether the password type is the RADIUS key (shared-secret) or is the MAC address of the client, as determined by the client setup in RADIUS for MAC Filtering configuration.
mac-delimiter colon | hyphen | singlehyphen | none	Optional. Sets the RADIUS profile delimiter character.
port port	Optional. Configures the RADIUS profile port (the default port 1812, is configured by default).
vlan vlan	Optional. Configures a VLAN for the RADIUS server. Use the command if the RADIUS server is located on a VLAN so that RADIUS requests are sent to the VLAN interface instead of default/untagged interface.
pmkcaching pmkcaching | disable	Enables or disables PMK caching.
rekey period n	Sets the PTK rekey period. The default is set to 60 seconds and the allowable range is 60 seconds to 60 minutes.
[no] group-rekey interval n	Sets the GTK group rekey period. The default is set to 60 seconds and the allowable range is 60 seconds to 60 minutes

TABLE 15: Commands Used to Create Security Profiles

Command	Purpose
allowed-l2-modes 802.1x	In Security Profile configuration, enables 802.1X authentication.

TABLE 15: Commands Used to Create Security Profiles

radius-server primary profile	In Security Profile configuration, specifies the RADIUS profile containing the configuration parameters for the primary RADIUS server.
radius-server secondary profile	Optional. In Security Profile configuration, specifies the RADIUS profile containing the configuration parameters for the secondary RADIUS server.
rekey multicast-enable	Optional. In Security Profile configuration, enable the multicast key broadcast.
[no] 8021x-network-initiation	In Security Profile configuration, determines 802.1X initiation method. When enabled (default), the AP sends the first EAP packet (an EAP ID request) to the wireless station to start 802.1X after the wireless station completes 802.11 authentication and association to an 802.1X-enabled ESSID. With the command no 8021x-network-initiation, the wireless station sends an EAPOL Start packet to the AP to start the 802.1X exchange.

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

Command	Purpose
encryption-modes wep128|wep64	Sets the cipher suite to WEP128, or WEP64 respectively.
static-wep key key	Sets the WEP key: •  For WEP64, also known as WEP or WEP40, the key is a 5-character ASCII (for example, 123de) or 10-character hex key (for example, 0x0123456789) (the 0x prefix must be entered). •  For WEP128, the key must be 13 ASCII characters or 26 hex digits (the 0x prefix must be entered).
static-wep key-index position	Sets which WEP key is in use. position can be set from 1 to 4.
allowed-l2-modes wep | clear	Enables or disables 802.11 WEP security. The clear option sets the mode to open.

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.

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.

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.

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.

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.