GUest WLAN with Anchor WLC - roaming problems

Hello,
my wireless network consists in 3 WLC 4402 which manage 40 APs.
I have a fourth WLC which I installed on my DMZ for guest vlan anchoring and web autentication.
Everiting works fine but I have a problem:
If my client associates with an AP and then I authenticate I'm ready to make traffic. As soon as my client roams to an AP managed by a differnt WLC I need to authenticate again. If I roam back to the first AP i need to reauthenticate.
In my guest WLAN I use WEB authentication provided by the internal web server of the Anchor WLC.
Thnks everybody

Here are the output of show mobility summary.
The last WLC is the anchor.
WLC1
Symmetric Mobility Tunneling (current) .......... Disabled
Symmetric Mobility Tunneling (after reboot) ..... Disabled
Mobility Protocol Port........................... 16666
Mobility Security Mode........................... Disabled
Default Mobility Domain.......................... mob1
Multicast Mode .................................. Disabled
Mobility Domain ID for 802.11r................... 0x392f
Mobility Keepalive Interval...................... 10
Mobility Keepalive Count......................... 3
Mobility Group Members Configured................ 2
Mobility Control Message DSCP Value.............. 0
Controllers configured in the Mobility Group
MAC Address IP Address Group Name Multicast IP Sta
tus
00:23:04:7d:3e:e0 10.25.1.21 mob1 0.0.0.0 Up
00:23:04:7d:73:20 10.20.1.21 mob1 0.0.0.0 Up
WLC2
Symmetric Mobility Tunneling (current) .......... Disabled
Symmetric Mobility Tunneling (after reboot) ..... Disabled
Mobility Protocol Port........................... 16666
Mobility Security Mode........................... Disabled
Default Mobility Domain.......................... mob1
Multicast Mode .................................. Disabled
Mobility Domain ID for 802.11r................... 0x392f
Mobility Keepalive Interval...................... 10
Mobility Keepalive Count......................... 3
Mobility Group Members Configured................ 2
Mobility Control Message DSCP Value.............. 0
Controllers configured in the Mobility Group
MAC Address IP Address Group Name Multicast IP Sta
tus
00:23:04:7d:3e:e0 10.25.1.21 mob1 0.0.0.0 Up
00:23:04:7d:62:a0 10.20.1.22 mob1 0.0.0.0 Up
WLC3
Symmetric Mobility Tunneling (current) .......... Disabled
Symmetric Mobility Tunneling (after reboot) ..... Disabled
Mobility Protocol Port........................... 16666
Mobility Security Mode........................... Disabled
Default Mobility Domain.......................... mob1
Multicast Mode .................................. Disabled
Mobility Domain ID for 802.11r................... 0x392f
Mobility Keepalive Interval...................... 10
Mobility Keepalive Count......................... 3
Mobility Group Members Configured................ 2
Mobility Control Message DSCP Value.............. 0
Controllers configured in the Mobility Group
MAC Address IP Address Group Name Multicast IP Sta
tus
00:23:04:7d:3e:e0 10.25.1.21 mob1 0.0.0.0 Up
00:23:04:7d:79:80 10.20.2.21 mob1 0.0.0.0 Up
WLCAnchor
(Cisco Controller) >show mobility summary
Symmetric Mobility Tunneling (current) .......... Disabled
Symmetric Mobility Tunneling (after reboot) ..... Disabled
Mobility Protocol Port........................... 16666
Mobility Security Mode........................... Disabled
Default Mobility Domain.......................... mob1
Multicast Mode .................................. Disabled
Mobility Domain ID for 802.11r................... 0x392f
Mobility Keepalive Interval...................... 10
Mobility Keepalive Count......................... 3
Mobility Group Members Configured................ 4
Mobility Control Message DSCP Value.............. 0
Controllers configured in the Mobility Group
MAC Address IP Address Group Name Multicast IP Sta
tus
00:23:04:7d:3e:e0 10.25.1.21 mob1 0.0.0.0 Up
00:23:04:7d:62:a0 10.20.1.22 mob1 0.0.0.0 Up
00:23:04:7d:73:20 10.20.1.21 mob1 0.0.0.0 Up
00:23:04:7d:79:80 10.20.2.21 mob1 0.0.0.0 Up

Similar Messages

ISE 1.2 - CWA supplicant provisioning with anchor WLC

