last person joined: 4 hours ago 

Enterprise security using ClearPass Policy Management, ClearPass Security Exchange, IntroSpect, VIA, 360 Security Exchange, Extensions and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

Guest MAC Auth Issue

Jump to Best Answer
  • 1.  Guest MAC Auth Issue

    Posted May 13, 2015 02:23 PM

    Ran into an issue with Guest MAC Auth that I'm unable to solve.


    I created a Guest MAC Auth service in ClearPass - it works as one would expect. New client isn't found in then Endpoint Repository, forced to Captive Portal, end user authenticates and then the client is updated as known. Here's the issue.


    When the client disconnects from the guest SSID, and then after a period of time, attempts to reconnect, the client never gets an IP address. In Access Tracker, the client shows that all is well and that it was provided the correct role and rights, but no IP address is ever provided and eventually, the client times out.


    Has anyone ever seen/experienced this before? Currently running CPPM and AOS

    Testing with both Android and iOS clients.


    I validated my design with this:


    Any help would be appreciated.




  • 2.  RE: Guest MAC Auth Issue

    Posted May 13, 2015 02:31 PM

    Is the VLAN changing during the MAC-auth?

  • 3.  RE: Guest MAC Auth Issue

    Posted May 13, 2015 03:05 PM

    No - all the traffic is being contained to the Guest VLAN.

  • 4.  RE: Guest MAC Auth Issue
    Best Answer

    Posted May 13, 2015 03:55 PM

    When the device comes back online (as MAC Auth; not user auth); what role does the controller show the user in?    What are the rights:


    show rights <name-of-role>


    Also, make sure you have MAC authentication and appropriate profiles defined.

  • 5.  RE: Guest MAC Auth Issue

    Posted May 13, 2015 05:36 PM

    Can you try running a packet capture (wireshark) on the client when it reconnects ? Do you see a DHCP Offer ?

  • 6.  RE: Guest MAC Auth Issue

    Posted May 13, 2015 07:48 PM

    Thanks for the reply Swathi-


    I had this same thought this afternoon. I did run a packet capture and saw only DHCP discovers coming from the client. I am running down this thread. It seems odd that on the initial authentication (captive portal), DHCP is ok, but on follow up authentication (MAC Auth), DHCP is not. I'm going back through my roles and ACL's to make sure something isn't screwy.

  • 7.  RE: Guest MAC Auth Issue

    Posted May 13, 2015 08:01 PM

    Does the client fall in the same role and/or same VLAN after MAC auth ? Verify if you have DHCP permit ACL, if it is a different user-role. Verify if there is DHCP Helper configured if it is a different Guest VLAN.


    Besides, you can enable DHCP debugging on the controller for further debugging.

    To enable from CLI, run:

    - 'logging level debugging network process dhcpd' &

    - 'logging level debugging network subcat dhcp'.


    To view the logs run 'show log network all | include <Client MAC>'.

  • 8.  RE: Guest MAC Auth Issue
    Best Answer

    Posted May 13, 2015 11:12 PM

    I figured out my own problem (which is always exciting...)


    The issue was around, as clembo always leads off with, the user role configuration. The user role that was set up was not defined properly and was creating the DHCP havoc that I was experiencing. I created a new user role for the guest users, which was more generic to guest access, updated my ClearPass Mac Auth service and voila! All is right in the world again.


    As always, many thanks for all the quick replies!




  • 9.  RE: Guest MAC Auth Issue

    Posted Oct 29, 2015 04:45 PM


    I'm replying to this old topic because it is what comes up when people will search

    for a problem I just resolved (I think.)


    It is very similar to the above problem, but there is nothing especially wrong with the

    ACLs on the user-roles.  It stems from the fact that, during initial connection, the stateful

    firewall will apparently treat the DHCP traffic differently and reliably deliver responses

    from the DHCP server to the client from the pre-web-auth state, but even with the

    same ACL in the post-mac-auth role, DHCP responses will be blocked.


    In our case, we were allowing a bare minimum of bootstrap traffic, enforcing DHCP,

    prohibiting client-to-client traffic, and our IP gateway is not our controller.


    Clients will log in through the portal, then be placed in a new role after the following

    MAC-auth succeeds.  The new user role has the same bootstrap ACL in it as the

    initial login role, minus the HTTP hijacking rules, and extra permissions beyond that.

    One would think it would behave the same, but DHCP responses get blocked.


    This will work fine until such a point as the device undergoes an event where it runs a

    DHCP transaction, and at that point reponses from the DHCP server will be blocked --

    you can see them in your DHCP server logs as having been sent, but they will not appear

    in a syslog with dhcp debugging turned on.  (Less occasionally, the REQUEST packets

    from the client will also be blocked but the DISCOVER packets will make it through,

    but this behavior is sporadic.)  If you delete the user from the user table, the device will

    again be able to complete a full DHCP transaction.


    The exact UX that results varies from device to device.  Some iPads, for example, will

    stop using the address while they DHCP, but will resume using the address when they

    get no answer.  So there will be a 30-second problem accessing the network every time

    this happens, and the device may decide to start using 4G instead.  There may be a recent

    addition to Apple's itinerary of strange behaviors which is making this more noticeable to

    the end user on newer iOS loads.


    In any case, (I know, I know, TLDR) things seemed to shape up when we added a permit rule

    allowing any traffic from the address of the gateway where the DHCP relay agent lives like so:


    ip access-list session UnsecureGuest-BootStrap

       host <relay agent IP> any any permit


    (Of course, if you have a deny all rule in that ACL you'll need to move it above that)


    We may tighten that some.  The fact that we had to use a rule in the to-client direction to allow the traffic

    suggests something in the stateful part of the firewall is going wonky and failing to build a

    reciprocal connection for DHCP traffic during these role changes due to web authentication.  It

    handles stateful session construction for normal traffic just fine on both sides of the transition.