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

Similar Messages

  • 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

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

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

  • IOS device failed to get ip address on multiple wlan on the same anchor controller

    Dear Experts:
    in my implementation, we need 2 WLANs be served on the same anchor controller.
    WLAN1: wep/40bit, integration with NAC/OOB on anchor controller for guest wlan service.
    and guest account controlled by NACguest server.
    WLAN2: wep/40bit, no layer3 secuirty for temporary using.
    foreign controller: WiSM on v6.0.196.4 (also testing on 6.0.182.0)
    anchor controller: WLC4402 on v6.0.196.4
    on WLAN1:
    Windows7 client get ip address correctly.
    iOS (iPhone4 on 4.3.1/4.3.2, iPad2 on 4.3.1/4.3.2) can get ip address correctly on WLAN1.
    WLAN2, iOS device cannot get ip address.
    compare with debug message "debug clien mac" + "debug dhcp message enable"
    on both foreign and anchor controller.
    on foreign controller:
    PM state has changed from: DHCP_REQD (7) Change state to RUN (20) last state RUN (20)
    on anchor controller:
    PM state always stay on: DHCP_REQD (7) Change state to DHCP_REQD (7) last state DHCP_REQD (7)
    Enable/Disable DHCP Address Assignment Required is not work.
    Enable/Disable DHCP proxy is not work.
    Any hit this issue when get ip address failed in multiple WLANs on the same anchor controller?
    In attachment log file,
    DMZ.log: anchor controller on DMZ.
    S3p1.log: WiSM on v6.0.182.0
    S3p2.log: WiSM on v6.0.196.4
    client mac: 00:1f:3b:05:33:c1, Windows7 Client
    client mac: 58:55:ca:cf:d2:07, iPhone4 with 4.3.1,
    WLAN1 subnet: 10.61.246.0/23
    WLAN2 subnet: 10.61.248.0/23

    Hi, Nicolas:
    just checking the attachment for the run-config on foreign/anchor controller.
    DMZ_run.config  - anchor controller
    s3p1_run.config - WiSM on v6.0.182.0
    s3p2_run.config - WiSM on v6.0.196.4
    at this moment, we have disable the wlan 10 on foreign controller, and wlan 2 on foreign controller.
    Wilson...

  • 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

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

  • Best place to create the DHCP scope for Guest SSID for remote office connected to HQ Foreign-Anchor controller

    Hi Experts ,
    Need help with the respect to understand the best practice to place/create the DHCP scope for remote site Guest SSID which will be connected to HQ Foeign-Anchor controller set-up.
    how about internet traffic for Guest SSID , which one will be recommanded :
    1) Guest SSID gets authenticated from HQ ISE and exposed to the local internet
    2) Guest SSID gets authenticated from HQ ISE and exposed to the HQ internet
    Thanks

    Hi George ,
    Thanks for your reply ...So you mean, best design would be to create the DHCP scope into DMZ for guest and let it get exposed to HQ internet ...
    how about if I have another anchor controller in lets say in other  office and I need to anchor the traffic or load balance from HQ foreign controller , in that case if I create DHCP scope into HQ anchor controller and if its down , I will loose the connectivity , how do I achieve fail-over to another anchor ?
    Do I need to create secondary scope into another anchor controller and let the client get reauthenticated from other location ISE and get ip address as well from another anchor controller . Is it what you are proposing ?

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

  • 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

Maybe you are looking for