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.