WLC 7.x GuestNet Anchor Controller Certificate Warning

Customer wants to remove the Certificate Warning for GuestNet.
One the anchor under Controller > Interfaces > Virtual > DNS hostname do I put the FQDN CLT111DMZWLC01.acme.com or just the hostname CLT111DMZWLC01 then do a Certificate Signing Request via CLI and then send off to Entrust?
DMZ DNS Server Test/Verification
C:\Users\jaarons>nslookup
Default Server: dc01.acme.com
Address: 10.32.11.100
> set type=ptr
> 1.1.1.1
Server: dc01.acme.com
Address: 10.32.11.100
1.1.1.1.in-addr.arpa name = CLT111DMZWLC01.acme.com
>
WLC 7.0.116.0
Clients Redirected to External Web Authentication Server Receive a Certificate Warning
http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a008076f974.shtml#t2

Jason,
In my experience there are a couple of steps that need to be considered. Are there any ap's running H-REAP? if so you need a certificate for each wireless controller. Secondly do you want a wildcard certificate or a specific certificate for each controller?
I have done the guest access both ways as either a dedicated certificate for the controller or using a wildcard (ie: *.didata.com versus guestwlc1.didata.com)
Once you know what type of certificate you want, configure the DNS name of the virtual interface as you have describe: ie: CLT111DMZWLC01.acme.com
Assuming the virtual interface is 1.1.1.1 makes sure external DNS has CLT111DMZWLC01.acme.com resolving to 1.1.1.1
Then you can use OPEN SSL 0.9.8 to create the certificate signing request.
then request your certificate and then you will need to compile the certificate and/or certificates into a certificate package to upload into the controller.
George Stefanick did a great Step-by-step of this on his blog
http://www.my80211.com/home/2011/1/16/wlcgenerate-third-party-web-authentication-certificate-for-a.html
also here is the cisco link for the steps.
http://www.cisco.com/en/US/products/ps6366/products_configuration_example09186a0080a77592.shtml
Hope this helps!!
Please rate useful posts.

Similar Messages

AAA, WLC, and AP Groups, Anchor Controller, Problem

All,
First, I have a TAC case open on this problem, but they seem to be stumped and I have been unable to get them to mock it up. Here are the details and the problem(s):
Have Cisco ACS using backend AD for user authentication
MSCHAP, 802.1x
Three wireless controllers running ver 7.0.98.0; one controller is 4404 the other two are on WiSM blade in 6509.
Many AP Groups and a few mobility achor setups.
Wifi clients used to test are Intel and have the proper drivers 12.4.4.5 and 13.1.1.1
First authentication problem is via SSIDs associated with anchor contollers. Whenever the SSID is set to use 802.1x, the anchor controller sends message to ACS(RADIUS), but ACS never sees the communication.
Second authentication problem is related to AP Groups. Whenever a client associates with an AP that is in a specific AP group and that SSID is also associated with that AP group's interface, I get the same result as above - the contoller talks to the ACS, but the ACS never sees the communication.
Note that all the above works fine as long as I am not using 802.1x. If I am using PSK, it all works flawlessly.
One other thing to note is that, in the case of the AP Group problem, if withing the AP group I associate the SSID with the management interface, the 802.1x works perfectly. The problem with that is that the client get assigned an IP address from the management Vlan... not what I want, instead, I want the client to get it's IP address from the interface associated with the AP Group.
It is not a routing problem....
I have gone through two TAC engineers and the problem is still not resolved. So close, but not succesfull.
Any interoperability/Security experts out there that can help nail this thing?
Thanks

Jeff,
Sorry for the late reply.... of course your suggestion was right-on the mark and a wireshark trace uncovered the problem. I had already re-engaged Cisco TAC and between the wireless engineer and one of their security engineers, they were able to point out that the Cisco ACS 5.0 has a bug specific to this particular problem. They told me to apply patch, apply OS upgrade, then apply ACS 5.1 upgrade to the ACS. I was able to apply the patch, but never could get the OS upgrade to take. For the heck of it, I re-checked the problem after applying the patch and YooHoo! Works as advertised!
Thanks for showing the interest, it was definetly a pain-point for my customer.

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.

