cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1107
Views
15
Helpful
7
Replies

Rogue Detection (Not Seeing "On Wire" Rogues)

jordanperks
Level 1
Level 1

We have been doing some testing and we are unable to see if rogues are on wire. I have a rogue plugged in to the network sitting on my desk plugged in to the ethernet cable that typically goes into my laptop and it will not be seen as on-wire.

I do see it as a Rogue, but not an on-wire rogue. I have got it to discover one on-wire rogue by issuing the following command:

config wps rogue-ap rldp initiate/enable <Rogue-ap MAC Address>

When I try to do this with the current Linksys WRT54G test Rogue I get the following error:

RLDP not supported for this rogue-ap entry

The rogue that I finally (After 3 days on wire) got to be discovered as on-wire was a defaulted Linksys WRT54G and my current rogue that I cannot get discovered is locked down pretty well.

It is configured to:

1. Not broadcast SSID

2. WEP Encrypted

3. Not issue DHCP addresses

Does anyone have any ideas as to what I may be doing wrong?

7 Replies 7

johnruffing
Level 4
Level 4

Hi Jordan,

Please keep in mind that the on-wire rogue detection mechanism works by the controller attempting to ping itself through the rogue AP.

That means that ANY encryption (even WEP as your rogue AP is using) is going to prevent the (somewhat limited) on-wire detection mechanism from working.

Also, the WLC needs to able to ping itself via a reachable network path where the rogue LWAP is connected. In other words, if the rogue AP is connected to an isolated VLAN which cannot reach the WLC controller, the "on-wire" detection mechanism will also be thwarted.

As an aside, if your testing is also going to evaluate the "rogue client" detection mechanism, keep in mind that there needs to be fairly significant RF traffic between the rogue client and the rogue AP to which it is associated in order for the rogue client to be detected. In part, this has to do with how much time the LWAP has to be checking for security issues while it also performs its primary job of carrying traffic. The rogue traffic needs to be seen during the very brief time slice that it gets between traffic-carrying activities.

I hope this helps,

- John

(Please remember to rate helpful posts)

Thanks John.

I was unaware that the encryption would make on-wire detection useless.

Yes, this is very interesting and a bit scary!

I too set a Linkys AP to non-broadcast SSID, no encryption, it was not been detected by WCS or the WLC for over a week that is has been up and running. I am using the thibor software:

http://www.thibor.co.uk

According to the release notes for 4.2, there was/(is?) a known problem in failing to detect on-wire rogues.

I ran into the same problem myself where I setup a test rogue AP (with open security) on the same subnet as the WLC itself. I could PING the WLC from a wireless client connected to the rogue AP, but the controller, while detecting the presence of the rogue AP, was unable to determine that it was on-wire.

As a an aside, the client that I connected to the test rogue AP was *NOT* detected by the WLC as a rogue client. Regarding the failure to detect the rogue client, Cisco TAC said "yes, it's supposed to work that way due to the fact that the LWAP scan fast enough to see small amounts of traffic and do its job as an LWAP at the same time." - Nice! Add to this the fact that the number of rogue clients shown on the summary for the rogue AP will rarely, if ever, match the underlying details records of rogue clients. This should not be surprising since the number of wireless clients on trusted LWAPs shown on the heatmap never matches up with the underlying detail either!

Unfortunately, I have not had time to test if the on-wire rogue AP detection has been fixed in 4.2. The

The bottom line is this: Don't assume that just because the on-wire rogue count is zero that you do not have them.

I do not know if/when this problem is/will be truly fixed.

You may find the following "caveats" regarding rogue AP detecting of interest as well:

CSCsi56611-Client and rogue access point detection might not function properly, and the controller might not respond to SNMP requests.

CSCsi81630-The controller might reboot repeatedly around 5 minutes after startup. This condition usually occurs when the controller, acting as a client station, attempts to associate with a rogue access point.

- John

(Please remember to rate helpful posts)

I just upgraded WCS to 4.2.62.11 and Rogue detection is working very well. Immediate discovery of on-wire rogues. I am very pleased with it.

I will be upgrading to 4.2.62.11 on the production WCS soon. Will let you know how it goes. The test controller I set up with the latest code 4.2 did detect the rogue the 4.1 version did not. Thanks for fixing that Cisco!

Works a lot better. I like the colors for depicting the rogues as known or threat. Sweet improvement. It detected the rogue and shutsthem down quick!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card