Hi,
We have several customers who use the guest anchor setup (in a DMZ etc) for their requirements. This causes a couple of challenges for us (as a WiFi provider) and I just wanted to ask the community experience on a few things. I would be very grateful anyone could clarify or comment.
1) When using external webauth, the external Webauth URL that the device is redirected to is missing the "ap_mac" parameter.
i.e. with guest anchor:
https://myportal.net/?switch_url=http://1.1.1.1/login.html&client_mac=11:22:33:44:55:66&wlan=MySSID&redirect=www.bbc.com
without guest anchor:
https://myportal.net/?switch_url=http://1.1.1.1/login.html&ap_mac=aa:bb:cc:dd:ee:ff&client_mac=11:22:33:44:55:66&wlan=MySSID&redirect=www.bbc.com
Is this still because the AP MAC is lost over the mobility tunnel, therefore it cannot forward it on to the webauth URL? I also heard from someone that this changed in 8.2 - but I've not seen evidence of this.
* the reason this matters is because without the ap_mac, we cannot identify the customer/venue because all anchor controllers will point to the same external webauth URL. So at present we have to hard-code a MAC on the end of this URL, but if a customer is using a controller to manage many sites, it means we can't differentiate the site etc.
2) Because it is the guest anchor controller is sending the RADIUS auth and accounting packets to us, we also lose the AP MAC again, and also the traffic counters, like download/upload for the client. Is this the same as above, this information is lost over the mobility tunnel? Quite often the internal (foreign) WLC does not have outbound Internet access so cannot be the RADIUS client in this setup.
3) DNS (FQDN) based ACL's - is this compatible with a guest anchor setup?
Thanks!
James
