Guest Access w/ DMZ Anchor controller

I know the documentation says that the Cisco 2100 series WLAN controllers can NOT terminate a VPN tunnel and as such cannot act as the Anchor controller in the DMZ.
Does the 2500 series suffer from the same problem, or can it be used as an anchor?
The only approved anchors listed are the 3750 w/ WLC, the 4400 series, and the 6500 series, but no mention is made of the 2500 or 5500 controllers.

The 2500 cannot be used as an anchor (but as a foreign controller, just like the 2100), the 5500 is capable of doing both.
Stefan

Similar Messages

  • 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.

  • ISE with CWA and wired guest access via WLC Anchor

    Can an Anchor WLC (WLCa) provide a wired guest LAN service if the wlan guest access is using CWA?
    We are deploying a WLAN only ISE solution (it is a full license ISE though) but they just want a few wired guest ports.  I was hoping to add L2 switch to the DMZ where the WLCa is and that the L2 switch wouldnt need any other config as the WLCa just bridges the wired to the wlan vlan.  This Im sure i have done before.
    So now I have set wiredguest the same as i have done before ISE and my wired clients get an IP address, but when they redirect, the URL they get is different, and the redirect just doesnt work.
    It comes out as:
    https://my_ise_ip:8443/guestportal/Login.action?switch_url=https://my_ise_host/login.html&wlan=my_wired_guest_lan&redirect=www.google.co.uk
    So does my simple L2 only switch need an ISE config on it or should the WLCa be handling or the redirection just as it would for a wlan device.

    The ISE never receives an auth entry, so i dont believe the redirect is working for the wired client.  So even though the clients browser gets a redirect url which fails connection, the client info in the WLCa doesnt have a redirect ACL listed like a wlan client would

  • 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

  • Wired Guest Access

    Hi!
    I enabled Wired Guest Access to connect Wired Ethernet Users to WLC. It doesn't explained on user guide how WLC does? If WLC strips 802.3 frame and encapsultes it with 802.11 or not. Any way, I couldn't redirect the ethernet flux to WLC and then to the external controller authenticator (Captive portal authentication).  Need a help!
    Cheers!

    In order to provide the wired guest access, the designated ports in the layer-2 access layer switch need to be configured on the guest VLAN by the administrator. The guest VLAN must be separate from any other VLANs that are configured on this switch. The guest VLAN traffic is trunked to the nearest WLAN local controller. The local controller tunnels the guest traffic across a EoIP tunnel to a DMZ Anchor controller. This solution requires at least two controllers.
    Here is the URL for the Wired Guest Access using Cisco WLAN Controllers Configuration
    http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00808ed026.shtml#ancwlan

  • Ask the Experts: Wired Guest Access

    Sharath K.P.
    Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions on wired guest access with expert Sharath K.P. Wired guest access enables guest users to connect to the guest access network from a wired Ethernet connection designated and configured for guest access. Sharath K.P. is a Customer Support Engineer specialized in wireless and switching technologies at the Technical Assistance Center in Cisco Bangalore. He has been troubleshooting wireless and switching networks and management tools since 2009. Sharath has a bachelor's degree in Electrical Electronics Engineering from P.E.S College of Engineering (PESCE), VTU at Belgaum. India. He holds CCNP certifications in R&S and Wireless.
    Remember to use the rating system to let Sharath know if you have received an adequate response. 
    Sharath might not be able to answer each question due to the volume expected during this event.
    Remember that you can continue the conversation on the Wireless and Mobility sub-community discussion forum shortly after the event. This event lasts
    through January 27, 2012. Visit this forum often to view responses to your questions and the questions
    of other community members.

    Hi Daniel ,
    Wonderful observation and great question .
    Yes, we dont find any recommendation or inputs in Cisco Docs on scenarios  where  we  have multiple foriegn WLC's present .When we go through the Cisco Doc available for Wired Guest Access
    http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00808ed026.shtml
    Two separate solutions are available to the customers:
    A single WLAN controller (VLAN Translation mode) - the access switch  trunks the wired guest traffic in the guest VLAN to the WLAN controller  that provides the wired guest access solution. This controller carries  out the VLAN translation from the ingress wired guest VLAN to the egress  VLAN.
    Two WLAN controllers (Auto Anchor mode) - the access switch trunks  the wired guest traffic to a local WLAN controller (the controller  nearest to the access switch). This local WLAN controller anchors the  client onto a DMZ Anchor WLAN controller that is configured for wired  and wireless guest access. After a successful handoff of the client to  the DMZ anchor controller, the DHCP IP address assignment,  authentication of the client, etc. are handled in the DMZ WLC. After it  completes the authentication, the client is allowed to send/receive  traffic.
    So  as per Cisco best pratices using multiple foreign controllers for the same wired guest VLAN is not supported and the results will be unpredictable
    I do understand the confusion regarding such scenario's as this( Multiple foriegn WLC's) is a very general setup which customer would like to deploy .
    We have already opened a bug for the same (Little late though )
    BUG ID :CSCtw44999
    The WLC Config Guide should clarify our support for redundancy options for wired guest
    Symptom:
    Do not trunk a wired guest VLAN to multiple foreign controllers.  This is not supported, and will
    generate unpredictable results.
    Some of the other tthat changes we will be making as a part of doc correction would be
    http://www.cisco.com/en/US/docs/wireless/controller/7.0MR1/configuration/guide/cg_user_accts.html#wp1066125
    1. The WiSM2 needs to be added as a supported controller.  (Not sure about the 7500, check with PM)
    2. Where it says "Do not attempt to trunk a guest VLAN on the Catalyst 3750G ...", this should read:
    "Do not trunk a wired guest VLAN to multiple foreign controllers.  This is not supported, and will
    generate unpredictable results."
    3. Add at least a line mentioning support for multiple anchors for a guest wired LAN.
    Now  if you already have such deployments , ther criteria would be that nearest WLC on the broadcast domain (Layer 2) would  respond to the client associtation request .
    Cisco Controller) >Tue Sep 11 13:27:42 2007: 00:0d:60:5e:ca:62 Adding mobile on Wired Guest 00:00:00:00:00:00(0)
    Tue Sep 11 13:27:42 2007: 00:0d:60:5e:ca:62 apfHandleWiredGuestMobileStation (apf_wired_guest.c:121) Changing state for mobile
    00:0d:60:5e:ca:62 on AP 00:00:00: 00:00:00 from Idle to Associated .
    I hope the above explanation could clarify your doubts to certain extent and also keep you
    informed on Cisco's  roadmap on this feature .
    Regards ,
    Sharath K.P.

  • Anchor Controller with 8021.x

    Hello,
    I would like to know if the Anchor controller is compatible with 802.1x.
    For my guest Wireless I would like to authentification with WPA2 AES on Layer 2 and a second authentification in Layer 3 with web authentification.
    I have tested it with my controller and it's working but when I apply my anchor mobiltity group it don't work.
    Could you please help me.
    Best Regards  

    The process?  The foreign elf and the anchor has to have the same configuration on the WLAN. The only exception is really the profile name and the interface.  If the layer 3 is using radius to authenticate, then your guest anchor has to communicate to the radius. If your using local username and password, then that has to be defined in the anchor. 
    Mid you haven't setup anchoring before, create a new open ssid and make sure anchoring works. 
    https://supportforums.cisco.com/document/11936816/cisco-guest-access-using-wlc-anchor-setup-–-release-70
    -Scott

  • DMZ Anchor DHCP Issue

    Hello,
    I recently configured a DMZ Anchor controller and both control and data paths are showing 'up'.  When a user connects the the WLAN they are receiving an IP address from the foreign controller interface rather than the DMZ anchor which is configured for an internal DHCP server.  I have the guest WLAN configured with the management interface which has the controller's IP as the DHCP server.
    Any ideas?
    Thank you,
    Scott

    Could you please try enabling DHCP Proxy on Anchor Controller:-
     Controller > Advanced > DHCP > Enable DHCP Proxy
    When DHCP proxy is enabled on the Cisco WLC, the Cisco WLC unicasts DHCP requests from the client to the configured servers. Consequently, at least one DHCP server must be configured on either the interface associated with the WLAN or the WLAN itself.

  • 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

  • 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

  • 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

  • Guest wireless running slow 1 Mb for one of the foreign vWLC (AIR-CTVM-K9) , the Anchor controller is on DMZ (AIR-CT5508-K9)

    Hi,
    We have few vWLC (AIR-CTVM-K9) as the foreign controller for anchoring on difference site . The Anchor controller (AIR-CT5508-K9) is located at DMZ at the main site. The guess wireless are working fine for all the site except Site A . The download speed is <1mb and i do not see any restriction on the Foreign controller as well as the anchor controller . Upload speed could reach to 5Mb . I have check the configuration for other foreign controller and it is working fine and have the similar setting . Could you please shed some light on where should i start to troubleshooting this . User are able to get the correct ip address, gateway , dns server ip address without any issue.

    Issue resolved . End out it is the Qos apply on the vWLC switch port that slow down the speed. Remove the Qos do the trick.

  • Anyone seen strange behavior with wired guest access on WLAN Controller?

    Cisco Doc ID 99470 spells out how to deploy wired guest access over wireless LAN Controllers.
    That said, everything has been up and working for almost a year.  Guest wireless uses anchor controller in DMZ - no issues.
    Recently configured two wired ports for wired guest networking.  The desktops get the correct IP address via DHCP.  A wireless client (on the table right next to the wired clients) on the guest wireless gets an IP address as expected as well.
    Open a continuous ping to the gateway 172.16.16.1 on all three machines.
    The two desktops will ping for a few minutes and then stop for 30 seconds or longer.  Wireless client will keep its connection.  (you might think it would be the other way around)
    I understand there is a 65,535 second inactivity timeout, but I am only sitting here for minutes, not 18 hours when this happens.
    On the wired desktops, you have to bring up a browser and log back in just as you do on a wireless client ever few minutes.  After debugging the client, I found a "failed to find scb" message in the output.
    The other trick here is that the wired clients are miles away from where I can actually get on the CLI of the controller.  This makes it difficult to run a debug and bring up a browser since I am not local to the machines when running debugs.
    Has anyone ever see this behavior?  Has anyone see the "failed to find scb" message?
    Thanks in advance!
    Succ
    essfully plumbed mobile rule (ACL ID 255)
    *pemReceiveTask: Dec 30 11:33:15.735: 00:25:b3:ce:cb:ef 0.0.0.0 tokenID = 5
    *pemReceiveTask: Dec 30 11:33:15.735: 00:25:b3:ce:cb:ef Set bi-dir guest tunn
    el for 00:25:b3:ce:cb:ef as in Export Foreign role
    *pemReceiveTask: Dec 30 11:33:15.735: 00:25:b3:ce:cb:ef 0.0.0.0 Added NPU ent
    ry of type 1, dtlFlags 0x4
    *spamReceiveTask: Dec 30 11:34:54.569: CCKM: Send CCKM cache entry
    FP08:(33207772)[cmdSendNodeInfo:3787]failed to find scb 0023.2422.c6eb
    *mmListen: Dec 30 11:35:58.539: 00:25:b3:ce:cb:ef Scheduling deletion of Mobi
    le Station: (callerId: 73) in 1 seconds
    *mmListen: Dec 30 11:35:59.471: 00:25:b3:ce:cb:ef Scheduling deletion of Mobi

    I found it in the document
    B.1 How Logout Works
    The WebGate logs a user out when it receives a URL containing "logout." (including the "."), with the exceptions of logout.gif and logout.jpg, for example, logout.html or logout.pl. When the WebGate receives a URL with this string, the value of the ObSSOCookie is set to "logout."
    The Access System sets an obSSOCookie for each user or application that accesses a resource protected by a WebGate. The obSSOCookie enables users to access resources that are protected by the Access System that have the same or a lower authentication level. Removing the ObSSOcookie causes the WebGate to log the user out and requires the user to re-authenticate the next time he or she requests a resource that is protected by the Access System.
    Well, I havn't got that far in the document:)
    Thanks a lot for your help.
    -Wei

  • Guest Anchor Controller DNS issues

    Hi,
    I have an anchor controller (4402) is running version 4.0.219.0 in our DMZ
    The main service we use is a guest service which uses the anchor controller in the DMZ for access to the internet. Authentication is via the WEB re-direct feature. We currently have a subnet assigned to the Guest SSID with a 22 bit mask providing just over 1000 ip addresses to clients.
    Change required (which were attemped).
    1. Move the dhcp server to a dedicated dhcp server and off the anchor controller.
    2. Increase the address space to /21 thereby providing about 2000 addresses for clients. (By changing the ip address mask on the SSID interface).
    Problems
    The provision of dhcp from the new dhcp server worked fine and clients were able to pick up dhcp addresses when they associated to the wireless SSID.
    The problem was that only some clients were being re-directed to the web-redirect page for authentication. Any clients who were re-directed were able to authenticate correctly.
    Diagnosis
    It appears that only some client's dns requests were being passed on from the anchor controller. A capture of packets between the anchor controller and the DMZ firewall did not pick up dns packets from an assiocated and connected client even when running dns queries manually from the wireless client.
    A reboot of the controller did not make any difference.
    Is there any throttling effect on dns queries which may have being implemented on the anchor controller by default once the subnet mask was increased? I noticed authentication successes of about 1 a minute while normally we would see authentication rates of 1 every couple of seconds.
    Are there any bugs or known reason why an interface mask of /21 would be problematic on the controller?
    We had to roll back the changes to the original configuration in order to bring the service back on-line.

    Hello Eoin
    Where is the external dhcp server ? in the same DMZ or on the inside network ? we have a /19 subnet allocated to the guests and I dont foresee any throttling on the dns queries.. The connectivity anyway till the anchor controller is on EoIP, and is just like the client connecting onto a local controller..
    laptops which had issues -> was the problem interim or its just that they are not able to get the web redirect page at all ?
    Check the release notes for any bugs on this software:
    http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn402190.html#wp170104
    Raj

  • Guest Anchor Controller

    Cisco documentation recommends using a dedicated controller for the guest anchor controller function becuase it needs to be located in the DMZ. However, if I have spare capacity on an existing controller (ie one used to manage APs) then perhaps I can also use it as the guest anchor.  Instead of being physically connected to the DMZ, I would just extend a guest user VLAN from the guest anchor controller to the DMZ.  I would welcome feedback on the validity & security of this alternate solution.
    Thanks.

    Hi Marvin,
    Like anything in networking, there are always different ways to skin a cat. First lets chat about the guest anchor deployment in the DMZ. This particular design is Ciscos most secure way to handle guest access. The wireless guest packet never touches your switch fabric until it hits the DMZ. The packet rides over the guest wifi, hits the ap, gets encapsulated and doesnt get unecapsulated until it hits the DMZ anchor.
    Another way and less expensive is to add a dynmic interface on your internal controller and ride that trffic into the DMZ. I have customer that do this very thing as well. Its cheaper and may be less hassle configuration wise.
    In this approch, your guest packet gets unwrppaed can placed at the door step of the WLC.
    I hope this helps.
    Does this make sense?

Maybe you are looking for