Guest Traffic Segregation without using Anchor Controller

Hi
I need help in calrifiing , is there any other option avaialble to segregate the guest traffic from CORP on internal WLC itself without using anchor controller ?

Well really can't tell you or else it would be a book. You either have use ACL's on your layer 3 to deny traffic from your guest subnet to your internal. Nothing has to change on the WLC. If you want to connect one port of the WLC to the DMZ, then disable LAG on the WLC and use port one as primary for the internal traffic which includes management and another port in the WLC as primary for the guest.
Sent from Cisco Technical Support iPhone App

WLC user rate limit on guest ssid anchor controller

Hi,
I have been looking through the forums & some cisco documents but not found a good example similar to what I am seeking to do so now I am turning to the expertise of my peers.
We have been deploying 3502 APs remotely to locations with full T1s that backhaul to where I sit at HQ.
Both the foreign and anchor controller are here at my location.
I am seeking to rate limit per user the bandwidth each client will get on the guest internet ssid.
As you know this traffic is encapsulated in capwap between the AP and the controller so I cant use a standard ACL on the switch or router.
We are trying to keep the guest internet access usage in check on the T1 at any given site so the other ssid's & local lan traffic is not overly competing for the bandwidth.
I found the place to edit the default profiles in the controller but the documentation really isnt clear on best practices.
So I put it to you my fellow wireless engineers to suggest how you are implementing bandwidth management on your wireless guest internet.
Thanks guys!
Oh and here is my hardware & software levels.
5508wlc - forgeign
4402wlc - anchor
Software Version
7.0.230.0

Amjad,
Thank you for taking the time to respond as well as the document link.
It was pretty clear on the steps and what it would impact.
Two things that push me for a different solution (assuming their is one).
Note The values that you configure for the per-user bandwidth contracts affect only the amount of bandwidth going downstream (from the access point to the wireless client). They do not affect the bandwidth for upstream traffic (from the client to the access point).
As you can see from the above note taken out of the linked document the roll based rate limit doesnt really rate limit the T1 traffic any guest user consumes it only limits usage from the AP down to the client.
#1 I am looking for a solution that limits the users up & down streams (if possible) & also before it leaves the AP for the T1.
The idea is to limit WAN utilization.
#2 I read in the forums here others asking about the "user role" and saw some comments saying it is not considered "best practice" to use user roles.
Let me clarify that our guest ssid's are using the http webpage pass through for authentication and it is really only the tic mark to indicate they understand the terms and conditions of using our internet as a guest service. No actual user accounts are used on the guest ssid's.
***One last question about this and any other changes***
Will any change I make be on the "Foreign, Anchor" or both Controllers?

Guest VLAN unable to get DHCP IP address from Anchor Controller

