05-13-2015 11:23 AM
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 22.214.171.124095 and AOS 126.96.36.199.
Testing with both Android and iOS clients.
I validated my design with this:
Any help would be appreciated.
Solved! Go to Solution.
05-13-2015 12:55 PM - edited 05-13-2015 12: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.
Systems Engineer, Northeast USA
ACCX | ACDX | ACMX
05-13-2015 04: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.
05-13-2015 05: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>'.
Swathi (ACMX, CWDP, CWNA, CCNA)
[Hit Kudos if this post helps]
05-13-2015 08:11 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!
10-29-2015 01:44 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.