Wireless Access

We are having issues across our enterprise network with a new Guest access that we have implemented.

Our topology looks like this.

Local AP's in a given building, Local controller in same building, and a 3200 Guest Controller in a DMZ for internet access.

The guest controller is acting as the DHCP server.

If we use a PC or laptop, we connect successfully 100% of the time. When we disable the session and re-establish the session, we are also successfull at reconnecting.

When we use any type of handheld device, Iphone, Blackberry, tablets etc, For the first attempt to connect to the Guest access, we are for the most part, successful.

If we turn off wifi and turn it back on, or reboot the handheld device, they cannot re-establish a DHCP address.

Our protocol analyzer team has captured traffic via sniffing inside the GRE tunnels and discovered the following:

When the handheld device attempts to re-establish a connection to Guest access, it does a "DHCP Discovery"

The Guest controller in the DMZ responds back with a "DHCP Offer", but it is responding to the handhelds original IP address that it had on the first successful session. However, the handheld does not have an IP address yet, it is trying to get one. So the local controller sends the unicast to the AP and the Offer never makes it to the handheld.

Should the Guest controller in the DMZ not send a DHCP Offer via a Broadcast  to find the MAC address of the handheld rather than a unicast to the originalIP address?

When we sniff the same traffic but from a Laptop, who is attempting to re-establish a new connection, the Laptop sends a DHCP Request, and not a "DHCP Discovery", to the DMZ controller.

Whats funny here, is that the DMZ controller responds to with a "DHCP ACK" by sending a broadcast to find the MAC address of the machine.

I'm not certain if this can be fixed by some derivation rules, or options on the controller.

Looking for suggestions,

Thanks,

I have seen this same behavior when the DHCP acl is not setup properly (if you created one within your policy).  

Ensure the policy states:

any any svc-dhcp permit

and NOT

user any svc-dhcp permit

If the latter is set and a client attempts to renew an IP (as yours are doing), the policy blocks the client from receiving the response from the DHCP server.

Can you please post the firewall policies associated with the role of the clients?   

show rights <rolename>

The policy is configured as "any any svc-dhcp permit"

Traffic is also confirmed passing the Firewalls.

Do you have  logon role and a post logon role for the guests?  Are they both setup that way for DHCP?   What I've seen happen is a mobile device go to sleep, awake and connect.  The user (depending on the user lifetime setting) may still be in the table as a post authenticated guest role.  Please make sure that role also has it setup that way.

If that all holds up, run DHCP debugging for one of the clients:

    config t

    logging level debugging network subcat dhcp

attempt to connect with the device; when it fails run:

   show log network all | include <MAC of client>

when done run

    no logging level debugging network subcat dhcp