Hello everybody,
In our test set up, we have two WLC 5508 Controllers connected via Checkpoint UTM-1 firewall Inside and DMZ Interfaces. Both the WLC controllers are connected to the firewall via Cisco 3750 switch. On the Local (Inside) Controller, guest SSID is enabled and attached to the wireless management Interface. On the remote anchor controller, guest SSID is enabled and attached to the Management Interface as well. The following configs are replicated on both the Controllers.
SSID Name - guest
Interface - Management ( VLAN 10 on Local and VLAN 20 on remote) -
Mobility Group: Same configs at both ends
SSID Anchor : Anchor SSID on local and local SSID on Anchor.
AP: CAPWAP 3502 Management Subnet
SSID Security etc all defaults and matching on both ends
Checkpoint Firewall Rules: Allowed 16666-7, IP 97 etc on the firewall
Checkpoint Inside/DMZ to Outside(Internet) is NAT enabled.
EoIP Tunnel Status: Up, UP - Both ends
Mping - OK
eping - OK
WLC Sofware Version on Local - 7.0.98.0
WLC Sofware Version on Local - 7.0.116.0
DHCP Scope: Definitions on Anchor Controller and Guest Anchor SSID points to the Anchor management IP as the Primary DHCP server.
Management IP Subnet on Local: 10.x.x.x
Management IP Subnet on Anchor: 172.x.x.x
The problem definition as follows:
When guest SSID associates to the local AP, the guest SSID never gets a DHCP address assigned from the Anchor Controller and the following debugs are obtained.
1. WLAN ID 1 (for Guest SSID Number) delete message appears in the Controller message logs, but the SSID does not DHCP from the local Management Subnet and i can see DHCP request via the tunnel to the Anchor WLC as follows:
DHCP Socket Task: Feb 24 17:20:46.612: 64:b9:e8:33:2d:13 DHCP received op BOOTREQUEST (1) (len 308,vlan 0, port 13, encap 0xec03)
*DHCP Socket Task: Feb 24 17:20:46.612: 64:b9:e8:33:2d:13 DHCP processing DHCP DISCOVER (1)
*DHCP Socket Task: Feb 24 17:20:46.612: 64:b9:e8:33:2d:13 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Feb 24 17:20:46.612: 64:b9:e8:33:2d:13 DHCP   xid: 0x49c54774 (1237665652), secs: 42, flags: 0
*DHCP Socket Task: Feb 24 17:20:46.612: 64:b9:e8:33:2d:13 DHCP   chaddr: 64:b9:e8:33:2d:13
*DHCP Socket Task: Feb 24 17:20:46.612: 64:b9:e8:33:2d:13 DHCP   ciaddr: 0.0.0.0, yiaddr: 0.0.0.0
*DHCP Socket Task: Feb 24 17:20:46.612: 64:b9:e8:33:2d:13 DHCP   siaddr: 0.0.0.0, giaddr: 0.0.0.0
*DHCP Socket Task: Feb 24 17:20:46.612: 64:b9:e8:33:2d:13 DHCP successfully bridged packet to EoIP tunnel
2. Similar debugs on the Anchor controller yields the following results;
Cisco Controller) >*DHCP Socket Task: Feb 25 04:30:25.488: 64:b9:e8:33:2d:13 DHCP options end, len 72, actual 64
*DHCP Socket Task: Feb 25 04:36:44.246: 64:b9:e8:33:2d:13 DHCP received op BOOTREQUEST (1) (len 308,vlan 20, port 1, encap 0xec05)
*DHCP Socket Task: Feb 25 04:36:44.246: 64:b9:e8:33:2d:13 DHCP processing DHCP DISCOVER (1)
*DHCP Socket Task: Feb 25 04:36:44.246: 64:b9:e8:33:2d:13 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Feb 25 04:36:44.246: 64:b9:e8:33:2d:13 DHCP   xid: 0x49c54778 (1237665656), secs: 52, flags: 0
*DHCP Socket Task: Feb 25 04:36:44.246: 64:b9:e8:33:2d:13 DHCP   chaddr: 64:b9:e8:33:2d:13
*DHCP Socket Task: Feb 25 04:36:44.246: 64:b9:e8:33:2d:13 DHCP   ciaddr: 0.0.0.0, yiaddr: 0.0.0.0
*DHCP Socket Task: Feb 25 04:36:44.246: 64:b9:e8:33:2d:13 DHCP   siaddr: 0.0.0.0, giaddr: 0.0.0.0
*DHCP Socket Task: Feb 25 04:36:44.246: 64:b9:e8:33:2d:13 DHCP successfully bridged packet to DS
*DHCP Socket Task: Feb 25 04:36:53.208: 64:b9:e8:33:2d:13 DHCP received op BOOTREQUEST (1) (len 308,vlan 20, port 1, encap 0xec05)
*DHCP Socket Task: Feb 25 04:36:53.208: 64:b9:e8:33:2d:13 DHCP processing DHCP DISCOVER (1)
*DHCP Socket Task: Feb 25 04:36:53.208: 64:b9:e8:33:2d:13 DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Feb 25 04:36:53.208: 64:b9:e8:33:2d:13 DHCP   xid: 0x49c54778 (1237665656), secs: 61, flags: 0
*DHCP Socket Task: Feb 25 04:36:53.208: 64:b9:e8:33:2d:13 DHCP   chaddr: 64:b9:e8:33:2d:13
*DHCP Socket Task: Feb 25 04:36:53.208: 64:b9:e8:33:2d:13 DHCP   ciaddr: 0.0.0.0, yiaddr: 0.0.0.0
*DHCP Socket Task: Feb 25 04:36:53.208: 64:b9:e8:33:2d:13 DHCP   siaddr: 0.0.0.0, giaddr: 0.0.0.0
*DHCP Socket Task: Feb 25 04:36:53.208: 64:b9:e8:33:2d:13 DHCP successfully bridged packet to DS
*apfOrphanSocketTask: Feb 25 04:37:49.931: 34:51:c9:59:b1:c7 Invalid MSCB state: ipAddr=169.254.254.148, regType=2, Dhcp required!
Is there any thing missing in the wireless configs and or the firewall rules as i could not see DHCP request back from the Anchor Controller. Also, after DHCP is obtained, the web authentication request will be redirected to an Amigopod device for authentication. In this case is the redirect URL congiguration to be performed only on the Anchor Controller or is this to be replicated on both the Local and Anchor Controllers.
Thanks and Regards.