Hi all,
Having an issue with supplicant provisioning via CWA on an anchor controller. I am able to connect via CWA and authenticate etc no problems but when the device registration page appears it says "unable to connect to the network at this time" - the mac address is populated but the button says try again. Once I click try again it cycles back to the original guest portal login page. In the reports section the failed supplicant provisioning message is "Error while trying to determine access privileges: Fail to get hostName from session cache.".
I have tried the same policy without the anchor (ie local controller) and it works perfectly. Interestingly enough if I manually register the device first then connect to the guest portal it allows me to click register and proceed to supplicant provisioning. I have also tried the anchor setup using peap and the NSP redirect - this also works perfectly.
I can confirm ahead of time that firewalls etc are not an issue with permit IP any any between all working parts - no blocks no drops etc. The policy is the standard trustsec CWA setup with Enable self-provisioning ticked. For what it is worth I am absolutely confident with the config having deployed this before - albeit without an anchor controller.

Stephen,
I was able to work with TAC the customer account team to find a resolution. The issue is with the Anchor WLC and the session not being replicated. I was able to get around it by disabling radius accounting for the ssid on the anchor controller, but when looking at the bug it looks like an alternative fix is to disable fast ssid switching, which would cause issues with BYOD in the dual ssid world. I'm still doing testing, but the accounting change seems to have solved it. The bug ID is: CSCui38627

Not able to form EoIP tunnel with anchor WLC

Hi all,
I have a WLC at a remote site that is supposed to form an EoIP tunnel with 2 anchor WLCs located at a data center. From the site WLC and the anchor WLCs, the mobility show UP on both ends. Also I can ping to the mobility peers from each end. However, when I look into the client details on the remote site WLC, there is no Mobility Anchor IP address, which tells me that the EoIP tunnel between the site and anchor controller is not forming for some reason. Any idea what I could be missing?
(WOHW-WC01) >show client detail 0c:3e:9f:ab:db:ed
Client MAC Address............................... 0c:3e:9f:ab:db:ed
Client Username ................................. N/A
AP MAC Address................................... 0c:68:03:b9:44:70
AP Name.......................................... WOHW-LAP016
Client State..................................... Associated
Client NAC OOB State............................. Access
Wireless LAN Id.................................. 66
Hotspot (802.11u)................................ Not Supported
BSSID............................................ 0c:68:03:b9:44:72
Connected For ................................... 1469 secs
Channel.......................................... 6
IP Address....................................... Unknown
Gateway Address.................................. Unknown
Netmask.......................................... Unknown
IPv6 Address..................................... fe80::1c1a:e07c:dd48:bc7e
Association Id................................... 3
Authentication Algorithm......................... Open System
Reason Code...................................... 1
Status Code...................................... 0
Session Timeout.................................. 0
Client CCX version............................... No CCX support
QoS Level........................................ Bronze
802.1P Priority Tag.............................. disabled
CTS Security Group Tag........................... Not Applicable
KTS CAC Capability............................... No
WMM Support...................................... Enabled
APSD ACs....................................... BK BE VI VO
Power Save....................................... ON
Current Rate..................................... m7
Supported Rates.................................. 9.0,12.0,18.0,24.0,36.0,48.0,
    ............................................. 54.0
Mobility State................................... None
Mobility Move Count.............................. 0
Security Policy Completed........................ No
Policy Manager State............................. STATICIP_NOL3SEC
>>> No Mobility peer IP address <<<<
(WOHW-WC01) >show mobility anchor wlan 66
Mobility Anchor Export List
WLAN ID     IP Address            Status
66          137.183.242.149       Up
66          137.183.242.150       Up
(WOHW-WC01) >show mobility sum
Mobility Architecture ........................... Flat
Mobility Protocol Port........................... 16666
Default Mobility Domain.......................... WOHW_ENT1
Multicast Mode .................................. Disabled
Mobility Domain ID for 802.11r................... 0x9cbf
Mobility Keepalive Interval...................... 10
Mobility Keepalive Count......................... 3
Mobility Group Members Configured................ 3
Mobility Control Message DSCP Value.............. 0
Controllers configured in the Mobility Group
MAC Address        IP Address       Group Name                        Multicast IP     Status
bc:16:65:f9:18:60 137.183.242.150 CIN_GUEST1                        0.0.0.0          Up
e0:2f:6d:7c:42:20 143.27.201.52    WOHW_ENT1                         0.0.0.0          Up
f8:72:ea:ee:a0:00 137.183.242.149 CIN_GUEST1                        0.0.0.0          Up

