Wireless Access

last person joined: 20 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Back to discussions
Expand all | Collapse all

MAC spoof issue

This thread has been viewed 4 times

  • 1.  MAC spoof issue

    Posted Mar 10, 2014 08:21 PM

    Hi,

     

    In the logs we are having following spoof errors: Any ideas what is causing it? Also I have a situation where same IP is assigned to two different clients and its happening on one of our SSID with 802.1x authentication. Controller model is 3400 and OS version is 6.1.3.9.

     


    Mar 11 13:09:27    authmgr[1559]: <522027> <WARN> |authmgr| MAC=50:cc:f8:6a:4d:31 IP=192.168.132.28 IP Spoof from MAC=18:00:2d:37:82:64 role=Authenticated/(null)
    Mar 11 13:09:27    authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)
    Mar 11 13:09:36    authmgr[1559]: <522027> <WARN> |authmgr| MAC=50:cc:f8:6a:4d:31 IP=192.168.132.28 IP Spoof from MAC=18:00:2d:37:82:64 role=Authenticated/(null)
    Mar 11 13:09:37    authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)
    Mar 11 13:09:42    authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)
    Mar 11 13:09:43    authmgr[1559]: <522027> <WARN> |authmgr| MAC=50:cc:f8:6a:4d:31 IP=192.168.132.28 IP Spoof from MAC=18:00:2d:37:82:64 role=Authenticated/(null)
    Mar 11 13:09:45    authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)
    Mar 11 13:09:46    authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)
    Mar 11 13:09:49    authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)

     

     

    Mar 11 13:09:23authmgr[1559]: <124006> <WARN> |authmgr| {486541} UDP srcip=0.0.0.0 srcport=68 dstip=255.255.255.255 dstport=67, action=permit, role=Student, policy=dhcp-acl
    Mar 11 13:09:27authmgr[1559]: <522027> <WARN> |authmgr| MAC=50:cc:f8:6a:4d:31 IP=192.168.132.28 IP Spoof from MAC=18:00:2d:37:82:64 role=Authenticated/(null)
    Mar 11 13:09:27sapd[916]: <404074> <WARN> |AP MUSIC CR1 (d8:c7:c8:ca:83:48)@192.168.116.119 sapd| AM d8:c7:c8:28:34:80: ARM - increasing power cov-index 10/1 tx-power 10 new_rra 6/11
    Mar 11 13:09:27authmgr[1559]: <124006> <WARN> |authmgr| {486542} UDP srcip=0.0.0.0 srcport=68 dstip=255.255.255.255 dstport=67, action=permit, role=Student, policy=dhcp-acl
    Mar 11 13:09:27authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)
    Mar 11 13:09:34authmgr[1559]: <124006> <WARN> |authmgr| {486543} UDP srcip=0.0.0.0 srcport=68 dstip=255.255.255.255 dstport=67, action=permit, role=Student, policy=dhcp-acl
    Mar 11 13:09:34sapd[931]: <404046> <WARN> |AP M2 (6c:f3:7f:cc:99:6c)@192.168.110.125 sapd| AM 6c:f3:7f:49:96:c8: Low RSSI 6 detected for STA 88:1f:a1:eb:3f:54 BSS 6c:f3:7f:49:96:ca ESS Rosmini_Hotspot Deauthing STA
    Mar 11 13:09:36authmgr[1559]: <522027> <WARN> |authmgr| MAC=50:cc:f8:6a:4d:31 IP=192.168.132.28 IP Spoof from MAC=18:00:2d:37:82:64 role=Authenticated/(null)
    Mar 11 13:09:37authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)
    Mar 11 13:09:37authmgr[1559]: <124006> <WARN> |authmgr| {486544} UDP srcip=0.0.0.0 srcport=68 dstip=255.255.255.255 dstport=67, action=permit, role=Student, policy=dhcp-acl
    Mar 11 13:09:38authmgr[1559]: <124032> <WARN> |authmgr| XML command=user_add (2) result='Ok', error=''
    Mar 11 13:09:40authmgr[1559]: <124006> <WARN> |authmgr| {486545} TCP srcip=172.16.2.82 srcport=54223 dstip=54.225.248.74 dstport=4244, action=permit, role=Student, policy=svc-DMZ-rdp-rcts01
    Mar 11 13:09:40authmgr[1559]: <124006> <WARN> |authmgr| {486546} UDP srcip=0.0.0.0 srcport=68 dstip=255.255.255.255 dstport=67, action=permit, role=Student, policy=dhcp-acl
    Mar 11 13:09:42authmgr[1559]: <124006> <WARN> |authmgr| {486547} UDP srcip=0.0.0.0 srcport=68 dstip=255.255.255.255 dstport=67, action=permit, role=Student, policy=dhcp-acl
    Mar 11 13:09:42authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)
    Mar 11 13:09:43authmgr[1559]: <522027> <WARN> |authmgr| MAC=50:cc:f8:6a:4d:31 IP=192.168.132.28 IP Spoof from MAC=18:00:2d:37:82:64 role=Authenticated/(null)
    Mar 11 13:09:45authmgr[1559]: <132093> <ERRS> |authmgr| WPA2 Key message 2 from Station b8:5e:7b:93:56:d6 00:24:6c:aa:fc:21 C2 (00:24:6c:c2:af:c2) did not match the replay counter 02 vs 03
    Mar 11 13:09:45authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)
    Mar 11 13:09:46authmgr[1559]: <124006> <WARN> |authmgr| {486548} UDP srcip=0.0.0.0 srcport=68 dstip=255.255.255.255 dstport=67, action=permit, role=Student, policy=dhcp-acl
    Mar 11 13:09:46authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)
    Mar 11 13:09:47authmgr[1559]: <132093> <ERRS> |authmgr| WPA2 Key message 2 from Station b8:5e:7b:93:56:d6 00:24:6c:aa:fc:21 C2 (00:24:6c:c2:af:c2) did not match the replay counter 03 vs 04
    Mar 11 13:09:49authmgr[1559]: <522027> <WARN> |authmgr| MAC=88:53:95:5b:72:2c IP=192.168.132.35 IP Spoof from MAC=88:53:95:cf:72:f3 role=Authenticated/(null)
    Mar 11 13:09:49sapd[593]: <404074> <WARN> |AP R6 (6c:f3:7f:cc:99:37)@192.168.105.125 sapd| AM 6c:f3:7f:49:93:70: ARM - increasing power cov-index 11/1 tx-power 11 new_rra 1/12
    Mar 11 13:09:54webui[1427]: USER: admin has logged in from 192.168.110.139.
    Mar 11 13:09:57authmgr[1559]: <124006> <WARN> |authmgr| {486549} UDP srcip=0.0.0.0 srcport=68 dstip=255.255.255.255 dstport=67, action=permit, role=Student, policy=dhcp-acl
    Mar 11 13:09:57authmgr[1559]: <124006> <WARN> |authmgr| {486550} UDP srcip=0.0.0.0 srcport=68 dstip=255.255.255.255 dstport=67, action=permit, role=Student, policy=dhcp-acl
    Mar 11 13:09:58authmgr[1559]: <124006> <WARN> |authmgr| {486551} UDP srcip=172.16.2.231 srcport=68 dstip=255.255.255.255 dstport=67, action=permit, role=Student, policy=dhcp-acl
    Mar 11 13:09:58authmgr[1559]: <124006> <WARN> |authmgr| {486552} UDP srcip=172.16.0.1 srcport=67 dstip=172.16.2.231 dstport=68, action=permit, role=Student, policy=dhcp-acl
    Mar 11 13:09:58authmgr[1559]: <124006> <WARN> |authmgr| {486553} TCP srcip=172.16.1.171 srcport=37707 dstip=74.125.31.188 dstport=5228, action=permit, role=Student, policy=Internet
    Mar 11 13:09:59

    authmgr[1559]: <124032> <WARN> |authmgr| XML command=user_add (2) result='Ok', error=''

     

     

     

     

     

     

     


    #3400


  • 2.  RE: MAC spoof issue
    Best Answer

    EMPLOYEE
    Posted Mar 10, 2014 09:07 PM

    Your first set of logs show ip spoofing, meaning a device tries to enter the user table with an ip address that is already in there.  There is a reason why this could happen:

     

    If your DHCP lease is less than your user-idle-timeout, you will have this problem.  To see your user-idle timeout:

     

    user-idle.png

     

    The user idle-timeout says how long a user stays in the user table before he is timed out.  By default it is 300 seconds but some people increase this so that people do not have to logon as often to the captive portal.  As this is increased, it shows more and more users that are no longer connected to the controller and if this number is more than your lease time, your DHCP server will happily assign an ip address that is still in the user table to another user...generating the ip spoof.

     

    Check to make sure that your global user idle timeout is less than your lease time, to see if it is your reason for the spoofing messages.

     

    The second set of logs is only logging for students.  It does not really matter.

     



  • 3.  RE: MAC spoof issue

    Posted Mar 10, 2014 09:15 PM

    I thought so. Yes we have increased default idle time-out. Having said that it is happening only on one SSID and I know that aaa timer is a global parameter. Also I have checked on our dhcp that lease time is 10 hours so it is already more than the aaa user timeout set on controller.

     

    I have also set "enforce dhcp" under aaa profile for that particular SSID.



  • 4.  RE: MAC spoof issue

    Posted Mar 10, 2014 09:22 PM

    I am also having one more issue. One SSID is setup to have WPA2-PSK. Client first enter a preshared key to connect to wireless network and then they get the captive portal to login. But I am getting following in the logs and on devices it says authentication error during roaming i believe:

     

    Mar 11 14:11:03authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station d0:51:62:e5:46:f0 d8:c7:c8:28:33:e2 DRAMA (d8:c7:c8:ca:83:3e)
    Mar 11 14:11:04authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station 04:db:56:4b:6a:38 6c:f3:7f:49:96:5a C1 (6c:f3:7f:cc:99:65)
    Mar 11 14:11:04authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station d0:51:62:e5:46:f0 d8:c7:c8:28:33:e2 DRAMA (d8:c7:c8:ca:83:3e)
    Mar 11 14:11:05authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station 04:db:56:4b:6a:38 6c:f3:7f:49:96:5a C1 (6c:f3:7f:cc:99:65)
    Mar 11 14:11:05authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station d0:51:62:e5:46:f0 d8:c7:c8:28:33:e2 DRAMA (d8:c7:c8:ca:83:3e)
    Mar 11 14:11:06authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station 04:db:56:4b:6a:38 6c:f3:7f:49:96:5a C1 (6c:f3:7f:cc:99:65)

     

     

     

     

     



  • 5.  RE: MAC spoof issue
    Best Answer

    EMPLOYEE
    Posted Mar 10, 2014 09:40 PM
    @fqureshi@rosmini.school.nz wrote:

    I am also having one more issue. One SSID is setup to have WPA2-PSK. Client first enter a preshared key to connect to wireless network and then they get the captive portal to login. But I am getting following in the logs and on devices it says authentication error during roaming i believe:

     

    Mar 11 14:11:03 authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station d0:51:62:e5:46:f0 d8:c7:c8:28:33:e2 DRAMA (d8:c7:c8:ca:83:3e)
    Mar 11 14:11:04 authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station 04:db:56:4b:6a:38 6c:f3:7f:49:96:5a C1 (6c:f3:7f:cc:99:65)
    Mar 11 14:11:04 authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station d0:51:62:e5:46:f0 d8:c7:c8:28:33:e2 DRAMA (d8:c7:c8:ca:83:3e)
    Mar 11 14:11:05 authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station 04:db:56:4b:6a:38 6c:f3:7f:49:96:5a C1 (6c:f3:7f:cc:99:65)
    Mar 11 14:11:05 authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station d0:51:62:e5:46:f0 d8:c7:c8:28:33:e2 DRAMA (d8:c7:c8:ca:83:3e)
    Mar 11 14:11:06 authmgr[1559]: <132094> <WARN> |authmgr| MIC failed in WPA2 Key Message 2 from Station 04:db:56:4b:6a:38 6c:f3:7f:49:96:5a C1 (6c:f3:7f:cc:99:65)

     

     

     

     

     

    That normally means an incorrect preshared key (unlikely) or alot of contention means that key exchanges fail to complete due to collisions.



  • 6.  RE: MAC spoof issue

    EMPLOYEE
    Posted Mar 10, 2014 09:38 PM

    It really makes a big difference in captive portal networks because alot of users who do not authenticate get an ip address and just sit there.  Either:  (1) Match the idle timeout with your scope duration (2) Match your scope duration with your idle timeout or (3) Move as many people as possible to 802.1x and reduce the idle timeout.



  • 7.  RE: MAC spoof issue

    EMPLOYEE
    Posted Mar 10, 2014 09:40 PM
    @fqureshi@rosmini.school.nz wrote:

    I thought so. Yes we have increased default idle time-out. Having said that it is happening only on one SSID and I know that aaa timer is a global parameter. Also I have checked on our dhcp that lease time is 10 hours so it is already more than the aaa user timeout set on controller.

     

    I have also set "enforce dhcp" under aaa profile for that particular SSID.

     

     

    Enforce DHCP does not matter.  That only makes sure that nobody has static ip addresses.  Your DHCP server will happily give out ip addresses that are still in the user table, because the lease has expired, but the idle timeout keeps it in the user table.