The DHCP issue is resolved if external DHCP server is configured on a 3750 switch connected to the WLC and the default gateway for DHCP points to the Firewall, which is in the data path between the Inside and Anchor Controllers. DHCP is essentially bridged (no Proxy setting now) from the EoIP tunnel to the Distribution system network. We will test this solution on pilot production and then consider upgrading to 7.0.116.0, as there are about six offices running 7.0.98.0, which will need to be upgraded.
For L3 security, configuration is set up on both the controllers for external captive portal redirection.I will try this only on the Anchor and revert.
Thanks again very much for all your help.

Auto-Anchor Controller's Best Practice

Hi All,
I got confused with this setup. I have 2 Wlc's.One is the internal controller and another one configured for the anchor controller (different subnet-DMZ zone) for guest traffic. Where do i configure DHCP assignment for this users..? Should Production controller intervine in this dhcp process or shall i direct to Anchor to take care of everything..? which is recommended ?
And also any best practice doc is available for this ..?
Please help...
thanks in advance.

Prasan,
Just keep in mind that there are best practices that are published and best practices that you learn from experience. Being a consultant, I get to implement wireless in various networks and everyone's network is quite different. Also code versions can change a best practice because of bug issues or how a standard might of changed and how that standard was implemented in code. The biggest best practice secret is really working with various client devices, scanner's, laptops, smartphones, etc., and seeing how those change because of newer models and it firmware updates. It's amazing to understand how some devices will require a few checkboxes in the WLAN to be disabled compared to others. Even with anchoring for guest and using a custom WebAuth to make sure the splash page works with various types of browsers.
What I can say is to always try the defaults if possible when you have issues and then enable things one by one.
Sent from Cisco Technical Support iPhone App

Controllers in the same WISM module in the 6500, i'm trying to make one of them anchor controller for guest internet

I have 2 controller in the same WISM module and I'm trying to make one of them Anchor controller for guest WLAN, but when I give put the anchor controller in a separated non-routed VLAN and connect it to an outside switch by creating VLAN 192 on the core. ( the Internet router is connected to the same switch).-it is showing path down... ( VLAN 192 visitor Internet and VLAN 224 my internal controller management VLAN are not talking)
there is no routing between these 2 VLAN ( because of security), but i can't get the controller to communicate.
-if I connect my laptop to this switch I'm able to go out on Internet but my visitor WLAN is not able to get IP address from the router connected to this switch.
- I called Cisco and one the guys told me that i can leave the management in VLAN 224 for the controller to communicate ( which they did), but the issue I'm having right now is that my visitors are not getting IP addresses from this VLAN at all
some one please advise
vlan192   4/1 vlan 192              int g0/0 192.168.2.201
6500 ----- switch ---- router--------- (outside)
    |         |   |
    |        DHCP server
   WLC

A couple of questions, is VLAN 192 allowed across the trunk link to the wlc? Do you have an interface tagged for vlan 192, with a valid address? What is providing the DHCP?
Cheers,
Steve
If this helps you and/or answers your question please mark the question as "answered" and/or rate it, so other users can easily find it.