It works now. I changed the NAC state to "Radius-NAC". Now the mobility hand-off is occurring.
(WOHW-WC01) >show wlan 66
WLAN Identifier.................................. 66
Profile Name..................................... PGGuest
Network Name (SSID).............................. PGGuest
Status........................................... Enabled
MAC Filtering.................................... Enabled
Broadcast SSID................................... Enabled
AAA Policy Override.............................. Enabled
Network Admission Control
Client Profiling Status ....................... Disabled
DHCP ......................................... Disabled
HTTP ......................................... Disabled
Radius-NAC State............................... Enabled

Guest ssid with anchor controller and Web policy

We have a WLC4404 and and anchor controller WLC4402 to provide guest access to the wifi net. We configured both in the same mobility group, and the guest ssid to attach to the mobility anchor 4402. All is working fine until we enable the web policy authentication on the 4402. In this case the client join the guest ssid but neither get an ip address from the dhcp server nor go anywhere. Is we disable the web authentication all works fine again. We are runnig 4.0.206.0 on both WLC. Anyone can help us?

Two things you might check. (1) The 4404's mobility anchor should point to the 4402, and the 4402 should anchor to itself. (2) Make sure you are configuring the same security policy for the SSID on both the 4402 and 4404. So if the SSID is "guest" and you turn on web authentication on the 4402, make sure "guest" is on the 4404 with web authentication. We are using a similar setup for guest access at several sites.

Locally switched Guest WLAN with Web Authentication

I have a remote location that has its own internet pipe. I have set up a new guest SSID and set to switch locally and changed the AP mode to Flex connect. When I connect to the new SSID, I get an IP address from the local LAN, but the Web redirection page will not load. Is this because the local LAN does not have a route to the WLC virtual interace of 1.1.1.1? Is there a way to tunnel just the web authentication portion of traffic and locally switch everything else?

You are close in your understanding.
If you want to use the web portal services on the WLC then you need to bring that traffic back to the WLC.
"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
‎"I'm in a serious relationship with my Wi-Fi. You could say we have a connection."

Guest configuration with WLC

i am using WLC 4402 with firmware 5.1 and 1252 Access Point.
i am in trouble to configure guest access with the WLC.
i have configured interface in WLC under CONTROLLER->INTERFACES->GUEST.
WHEN I SELECT THIS INTERFACE AS GUEST IT DOESN'T TAKE IP ADDRESS INFORMATION. IN THIS CASE I HAVE TO UNCHECK GUEST SELECTION BOX.
AND I GOT DYNAMIC INTERFACE WITHOUT IP ADDRESS.
AFTER DOING THIS I CREATE WLAN NAMED GUEST AND ENABLED IT.
i have put guest interface as a ingress interface and management as egress interface and applied web auth successfully but still it is not showing me guest SSID when i try to search it.
help me
plz
thanks

Have you gone through these documents yet?
Wired Guest Access using Cisco WLAN Controllers Configuration Example
http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00808ed026.shtml
Guest WLAN and Internal WLAN using WLCs Configuration Example
http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a008070ba8f.shtml
Hope these will help you.

Guest WLAN and DNS tunneling (IP over DNS with iodine, NSTX, etc)

Hello,
I'm trying to implement guest WLAN with web authentication on the WLC 2504. L3 for guests WLAN is terminated on ASA 5510 (as subinterface).
All works pretty fine. Guests clients are prompted to enter login/password, guests are authenticated against ACS and so on.
But I have a strange idea. How can I prevent unauthorised DNS tunneling from the guest network?
I think that DNS tunneling can be prevented with dns-guard on ASA and dns inspections, e.g. drop dns packets larger then 512 bytes and perform deep inspection againd packets.
Any ideas or advices?

Hello,
I'm trying to implement guest WLAN with web authentication on the WLC 2504. L3 for guests WLAN is terminated on ASA 5510 (as subinterface).
All works pretty fine. Guests clients are prompted to enter login/password, guests are authenticated against ACS and so on.
But I have a strange idea. How can I prevent unauthorised DNS tunneling from the guest network?
I think that DNS tunneling can be prevented with dns-guard on ASA and dns inspections, e.g. drop dns packets larger then 512 bytes and perform deep inspection againd packets.
Any ideas or advices?

