Security

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 6.5.0.71095 and AOS 6.3.1.14.

Testing with both Android and iOS clients.

I validated my design with this:

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Step-by-Step-Controller-CPPM-6-5-Captive-Portal-authentication/td-p/229740

Any help would be appreciated.

Thanks,

Shane

Is the VLAN changing during the MAC-auth?

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

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.

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

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.

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>'.

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!

Shane

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.