AP Groups - Guest Access - Anchor Controller

Need clarification - I think it does work
Does the AP Group feature work with the anchor controller guest access feature
SSID guest --- LWAP -- LWAPP -- Foreign WLC --- EoIP --- Anchor Controller --- VLAN 10 or VLAN 11
ie
Guests in Building 1
SSID guest VLAN 10
Guests in Building 2
SSID guest VLAN 11
Mark

Hi,
As far as I know, AP Group only works locally in each controller, and the mapping between SSID and VLAN is done in the anchor controller.
Therefore, all clients will end up in the same VLAN, even if access points are in different AP Groups in the first WLC.
Kind regards
Johan

WLC as a Mobility Anchor for guest access - Management on DMZ or not DMZ

When using Guest Access Cisco recommend a Mobility Anchor Controller be placed on a DMZ and the guest access wireless Lan is tunneled to this controller. This means that 2 DMZ subnetworks are required - one for the management interface and one for the wireless lan's dynamic interface itself.
I am trying to see if there are any disadvantages/security risks using 2 physical ports on the controller (no LAG) and placing one on a corporate network inside the firewall for management and to terminate the mobility anchor tunnel, and one outside the firewall on a DMZ for the wireless lan's dynamic interface.
Advantages that I see are that no tunnels need to go though a firewall, management of the WLC is kept completely inside the corporate network, protected by the firewall and not left on the DMZ.
Thanks.

