cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
31697
Views
35
Helpful
41
Replies

5508 WLC and Office Extend AP's

spirotsares
Level 1
Level 1

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

41 Replies 41

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

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

reload in 25 years

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) :

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtb81959

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

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.

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?

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

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________

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

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.

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.

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..:)

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

I have no NAT on the inside, the APs and the WLC mgmt interface are on the same vlan.

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.

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.

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

Review Cisco Networking for a $25 gift card