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

Answered Question
Jan 19th, 2010

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.

I have this problem too.
0 votes
Correct Answer by brian.kachel@qu... about 4 years 2 months ago

I've use both designs and had success with both.  There are obvious benefits to installation in the 2 legged model because you don't need to open up the pinholes through the firewall for management etc.

Cisco originally recommended that solution in environments where the FW may tend to disconnect sessions for packet inspection.

The WLC is not a router so we didn't have a security problem with the 2 arm method, but some people prefer to have the anchor entirely in the DMZ.

Using the LAG approach with everything in the DMZ has also function well for us.  It did require the rules in the FW but once this is accomplished the end result is the same.

I do have an issue with some distant locations with high latency - they were able to anchor when I had the 2 legged approach with the management on the private lan - now they are unable to anchor with the entire connection in the DMZ.

That is a unique situation with ~300 ms latency.. the other sites are running fine.

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
Correct Answer
brian.kachel@qu... Wed, 01/20/2010 - 08:35

I've use both designs and had success with both.  There are obvious benefits to installation in the 2 legged model because you don't need to open up the pinholes through the firewall for management etc.

Cisco originally recommended that solution in environments where the FW may tend to disconnect sessions for packet inspection.

The WLC is not a router so we didn't have a security problem with the 2 arm method, but some people prefer to have the anchor entirely in the DMZ.

Using the LAG approach with everything in the DMZ has also function well for us.  It did require the rules in the FW but once this is accomplished the end result is the same.

I do have an issue with some distant locations with high latency - they were able to anchor when I had the 2 legged approach with the management on the private lan - now they are unable to anchor with the entire connection in the DMZ.

That is a unique situation with ~300 ms latency.. the other sites are running fine.

ramessecurity Wed, 04/13/2011 - 11:23

Sorry Dave for using your thread ,

` I'm setting up wlan solution for a client. It involves mobility group, anchor and without LAG. Anchors are placed in DMZ. Anchors management interfaces are blocked from sending any packet to corporate network wlc.

Is it possible to configure mobility group using AP-manager IP. If WLCs management interfaces are not connected & only used for management purpose(bloody corporate policy), is it possible to setup wlan using AP-manager ip addresses. Will it have any impact in wlan?

mobility group member add ----> can we specify ap-manager ip here?

mobility group anchor wlan add  ---> anchor ap-manager ip here?

c-balduck Thu, 07/11/2013 - 03:44

Hi,

I'm deploying the 2 legged setup, 1 leg in DMZ and 1 in the corporate lan. The mobility stuff works, guest clients get dhcp, but when they want to do an nslookup, I see fw-logs of the management interface trying to do a lookup..

This is a problem since I want the guests to use public DNS servers...

How can I get around this?

Scott Fella Thu, 07/11/2013 - 04:53

The traffic should egress out of the WLAN's interface you have set on the WLC. I have done this many times and have pointed the guest DNS to a public DNS server. You have created a dynamic interface that is associated to a port in the DMZ switch correct? Since that port has to also be a trunk port, make sure you only allow the DMZ vlan on that port and also make sure on the trunk port that the management is connected to doesn't allow the DMZ vlan.

Sent from Cisco Technical Support iPhone App

c-balduck Thu, 07/11/2013 - 05:45

Hi Scott,

yes I have a dynamic interface associated / connected directly on DMZ switch. That port is a trunk and only allows the VLAN to the the ASA Guest subinterface.

The trunks to the management interfaces have only the management vlan allowed.

Stilll, when I ping the public DNS from the Anchor, I see the requested originated from the management interface.

Scott Fella Thu, 07/11/2013 - 05:49

Oh... so your are anchoring the ssid to another WLC which you are doing one leg in one leg out?  That might be the issue.... When using the setup like what you have, its works best when your not anchoring at all.  If you have a seperate wlc, you should just really place that in the dmz.

Thanks,

Scott

Help out other by using the rating system and marking answered questions as "Answered"

c-balduck Thu, 07/11/2013 - 06:07

Yes, that is right. I want(ed) to have guest ssid's anchored on the 2nd wlc and go out via dmz.

You suggest to not anchor at all, but how can I have the same ssid's (corp and guest) broadcasted then if the wlc's dont talk to each other? 

Scott Fella Thu, 07/11/2013 - 06:15

The foreign WLC will have the SSID's and that is in the inside network. You place the other WLC in the DMZ and only anchor the guest SSID to that.

Sent from Cisco Technical Support iPhone App

c-balduck Thu, 07/11/2013 - 06:30

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

grabonlee Thu, 07/11/2013 - 06:37

Christophe,

Even if you have a different dynamic vlan for the guest IP addresses, the DNS requests will always go through the MGT interface. That doesn't mean that it's the mgt IP address that is sent to the Internet. The Firewall will NAT for you. If you run a packet trace on your laptop, you will see that the DNS query will go from the guest vlan to the mgt interface and the mgt interface will respond with the DNS infomation that was obtained.

c-balduck Fri, 07/12/2013 - 06:29

Hi Osita,

I have disabled web-authentication for troubleshooting and permitted icmp.

Wireshark output from laptop shows it sends a query directly to the DNS, and nslookup fails. (with or without web-auth)

Packet-tracer on ASA shows that connectivity is OK to public IP's.

The guest laptop can ping the fw interface (dmz) but no public IP's.

Would there be a NAT problem? If so, why would packet-tracer allow everything?

Packet-tracer result:

input-interface: Guest_wireless

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

I see no translate hits on the "sh nat" output

12 (dmz) to (outside) source dynamic Guest_wireless 5.149.114.107

    translate_hits = 0, untranslate_hits = 0

Scott Fella Thu, 07/11/2013 - 06:32

Take a look at this guide as it explains the DMZ anchor setup.

http://www.cisco.com/en/US/docs/wireless/technology/guest_access/technical/reference/4.1/GAccess_41.html

Sent from Cisco Technical Support iPhone App

c-balduck Fri, 07/12/2013 - 07:25

Of course, the problem was NAT :-s

nat (dmz,outside) dynamic "public ip"   had to become

nat (guest_int,outside) dynamic "public ip"

Guest_int is the new interface, and I'm programmed for NAT config related to DMZ..

Anyhow, I'm happy it's fixed.

Thanks for the help all!!

Actions

Login or Register to take actions

This Discussion

Posted January 19, 2010 at 10:54 AM
Stats:
Replies:13 Avg. Rating:5
Views:9306 Votes:0
Shares:0

Related Content

Discussions Leaderboard