Implementing Two Guest Anchor WLCs

Hello -
I am wondering if anyone has ever setup a guest network solution using two anchor controllers where the internal WLCs each have two anchors configured and use a primary Anchor and when unavailable can dynamically fail over to a secondary Anchor.
I am looking to bring my current guest service onto the DMZ. Right now we are using separate ISPs where we tunnel the guest traffic to an anchor controller and out the separate ISP. We do not use our corporate internet service for guest. In any event. The DMZ design I am working on would include two WLCS sitting on our DMZ. I'd like to have each internal WLC configured to associate to the DMZ WLC that is connected to our active DMZ/Border. Upon failure, I would then like to have the internal WLCs failover to the second DMZ WLC on our standby DMZ/Border. So I would need to configure both anchors on the guest WLAN of each WLC. I'm just wondering if this is possible and if the failover will actually work.
Any input is appreciated. I'd like to implement a redundant guest solution where internal WLCS can dynamically failover to a backup Anchor....
Thanks
Chuck

Hi, I just got done moving our anchors to the DMZ so you are in luck as everything is fresh in my mind. I, like you, have dual anchors in the DMZ I also have over 30 inside (foreign controllers) connected to these anchors.
When you anchor a WLAN to (2) anchor controllers, the controllers automagically load balance guest associations. Example: 2 guest attached to SSID: GUEST. Guest#1 goes to anchor#1 and guest #2 goes to anchor#2. You dont configure anything, this happens automagically, like I mentioned.
As for failover. Yes, if you pull the plug to anchor#1. The EoIP tunnel breaks between the anchor and the foreign controller. Guest that were on anchor#1 will require reauthentication and then join to anchor#2.So if you had say a "accept page", these guest will get that same page again from anchor 2.
Does that answer your question?

Guest Wlan - foreign maps

Hi,
I am testing guest wlan with foreign map feature.
I am not able to assign the client an IP address from the subnet mapped under wlan > foreign map (WLC specific subnet)
The debugs on the anchor show a DHCP relay been sent from the interface mapped on the wlan and not the interface mapped under the foreign map.
I tried to map the wlan on anchor WLC to the management interface and have dhcp scopes locally on the WLC. Still same result, it is trying to obtain an IP address from the management subnet. This was based on the example in the link below
http://wifinigel.blogspot.com/2011_08_01_archive.html
I am using WLC version 7.0.116.0 on foreign wlc and verson 7.2.110.0 on the anchor.
Any suggestions will be helpful.
Thanks
Vikram

Rasikanayanajith,
Thanks for the reply. I just got off the phone with Cisco TAC and it looks like I am hitting bug CSCuh69558. I provided the config and debugs to TAC.
The bug has to do with having AAA Override configured on the WLAN Advanced tab and the RADIUS server not actually sending an interface attribute which is a common config in a BYOB WLAN controlled by ISE. The default interface configured on the WLAN is incorrectly used instead of the foreign map in this situation.
TAC also recommended upgrading away from the current version for the same reason you gave. I will be upgrading soon.
Thank you,
Mark

Guest Cert problems ISE and Anchor WLC

I'm setting up new Guest Wireless, I have 2 internal foreign 5508 WLC's talking to 2 DMZ anchor WLC's. The guest connects to Guest SSID and the anchor controllers acts as a DHCP server, the Guest interface configured on the WLC is the in the range of the DHCP scope I've setup. The DHCP scope is using the anchor WLC Mgmt interface as the DHCP server.
Guest SSID - is setup for Webauth and Guest is redirected to the ISE server https://wlc.company.com/login...., when the page is presented to the Guest they get cert problem because the cert is not trusted (its an Internal Cert), Guest logins in ok and the AUP says "cert not trusted" 1.1.1.1 name of the WLC wlc.company.com.
In the browser Guest has https://wlc.company.com/loginredirecthttps://1.1.1.1........
1.1.1.1 is the Virtual interface of the Anchor WLC.
How can I get the client to stop using the Virtual Interface for cert. Why is the WLC doing this? I gather something to do with DHCP?
My plan is to apply a External Cert on the ISE for Guests, that way they will automatically trust a cert from Geotrust for example. But I'm going to still run into this Cert "not trusted" problem where the Guest is not trusting the WLC anchor Virtual Interface 1.1.1 . Why is the guest using the Virtual interface error 1.1.1.1. I've even added the ISE name of the cert to the Virtual interface, same problem, instead its just says wlc.company.com not trusted. I have also imported the cert onto the WebAuth cert on anchor WLC, still doesn't work.
Hopefully I've explained this ok.....any ideas? but if the Guest page keeps getting presented with
https://wlc.company.com/loginredirecthttps://1.1.1.1........ it will never work.

