I would like to shed some light on how exactly the guest redirect works when a guest user connects and is redirected to the WLC’s captive portal. This is one of those items that I always overlooked (because it was working) but was forced to learn when it was found the virtual IP address was causing problems. You can read about that here if you would like.
The following is the text from Cisco’s WLC Configuration Guide:
With Layer 3 security, the client will issue a DNS query for a web server; the controller spoofs the DNS
response, providing its own Virtual IP address. The client then opens a web connection (HTTP port 80 or
HTTPS port 443) to that address. The controller redirects(to itself [Local Web Authentication] or to an external
server [Central Web Authentication]), and then that dialog is used to authorize the client to connect to the
network.
Many times it is easier for me to understand something if it is laid out in a step-by-step, serial fashion. In order to help out the reader, I thought it would be best to capture some packets and illustrate the process of how a guest user is redirected to the captive portal.
Upon connecting, the device uses DHCP to get an IP address. In the instance shown below, the device is requesting an IP address immediately instead of going through the full DORA process. Note the virtual IP is used as the source and in this case is being used as the DHCP relay (the WLC is the DHCP server).
The client’s OS is Windows 10 and Microsoft has a built-in method for testing whether or not the computer is connected to the internet when it detects a potential hotspot. It will send a packet to msftconnecttest.com. The guest wlan is configured such that 8.8.8.8 is utilized for DNS. Note the computer sends a DNS request for msftconnecttest.com and a response is given.
Now that the computer knows how to communicate to msftconnecttest.com, it next attempts to communicate with the server by sending an HTTP request to “4-c-0003-.c-msedge.net”. It is not shown below, but the response in packet 5 gave both the IP address as well as the URL. The packet capture tool used the URL in packet 6 instead of the IP address in the Destination column. The WLC spoofs the server in packet 8 and redirects the client to “guest.company.com”…very sneaky eh?
The client does a DNS lookup to be able to get to guest.company.com. This step is very important as an external DNS server needs to to have a DNS record pointing it to the virtual IP address. This caused some confusion because it didn’t make any sense that a DNS record was going to point to a virtual IP address that was not routable! Nonetheless, this is how the WLC and the client communicate…please note there is never any traffic on the distribution system addressed to this IP address. This traffic is only between the wireless clients and the WLC.
Finally the guest device sends traffic to the WLC captive portal – guest.company.com (192.0.2.1) utilizing secure HTTP where the WLC can then authenticate the device and allow it access to the internet.
One final note on the HTTPS captive portal certificate. In order to avoid the certificate warning, the Web Auth Certificate needs to have the FQDN of the virtual IP address (exactly as the DNS record) listed as the CN. To make things a little easier, wildcard certificates are also accepted. In my case, “*.company.com” is used as the CN.
This article does not cover all the uses of the virtual IP address but hopefully it provides a little more understanding. Thanks for reading!
RF Blogger 