Category Archives: Administration Guides

FortiWLC – RADIUS Authentication

RADIUS Authentication

Conceptual 802.1X Model for RADIUS Authentication

The conceptual model for 802.1X authentication looks like this:

Figure 53: Conceptual Model for 802.1X RADIUS Server Authentication

802.1X RADIUS authentication works like this:

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

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

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

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

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

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

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

Indicate which ESS Profile should use the Security Profile.

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

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

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

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

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

802.1x                MAC Auth            Captive Portal

Y                            Y                              Y

RADIUS Disconnect

Y    x              Y CoA (Filter-ID)

Configure RADIUS Authentication for Administrators With the Web UI

Configure RADIUS authentication for all administrators by following these steps:

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

Figure 54: Configure a User for RADIUS Authentication

  1. Provide the IP address of the primary RADIUS server.
  2. Provide a primary RADIUS port number; the default is 1812.
  3. Provide the secret key for RADIUS server access.
  4. Optionally repeat steps 4, 5 and 6 for a secondary RADIUS server.
  5. Click OK.
  6. Add administrators on the RADIUS server using these three levels.
1 Operator is the lowest authentication level and also the default. Operators can see statistics and results but cannot make any configuration changes.
10 Administrators can also do general configuration changes, but cannot upgrade APs or controllers, nor can they upgrade FortiWLC (SD) versions using Telnet. The cannot configure an NMS server, NTP server, change the system password, date or time (all CLI). They cannot create admins nor can they set the authentication mode for a controller (GUI and CLI). Administrators cannot add or remove licensing.
15 SuperUser administrators can perform all configurations on the controller. They are the only ones who can upgrade APs or controllers and they can upgrade FortiWLC (SD) versions using Telnet. The can configure an NMS server, NTP server, system password, date and time (all CLI). They can also create admins and set the authentication mode for a controller (GUI and CLI). Superusers can add and remove licensing.
Configure RADIUS Authentication for Administrators With the CLI

Commands to configure all controller administrators for RADIUS authentication mode:

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

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

CLI Example for Setting Authentication Mode to RADIUS

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

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

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

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

AuthenticationType           : radius

Primary RADIUS IP Address    : 172.18.1.3

Primary RADIUS Port          : 1812

Primary RADIUS Secret Key    : *****

Secondary RADIUS IP Address  : 172.18.1.7

Secondary RADIUS Port        : 1812

Secondary RADIUS Secret Key  : *****

Primary TACACS+ IP Address   : 0.0.0.0

Primary TACACS+ Port         : 49

Primary TACACS+ Secret Key   : *****

Secondary TACACS+ IP Address : 0.0.0.0

Secondary TACACS+ Port       : 49

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


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWLC – Configuring VPN Connections

Configuring VPN Connections

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

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

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

Activating Controller Certificates for VPN

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

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

To enable a certificate for VPN use:

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

Integration with Palo Alto Networks Firewall

 

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

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

Configuring the VPN

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

To configure the VPN:

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

Figure 50: Configuring the VPN

  1. Enter the desired configuration for the VPN server. Refer to the following table for details:
Field Description  
Status Can be set to Enable or Disable. When enabled, the VPN Server will be active. By default, this is disabled.  
VPN Server IP/Name Enter an IP address or DNS name to be used by the VPN server.  
  Field Description
  VPN Server Port Enter the port to be used for VPN communications. By default, the value is set to 1194.
  IP Pool Enter the IP range that can be used by the VPN server (in standard 255.255.255.255 notation).

Note: Be sure that the IP from which you are accessing the controller (i.e., your current machine’s IP address) is not included in this range. If it is, your local connection will be terminated once VPN is enabled.

Note: The IP address 192.168.1.12 is reserved by the controller and cannot fall within the VPN range specified.

  Netmask Enter the netmask for the VPN server (in standard 255.255.255.255 notation).
  1. Click OK to save the changes. The controller is now configured for VPN service.
Adding VPN APs

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

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

Configuring VPN Connections

Figure 51: Selecting VPN APs

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

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

Figure 52: Activation Table

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

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

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

Configuring VPN Client Connections

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

To configure VPN Client connection:

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

Configuring VPN Connections

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

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWLC – Integration with Palo Alto Networks Firewall

Integration with Palo Alto Networks Firewall

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


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWLC – WAPI Configuration

WAPI Configuration

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

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

WAPI Configuration

Specifying WAPI Authentication Mode

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

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

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

Importing a WAPI Certificate

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

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

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

To configure the WAPI Server:

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

WAPI Configuration

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

3810).


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWLC – Security Certificates

Security Certificates

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

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

Figure 45: Sample CSR Sent to CA

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

Generate a CSR on a Controller

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

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

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

Generate a Wildcard Certificate

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

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

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

Import the Certificate

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

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

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

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

  1. Click Import.

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

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

You should now see all certificates imported into the controller

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

10.Click OK > Close > Close.

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

You are finished importing the certificates.

Assign a Server Certificate to an Application

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

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

Figure 47: Applications to Use Certificate

a

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

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

AP Certificates

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

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

Generating an AP CSR

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

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

Figure 48: AP Certificates Table

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

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

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

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

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

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

Installing the AP Certificate

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

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

The AP is now certified and ready for use.

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

 

Troubleshooting Certificates

.The following errors can occur during the certificate process.

Error Message Why It Appeared How to Correct Problem
  Certificate file is not a valid x.509 certificate Certificate file is corrupt or not a X.509 certificate (PEM/DER) file. Navigate to a valid X.509 certificate file.  
  Certificate has expired or not yet valid Certificates are valid for a specified number of days with Start Date (Valid From) and End Date (Valid To). This certificate is not valid at this time. Make sure that the Certificates Start Date (Valid From) and End Date (Valid To) range is current.

If the certificate Start Date is in future, then wait till that time to import the certificate. If the certificate has expired, then get another certificate issued by the CA.

 
  Certificate alias name already exists Another certificate with same alias name has already been imported. Use a different alias name.  
  Certificate already exists (with either same alias name or different alias name) Certificate has already been imported. Do nothing.  
  Certificate Public key verification failed You selected an alias name that is different from the certificate’s CSR alias name. Select the alias name that you used when creating the CSR for this certificate.  
  Certificate’s Issuers verification failed The Issuers certificates (complete chain-of-trust) is not available in

Trusted Root CA’s list. The most com-

Import the Trusted Root CA certificates chain of trust first.

Then import the Server Certificate.

 
  mon cause is that you tried to import an intermediate or server certificate first.  

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWLC – Configure MAC Filtering

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.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWLC – RSA SecurID Authentication

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


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

FortiWLC – Policy Enforcement Module

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.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!