In-net Rogue Access Points

  • 2
  • Question
  • Updated 5 years ago
  • Answered
I have two sites (both running on-premise HiveManagers - one on 5.1r5 and one on 6.1r1) where access points in neighbouring sites are being detected by Aerohive's WIPS as being in-net when there is no way they can be. One of the sites is next to a major shopping mall and the HiveManager is regularly reporting that the shop's wireless ADSL routers are in-net rogues. It is not hard to work out where the BSSID is located as the SSID is commonly the shop's name.

My questions are:

  1. From a low level technical point of view what does the Aerohive access point to locate an in-net rouge access point? Is it as simple as using ARPs to detect the rogue access point on a VLAN that is trunked to the Aerohive access point?
  2. How can an Aerohive access point that has no access to a local ADSL circuit determine that a neighbouring access point, which is on a local ADSL circuit, is an in-net rogue access point?
  3. Can we see the WIPS information in any debug log, for example?
Photo of Crowdie

Crowdie, Champ

  • 960 Posts
  • 269 Reply Likes

Posted 5 years ago

  • 2
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1026 Posts
  • 269 Reply Likes
Rogues are anything that doesn't match the WIPS policies.

APs scan the radio spectrum and then check the scan results against one or more specified characteristics of a valid access point. If an access point is discovered that does not comply with the specified criteria, it is categorized as a rogue access point. The criteria identifying a valid access point can be one or more of the following:
- The MAC OUI of the access point
- The SSID names that the access point advertises
- Whether the SSIDs use encryption and, if so, what type of encryption
- If the SSID advertises support for short preambles in its beacons and probe responses
- Whether an SSID supports WMM (Wi-Fi Multimedia) classification for QoS (Quality of Service)
- Whether an access point transmits beacons at the expected interval
- Whether beacons and probe responses advertise IBSS (independent basic service set) capabilities, which are used to establish an ad hoc network

We declare a given rogue AP is "in-net" when we see it's MAC address on both the wired and wireless interfaces. Since most enterprise-class (and many SOHO-class) access points have multiple MACs, we look for anything within +/- 64 of the original observed MAC address. In other words, if we saw DEADBEEF on wireless and then saw DEADBEE0 or DEADBEFE on wired we would think they are the same device and declare it to be "in-net".

It IS possible, although not terribly common, for us to falsely declare a rogue AP to be "in-net", if the MAC addresses of legitimate equipment is too close to that of an AP discovered via scanning for rogues.

I hope this helps.

I'll have to defer the answering of your debug questions to our support folks, who are much more familiar with the CLI than I am.
Photo of Emilio Maldonado

Emilio Maldonado

  • 37 Posts
  • 11 Reply Likes
This thread explains how in-net rogues are detected.

Also a typical case is missing the OUI's of known AH AP's, can you make sure you add the latest OUI's to your list of "good devices"(as indicated in this other thread)

Photo of Crowdie

Crowdie, Champ

  • 960 Posts
  • 269 Reply Likes
I have looked at the OUIs and they are correct.

I have looked at the BSSID reported by the WIPS system and it is an Aerohive OUI broadcasting our customer's SSID but the BSSID is not from any of the customer's access points.

The BSSID being reported as an in-net rogue ends FCD5. The customer has three access points whose Node ID is close - FC00, FC40 and FC80 - but none of them are close enough to be generating a BSSID of FCD5.