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!
-Andrew
Hi Andrew,
ReplyDeleteNice post ! quick question : if i have a guest anchor setup and i want to use just one ssid and have something like 3000 users on that ssid. I want to split it up into vlans , but still using same ssid (can use ap groups in normal scenario). But if i want to do guest anchor the single ssid and achieve this dynamic vlan assignment, can it be done with just the anchor wlc dhcp scope ? or is this not a supported feature ?
regards
Son
Hi Son,
ReplyDeleteUnfortunately, there is currently no method to map a single SSID to multiple VLANs on an Anchor controller. Like you said, on a local SSID (not tunneled) you can use AP Groups or Dynamic VLAN Assignment by a RADIUS server. But these are not options for an Anchor controller since it does not control APs or authenticate wireless clients using L2 auth (802.1x/EAP).
To perform this today, you have to deploy multiple Anchor controllers, each tying the same SSID to a different VLAN. Then assign all of them as Anchors on the internal controllers and clients will be round-robin load-balanced between the VLANs equally.
However, I have it on good authority that the feature you are looking for is going to be released very soon! Hold off on deploying multiple Anchor WLCs for a few months.
Andrew
Thank you very much for the info Andrew ! Much appreciated !
ReplyDeleteregards
Son
Hi Andrew,
ReplyDeleteThanks for the post.
One question- Does the authentication packet go through the tunnel to Anchor controller and then to RADIUS or they go directly to RADIUS. I have a setup where my foreign controller is behind a NAT and clients conencting to it are failing on Authentication.
Cheers
Nick
Hi Nick,
ReplyDeleteFor Layer 2 (802.1x) authentication is originated from the Foreign WLC to the RADIUS server.
For Layer 3 (webauth) authentication is originated from the Anchor WLC to the RADIUS server.
If you're Foreign WLC is behind NAT, make sure it has a 1-1 static NAT setup on the firewall/router. The RADIUS server and any other WLCs on the other side of the NAT device will need to be configured with the NAT'd address of the WLC behind the firewall/router.
Cheers,
Andrew
Andrew,
ReplyDeleteso am I correct in thinking that the gateway for the dynamic interface mapped to the WLAN on the anchor controller should be the firewall interface address? Also, is there a need for a dynamic interface on the foreign controller to map to the guest WLAN or is it just mapped to the management interface?
thanks
Yes, the gateway for the anchor controller's egress interface assigned to the WLAN could be the firewall. It depends on your DMZ environment and how big it is. If it's a small shop, then it more than likely is just a routed interface off the firewall with a layer 2 switch attached to several hosts.
ReplyDeleteOn the foreign controller, you can map the guest WLAN to either the management interface or another dynamic interface. Be aware that if all anchors for a guest WLAN are unreachable, guest client traffic will be forwarded out the interface assigned on the foreign controller. For this reason, security best practice dictates that you create a non-routable dynamic interface and assign it to the guest WLAN. Use a non-existent VLAN on the network, and make sure the trunk setup on the switch does not allow that VLAN on the link.
Andrew
Hello, Andrew, Small question to you. Could I use anchor controlers not for guest users, but just for particular SSID trafic termination on different site? For example,Company A and B are sharing same APs. Users from Company A terminated on WLC on Site A, and users traffic from company B would be terminated on Anchor WLC at Site B?
ReplyDeleteAbsolutely! Mobility anchoring can be used in non-guest scenarios and it works just as you would expect. You can use it with layer 2 security, such as WPA2-AES, as well. You're not limited to web-auth.
ReplyDeleteAndrew
Thank you for great answer. Onother small question, if I understood authentication process correctly, foreign controler will perform Layer 2 authentication for clients. If I use 802.11x authentication, all athentication traffic will be sent between Radius and foreign WLC, no need to open additional ports on FW anchor WLC located in DMZ? Layer 3 authentication is set to none.
ReplyDeleteYes, that is correct. The Foreign WLC which terminates the LWAPP/CAPWAP connection with the access points handles all layer 2 authentication, including 802.1x/EAP with a backend RADIUS server.
ReplyDeleteAn anchor controller will never handle layer 2 authentication, only layer 3 authentication (web-auth) after the user traffic is forwarded inside the mobility tunnel (EoIP).
You do not need to open firewall traffic between the anchor WLC in a DMZ and a RADIUS server for EAP. However, if layer 3 web-auth is checking credentials from the RADIUS server (versus internal on the WLC) then you would still need to open the ports through the firewall.
Andrew
Thank you a lot for one more perfect responce.
ReplyDeleteHi Andrew,
ReplyDeleteWe're planning to buy 2 additional WLCs (5500), Currently 2 WLCs are in the same mobilty group, do recommend I put 4 WLCs in 1 mobility group?
We're also planning to buy Cisco NGS guest server. Due to IP address limitation, therefore we're heading towards NAT, my question is where should i put the NGS server, close to the INternet router so guest users wont affect the internal network?
Thanks in advance,
Tony
Hi Tony,
ReplyDeleteThe rule of thumb for mobility groups is to put controllers in the same mobility group if users should be able to seamlessly roam between APs attached to different controllers while maintaining their IP address.
For guest anchor controllers that do not control APs directly, they can be in their own mobility group. You can then configure the foreign controllers with the anchors and simply specify the alternate mobility group name when you add them to the list.
As for the NAC Guest Server, it can be placed out of band and act as a RADIUS server to authenticate guests. The WLAN on the controller is usually configured for web-auth and points to the NGS as a RADIUS server.
Cheers,
Andrew
Thanks for the info Andrew.
ReplyDeleteI have 4 controllers (5500 series), I also want the controllers to have fail-over capability in case one of them fail. I also run Cisco NGS
What are your recommendations? Having 4 controllers in 1 mobility group?
If i put the controllers in different groups, users won't be able to do roaming?
As NGS act as a radius server, would you recommend putting the Guest server in the internal network, dmz or on the edge block?
Tony
Hi Tony,
ReplyDeleteIf the WLCs in question have APs joined to them and you want fail-over redundancy, it would be best to put them in the same mobility group. This is not a requirement, fail-over can also be achieved by configuring the AP's primary, secondary, and tertiary controller IP addresses.
If you put the WLCs in different mobility groups, users will need to perform a full 802.1X authentication when them roam to APs on a different controller, so you will lose fast roaming capability. Also, users will not be able to maintain their existing IP address and will have to request a new one from DHCP. If you're using the same SSID, most clients just assume their existing IP address will work and they'll lose service (dumb clients)! In that case they would have to manually disconnect from Wi-Fi and then reconnect, which would be a huge support nightmare.
Long story short, you should probably put them in the same mobility group AND configure AP controller preferences.
The NGS location really doesn't matter. It's just authenticating clients so it just needs to be reachable from the WLCs. Internal or DMZ should both be fine. I'd recommend against the edge block.
Cheers,
Andrew
Hi Andrew,
ReplyDeleteIf i have 802.1x implemented as Layer 2 authentication, and users roam between foreign and anchor controller, do they lose connection and get different IP address?
As i know, anchor controller will handle DHCP request and issue IP address to user, so it should be no problem for client to retain the same IP.
You already mentioned Layer 2 authentication like 802.1x is handled by foreign controller and the client will need to re-authenticate again when they roam to APs controlled by anchor controller.
How's about WPA2-PSK? For cases like same PSK and different PSK?
Thank you,
Alex
Hi Alex,
ReplyDeleteUsually anchor controllers do not have APs directly joined. I assume you are asking if a user roams from one foreign controller to another foreign controller. In this case, both foreign controllers should be in the same mobility group and have the WLAN anchored to the same anchor controller(s), in which case the user should keep the same IP address.
802.1X and PSK users will be the same in this regard as well. The key is having the foreign controllers in the same mobility group so that the user's state information can be transferred between WLCs when they roam.
Cheers,
Andrew
Hi Andrew,
ReplyDeleteThank you for your prompt reply.
I know it's odd when having APs joined anchor controllers, but it's the case for my current solution.
Let's me explain in more details. Currently, there are two research entities sitting in the same building. They have separate network infrastructure (controllers and APs), but they want to advertise each other SSIDs. Regardless of user's location, they will receive IP address belongs to their entity.
With anchor mobility, I can achieve IP address and traffic routing independence since DHCP process and traffic are tied to anchor controllers. However, mobility will not be seamless. I did a test with PSK and saw one packet drop when roaming.
Regards,
Alex
Hi,
ReplyDeleteI have same setup with WLC as foreign and Anchor in DMZ.I use Anchor as DHCP server with firewall interface as gateway.
I trunk the management VLAN and guest VLAN in switch. I am having issues getting DHCP information. Please can shed some light on how dhcp should be configured and how vlans should be sent from DMZ to the inside.
Thanks,
hello,
ReplyDeleteI have two 5508 with internal web authentication using radius server, no anchor, only one SSID.
Under "Configuring Mobility Groups", Cisco guide says: I"f a client roams in web authentication state, the client is considered as a new client on another controller instead of considering it as a mobile client".
I understand that if a client roams between two LAPs that are associated with different WLCs, it has to reathenticate.
What is yous opinion ?
Thanks a Lot
Hi,
ReplyDeleteI believe the guide is correct, L3 web-auth must be completed again when the user roams between controllers in the same mobility group.
You can avoid this by using an anchor controller. Since a single anchor would be performing the web-auth, then both foreign controllers can forward the client traffic through the mobility tunnel to the same anchor without forcing a re-auth. You could just set one of your existing controllers as a permanent anchor if you wanted to.
Andrew
Cisco really need to offer a prioritised anchor selection. Having anchor resilience means that the foreign WLC will round-robin the connecting clients to both anchor WLCs. Which requires reauth... meh!
ReplyDeleteI have a question for the dependings... especially for creating identical WLANs on both controllers. At the foreign controller and the anchor controller the names of the WLAN-Profiles are identic. But the Interfaces are different. The ID aswell. At the anchor Controller the WLAN Profiles belonging to the foreign Controller have an ID above 300 because they use the same SSID as the first ID (It isnt possible to create WLANs with duplicate SSIDs within the first 16 Profiles). At the first ID only the ssid is identic, the profile name is diffrent. The Problem is that all traffic coming from the foreign controllers uses the interface of the first ID (at the anchor controller) although the profile name isnt matching. Any foreign traffic uses the first wlan Profile and not that with the matching profile name (ID above 300). Is it possible that only the first 16 WLAN Profiles can be used for this topic? I have a lot of foreign Locations and it is not possible for me to use only 16 profiles. But it is needed that every location has its own Profile (Interfcae -> VLAN) for reporting.
ReplyDeleteHi Andrew,
ReplyDeleteI want to ask about your design picture, What is Anchor Controller?, It's same with Wireless Controller.
Thanks,