01-19-2010 10:54 AM - edited 07-03-2021 06:26 PM
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.
Solved! Go to Solution.
01-20-2010 08:35 AM
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.
01-20-2010 08:35 AM
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.
04-13-2011 11:23 AM
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?
07-11-2013 03:44 AM
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?
07-11-2013 04:53 AM
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
07-11-2013 05:45 AM
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.
07-11-2013 05:49 AM
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"
07-11-2013 06:07 AM
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?
07-11-2013 06:15 AM
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
07-11-2013 06:30 AM
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
07-11-2013 06:37 AM
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.
07-12-2013 06:29 AM
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
07-11-2013 06:32 AM
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
07-12-2013 07:25 AM
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!!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide