Control Plane Security. Aruba M3MK1, 7024, 7240, 620, 7280, 650, ArubaOS 6.5.3.x, 3200
Add to My manuals1162 Pages
advertisement
Chapter 2
Control Plane Security
ArubaOS supports secure IPsec communications between a controller and campus or remote APs using publickey self-signed certificates created by each master controller. The controller certifies its APs by issuing them certificates. If the master controller has any associated local controllers, the master controller sends a certificate to each local controller, which in turn sends certificates to their own associated APs. If a local controller is unable to contact the master controller to obtain its own certificate, it is not be able to certify its
APs, and those APs cannot communicate with their local controller until master-local communication has been reestablished. You create an initial control plane security configuration when you first configure the controller using the initial setup wizard. The ArubaOS initial setup wizard enables control plane security by default, so it is very important that the local controller be able to communicate with its master controller when it is first provisioned.
Some AP model types have factory-installed digital certificates. These AP models use their factory-installed certificates for IPsec, and do not need a certificate from the controller. Once a campus or remote AP is certified, either through a factory-installed certificate or a certificate from the controller, the AP can failover between local controllers and still stay connected to the secure network, because each AP has the same master controller as a common trust anchor.
Starting with ArubaOS 6.2, the controller maintains two separate AP whitelists; one for campus APs and one for
Remote APs. These whitelists contain records of all campus APs or remote APs connected to the network. You can use a campus or AP whitelist at any time to add a new valid campus or remote AP to the secure network, or revoke network access to any suspected rogue or unauthorized APs.
The control plane security feature supports IPv4 campus and remote APs only. Do not enable control plane security on a controller that terminates IPv6 APs.
When the controller sends an AP a certificate, that AP must reboot before it can connect to its controller over a secure channel. If you are enabling control plane security for the first time on a large network, you may experience several minutes of interrupted connectivity while each AP receives its certificate and establishes its secure connection.
n n n n
HP Platform interoperating with Aruba Controllers
Following HP TPM based switches can now inter-operate with the Aruba controllers and create the IKE / IPSec tunnels.
n n n n n n
2930F
5400R/v3 3810
5400R/v2 (compat. mode)
3800
2920
2530
2620
5400/v2
5400/v1
3500
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 54
n n n
2615
2915
8200
These HP platforms are running version k.16.02.
Topics in this chapter include: n n n n n n n n
Control Plane Security Overview on page 55
Configuring Control Plane Security on page 55
Managing AP Whitelists on page 57
Managing Whitelists on Master and Local Controllers on page 64
Working in Environments with Multiple Master Controllers on page 68
Replacing a Controller on a Multi-Controller Network on page 71
Configuring Control Plane Security after Upgrading on page 75
Troubleshooting Control Plane Security on page 76
Control Plane Security Overview
Controllers using control plane security only send certificates to APs that you have identified as valid APs on the network. If you want closer control over each AP that is certified, you can manually add individual campus and remote APs to the secure network by adding each AP's information to the whitelists when you first run the initial setup wizard. If you are confident that all APs currently on your network are valid APs, then you can use the initial setup wizard to configure automatic certificate provisioning to send certificates from the controller to each campus or remote AP, or to all campus and remote APs within specific ranges of IP addresses.
The default automatic certificate provisioning setting requires that you manually enter each campus AP’s information into the campus AP whitelist, and each remote AP's information into the remote AP whitelist. If you change the default automatic certificate provisioning values to let the controller send certificates to all APs on the network, that new setting ensures that all valid APs receive a certificate, but also increases the chance that you will certify a rogue or unwanted AP. If you configure the controller to send certificates to only those
APs within a range of IP addresses, there is a smaller chance that a rogue AP receives a certificate, but any valid
AP with an IP address outside the specified address ranges will not receive a certificate, and can not communicate with the controller (except to obtain a certificate). Consider both options carefully before you complete the control plane security portion of the initial setup wizard. If your controller has a publicly accessible interface, you should identify the APs on the network by IP address range. This prevents the controller from sending certificates to external or rogue campus APs that may attempt to access your controller through that publicly accessible interface.
Configuring Control Plane Security
When you initially deploy the controller, you create your initial control plane security configuration using the initial setup wizard. These settings can be changed at any time using the WebUI or the command-line interfaces.
If you are configuring control plane security for the first time after upgrading from ArubaOS 5.0 or earlier, see
Configuring Control Plane Security after Upgrading on page 75
for details on enabling this feature using the WebUI or CLI.
55 | Control Plane Security ArubaOS 6.5.3.x | User Guide
In the WebUI
1. Navigate to Configuration > Network > Controller .
2. Select the Control Plane Security tab.
3. Configure the following control plane security parameters:
Table 17: Control Plane Security Parameters
Parameter Description
Control Plane
Security
Auto Cert
Provisioning
Addresses allowed for Auto Cert
Number of AP
Whitelist Entries
Select enable or disable to turn the control plane security feature on or off. This feature is enabled by default.
When you enable the control plane security feature, you can select this checkbox to turn on automatic certificate provisioning. When you enable this feature, the controller attempts to send certificates to all associated campus APs. Auto certificate provisioning is disabled by default.
NOTE: If you do not want to enable automatic certificate provisioning the first time you enable control plane security on the controller, you must identify the valid APs on your network by adding those to the campus AP whitelist. For details, see
Viewing the Master or Local Controller Whitelists on page 66 .
After you have enabled automatic certificate provisioning, you must select either
Auto Cert Allow all or Addresses Allowed for Auto Cert .
The Addresses Allowed for Auto Cert section allows you to specify whether certificates are sent to all associated APs, or just APs within one or more specific IP address ranges. If your controller has a publicly accessible interface, you should identify your campus and Remote APs by IP address range. This prevents the controller from sending certificates to external or rogue campus APs that may attempt to access your controller through that interface.
Select All to allow all associated campus and remote APs to receive automatic certificate provisioning. This parameter is enabled by default.
Select Addresses Allowed for Auto Cert to send certificates to a group of campus or remote APs within a range of IP addresses. In the two fields below, enter the start and end IP addresses, then click Add . Repeat this procedure to add additional IP ranges to the list of allowed addresses. If you enable both control plane security and auto certificate provisioning, all APs in the address list receives automatic certificate provisioning.
Remove a range of IP addresses from the list of allowed addresses by selecting the
IP address range from the list and clicking Delete.
This parameter is the total number of APs in the remote AP and campus AP
Whitelists. This number is also a link to a combined whitelist that displays all campus and remote AP entries.
4. Click Apply .
The master controller generates its self-signed certificate and begins distributing certificates to campus APs and any local controllers on the network over a clear channel. After all APs have received a certificate and have connected to the network using a secure channel, access the Control Plane Security window and turn off auto certificate provisioning if that feature was enabled. This prevents the controller from issuing a certificate to any rogue APs that may appear on your network at a later time.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 56
Figure 4 Control Plane Security Settings
In the CLI
Use the commands below to configure control plane security via the command line interface on a standalone or master controller. Descriptions of the individual parameters are listed in
(host)(config) #control-plane-security
(host)(Control Plane Security Profile) #auto-cert-allow-all
(host)(Control Plane Security Profile) #auto-cert-allowed-addrs <ipaddress-start> <ipaddressend>
(host)(Control Plane Security Profile) #auto-cert-prov
(host)(Control Plane Security Profile) #cpsec-enable
View the current control plane security settings using the following command:
(host) #show control-plane-security
Managing AP Whitelists
Campus or Remote APs appear as valid APs in the campus or Remote AP whitelists when you manually enter their information into the campus or Remote AP whitelists through the WebUI or CLI of a controller or after a controller sends a certificate to an AP as part of automatic certificate provisioning and the AP connects to the controller over a secure tunnel. APs that are not approved or certified on the network are included in the campus AP whitelists, but these APs appear in an unapproved state.
Use the AP whitelists to grant valid APs secure access to the network or to revoke access from suspected rogue
APs. When you revoke or remove an AP from the campus or remote AP whitelists on a controller that uses control plane security, that AP is not able to communicate with the controller again, except to obtain a new certificate.
If you manually add APs to the AP whitelists (rather than automatically adding the APs as part of automatic certificate provisioning), make sure that the AP whitelists have been synchronized to all other controllers on the network before enabling control plane security.
Adding an AP to the Campus or Remote AP Whitelists
You can add an AP to the campus AP or remote AP whitelists over the WebUI or CLI.
In the WebUI
To add an AP to the campus AP or Remote AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Select the whitelist to which you want to add an AP. The Whitelist tab displays status information for the
Campus AP Whitelist by default. To add a Remote AP to the Remote AP whitelist, click the Remote AP link before you proceed to
.
57 | Control Plane Security ArubaOS 6.5.3.x | User Guide
Figure 5 Control Plane Security Settings
4. Click Entries in the upper right corner of the whitelist status window.
5. Click New .
6. Define the following parameters for each AP you want to add to the AP whitelist.
Table 18: AP Whitelist Parameters
Parameter Description
Campus AP whitelist configuration parameters
AP MAC Address MAC address of campus AP that supports secure communications to and from its controller.
AP Group
AP Name
Name of the AP group to which the campus AP is assigned. If you do not specify an AP group, the AP uses default as its AP group.
Name of the campus AP. If you do not specify a name, the AP uses its MAC address as AP name.
Description Brief description of the campus AP.
Remote AP whitelist configuration parameters
AP MAC Address
User Name
AP Group
AP Name
MAC address of the remote AP, in colon-separated octets.
Name of the end user who provisions and uses the remote AP.
Name of the AP group to which the Remote AP is assigned.
Name of the Remote AP. If you do not specify a name, the AP uses its MAC address as AP name.
Description
IP-Address
Brief description of the Remote AP.
The static inner IP address to be assigned to the Remote APs.
7. Click Add .
In the CLI
To add an AP to the campus AP whitelist:
(host) #whitelist-db cpsec add mac-address <name> ap-group <ap_group> ap-name <ap_name>
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 58
description <description>
To add an AP to the remote AP whitelist:
(host) #whitelist-db rap add mac-address <mac-address> ap-group <ap-group> ap-name <ap-name> description <description> full-name <name> remote-ip <inner-ip-adr>
Viewing AP Whitelist Status
The WebUI displays either a status of the selected AP whitelist or a table of entries in the selected AP whitelist.
The status page displays the current status of the AP whitelist and for controllers in a master/local controller topology, it displays the AP whitelist synchronization status between controllers. When the status of an entry in the AP whitelist changes, the AP whitelist status is updated automatically. The table of entries page displays the status of each AP on the AP whitelist.
The Configuration > Wireless > AP Installation > Whitelist tab displays the status of the campus AP whitelist by default. To view the status of remote AP whitelist, click the Remote AP link.
The following table describes the contents of the status page.
Table 19: Whitelist Status Information
Status Entry Description
Campus AP whitelist status information
Control Plane Security
Total entries
Shows if the control plane security is enabled or disabled on the controller.
This status entry is also a link to the control plane security configuration tab.
Number of entries in the campus AP whitelist.
Approved entries
Unapproved entries
Number of entries in the campus AP whitelist that have been approved by the controller.
Number of entries in the campus AP whitelist that have not been approved by the controller.
Certified entries
Certified hold entries
Revoked entries
Number of entries in the campus AP whitelist that have an approved certificate from the controller.
Number of entries in the campus AP whitelist that have been certified with a factory certificate but request to be certified again. Such APs are not approved as secure until you manually change the status and verify that it is not compromised.
NOTE: If an AP is in the hold state because of connectivity problems, then the AP recovers and moves out of the hold state when connectivity is restored.
Number of entries in the campus AP whitelist that has been manually revoked.
Marked for deletion entries Number of entries in the campus AP whitelist that has been marked for deletion, but not removed from the Remote AP whitelist.
Remote AP whitelist configuration parameters
59 | Control Plane Security ArubaOS 6.5.3.x | User Guide
Table 19: Whitelist Status Information
Status Entry Description
Total entries
Revoked entries
Marked for deletion entries
Number of entries in the Remote AP whitelist.
Number of entries in the Remote AP whitelist that has been manually revoked.
Number of entries in the Remote AP whitelist that has been marked for deletion, but not removed from the Remote AP whitelist.
The Remote AP whitelist entries page displays only the information you manually configure. The campus AP whitelist entries page displays both user-defined settings and additional information that is updated when the status of a campus AP changes.
Table 20: Additional Campus AP Status Information
Parameter
Cert Type
Description
State
Revoked
Revoked Text
Last Update
The type of certificate used by the campus AP.
n n switch-cert : The campus AP is using a certificate signed by the controller.
factory-cert : The campus AP is using a factory-installed certificate.
The state of a campus AP.
n unapproved-no-cert: The campus AP has no certificate and is not approved.
n n n unapproved-factory-cert: The campus AP has a pre-installed certificate which is not approved.
approved-ready-for-cert: The campus AP is approved as valid and is ready to receive a certificate.
certified-factory-cert : The campus AP already has a factory certificate. If a campus AP has a factory-cert type of certificate and is in certified-factory-cert state, then a new certificate is not reissued to the campus AP when you enable automatic certificate provisioning.
n n certified-switch-cert: The campus AP has an approved certificate from the controller.
certified-hold-factory-cert : The campus AP is certified with a factory certificate but requests to be certified again. Such APs are not approved as secure until you manually change the status and verify that it is not compromised.
NOTE: If an AP is in this state due to connectivity problems, then the AP recovers and leaves this hold state as soon as connectivity is restored.
n certified-hold-switch-cert : An AP is put in this state when the controller thinks the AP has been certified with a controller certificate but the AP requests to be certified again. Because this is not a normal condition, the AP is not approved as a secure AP until a network administrator manually changes the status of the AP to verify that it is not compromised.
NOTE: If an AP is in the hold state because of connectivity problems, then the AP recovers and moves out of the hold state when connectivity is restored.
Shows if the secure status of the AP is revoked.
Brief description for revoking the campus AP.
Time and date of the last AP status update.
To view information about the campus and remote AP whitelists using the CLI, use the following commands:
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 60
(host) #show whitelist-db cpsec ap-group <ap_group> ap-name <ap_name> cert-type {factory-cert|switch-cert} mac-address <name> page <num> start <offset> state {approved-ready-for-cert| certified-factory-cert| unapproved-factory-cert| unapproved-no-cert}
(host) #show whitelist-db cpsec-status
(host) #show whitelist-db rap apgroup <rap-group> apname <rap-name> fullname <rap-fullname> long mac-address <mac-address> page <page-number> start <offset>
(host) #show whitelist-db rap-status
Modifying an AP in the Campus AP Whitelist
Use the following procedures to modify the AP group, AP name, certificate type, state, description, and revoked status of an AP in the campus AP whitelist.
In the WebUI
To modify an AP in the campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Click the Entries>> button.
4. Select the checkbox of the AP that you want to modify, then click Modify .
If your campus AP whitelist is large and you cannot immediately locate the AP that you want to modify, select the Search link. The Whitelist Search tab displays the fields AP Group , Cert Type , AP MAC
Address , AP Name , and State that allow you to search for an AP. Specify the values of the AP that you want to locate in these fields, then click Search . The campus AP whitelist displays a list of APs that match your search criteria. Select the checkbox of the AP that you want to modify, then click Modify .
5. Modify the settings of the selected AP. Some of the following parameters are available when adding an
AP to the campus AP whitelist and are described in
n
AP Group : The name of the AP group to which the campus AP is assigned.
n n
AP Name : The name of the campus AP. If you not specify a name, the AP uses its MAC address as a name.
Cert-type : The type of certificate used by the AP.
n n n l l switch-cert: The campus AP is using a certificate signed by the controller.
factory-cert: The campus AP is using a factory-installed certificate.
State : When you click the State drop-down list to modify this parameter, you may choose one of the following options: l l approved-ready-for-cert: The AP has been approved state and is ready to receive a certificate.
certified-factory-cert: The AP is certified and has a factory-installed certificate.
Description : Brief description of the campus AP.
Revoked : Click the Revoked checkbox to revoke an invalid or rogue AP.
61 | Control Plane Security ArubaOS 6.5.3.x | User Guide
n
Revoke Text : When the Revoked checkbox is selected, enter a brief comment describing why the AP is being revoked.
6. Click Update to update the campus AP whitelist entry with its new settings.
In the CLI
To modify an AP in the campus AP whitelist:
(host) #whitelist-db cpsec modify mac-address <name> ap-group <ap_group> ap-name <ap_name> cert-type {switch-cert|factory-cert} description <description> mode {disable|enable} revoke-text <revoke-text> state {approved-ready-for-cert|certified-factory-cert}
Revoking an AP from the Campus AP Whitelist
You can revoke an invalid or rogue AP either by modifying its revoke status (as described in
parameter. When revoking an invalid or rogue AP, enter a brief description why the AP is being revoked. When you revoke an AP from the campus AP whitelist, the campus AP whitelist retains the information of the AP. To revoke an invalid or rogue AP and permanently remove it from the whitelist, delete that entry (as described in ).
In the WebUI
To revoke an AP from the campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Click the Entries>> button.
4. Select the checkbox of the AP that you want to revoke, then click Revoke .
If your campus AP whitelist is large and you cannot immediately locate the AP that you want to revoke, select the Search link. The Whitelist Search tab displays the fields AP Group , Cert Type , AP MAC
Address , AP Name , and State that allow you to search for an AP. Specify the values of the AP that you want to locate in these fields, then click Search . The campus AP whitelist displays a list of APs that match your search criteria. Select the checkbox of the AP that you want to revoke, then click Revoke .
5. Enter a brief description why the AP is being revoked, then click Update .
In the CLI
To revoke an AP via the campus AP whitelist:
(host) #whitelist-db cpsec revoke mac-address <name> revoke-text <revoke-text>
Deleting an AP from the Campus AP Whitelist
Before deleting an AP from the campus AP whitelist, verify that auto certificate provisioning is either not enabled or enabled only for IP addresses that do not include the AP being deleted. If you enable automatic certificate provisioning for an AP that is still connected to the network, you cannot delete it from the campus
AP whitelist; the controller immediately re-certifies the AP and recreates its whitelist entry.
In the WebUI
To delete an AP from the campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 62
3. Click the Entries>> button.
4. Select the checkbox of the AP you want to delete, then click delete .
If your campus AP whitelist is large and you cannot immediately locate the AP that you want to delete, select the Search link. The Whitelist Search tab displays the fields AP Group , Cert Type , AP MAC
Address , AP Name , and State that allow you to search for an AP. Specify the values of the AP that you want to locate in these fields, then click Search . The campus AP whitelist displays a list of APs that match your search criteria. Select the checkbox of the AP that you want to delete, then click Delete .
In the CLI
To delete an AP from the campus AP whitelist:
(host) #whitelist-db cpsec del mac-address <name>
Purging a Campus AP Whitelist
Before adding a new local controller to a network using control plane security, purge the campus AP whitelist on the new controller. After adding the new controller to the hierarchy, the entries in the campus AP whitelist of the new controller merge into the whitelist for all other master and local controllers. If you add any old or invalid AP entries to the campus AP whitelist, all controllers in the hierarchy will trust those APs, creating a potential security risk. For additional information on adding a new local controller using control plane security to your network, see
Replacing a Local Controller on page 71
In the WebUI
To purge a campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Click the Entries>> button.
4. Click Purge .
In the CLI
To purge a campus AP whitelist:
(host) #whitelist-db cpsec purge
Offloading a Controller Whitelist to ClearPass Policy Manager
This feature allows to externally maintain AP whitelist in a ClearPass Policy Manager (CPPM) server. The controller, if configured to use an external server, can send a RADIUS access request to a CPPM server. The
MAC address of the AP is used as a username and password to construct the access request packet. The CPPM server validates the RADIUS message and returns the relevant parameters for the authorized APs.
The following supported parameters are associated with the following VSAs. The CPPM server sends them in the RADIUS access accept packet for authorized APs: n n n ap-group: Aruba-AP-Group ap-name: Aruba-Location-ID ap-remote-ip: Aruba-AP-IP-Address
The following defaults are used when any of the supported parameters are not provided by the CPPM server in the RADIUS access accept response: n n ap-group: The default ap-group is assigned to the AP.
ap-name: The MAC address of the AP is used as the AP name.
63 | Control Plane Security ArubaOS 6.5.3.x | User Guide
There is no change in the RAP role assignment. The RAP is assigned the role that is configured in the VPN default-rap profile.
In the WebUI
To assign a CPPM server to a RAP:
1. Configure a CPPM server using the controller WebUI: a. Navigate to Configuration > Security > Authentication > Servers .
b. Select Radius Server to display the CPPM Server List.
c. To configure a CPPM server, enter the name for the server and click Add .
d. Select the name to configure server parameters. Select the Mode check box to activate the authentication server.
e. Click Apply .
2. Create a server group that contains the CPPM server.
3. Navigate to Configuration > All Profile Management > Wireless LAN > VPN Authentication > default-rap > Server Group .
4. Select the CPPM server from the Server Group drop-down list.
5. Click Apply .
To assign a CPPM server to a RAP that was initially an Instant AP:
1. Make sure that a CPPM server is configured on the controller.
2. Navigate to Configuration > All Profile Management > Wireless LAN > VPN Authentication > default-iap > Server Group .
3. Select the CPPM server from the Server Group drop-down list.
4. Click Apply .
In the CLI
To add a CPPM server to a RAP:
Configure a radius server with CPPM server as host address. In this example cppm-rad is the CPPM server name and cppm-sg is the server group name.
(host)(config) #aaa authentication-server radius cppm-rad
Add this server to a server group:
(host)(config) #aaa server-group cppm-sg
(host) (Server Group "cppm-sg") #auth-server cppm-rad
Add this server group to the default-rap vpn profile:
(host)(config) #aaa authentication vpn default-rap
(host)(VPN Authentication Profile "default-rap") #server-group cppm-sg
Managing Whitelists on Master and Local Controllers
Every controller using the control plane security feature maintains a campus AP whitelist, a local controller whitelist and a master controller whitelist. The contents of these whitelists vary, depending upon the role of the controller, as shown in the table below.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 64
Table 21: Control Plane Security Whitelists
Controller Role
On a (standalone) master controller with no local controllers:
On a master controller with local controllers:
On a local controller:
Campus AP Whitelist
Master Controller
Whitelist
The campus AP whitelist contains entries for the secure campus
APs associated with that controller.
The master controller whitelist is empty, and does not appear in the
WebUI.
The campus AP whitelist contains an entry for every secure campus AP on the network, regardless of the controller to which it is connected.
The master controller whitelist is empty, and does not appear in the
WebUI.
The campus AP whitelist contains an entry for every secure campus AP on the network, regardless of the controller to which it is connected.
The master controller whitelist contains the
MAC and the IP addresses of the master controller.
Local Controller
Whitelist
The local controller whitelist is empty, and does not appear in the WebUI.
The local controller whitelist contains an entry for each associated local controller.
The local controller whitelist is empty, and does not appear in the WebUI.
Figure 6 Local Controller Whitelist on a Master Controller
If your deployment includes both master and local controllers, then the campus AP whitelist on every controller contains an entry for every secure AP on the network, regardless of the controller to which it is connected. The master controller also maintains a whitelist of local controllers using control plane security.
When you change a campus AP whitelist on any controller, that controller contacts the other connected controllers to notify them of the change.
The master controller whitelist on each local controller contains the IP and MAC addresses of its master controller. If your network has a redundant master controller, then this whitelist contains more than one entry.
You rarely need to delete the master controller whitelist. Although you can delete an entry from the master controller whitelist, you should do so only if you have removed a master controller from the network.
Campus AP Whitelist Synchronization
The current sequence number in the AP Whitelist Sync Status field shows the number of changes to the campus AP whitelist made on that controller. Each controller compares its campus AP whitelist against whitelists on other controllers every two minutes by default. If a controller detects a difference, it sends its changes to the other controllers on the network. If all other controllers on the network have successfully received and acknowledged all whitelist changes made on that controller, every entry in the sequencenumber column in the local controller or master controller whitelists has the same value as the sequence number displayed in the AP Whitelist Sync Status field. If a controller in the master or local controller whitelist has a
65 | Control Plane Security ArubaOS 6.5.3.x | User Guide
lower sequence number, that controller may still be waiting to complete its update, or receive its update acknowledgment. In the example in
, the master controller has a current sequence number of 3, and each sequence number in its local controller whitelist also shows a value of 3, indicating that both local controllers have received and acknowledged all three campus AP whitelist changes made on the master controller. For additional information on troubleshooting whitelist synchronization, see
.
You can view a controller’s current sequence number via the CLI:
(host) #show whitelist-db cpsec-seq
Viewing the Master or Local Controller Whitelists
The following sections describe the commands to view and delete entries in a master or local controller whitelist.
In the WebUI
To view the master or local controller whitelists:
1. Access the controller’s WebUI, and navigate to Configuration > AP Installation.
2. Select the Whitelist tab.
The master and local controller tables each include the following information:
Table 22: Master and Local Controller Whitelist Information
Field
MAC-Address
IP-Address
Sequence Number
Remote Sequence Number
Null Update Count
Description
On a local controller whitelist: MAC address of the master controller.
On a master controller whitelist: MAC address of a local controller.
On a local controller whitelist: IP address of the master controller.
On a master controller whitelist: IP address of a local controller.
The number of times the controller in the whitelist received and acknowledged a campus AP whitelist change from the controller whose
WebUI you are currently viewing.
For deployments with both master and local controllers: n The sequence number on a master controller should be the same as the remote sequence number on the local controller.
n The sequence number on a local controller should be the same as the remote sequence number on the master controller.
The number of times that the controller whose WebUI you are viewing received and acknowledged a campus AP whitelist change from the controller in the whitelist.
For deployments with both master and local controllers: n The remote sequence number on a master controller should be the same as the sequence number on the local controller.
n The remote sequence number on a local controller should be the same as the sequence number on the master controller.
The number of times the controller checked its campus AP whitelist and found nothing to synchronize with the other controller. The controller compares its control plane security whitelist against whitelists on other controllers every two minutes by default. If the null update count reaches five, the controller sends an “empty sync” heartbeat to the remote controller to ensure the sequence numbers on both controllers are the same, then resets the null update count to zero.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 66
In the CLI
To view the master or local controller whitelists via the command-line interface, issue the following commands:
(host) #show whitelist-db cpsec-master-switch-list [mac-address <mac-address>]
(host) #show whitelist-db cpsec-local-switch-list [mac-address <mac-address>]
Deleting an Entry from the Master or Local Controller Whitelist
You do not need to delete a master controller from the master controller whitelist during the course of normal operation. However, if you remove a local controller from the network, you should also remove the local controller from the local controller whitelist on the master controller. If the local controller whitelist contains entries for controllers no longer on the network, then a campus AP whitelist entry can be marked for deletion but is not physically deleted, as the controller is waiting for an acknowledgment from another controller no longer on the network. This can increase network traffic and reduce memory resources on the controller.
In the WebUI
To delete an entry from the master or local controller whitelist:
1. Navigate to Configuration > Controller.
2. Select the Control Plane Security tab.
3. To delete an entry from the Local Controller Whitelist: In the Local Switch List For AP Whitelist Sync section, click the Delete button by each controller entry you want to remove.
Or,
To delete an entry from the Master Controller Whitelist: In the Master Switch List For AP Whitelist Sync section, click Delete by each controller entry you want to remove.
4. Click Apply .
In the CLI
To delete an entry from the master or local controller whitelist:
(host) #whitelist-db cpsec-master-switch-list del mac-address <mac-address>
(host) #whitelist-db cpsec-local-switch-list del mac-address <mac-address>
Purging the Master or Local Controller Whitelist
There is no need to purge a master controller whitelist during the course of normal operation. If, however, you are removing a controller from the network, you can purge its controller whitelist after it has been disconnected from the network. To clear a local controller whitelist entry on a master controller that is still connected to the network, select that individual whitelist entry and delete it using the delete option.
In the WebUI
To purge a controller whitelist:
1. Navigate to Configuration > Controller .
2. Select the Control Plane Security tab.
3. To clear the Local Controller whitelist: In the Local Switch List For AP Whitelist Sync section, click
Purge.
Or,
4. To clear the Master Controller whitelist: In the Master Switch List For AP Whitelist Sync section, click
Purge .
67 | Control Plane Security ArubaOS 6.5.3.x | User Guide
In the CLI
To purge a controller whitelist:
(host) #whitelist-db cpsec-master-switch-list purge
(host) #whitelist-db cpsec-local-switch-list purge
Working in Environments with Multiple Master Controllers
This section describes the configuration steps required in a multiple master controllers network.
Configuring Networks with Clusters of Master Controllers
If your network includes multiple master controllers each with their own hierarchy of APs and local controllers, you can allow APs from one hierarchy to failover to any other hierarchy by defining a cluster of master controllers. Each cluster has one master controller as its cluster root, and all other master controllers as cluster members. The master controller operating as the cluster root creates a self-signed certificate, then certifies its own local controllers and APs. Next, the cluster root sends a certificate to each cluster member, which in turn certifies its own local controllers and APs. Because all controllers and APs in the cluster have the same trust anchor, the APs can switch to any other controller in the cluster and still remain securely connected to the network.
Figure 7 A Cluster of Master Controllers using Control Plane Security
To create a controller cluster, you must first define the root master controller and set an IPsec key or select a certificate for communications between the cluster root and cluster members.
You must use the command-line interface to configure certificate authentication for cluster members. The WebUI supports cluster authentication using IPsec keys only. If your master and local controllers use a pre-shared key for authentication, they create the IPsec tunnel using IKEv1. If your master and local controllers use certificates for authentication, the IPsec tunnel is created using IKEv2.
Creating a Cluster Root
Use the WebUI to identify a controller as a cluster root, and use an IPsec key to secure communication between the cluster root and cluster members. Use the command-line interface to create a cluster root using an IPsec key, factory-installed certificate, or custom certificate.
In the WebUI
To create a cluster root:
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 68
1. Access the WebUI of the controller you want to identify as the cluster root, and navigate to Configuration
> Controller .
2. Click the Cluster Setting tab.
3. For the cluster role, select Root.
4. In the Cluster Member IPsec Keys section, enter the controller IP address of a member controller in the cluster. If you want to use a single key for all member controllers, use the IP address 0.0.0.0
.
5. In the IPsec Key and Retype IPsec Key fields, enter the IPsec key for communication between the specified member controller and the cluster root.
6. Click Add .
7.
Optional : repeat steps 4-6 to add another member controller to the cluster.
8. Click Apply.
In the CLI
To create a cluster root, access the command-line interface of the controller you want to identify as the root of the controller cluster, then issue one of the following commands: n n n
To authenticate cluster members using a custom certificate:
(host)(config) #cluster-member-custom-cert member-mac <mac> ca-cert <ca> server-cert <cert> suite-b <gcm-128|gcm-256>]
To authenticate cluster members using a factory-installed certificate:
(host)(config) #cluster-member-factory-cert member-mac <mac>
To authenticate cluster members using an IPsec key:
(host)(config) #cluster-member-ip <ip-address> ipsec <key>
The <ip-address> parameter in this command is the IP address of a member controller in the cluster, and the <key> parameter in each command is the IPsec key for communication between the specified member controller and the cluster root. Use the IP address 0.0.0.0
in this command to set a single IPsec key for all member controllers, or repeat this command as desired to define a different IPsec key for each cluster member.
Creating a Cluster Member
Once you have identified the cluster root, you must then identify the member controllers in the cluster.
Use the WebUI to identify a controller as a cluster member, and use an IPsec key to secure communication between the cluster member and the cluster root. Use the command-line interface to create a cluster member and secure communications between that member and the cluster root using an IPsec key, factory-installed certificate, or custom certificate.
In the WebUI
To create a cluster member:
1. Access the WebUI of the cluster member controller, and navigate to Configuration > Controller.
2. Click the Cluster Setting tab.
3. For the cluster role, select Member .
4. In the Controller IP Address field, enter the IP address of the root controller in the cluster.
5. In the IPsec Key and Retype IPsec Key fields, enter the IPsec key for communication between the specified member controller and the cluster root. This parameter must be have the same value as the key defined for the cluster member in
Creating a Cluster Root on page 68
.
6. Click Add .
7. Click Apply .
69 | Control Plane Security ArubaOS 6.5.3.x | User Guide
In the CLI
To create a cluster root via the CLI, access each of the member master controllers and define the IPsec key or certificate for communication between that controller and the cluster root.
(host)(config) #cluster-root-ip <ip-address> ipsec <key> ipsec-custom-cert root-mac-1 <root-mac-address-1> [master-mac2 <mac2>] ca-cert <ca> servercert <cert> [suite-b <gcm-128 | gcm-256>] ipsec-factory-cert root-mac-1 <root-mac-address-1> root-mac-2 <root-mac-address-2>
In this command the <ip-address> parameter is the IP address of the root master controller in the cluster. If you are using an IPsec key, the <key> parameter in this command must be have the same value as the key defined for the cluster member via the cluster-member-ip command.
Viewing Controller Cluster Setting
You can view the controller cluster configuration using the WebUI or CLI.
In the WebUI
To view the current cluster configuration:
1. Navigate to Configuration > Controller .
2. Click the Cluster Setting tab.
n
If you are viewing the WebUI of a cluster root, the output of this command displays the IP address of the
VLAN on the cluster member used to connect to the cluster root.
n
If you are viewing the WebUI of a cluster member, the output of this command displays the IP address of the VLAN on the cluster root used to connect to the cluster member.
In the CLI
To view your current cluster configuration, issue the CLI commands described in
Table 23: CLI Commands to Display Cluster Settings
Command show cluster-switches
Description show cluster-config
When you issue this command from the cluster root , the output of this command displays the IP address of the VLAN the cluster member uses to connect to the cluster root.
If you issue this command from a cluster member , the output of this command displays the IP address of the VLAN the cluster root uses to connect to the cluster member.
When you issue this command from the cluster root , the output of this command shows the cluster role of the controller, and the IP address of each active member controller in the cluster.
When you issue this command from a cluster member , the output of this command shows the cluster role of the controller, and the IP address of the cluster root.
Configuring Networks with a Backup Master Controller
If your network includes a redundant backup master controller, you must synchronize the database from the primary master to the backup master at least once after all APs are communicating with their controllers over a secure channel. This ensures that all certificates, IPsec keys, and campus AP whitelist entries are synchronized to the backup controller. You should also synchronize the database any time the campus AP whitelist changes
(APs are added or removed to ensure that the backup controller has the latest settings).
Master and backup controllers can be synchronized using either of the following methods:
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 70
n n
Manual Synchronization : Issue the database synchronize command in enable mode to manually synchronize databases from your primary controller to the backup controller.
Automatic Synchronization : Schedule automatic database backups using the database synchronize period command in configuration mode.
If you add a new backup controller to an existing controller, you must add the backup controller as the lower priority controller. If you do not add the backup controller as a lower priority controller, your control plane security keys and certificates may be lost. If you want the new backup controller to become your primary controller, increase the priority of that controller to a primary controller after you have synchronized your data.
Replacing a Controller on a Multi-Controller Network
The procedure to replace a controller within a multi-controller network varies, depending upon the role of that controller, whether the network has a single master controller or a cluster of master controllers, and whether or not the controller has a backup.
The following sections describe the steps to replace an existing controller. To add a new local controller to a network, or to permanently remove a local controller without replacing it, see
Viewing the Master or Local Controller
Replacing Controllers in a Single Master Network
Use the procedures in this section to replace a master or local controller in a network environment with a single master controller.
Replacing a Local Controller
Use the following procedure to replace a local controller in a single-master network:
1. Disconnect the local controller from the network.
2. If you plan on moving the local controller to another location on the network, purge the campus AP whitelist on the controller.
Access the command-line interface on the old local controller and issue the whitelist-db cpsec purge command.
or,
Access the local controller WebUI, navigate to Configuration > AP Installation > Campus AP Whitelist and click Purge .
3. Once you purge the campus AP whitelist, you must inform the master controller that the local controller is no longer available using one of these two methods:
This step is very important ; unused local controller entries in the local controller whitelist can significantly increase network traffic and reduce controller memory resources.
n n
Access the command-line interface on the master controller, and issue the whitelist-db cpsec-localswitch-list del mac-address <local--mac> command.
Access the master controller WebUI, navigate to Configuration > Controller > Control Plane
Security , select the entry for the local controller you want to delete from the local controller whitelist, and click Delete .
4. Install the new local controller, but do not connect it to the network yet. If the controller has been previously installed on the network, you must ensure that the new local controller has a clean whitelist.
5. Purge the local controller whitelist using one of the following two methods:
71 | Control Plane Security ArubaOS 6.5.3.x | User Guide
n n
Access the command-line interface on the new local controller and issue the whitelist-db cpsec purge command.
Access the local controller WebUI, navigate to Configuration > AP Installation > Campus AP
Whitelist and click Purge .
6. Now connect the new local controller to the network. It is very important that the local controller be able to contact the master controller the first time it connects to the network, because the master controller certifies the local controller's control plane security certificate the first time the local controller contacts its master.
7. Once the local controller has a valid control plane security certificate and configuration, the local controller receives the campus AP whitelist from the master controller and starts certifying approved APs.
8. APs associated with the new local controller reboots and creates new IPsec tunnels to their controller using the new certificate keys.
Replacing a Master Controller with No Backup
Use the following procedure to replace a master controller that does not have a backup controller:
1. Remove the old master controller from the network.
2. Install and configure the new master controller, then connect the new master to the network. The new master controller generates a new certificate when it first becomes active.
3. If the new master controller has a different IP address than the old master controller, change the master IP address on the local controllers to reflect the address of the new master.
4. Reboot each local controller to ensure the local controllers obtain their certificate from the new master.
Each local controller begins using a new certificate signed by the master controller.
5. APs are now no longer able to securely communicate with the controller using their current key, and must obtain a new certificate. Access the campus AP whitelist on any local controller, and change all APs in a
“certified” state to an “approved” state. The new master controller sends the approved APs new certificates.
The APs reboot and create new IPsec tunnels to their controller using the new certificate key.
If the master controller does not have any local controllers, you must recreate the campus AP whitelist by turning on automatic certificate provisioning or manually reentering the campus AP whitelist entries.
Replacing a Redundant Master Controller
The control plane security feature requires you to synchronize databases from the primary master controller to the backup master controller at least once after the network is up and running. This ensures that all certificates, keys, and whitelist entries are synchronized to the backup controller. Because the AP whitelist may change periodically, you should regularly synchronize these settings to the backup controller. For details, see
Configuring Networks with a Backup Master Controller on page 70 .
When you install a new backup master controller, you must add it as a lower priority controller than the existing primary controller. After you install the backup controller on the network, synchronize the database from the existing primary controller to the new backup controller to ensure that all certificates, keys, and whitelist entries required for control plane security are added to the new backup controller configuration. If you want the new controller to act as the primary controller, you can increase that controller’s priority after the settings have been synchronized.
Replacing Controllers in a Multi-Master Network
Use the following procedures to replace a master or local controller in a network environment with a multiple master controllers.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 72
Replacing a Local Controller in a Multi-Master Network
The procedure to replace a local controller in a network with multiple master controllers is the same as the procedure to replace a local controller in a single-master network. To replace a local controller in a multi-master network, follow the procedure described in
Replacing a Local Controller on page 71
Replacing a Cluster Member Controller with no Backup
The control plane security feature allows APs to fail over from one controller to another within a cluster.
Therefore, cluster members or their local controllers may have associated APs that were first certified under some other cluster member (or the cluster root). If you permanently remove a cluster member whose APs were all originally certified under the cluster member being removed, its associated APs do not need to reboot in order to connect to a different controller. If, however, you remove a cluster member whose associated APs were originally certified under a different cluster member, those APs need to reboot and be re-certified before they can connect to a different controller. If the cluster member you are removing has local controllers, the local controllers also reboot so they can be updated with new certificates, then pass the trust update to their terminating APs.
To replace a cluster member that does not have a backup controller:
1. On the cluster master to be removed, clear the cluster root IP address by accessing the command-line interface and issuing the no cluster-root-ip <cluster-root-ip> ipsec <clusterkey> command.
2. Remove the cluster member from the network.
3. If the cluster master you removed has any associated APs, you must reboot those APs so they receive an updated certificate.
4. If the cluster member you removed has any associated local controllers, reboot those local controllers so they receive a new certificate and then pass that trust update to their APs.
5. Remove the cluster master from the cluster root’s master controller list by accessing the command-line interface on the cluster root and issuing the whitelist-db cpsec-master-switch-list del mac-address
<cluster-master-mac> command.
This step is very important . Unused local controller entries in the local controller whitelist can significantly increase network traffic and reduce controller memory resources.
6. Remove the old cluster member from the network. Remember, that controller still has campus AP whitelist entries from the entire cluster. You may want to delete or revoke unwanted entries from the campus AP whitelist.
Now, you must install the new cluster member controller according to the procedure described in
. The new cluster member obtains a certificate from the cluster root when it first becomes active.
7. If the new cluster member has any associated APs, reboot those APs so they obtain a trust update.
8. If the new cluster member has any local controllers, reboot the local controllers associated with the new cluster member. The local controllers obtain a new certificate signed by the cluster member, and then pass that trust update to their associated APs.
Replacing a Redundant Cluster Member Controller
The control plane security feature requires you to synchronize databases from the primary controller to the backup controller at least once after the network is up and running. This ensures that all certificates, keys, and whitelist entries are synchronized to the backup controller. Because the AP whitelist may change periodically, you should regularly synchronize these settings to the backup controller. For details, see
Configuring Networks with a Backup Master Controller on page 70
.
73 | Control Plane Security ArubaOS 6.5.3.x | User Guide
When you install a new backup cluster member, you must add it as a lower priority controller than the existing primary controller. After you install the backup cluster member on the network, resynchronize the database from the existing primary controller to the new backup controller to ensure that all certificates, keys, and whitelist entries required for control plane security are added to the new backup controller configuration. If you want the new controller to act as the primary controller, you can increase that controller’s priority after the settings have been resynchronized.
Replacing a Cluster Root Controller with no Backup Controller
If you replace a cluster root controller that does not have a backup controller, the new cluster root controller creates its own self-signed certificate. You then need to reboot each controller in the hierarchy in a specific order to certify all APs with that new certificate:
1. Remove the old cluster root from the network.
2. Install and configure the new cluster root.
3. Connect the new cluster root to the network so it can access cluster masters and local controllers.
4. If necessary, reconfigure the cluster masters and local controllers with their new cluster root IP and master
IP addresses.
5. Reboot every cluster member controller. The cluster member begins using a new certificate signed by the cluster root.
6. Reboot every local controller. Each local controller begins using a new certificate signed by the cluster member.
7. Because the cluster root is new, it does not have a configured campus AP whitelist. Access the campus AP whitelist on any local controller or cluster master, and change all APs in a “certified” state to an “approved” state. The APs get re-certified, reboot, and create new IPsec tunnels to their controller using the new certificate key.
If a cluster root controller does not have any cluster master or local controllers, you must recreate the campus AP whitelist on the cluster root by turning on automatic certificate provisioning or manually reentering the campus AP whitelist entries.
Replacing a Redundant Cluster Root Controller
Best practices is to use a backup controller with your cluster root controller. If your cluster root has a backup controller, you can replace the backup cluster root without having to reboot all cluster master and local controllers, minimizing network disruptions.
The control plane security feature requires you to synchronize databases from the primary controller to the backup controller at least once after the network is up at running. This ensures that all certificates, keys, and whitelist entries are synchronized to the backup controller. Because the AP whitelist may change periodically, you should regularly synchronize these settings to the backup controller. For details, see
Configuring Networks with a Backup Master Controller on page 70
.
When you install a new backup cluster root, you must add it as a lower priority controller than the existing primary controller. After you install the backup cluster root on the network, resynchronize the database from the existing primary controller to the new backup controller to ensure that all certificates, keys, and whitelist entries required for control plane security are added to the new backup controller configuration. If you want the new controller to act as the primary controller, you can increase that controller’s priority after the settings have been resynchronized.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 74
Configuring Control Plane Security after Upgrading
When you initially deploy a controller running ArubaOS 6.0 or later, create your initial control plane security configuration using the initial setup wizard. However, if you are upgrading to ArubaOS 6.0 from ArubaOS 3.4.x
or earlier releases, or if you are upgrading from ArubaOS 5.0
but did not yet have control plane security enabled before the upgrade , then you can use the strategies described in
to enable and configure control plane security feature.
If you upgrade a controller running ArubaOS 5.0.x to ArubaOS 6.0 or later, then the controller’s control plane security settings do not change after the upgrade. If control plane security was already enabled, then it remains enabled after the upgrade. If it was not enabled previously, but you want to use the feature after upgrading, then you must manually enable it.
Table 24: Control Plane Security Upgrade Strategies
Automatically send Certificates to Campus
APs
Manually Certify Campus APs
1. Access the control plane security window and enable both the control plane security feature and the auto certificate provisioning option. Next, specify whether you want all associated campus APs to automatically receive a certificate, or if you want to certify only those APs within a defined range of IP addresses.
2. Once all APs have received their certificates, disable auto certificate provisioning to prevent certificates from being issued to any rogue APs that may appear on your network at a later time.
1. Identify the campus APs that should receive certificates by entering the campus APs’ MAC addresses in the campus AP whitelist.
2. If your network includes both master and local controllers, wait a few minutes, then verify that the campus AP whitelist has been propagated to all other controllers on the network. Access the WebUI of the master controller, navigate to Configuration
> Controller > Control Plane Security , then verify that the Current Sequence Number field has the same value as the Sequence Number entry for each local controller in the local controller whitelist.
(For details, see
Verifying Whitelist Synchronization on page 76
.)
3. Enable the control plane security feature.
3. If a valid AP did not receive a certificate during the initial certificate distribution, you can manually certify the AP by adding that MAC address of the AP to the campus AP whitelist. You can also use this whitelist to revoke certificates from APs that should not be allowed access to the secure network.
If you upgraded your controller from ArubaOS 5.0 or earlier and you want to use this feature for the first time, you must either add all valid APs to the campus AP whitelist, or enable automatic certificate provisioning before you enable the feature . If you do not enable automatic certificate provisioning, only the APs currently approved in the campus AP whitelist are allowed to communicate with the controller over a secure channel. Any APs that do not receive a certificate will not be able to communicate with the controller except to request a certificate.
75 | Control Plane Security ArubaOS 6.5.3.x | User Guide
Troubleshooting Control Plane Security
Identifying Certificate Problems
If an AP has a problem with its certificate, check the state of the AP in the campus AP whitelist. If the AP is in either the certified-hold-factory-cert or certified-hold-switch-cert states, you may need to manually change the status of that AP before it can be certified.
n n certified-hold-factory-cert : An AP is put in this state when the controller thinks the AP has been certified with a factory certificate, but the AP requests to be certified again. Because this is not a normal condition, the AP is not approved as a secure AP until you manually change the status of the AP to verify that it is not compromised. If an AP is in this state due to connectivity problems, then the AP recovers and is taken out of this hold state as soon as connectivity is restored.
certified-hold-switch-cert : An AP is put in this state when the controller thinks the AP has been certified with a controller certificate yet the AP requests to be certified again. Because this is not a normal condition, the AP is not be approved as a secure AP until a network administrator manually changes the status of the
AP to verify that it is not compromised. If an AP is in this state due to connectivity problems, then the AP recovers and is taken out of this hold state as soon as connectivity is restored.
Disabling Control Plane Security
If you disable control plane security on a standalone or local controller, all APs connected to that controller reboot then reconnect to the controller over a clear channel.
If your disable control plane security on a master controller, APs directly connected to the master controller reboot then reconnect to the master controller over a clear channel. However, its local controllers continue to communicate with their APs over a secure channel until you save your configuration on the master controller.
Once you save the configuration, the changes are pushed down to the local controllers. At that point, any APs connected to the local controllers also reboot and reconnect over a clear channel.
Verifying Whitelist Synchronization
To verify that a network of master and local controllers are correctly sharing their campus AP whitelists, check the sequence numbers on the master and local controller whitelists.
n n
The sequence number value on a master controller should be the same as the remote sequence number on the local controller.
The sequence number value on a local controller should be the same as the remote sequence number on the master controller.
ArubaOS 6.5.3.x
| User Guide Control Plane Security | 76
Figure 8 Sequence numbers on Master and Local Controllers
Rogue APs
If you enable auto certificate provisioning enabled with the Auto Cert Allow All option, any AP that appears on the network receives a certificate. If you notice unwanted or rogue APs connecting to your controller via an
IPsec tunnel, verify that automatic certificate provisioning has been disabled, then manually remove the unwanted APs by deleting their entries from the campus AP whitelist.
77 | Control Plane Security ArubaOS 6.5.3.x | User Guide
advertisement
Related manuals
advertisement