Product and Software: This article applies to all Aruba controllers and ArubaOS versions.
A rogue AP is an unauthorized AP that is plugged into the wired side of the network. ArubaOS provides the Rogue AP detection functionality available in the base operating system.
Before ArubaOS can classify an AP as a rogue and consequently contain it, the OS must detect the AP, detect any stations that associate to it, and detect the wired devices with which it attempts to communicate.
To detect wireless devices, Access Point (AP) and Air Monitor (AM) scan the air looking for new devices and keeping tabs on existing devices.
- AMs always scan and they scan every possible channel in order, even channels outside of the regulatory domain for one second. The AM remains on a channel to contain a rogue AP for up to 32 seconds. This is not configurable.
- APs only scan if ARM scanning is enabled, and they scan less often since they must provide wireless access on their service channel. The Scan Time, Scan Interval, and Beacon Interval determine how often and for how long the AP scans nonservice channels. The AP never scans for more than 0.8 times the Beacon Interval to make sure it can transmit each beacon and perform other necessary actions. By default, the AP never scans a channel for longer than 80 ms since the Beacon Interval is 100 ms by default. The AP scans the next channel only after providing access on the service channel for Scan Interval seconds. How often the AP scans is configurable. Note: Unlike AMs, APs only scan the channels within the regulatory domain. This means that the AP will never detect a wireless device (for example, a rogue AP) that is operating on an illegal channel.
Since it is possible to carry APs across international borders and even configure an illegal channel on some, you should keep this in mind when deploying APs without any AMs.
To correctly classify and contain rogue APs, each Aruba AP and AM must also see specific traffic on the wire. So, in addition to scanning the air, they scan the wire to record MAC addresses and look for routers and gateways. Gateways are important for classification. They are the default gateways used by the APs. Their MAC addresses are propagated by the WMS process on the controller to all of the APs in the RF vicinity. RF vicinity is defined by building in 2.x and by what APs can hear each other in 3.x.
Routers are detected by inspecting the TTL of received traffic. If the TTL is 31, 63, 127, or 254, the sender is most likely a router. Routers are possible wireless gateways (L3 APs). They have to be manually inspected by the user to determine if they are valid devices.
Each AP/AM maintains a list of all APs, stations, gateways, and wired MAC addresses it can see. Each AP/AM also maintains a list of associations, that is, which stations are associated to which APs. The amount of information stored is capped and this information is aged out when the specific device is inactive for a configurable period of time.
To correctly classify an AP as a rogue, an Aruba AP must be able to hear the AP and be a member of its wired broadcast domain, that is, VLAN. If many VLANs are in the area, all of these VLANs should be trunked to each Aruba AP. If the AP is a bridge (L2 AP, not a wireless router), the Aruba AP must also be able to hear any station that associates to the rogue AP. An AP is classified as rogue when wired traffic is seen from a gateway (or any known wired MAC address in 2.x) transmitted into the air to a station associated to the AP.
(However, routers with a well-known MAC address, for example, an HSRP MAC address, are ignored. An option was added to 188.8.131.52 to disable ignoring these MAC addresses, but please be mindful that nearby networks may also be using these MAC addresses.) Gateway MAC addresses are propagated to all APs within earshot so that there is a better chance of classifying an AP as rogue.
A wireless router (L3 APs or NAT APs) can only be classified as a rogue it if its wired (WAN) MAC address is adjacent to (off by one from) its WLAN MAC address (BSSID). (This is enabled via “wms ap-policy adj-mac-classification” in 2.x and is always enabled in 3.x.)