The Cisco WLC supports guest access in addition to the normal user SSID/VLAN combinations. They've actually buitl a very nice implementation of it. You can force a splash screen (captive portal) through a web page to force guests to sign in and/or accept an Acceptable Use Policy. Providing Guest access requires a sensitivity to security issues though. It wouldn't be wise to run the Guest VLAN right into the middle of the network. In the situation I ran into I created a VLAN that didn't terminate to any interfaces inside the network. The SSID for Guests had access to the VLAN and a physical port in the same VLAN was connected to a "DMZ" port on the firewall. That port on the firewall (PIX) was then set with a security level just below that of the outside interface. Works great except how do you get DHCP to the wireless Guest clients?
I tried configuring a DHCP scope on the PIX to no avail. I believe the PIX wasn't allowing the forwarding of DHCP information from the Controller. Since the Controller acts as a proxy of sorts it would be similar to using a broadcast helper pointing at the PIX. I haven't checked to see if that's why it was broken but it makes sense. The other alternative is to either allow DHCP through the PIX back to the LAN, or to configure a virtual interface and a helper. Either way the Guest client is touching an internal DHCP server and we have to be sure the ACL's are dead on so that nothing else gets through. I don't like that idea.
A third alternative is to use the built in DHCP server on the Controller. Tried that, didn't work. Shane thinks he's found out why. Each virtual interface inside the controller that's tied to an SSID/VLAN combination has the option for "DHCP Override". Naturally I tried this on the interface for the Guest SSID/VLAN. It would seem that the proper place is on the Management interface instead. The scope is still created for the Guest subnet but it's forwarded by the Management interface to the internal DHCP server. That might make some sense. The LWAPP encapsulated packets are arriving on the Management interface before getting processed and shipped to the appropriate VLAN. As a helper of sorts it would stand to reason it needs to be on the incoming interface. Just seemed counter-intuitive to me.