01-19-2010 08:46 AM - edited 07-03-2021 06:26 PM
I have a 5508 wireless lan controller with a WPlus 100 AP license installed on it. The controller MGMT IP address is an internal IP (172.x.x.x). I setup a 1:1 static NAT, with an externally accessible (208.x.x.x) being translated to the inside mgmt address (172.x.x.x) of the controller with ports 5246, and 5247 UDPports open. I've connected the OEAP (1142) to the controller inside my network (primed it) and set it to H-reap mode. I then selected the office extend ap under the H-reap tab as per the 6.0 config guide.In the High Availabilty tab I've put the name of the controller and the externally accessible IP (208.x.x.x).
When I connect the OEAP to the outside world I look under the montior -> statistics -> AP join page and I see the AP with a successfull discovery phase message :"Received Discovery request and sent response" However the Join phase statistics are all zeroed out. Is there something I'm missing? Does the controller have to be in the DMZ or have an external MGMT IP for OEAPs to join?
Thanks
Spiro
03-17-2011 03:32 PM
RChester,
I'm curious about a few things...
1. What IP address do your main controllers use to anchor to the guest controller? NAT'd IP or internal(real IP)?
2. If you reply NAT'd IP... I currently have controllers anchored to the guest controller using the real IP address and I turn on NAT, will the internal controllers lose their connection to the guest anchor? Because you have to add the Guest Controller as a mobitlity member(different group) in order to anchor to that controller.
3. What configurations were needed on the firewall to achieve this setup?
a. Did you NAT the outside interface to the conrtoller's DMZ interface?
b. Did you NO NAT the internal interface to the DMZ interface?
Any information you can provide regarding using a guest anchor as an office extender would be greatly appreciated.
TIA,
Tony
05-04-2011 08:43 AM
The guest controller only registers Office Extend APs so I can use the Natted address for inbound APs
on the FW outside interface to DMZ and then use no-nat for mobility anchor on the inside interface to DMZ
It deffo works
09-12-2011 12:30 PM
Has anyone tried office extend with NAT and with 7.0.116.0 release?
What i can read it should be fixed in 7.0(110.12) :
But i cant find anything in the release notes for the 7.0.116.0:
http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn7_0_116_0.html
/Per
09-12-2011 08:24 PM
We've got a bunch of the aironet 600s working with a 5508 controller (running 7.0.116.0) in a DMZ. There's one big glaring problem - you *must* use the management interface to get them to work. I wanted to use a dedicated dynamic interface designated as an 'ap-manager' but it won't accept them (debug shows that it recognises the join requests but they're on the wrong vlan (using LAG) so the request is dropped.)
We have a firewall and controller with three DMZs - mgmt, office extend and guest.
Office extend:
- configure static translation on the firewall outside intf pointing to the mgmt ip address and permit the two oe udp ports (udp/5246 and 5247) inbound to that address (you can use PAT for this, depending on your public range)
- configure the mgmt interface as NAT enabled with the outside static address you just created
- prime the 600s with the controller ip (login to the 600 -> config ->wan ->controller ip)
- (optional but recommended) configure the controller to auth against list or aaa and add each ap.
- (optional) configure a dynamic interface for office extend and use this for your wlan
- configure the firewall ruleset according to your corp sec policies.
One thing to bear in mind here - we had problems when trying to use internal DHCP servers for the office extend subnets, the ASA kept filtering the packets and in the end we had to use the controller for DHCP. There may have been a fix but we couldn't find it in the time we had available. We also decided against anchoring the OE wlan to the internal controllers, we wanted to be able to pass the traffic through the IPS module on the ASA.
There seems to be a 1-AP-per-IP-address limitation with the office extend. So you only get one per home user.
Guest wifi:
- (optional) configure another static translation on the firewall inside intf pointing to the mgmt ip address and permit the mobility ports (udp/16666 and 16667) plus EoIP (ip/97)
- configure the mobility group list on your internal WLCs with the inside static translation plus the mobility group name
- configure the mobility group list on your DMZ controller with the IPs of your internal WLCs plus their mobility group names
- configure a guest wlan on your DMZ controller (using a guest dynamic intf) and configure the exact same wlan on the internals (using the mgmt interface); the configs for the Security, QoS and Advanced tabs must match.
- configure the mobility anchor for your guest wireless with the inside translation address (on the wlans page, hover over the blue arrow; or through cli)
Hope that helps.
09-12-2011 10:51 PM
Thanks for your replay.
The problem that i have when i enable NAT on my MGMT interface, the APs on the "inside" does not find the WLC.
If uncheck the NAT the APs will connect right away.
But im running 7.0.98.0 so maybe this i fixed in 7.0.116.0?
09-12-2011 10:58 PM
Hummm. O/E w/ 600's is supported only on 7.0.116.0 ...
I have a 5508 with a number of 600s. Im not NATing, I gave the WLC an outside IP and all is well.
Thinking of trying NAT to see if there is issues...
09-12-2011 11:02 PM
Sorry im using AP1142..:)
As it is right now i cant change the MGMT adress on the wlc...:(
Will try to upgrade the controller under day and see if it makes NAT to work
09-13-2011 12:00 AM
I haven't tried to connect our internal APs to the DMZ controller. I've got a couple of test units so I'll give it a go and let you know what happens.
09-13-2011 12:23 AM
It doesn't work for me but that might be because I have two different NAT addresses (inside and outside.) It definitely tries to connect but the peer_ip it receives is the outside NAT address so it attempts DTLS connection through that IP. The AP also shows up in the 'show ap join stats summary all' list.
As GS mentions above, a public IP might solve this problem so long as the appropriate internal routing was in place. The downside is that, if you use an auth list , you have to add every AP (internal and external) to it.
You might be able to configure a different dynamic interface as the ap manager but I'm not sure what that would do to your office extend APs. I can't really test that without breaking our OE environment (and jumping through a lot of change control hoops) but it might do the trick.
09-13-2011 05:29 AM
I confirm it that it work with 7.0.116.0 and NAT enable on the mgmt interface, both the outside OE 1142 AP and the inside 1142 APs finds the controller.
So i seems that the bug has been fixed..:)
09-13-2011 06:21 AM
Just to understand something here: is your controller in a DMZ and do you use NAT on the inside as well as the outside (or just on the outside?)
09-13-2011 06:27 AM
I have no NAT on the inside, the APs and the WLC mgmt interface are on the same vlan.
09-13-2011 06:31 AM
Ok, that makes sense now. I tried doing the same thing but I'm using NAT on the inside for the DMZ controller which means it fails.
11-23-2011 09:32 PM
I have the exact same problem even with code 7.0.222.0. As soon as I enable NAT on the management interface, the OEAP's work fine, but my internal wireless goes bonkers. I worked with TAC for 4 hours on the issue and got nowhere yet, still have an open ticket. I am also using LAG and was saddly disappointed to see the 5508 only supports 1 LAG, so there goes my idea of setting up couple extra interfaces in a LAG just for OEAP. I'll keep you posted if I find a fix, hopefully we can get this sorted.
11-23-2011 11:58 PM
Justin,
I've not read this entire thread above, but to address your specific scenario:
config network ap-discovery nat-ip-only disable
I bet that fixes your problem.
Without going in to too much detail, 7.0.98.0 didn't have any support for Local connected APs when NAT was enabled. This was enhanced in 7.0.116.0 to allow local connected APs while NAT is enabled. However, the feature had no "off" switch and it ultimately caused an issue with "Least Latency Join" OEAP upon upgrade to 7.0.116.0.......
In 7.0.220.0 that "off switch" now exists in the form of "ap-discovery NAT-IP-ONLY" which needs to be disabled in order to get local connected APs when NAT is enabled...
Clearly this isn't documented well enough. I'll see what I can do to spread the word through TAC and to stress it more in the Release Note. (It is loosely summarized in Configuring NAT Discovery section of the 7.0.220.0 Release Note).
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