Detecting in-net rouges with spare APs

  • 1
  • Question
  • Updated 5 years ago
  • Answered
On all of my AP's only the necessary wireless vlans are trunked (ex vlans 6,13,24,50) I want to know if i can still detect in-net rouges on other vlans by using a spare AP in a wiring closet with the radios off but EVERY vlan trunked to the AP?
Photo of Rob


  • 42 Posts
  • 5 Reply Likes

Posted 5 years ago

  • 1
Photo of Tim Ruda

Tim Ruda, Official Rep

  • 40 Posts
  • 56 Reply Likes
Hi Rob,

An Aerohive AP builds a MAC learning table from source MAC addresses in the broadcast traffic it receives from devices in its Layer 2 broadcast domain. When an Aerohive AP running HiveOS 5.0r2 or later detects a rogue AP through any of the rogue detection mechanisms in the WIPS policy, it checks its MAC learning table for an entry within a 64-address range above or 64-address range below the BSSID of the invalid SSID. If there is a match, it is assumed that both MAC addresses belong to the same device. Because one of its addresses is in the MAC learning table, the rogue is considered to be in the same backhaul network as the detecting AP and "In Net" appears in the In Network column for that rogue in the list of rogue APs.

Because of this operation, the same AP must detect the rogue on the radio and in it's MAC table. If a particular hive member detects it on the wire, and another detects it on the radio, the two do not work together to classify it as in-net.

Additionally, since the AP must be on the same channel as the rogue to detect it, having only 1 or two spare AP's would not give you complete detection across a spectrum.

The best way I can think for you to use the AP's as "rogue detectors" only would be to push a policy to them with WIPS at the desired detection settings, but simply disable the SSID's, rather than the radios themselves. If using an existing network policy, you can accomplish this using the SSID allocation option on device-specific configuration.

Monitor tab >> Check the device > Click Modify >>

In theory this should allow the interfaces to perform the detection and compare it with their MAC tables, without using your existing deployment used for serving clients.

I'll admit I have not tested this personally, so I would be happy to be corrected by another employee if there is an issue with my method. My only concern is if disabling the SSID's using SSID allocation will subsequently disable the virtual interfaces (wifi0.1 / 0.2 / 0.3 etc...) that are needed for detection.

Hopefully this provides some help! Let me know if you have any further questions.
Photo of Emilio Maldonado

Emilio Maldonado

  • 37 Posts
  • 11 Reply Likes
HiveAPs can only detect if a rogue AP is in the same subnet as itself (in-net) if the rogue AP has at least one active client and is using the same radio channel as the HiveAP. If you turn off the radio on that closet AP, you won't be able to detect in-net rogues.

Photo of Rob


  • 42 Posts
  • 5 Reply Likes
Tim, Emilio,

Great explanation of how this works! I now have a good understanding so I can come up with another way to accomplish my goals.

Photo of David Coleman

David Coleman, Official Rep

  • 209 Posts
  • 164 Reply Likes
Couple of things. If you want to put an Aerohive AP in a listening-only mode to act as a full-time WIPS sensor... do the following steps:

1) Disable the SSIDs under SSID allocation as Tim suggested.
2) Change the scanning time from 10 to 1 in both radios
3) Any wired VLANs will also need to be trunked to the Aerohive APs for "in-net" rogue detection to work by maintaining a wired MAC table

Some businesses require dedicated WIPS sensors and the above steps will meet those requirements. A good rule of thumb for dedicated WIPS sensors is a ration of 1 to every 5 deployed APs. Also keep in mind that all Aerohive APs can be configured with a WIPS policy and detect rogue devices on their channel when they are not transmitting.