I followed Richard's advice and started from scratch, removing LWA and implementing CWA -MAB. It didn't take too long to setup CWA and get authentication working, I appled a Preauth ACL on WLC's and on ISE under Authorization pofile (CWA)
This is when the problems started happening, I was using the default ISE Authorization profile
cisco-av-pair = url-redirect=https://ip:8443/guestportal/gateway?sessionid=SessionValueIdValue&action=cwa.which is not what I want, again the certificate is the server cert which is not an external Cert that the guest wants to see. The user can login fine, unlike LWA, with Firefox or IE it would accept the cert and login so at least I had a working Guest wifi solution. Though there was a cert error symbol at the end of the browser url.
The next step I tried was to change the Authorization Profile to
(wireless.company.com which is a C-NAME for ISE box and has this Alias in the cert, this was a test before I apply the external cert)
cisco-av-pair = url-redirect=https://wireless.company.com:8443/guestportal/gateway?sessionid=SessionValueIdValue&action=cwa
I applied the change and the new page appeared on the users laptop, great, but this time users were declined access via live Authentications, reason "Cannot login due to session id expiry, please login a again", I created a new user a/c, same problem. Not good. Ok so I thought well if I want clear all these stale session id's that appartenly exist I'll stop/start the application which I did from the command line, still the same error "Cannot login due to session id expiry". hmmm, whats going on here.
I then rebooted the ISE (this must clear all the sessions!), reboot I performed from home and now for some reason I cannot login to the ISE front end GUI with the admin account or my account. Tried resetting the GUI password for admin and other admin users, the message "Error: cannot reset password this can only be performed on Standalone or Primary node" Well what have I done, just rebooted ISE nothing else apart from changing authorization profile. This box is a Standalone node. Without seeing if the clients connect due t no GUI access, I have referred this issue to TAC!
Also I don't like the fact that your have to install a external cert against the internal node name, epsecially when its external. But again I haven't reached this part yet.

Using ISE for guest access together with anchor controller WLC in DMZ

Hi there,
I setup a guest WLAN in our LAB environment. I have one internal WLC connection to an anchor controller in our DMZ. I'm using the WLC integrated web-auth portal which works fine.
To gain more flexibility regarding guest account provisioning and reporting my idea is to use Cisco Identity Services Engine (ISE) for web-authentication. So the anchor controller in the DMZ would redirect the guest clients to the ISE portal.
As the ISE is located on the internal network while the guest clients end up in the DMZ network this would mean that I have to open the web-auth portal port of ISE for all guest client IPs in order to be able to authenticate.
Does anyone know of a better solution for this ? Where to place the ISE for this scenario, etc ?
Thx
Frank

So i ran into a similar scenario on a recent deployment:
We had the following:
WLC-A on private network (Inside)
ISE Servers ISE01 and ISE02 (Inside)
WLC-B Anchor in DMZ for Guest traffic (DMZ)
ISE Server 3 (DMZ)
ISE01 and ISE02 are used for 802.1X for the private network WLAN.
Customer does not allow guest traffic to move from a less secure network to a more secure network (Compliance reasons).
The foreign controller (WLC-A) must handle all L2 authentication and it must use the same policy node that the clients will hit for web auth. Since we want to do CWA, we use Mac Filtering with ISE as the radius server. If you send this traffic RADIUS authentication for Mac Filtering to ISE01/ISE02, it will use https://ise01.mydomain.com/... to redirect the client to. Since we don't allow traffic to traverse from the DMZ with the anchor in it back inside to the network where ISE01 and ISE02 are, client redirection fails. (This was a limitation of ISE 1.1. Not sure if this persists in 1.2 or not.
So what now? In our deployment we decided to use a 3rd ISE policy node (ISE03 in the DMZ) for guest authentiction from the Foreign controller so that the client will use a DNS of https://ise03.mydomain.com/... to redirect the client to. Once the session is authenticated, ISE03 will send a CoA back to the foreign which will remove the redirect for the session. Note, you do have to allow ISE03 to send a CoA.
In summary, if you can't allow guest traffic to head back inside the network to hit the CWA portal, you must add a policy node in a DMZ to use for the CWA portal so they have a resolvable and reachable policy node.

