Auto-anchor mobility (also called guest-tunneling) is used to force client data traffic on wireless LANs through a pre-determined set of anchor controllers. This can be beneficial to improve load-balancing and security for guests.
In normal roaming conditions, clients are anchored to the first controller which they join on the network. If a client roams to a different subnet, the new controller tunnels user data back to the anchor controller which they first joined. This behavior may not be ideal.
In auto-anchor mobility mode, a subset of a mobility group is specified as the anchor controllers for a WLAN. You can use this feature to restrict a WLAN to a single subnet (typically in a DMZ or other firewalled network segment), regardless of a client’s entry point into the network. Clients can then access a guest WLAN throughout an enterprise but still be restricted to a specific subnet.
Auto-anchor mobility is dependent on configuring mobility group peers between multiple controllers, configuring identical WLANs on both controllers, and assigning mobility anchors to the WLAN. On the foreign WLC (the one which terminates LWAPP/CAPWAP APs) you assign the anchor WLC in the DMZ as the mobility anchor.
On the anchor controller in the DMZ you assign itself as the mobility anchor for the WLAN, effectively telling it that it will be the termination point for the tunnel.
In a traditional guest access scenario with a completely open wireless network (no 802.1x/EAP or PSK), in which case only web authentication is performed, the captive portal and authentication are performed by the anchor controller as shown above.
However, I have noticed an oddity when enabling a secure wireless network with auto-anchor mobility. The foreign controller performs all layer 2 authentication and security for the client, including 802.1x/EAP or PSK authentication. In a way this makes sense, since the foreign controller maintains the LWAPP connections to APs which must encrypt/decrypt client traffic. Therefore, the foreign controller must receive the PMK from the AAA server upon successful authentication to be able to send it to the AP serving the client for PTK negotiation during the 4-way handshake.
We can confirm this is the case by monitoring the AAA authentication logs, in this case from Cisco ACS. In my lab setup the foreign controller has IP 10.108.50.20 and the anchor controller has IP 10.127.78.5. The authentication log clearly shows the authentication originating from a NAS at IP 10.108.50.20, the foreign controller.
So, when using the auto-anchor mobility (guest tunneling) feature on Cisco controllers, remember that layer 2 security is handled by the foreign controller and layer 3 security is handled by the anchor controller. Strange but true!