Reason for Identity Theft

bradleyordner · ‎04-02-2019

Hi,

Just wondering if other people have come across this message in the WLC Reason - Identity Theft. We are running code - 8.5.140.x and one machine out of 100's just won't connect to our WLC. The machine gets excluded as - Identity Theft and the debug of client doesn't give anything meaningful. It is as if it just won't get an IP address, so I am suspecting a laptop issue at this stage.

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Mobility query, PEM State: L2AUTHCOMPLETE

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Building Mobile Announce :

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Building Client Payload:

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Client Ip: 0.0.0.0

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Client Vlan Ip: x.x.x.x., Vlan mask : 255.255.252.0

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Client Vap Security: 16384

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Virtual Ip: 2.2.2.2

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d ssid: xxxxxxxxxxx

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Building VlanIpPayload.

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Not Using WMM Compliance code qosCap 00
*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d flex webauth acl id to be sent when fabric is disabled:65535
*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d flex webauth acl id to be sent :65535 name : client acl id : 65535
*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Vlan while overriding the policy = -1
*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d sending to spamAddMobile vlanId -1 aclName = , flexAclId 65535

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d 0.0.0.0 L2AUTHCOMPLETE (4) Plumbed mobile LWAPP rule on AP 70:e4:22:dd:18:b0 vapId 8 apVapId 2 flex-acl-name:
*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d 0.0.0.0 L2AUTHCOMPLETE (4) Change state to DHCP_REQD (7) last state L2AUTHCOMPLETE (4)

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d spamSendFabricClientRegistration: Not sending Registration for Fabric client 44:85:00:9e:5f:4d, primary and secondary MS IP is zero
*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 7007, Adding TMP rule
*spamApTask3: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Add SGT:0 to AP 70:e4:22:dd:18:b0
*spamApTask3: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Add CTS mobile SGT - Encoded the capwap payload for the mobile with SGT 0
*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d 0.0.0.0 DHCP_REQD (7) Adding Fast Path rule
type = Airespace AP - Learn IP address
on AP 70:e4:22:dd:18:b0, slot 1, interface = 8, QOS = 2
IPv4 ACL ID = 255, IPv
*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 5, DSCP = 46, TokenID = 64206, IntfId = 10 Local Bridging Vlan = 10, Local Bridging intf id = 10
*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) AVC Ratelimit: AppID = 0 ,AppAction = 4, AppToken = 64206 AverageRate = 0, BurstRate = 0

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) AVC Ratelimit: AppID = 0 ,AppAction = 4, AppToken = 64206 AverageRate = 0, BurstRate = 0

*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (IPv4 ACL ID 255, IPv6 ACL ID 255, L2 ACL ID 255,URL ACL ID 255,URL ACL Action 0)
*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d 0.0.0.0 DHCP_REQD (7) NO release MSCB
*Dot1x_NW_MsgTask_5: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d Successfully Plumbed PTK session Keysfor mobile 44:85:00:9e:5f:4d
*pemReceiveTask: Apr 02 11:20:05.996: [PA] 44:85:00:9e:5f:4d 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0
*DHCP Socket Task: Apr 02 11:20:06.011: [PA] 44:85:00:9e:5f:4d DHCP received op BOOTREQUEST (1) (len 345,vlan 2, port 8, encap 0xec03, xid 0x7c04b84d)
*DHCP Socket Task: Apr 02 11:20:06.011: [PA] 44:85:00:9e:5f:4d DHCP (encap type 0xec03) mstype 0ff:ff:ff:ff:ff:ff
*DHCP Socket Task: Apr 02 11:20:06.011: [PA] 44:85:00:9e:5f:4d DHCP dropping packet due to ongoing mobility handshake exchange, (siaddr 0.0.0.0, mobility state = 'apfMsMmQueryRequested'
*dtlArpTask: Apr 02 11:20:06.038: [PA] 44:85:00:9e:5f:4d apfBlacklistMobileStationEntry2 (apf_ms.c:6966) Changing state for mobile 44:85:00:9e:5f:4d on AP 70:e4:22:dd:18:b0 from Associated to Exclusion-list (1)

*dtlArpTask: Apr 02 11:20:06.038: [PA] 44:85:00:9e:5f:4d Scheduling deletion of Mobile Station: (callerId: 44) in 10 seconds

They went to another office, connected to the local WLC (which uses the same backend ISE) and no problems. Come back to Head Office and won't connect.

At the moment it looks like the machine and its MAC just won't play ball on the local controller here. I have cleared IP address in the DHCP scope, I have joined machine to domain again and updated client certificates.

Is there any other commands or reference I can use on the WLC? I am going to take a packet capture on the device as well I think.

Thanks!

patoberli · ‎04-02-2019

I doubt this is the solution, but check on the WLC under Security -> AAA -> Disabled Clients. Is it entered here?
Otherwise, update the driver of the Wi-Fi adapter on the client, might be a weird bug.

bradleyordner · ‎04-03-2019

I just got the machine reimaged and it is still not working. I am going to
take a capture of the client tomorrow to see what is happening.

Brad

bradleyordner · ‎04-04-2019

For anyone interested, Re image did not fix it.

I did find the following -

1. Machine immediately requests the IP address of the SSID interface on the controller when wireless is activated.

2. The DHCP server is incorrectly configured to lease this IP

3. No offer is sent from DHCP server, but the laptop starts to use the IP and sends a GARP.

4. Eventually the IP appears in the DHCP leases.

So, for some reason this machine out of all machines requests this IP, even when moving this internal wireless card to another laptop. At this stage I am getting the DHCP scope adjusted and will continue looking into why this card likes this IP.

bradleyordner · ‎04-11-2019

Update -

1.Removed the offending addressing from the DHCP scope. This IP is the SSIDs interface IP.

2. Cleared the IP from leases

3. Removed wireless card on motherboard and reinstalled.

The following occurs -

1. Wireless Card powers up and once again requests the IP of the SSID’s interface on the WLC.

2. The host checks to see if the IP is in use and receives a ARP message saying it is.

3. The host then sends a GARP and the switch learns the wireless hosts Mac and Re writes the ARP table.

I can’t figure out why the card holds onto this address and also why the switch overwrites the ARP table.

Is is there a possibility of hardware level malware or corruption?

patoberli · ‎04-11-2019

Does the client really do the DHCP Request? You can use Wireshark on the client to check this. Filter for bootp.

The client should do a DHCP Request, then your DHCP should send a DHCP Offer. Inside that offer packet, you should see a valid IP address of your range, one that is not reserved or blocked. And lastly the client and then the server sends a DHCP Ack.

If the DHCP server still offers the wrong address, make sure it hasn't an old entry in it's database from the previous tests, some servers don't update their lease table if you add an address to the blocked list!

If the client doesn't do a dhcp handshake at all, it has it configured as a fixed address somewhere in its system.

bradleyordner · ‎04-12-2019

Hi,

The first message I capture on wireshark once he has authenticated is a DHCP Request for the IP in question. It never got a reply when it was configured in the scope, it just takes it. Now that I have removed the IP from the scope it still does the same thing.

Now, if I put this card in another machine it does the exact same thing!

If I give it a static IP address, it connects to the network. Then when i removed the static, it does the same thing and requests the other IP again.

It really looks like this NIC card is haunted lol.

I am doing one more test, moving the card to another laptop and connecting to another wireless first, then back to ours. If it still occurs I am sending the network card back to Intel.

patoberli · ‎04-12-2019

Sounds like the card has a buggy firmware, yeah I would indeed exchange it.