Layer 2 security with WLAN auto-anchor mobility

Hello,
I was wondering if Layer 2 security can be used with auto-anchored WLANs.
I need to deploy two new isolated WLANs which will terminate in two DMZ environments.
I was hoping to use the existing WCS-managed infrastructure with 4404 and 4402 WLCs and just throw on a couple more WLANs.
However, I've built a little test environment and while I can get the new VLAN traffic tunneled and origininating from the correct anchor controller with no layer 2 security - as soon as I turn on WEP or WPA security options it stops working. I can't find anything in documents or this forum to show auto-anchor mobility with anyhing other than unsecured guest WLANs.
Am I trying to do somethng unsupported or is it just an error on my part?

Hi Greg,
no, the users are internal so I only want to use L2 security. I can't see that L3 should be a problem to add on though. I'm using 3.2.x of the WLC code - so there is no "Guest LAN" mode - I was playing with the new versions and it looks like L2 security is disabled in that mode?
If you want to see how I got my bit working I would be happy to share my doco when I'm done.
regards,
Aaron

WLC 7.4.100.60 and roaming problems on 8500

Hello,
After installing an 8500 controller on 7.4.100.60 and migrating 1000 APs do this controller, we have the following problems:
[1] clients get disconnected and loose sessions (note: client is mobile gun and is heavily mobile). I have the impression there are more coverage holes. This might be due to bug CSCue13108, but says fixed in 7.4.100.60, we wil be upgrading to 7.4.110.0 anyway shortly.
[2] we have lots of L3 roaming problems between clients, especially when clients roam between old WISM controller and new 8500 controller. They don't roam, they get disconnected and reconnected, resulting in ip address change, resulting in sessions loss. Old controller still runs 7.0.230.0 but compatibility matrix says these two versions are L3 roaming compatible.
However, the release notes of 8500 mention this: "Cisco 8500 Series Controller cannot be configured as a guest anchor controller. However, it can be configured as a foreign controller to tunnel guest traffic to a guest anchor controller in a DMZ"
Because Layer 3 roaming is similar to guest traffic tunneling, does this mean that the 8500 can be the initiator of a L3 roam tunnel, but cannot be the endpoint of a L3 roam tunnel ?
We have done a test that seems to confirm this: client starts on 8500 in state "local", goes to AP on old controller (7.0.230.0), but roam doesn't work. Client gets re-associated with ip address change. Then when moving back to the 8500 controller, the client does roam successfully, keeps its ip address in the 7.0.230.0 vlan and gets status "foreign" on 8500 controller. controllers are in same mobility group and mobility connections are all up.
In the 7.5 release notes, this limitation is not mentioned anymore. Does it mean it is solved and 8500 can be used as guest anchor controller in 7.5 ??
regards,
Geert

[2] we have lots of L3 roaming problems between clients, especially when clients roam between old WISM controller and new 8500 controller. They don't roam, they get disconnected and reconnected, resulting in ip address change, resulting in sessions loss. Old controller still runs 7.0.230.0 but compatibility matrix says these two versions are L3 roaming compatible.
Roaming from one AP to another that shares the same controller is totally different with inter-controller roaming, which you have now. I believe WiSM-1 has 180 ms compared to the 90 ms on a 5508. And this time difference means alot.
So when your client goes from one controller to another, they actually have to do a full re-authentication to the new controller.
I presume both the old and new controller are in the same Mobility Group?
However, the release notes of 8500 mention this: "Cisco 8500 Series Controller cannot be configured as a guest anchor controller. However, it can be configured as a foreign controller to tunnel guest traffic to a guest anchor controller in a DMZ"
Pffft! That'll be the most expensive Guest Anchor Controller if I follow this solution.

DMZ Anchor WLC setup for Wireless Guest Access

