locked
ARP table mismatched to IP address RRS feed

  • Question

  • Hi all,

    I have a strange issue where the ARP table (MAC address) does not match the intended IP.
    This happens for student BYOD devices - the student BYOD MAC address is listed with a static server IP address.

    For example, there are different symptoms - but lets say no new user can access the corporate wireless network. When I log into the Network Policy Server (802.1x) and look at the arp cache, the IP address for my Global Catalog DC refers to a student MAC address.

    Usually I either wait, or block the offending MAC address on the network and the problem resolves itself.

    Checking DHCP, it has issued a correct IP address outside the statically assigned server range.

    Where should I start looking? - I have upgraded our switches to Layer-2 managed so I will be implementing VLAN for BYOD, but I have not fully planned this out yet.

    I don't suspect ARP spoofing - some of the users barely know how to connect their device to the network. Could it be device malware?


    • Edited by StixNZ Monday, July 15, 2013 9:18 AM More accurate title
    Wednesday, July 10, 2013 11:34 PM

Answers

All replies

  • Hi,

    “When I log into the Network Policy Server (802.1x) and look at the arp cache, the IP address for my Global Catalog DC refers to a student MAC address.” According your description, it seems is the ARP snooping. There maybe someone’s device has got virus.

    More information:
    Detecting ARP Spoofing Attacks
    http://blogs.technet.com/b/neilcar/archive/2007/07/05/detecting-arp-spoofing-attacks.aspx

    Dynamic ARP Inspection
    http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dynarp.html

    Configuring Dynamic ARP Inspection
    http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.2_25_see/configuration/guide/swdynarp.html

    Hope this helps.


    Alex Lv

    Thursday, July 11, 2013 9:15 AM
  • I am thinking malware / virus but not totally convinced.

    What would happen if the device connected to the network but could not obtain a DHCP lease. Could it at all retain an old lease from a different network (ie at home)

    The suspect devices are always BYOD but appear to be the least suspecting and differ in type. ie the clients have been iPod, iPhone and Android devices. In most cases not rooted, not jailbroken or unlocked/side loaded.

    Monday, July 15, 2013 9:13 AM
  • Base on my experience, the different BYOD system may have the different DHCP obtain fail workflow. About the Windows system DHCP process please refer the following KB:

    How DHCP Technology Works

    http://technet.microsoft.com/en-us/library/cc780760(v=ws.10).aspx

    Hope this helps.


    Alex Lv


    • Edited by Alex Lv Wednesday, July 17, 2013 9:19 AM edit
    • Marked as answer by Alex Lv Wednesday, July 17, 2013 10:59 AM
    Wednesday, July 17, 2013 9:19 AM
  • Thanks Alex,

    I think I am going to work under this assumption:

    If the DHCP client obtained a lease from a DHCP server on a previous occasion, and the lease is still valid (not expired) at system startup, the client tries to renew its lease. If, during the renewal attempt, the client fails to locate any DHCP server, it attempts to ping the default gateway listed in the lease, and proceeds in one of the following ways:

    • If the ping is successful, the DHCP client assumes that it is still located on the same network where it obtained its current lease, and continues to use the lease as long as the lease is still valid. By default the client then attempts, in the background, to renew its lease when 50 percent of its assigned lease time has expired.

    I think that it is possible under some circumstances that I use the same gateway IP as users at home. If a device connected and could not obtain a DHCP lease, and the gateway matches - it may use the same IP that was issued from a different DHCP server.

    I would have thought this would be remote. However I intend to isolate BYOD by VLAN on a much different IP structure which may help in resolving this issue.

    Monday, August 5, 2013 8:45 PM