OK, so to recap;
- place the 2nd WLC in the DMZ with only 1 port (set for dynamic AP management)?
- Then Anchor the guest SSID (on it's DMZ IP instead of management IP as is now)
And to make that kind of anchoring work, I have to open ports below on the firewall.. right?
UDP port 16666 for inter-WLC communication, and IP protocol ID 97 Ethernet in IP for client traffic.
and:
•TCP 161 and 162 for SNMP
•UDP 69 for TFTP
•TCP 80 or 443 for HTTP, or HTTPS for GUI access
•TCP 23 or 22 for Telnet, or SSH for CLI access
Thanks to confirm that

Central Web Auth with Anchor Controller and ISE

Hi All
I have a 5508 WLC on the corporate LAN and another 5508 sat in a DMZ as an anchor controller.
I also have an ISE sat on the corporate LAN.
Authenticate is working fine to the ISE and the client tries to re-direct to the ISE Portal but doesn't get there.
DNS is working fine and the client can resolve the URL of the ISE to the correct IP address.
I have a redirect ACL configured on the foreign controller which permits DNS, DHCP and traffic to and from the ISE.
My questions are:
1. Do I need to re-direct ACL to be present on both the foreign and anchor controllers?
2. Since the Radius requests originate from the foreign controller do I need to configure the ISE server address on the WLAN on the anchor?
3. Does the re-direct ACL need to be enabled on the advanced page of the WLAN on the foreign to over-ride the interface ACL - I don't believe it does.
4. Is ICMP still blocked by the WLC until the web authentication is complete?
Thanks.
Regards
Roger

Hi Roger,
Thanks for your brief explanation here are the answers for your queries.
1. Do I need to re-direct ACL to be present on both the foreign and anchor controllers?
The only catch is that since this web authentication method is Layer 2, you have to be aware that it will be the foreign WLC that does all of the RADIUS work. Only the foreign WLC contacts the ISE, and the redirection ACL must be present also on the foreign WLC.
2. Since the Radius requests originate from the foreign controller do I need to configure the ISE server address on the WLAN on the anchor?
Yes, you have to configure the ISE server address on the anchor WLC.
3. Does the re-direct ACL need to be enabled on the advanced page of the WLAN on the foreign to over-ride the interface ACL
Yes, you should override AAA under advanced tab of WLAN as ACL will be present on the foreign WLC.
4. Yes, ICMP will work only after the sucessful web auth is complete.
Please do go through the link below to understand the Anchor-Foreigh Scenario.
http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/115732-central-web-auth-00.html#anc11
Regards
Salma

Wireless Guest Network using Cisco 4402 as an Anchor Controller

Hello,
We have recently redesigned our wireless guest network in accordance to Cisco's recommended deployment using the anchor controller in the DMZ. We have created two mobility groups (enterprise and anchor). The anchor controller and DMZ has two subnets (guest managment and guest clients). The guest management subnet is connected to the controller and firewall allowing the mobility groups and EOIP tunnels while the guest client network is also connected to the controller and firewall to push the client traffic directly out the firewall. The setup works well but the one part that I'm not happy with is the DHCP. Currently DHCP is being handled on the firewall because of issues we had with dhcp relay and the controllers internal dhcp service.
Does anyone have any information on getting DHCP relay working or the internal dhcp service on the controllers when using as a anchor?
This is basically the setup guide that we followed.
http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob41dg/ch10GuAc.html
Thanks!

Hi,
Make sure you have the IP helper address configured under the VLAN interface on the L3 and also make sure to disable DHCP proxy on both the WLC (Anchor and Foreign).
This will help us as well..
lemme know if this answered your question..
Regards
Surendra
====
Please dont forget to rate the posts which answered your question and mark it as answered or was helpfull

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.

Guest access to the Internet with Guest Anchor Controller

Hi;
We are doing our initial implementation of an enterprise wireless system. I deployed a WLC 5508 connected to our data center core switch using LAG. The 5508 is configured in FlexConnect mode since it is serving APs deployed to a handful of remote offices. Employee wireless access has been rolled out and is working well.
I am designing guest access. As is typical, I want to enforce a policy that guest wireless traffic is forwarded to the Internet Edge in our DMZ and directed out to the Internet. We do not plan to deploy a Guest Anchor controller in the first phase of the roll out.
What is the best way to enforce forwarding of guest traffic towards the Internet Edge once the guest traffic arrives at the 5508? A guest VLAN between the core switch and the Internet Edge isn't feasible since there is a firewall between the core and DMZ that is configured in Routed mode.
Thanks for the assistance! Glenn Morrison

you'd have to do a VLAN between the core and the firewall for the guest traffic until you get the anchor installed.
HTH,
Steve

DMZ Anchor Controller

I'm having trouble setting up an Anchor Controller on my DMZ. I have setup everything up and tested it out on my inside network and the Anchor Controller comes up with no problem. When I put the Anchor Controller on the DMZ the data path is up but the control path is down. I can do EPING's but MPINGS fail everytime. The DMZ is secured by a checkpoint firewall. I've made sure ports UDP 16666, 16667 and TCP 97 are open on the firewall. It looks like the traffic is going out to the Anchor controller on the DMZ but not coming back in to establish the tunnel. I've contacted Checkpoint but there support is not the best and I'm wondering if anyone has suppport for a checkpointfirewall. Thanks in advance

From Chapter 10 of the Enterprise Mobility 4.1 Design Guide -
http://www.cisco.com/en/US/netsol/ns656/networking_solutions_design_guidance09186a00808d9330.html
The following verifications and troubleshooting tasks assume the following: â¢The solution is using the web authentication functionality resident in the anchor controller(s). â¢User credentials are created and stored locally on the anchor controller(s).
Before attempting to troubleshoot the various symptoms below, at the very least you should be able to ping from the campus (foreign) controller to the anchor controller(s). If not, verify routing.
Next, you should be able to perform the following advanced pings. These can only be performed via the serial console interfaces of the controllers: â¢mping neighbor WLC ip
This pings the neighbor controller through the LWAPP control channel. â¢eping neighbor WLC ip
This pings the neighbor controller through the LWAPP data channel.
If a standard ICMP ping goes through, but mpings do not, ensure that the default mobility group name of each WLC is the same, and ensure that the IP, MAC, and mobility group name of each WLC is entered in the mobility members list of every WLC.
If pings and mpings are successful, but epings are not, check the network to make sure that IP protocol 97 (Ethernet-over-IP) is not being blocked.
Please make sure that the mobility group names are on each other's controller.
Hope this helps

WLC 7.x GuestNet Anchor Controller Certificate Warning

Similar Messages

Maybe you are looking for