I have the following setup.
A DMZ WLC 4402 connected to firewall DMZ interface in 10.10.73.0/24 network.
An Inside WLC 2106 connected to firewall Inside interface in 10.10.71.0/24 network.
Both WLCs are running the same 4.2.176 code.
DMZ WLC is anchor to itself and Inside WLC select the DMZ WLC as the anchor point.
I have setup EoIP between DMZ and Inside WLCs successfully with both the control and data path both show as UP status. >> "show mobility anchor"
The main issue: Clients cannot obtain IP addresses after connected to Guest SSID.
1. Inside WLC, the guest WLAN ingress is 802.11b/g radio and egress port is set to management interface (EoIP) of type WLAN.
What is the DMZ WLC setting? Is the ingress set to "802.11b/g" which does not make sense because the ingress is EoIP from Inside WLC?
Or I still set as 802.11b/g? Same config as Inside WLC? I read from other threads suggested by Terry that the config must be the same for both WLCs.
In the Inside WLC, I saw alot of pdu encapsulation errors for broadcast packets which is ffff.ffff.ffff xxxx which I think is the DHCP request from the connected Wireless clients not making through the EoIP tunnel. I have set static ip for the Wireless client but the packets cannot route through the EoIP tunnel to the far end.
2. DHCP server is provided by DMZ WLC with the scope 10.10.76.0/24. In the Inside WLC, which DHCP server IP adddress to set to? DMZ WLC mgmt ip address? DMZ WLC, the DHCP server is also set to DMZ WLC mgmt ip?
3. Layer 2 authentication. I read that DMZ WLC is supposed to be the DHCP server, Layer 2 or 3 authentication for Wireless Clients. However, it seems like Inside WLC is required to configure the Layer 2 authentication parameters and the DMZ WLC is set to providing the DHCP service?
4. Lastly, anyone has done DMZ WLC sending the Wireless clients traffic to Bluecoat proxy server before hitting the Internet?
Thanks.

One of the biggest things is to make sure the wlan is configured exactly the same. The DMZ WLC ingress is the management and also is the egress port. You can create a dynamic interface on the DMZ WLC, but this way makes thing easier. The DMZ WLC should provide the dhcp, so the dhcp scope of course will be on the same subnet as the management of the DMZ WLC. The DHCP Server will be the ip address of the management interface of the DMZ WLC. The authentication also has to be configured exactly the same on the inside wlc and the DMZ wlc. Since you are pushing clients through the tunnel to the DMZ WLC, that is where clients will need to get their ip address, since that DMZ WLC has a network interface to the guest network. I haven't had luck when a proxy is involved, but I know there was a post a while ago on how to setup the proxy to allow the wlc to bypass the users initial dns resolution.

LWA Guest Access with ISE and WLC

Hi guys,
Our Company try to implement Guest Access with ISE dan WLC with Local Web Auth Method. But there is problem that comes up with the certificate. This is the scenario :
1. Guests try to connect wifi with SSID Guest
2. Once it connect, guests open the browser and try to open a webpage (example: cisco.com)
3. Because, guests didn't login, so it redirect to "ISE Guest Login Page" (url became :
https://ise-hostname:8443/guestportal/Login.action?switch_url=https://1.1.1.1/login.html&wlan=Guest&redirect=www.cisco.com/
4. If there is no ISE Guest Login Page installed, message Untrusted Connection message will appear, but it will be fine if they "Add Exception and install the certificate"
5. After that the Guest Login Page will appear, and guests input their username and password.
6. Login success and they will be redirected to www.cisco.com and there is pop up from 1.1.1.1 (WLC Virtual Interface IP) with logout button.
The problem happen in scenario 6, after login success, the webpage with ISE IP address and message certificate error for 1.1.1.1 is appear.
I know it happened when guests didn't have the WLC Login Page Certificate...
My Question is, is there a way to tunneling WLC Certificate on ISE ? Or what can we do to make ISE validate WLC Certificate, so guests doesn't need to install WLC Certificate/ Root Certificate before connect to Wifi ?
Thx 4 your answer and sorry for my bad English....

Thx for your reply Peter, your solution is right,
i don't choose CWA, because their DNS is not stable...
i've found the problem...
the third-party CA is revoked, so there is no way it will success until it fixed...
and there is no guarantee, they will fix it soon..
so solution that we choose is by disable "HTTPS" on WLC...
"config network web-auth secureweb disable".
"config network web-auth secureweb disable".
"config network web-auth secureweb disable".
"config network web-auth secureweb disable".
"config network web-auth secureweb disable"
thank you all...

GUest WLAN with Anchor WLC - roaming problems

Similar Messages

Maybe you are looking for