5508 WLC and Office Extend AP's

Unanswered Question
Jan 19th, 2010

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (7 ratings)
Loading.
gphilebaum-nrh Thu, 01/21/2010 - 10:57

I don't have any answer, but I'm hoping someone does.  We are in the same situation.


We have a 5508 internally with a 10.x.x.x address behind an ASA 5510.  The NATed address of the 5508 is 66.x.x.x.  The AP is setup with the public address of the 5508 as its primed controller.


While watching our ASA logs, I can see the AP connecting through the ASA to the 5508 on UDP 5246 and 5247.  At the same time I'm capturing the log information on the AP via the console port, so I can see what is happening.


I have also captured the internal traffic with our NAM, and it shows the UDP 5246 and 5247 traffic getting through the ASA to the 5508 as well as the return traffic going back out.


What I've noticed is that once the the AP finishes the initial communication on UDP 5346 and 5247, it then attempts to establish the DTLS connection.  The problem is that it is trying to establish the DTLS connection to the 5508's private IP addess.


This is what is seen on the AP via the console.


%CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: 10.x.x.x peer_port: 5246


I've double checked the AP configuration, and the controller's 10.x.x.x address is not set anywhere; so I'm assuming it is being sent to the AP from the controller.


So, basically, after initial contact between the two public IPs, the AP then tries creating the DTLS connection to the private IP of the controller.


I'm hoping someone out there has some info on why this happens, and what to check.


Thanks in advance for the help.

arni.s.eggertsson Wed, 01/27/2010 - 02:42

I have had the same problems,


I solved the in the end by giving the WLC a public IP addresse, and making a subnet on the inside of the network with public addresses.


in the ASA5510 I do a static NAT for the WLC into the same address.


I reported this as a bug to Cisco,  the answer I got back was that it was working as designed.  I asked our account manager to check on this but have not had any luck yet having this changed.


Here is a link to the bug I reported.

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



regards,

Arni

gphilebaum-nrh Wed, 01/27/2010 - 05:43

I managed to fix it, but then ran into another situation.


I talked to our local account rep, and he pointed out that I missed a checkbox on the 5508's management interface.  The checkbox is to enable NAT.  It will then present a text box where the public address can be entered.  This will make the 5508 tell the AP to use the controller's public address to join instead of the private one.


While this resolved my above issue, it presented a new problem.  Once I enable NAT on the 5508 management interface, then I'm not longer able to join APs internally on the network.


What I'm going to try next is to setup two management interfaces.  One with NAT enabled, and one for internal use only.  Our internal DNS will then point to the internal management interface, so I can join and configured the APs in the office, and the Office Extend APs being issued out to employees will have the NAT'd interface configured for them to use.


I think that should take care of it.


Hope this info helps out everyone who may be in the same situation.

spirotsares Wed, 01/27/2010 - 08:54

Please keep us posted with your findings.  I spoke with a TAC escalation engineer and was told that at this point he'd recommend changing the mgmt. address back and forth from internal address to gloabally accessible address to join inside AP's first, then OEAP's.

arni.s.eggertsson Wed, 01/27/2010 - 10:48

Hi,


I tried that as well,  at that point the WLC sometimes told the Office Extend AP´s still to connect to the interface which was on the inside.  So if many AP's were connected the WLC started to try to load balance the AP's,  so when we had about 10 Office Extend AP's connected the we could not have more since they always tried to connect to the interface which was on the inside.


I´ve tried many things,  the only thing which actually solved this for me was to put an public IP on the WLC........ and nat that address into itself on the firewall.


Right now the AP´s are join with out problems.  both on the inside and outside.


The bug I linked to before explained that "work-around" which somebody mentioned to remove the NAT when joining AP's on the inside,  from my view that is not a workaround,  it is a hack...........  not something I did expect from Cisco.



Our main problems at this moment are performance problems.  I have an open TAC about that now,  maybe somebody has input about how they think office extend is performing..........




best regards,

Arni

gphilebaum-nrh Wed, 01/27/2010 - 11:56

Good info.  Thanks!


I just finished the test myself.  Results weren't very stable.


I had one mgt interface on port-1 with NAT.  The 2nd mgt interface on port-2 with no NAT.  DNS pointed to end interface only.


APs still weren't sure which one to talk to consistently.  The only thing that worked 100% of the time was to use a single mgt interface and turn off NAT when configuring a new AP.  I don't really like that solution.

Scott Pickles Tue, 02/09/2010 - 14:38

Using static NAT on a firewall doesn't work due to the nature of LWAPP/CAPWAP and the join process.  When you use static NAT on a firewall, the problem with the join part is that once the controller gets the hello (i.e. discovery) packet from the AP and subsequently the join request, the controller responds with its private internal address.  Therefore, when the AP sends its join reply, it sends it to that address (most likely an RFC-1918 address not routeable on the 'net).  So the join process fails.  That is why enabling NAT on the managment interface is required, or putting the controller into a DMZ.  Has anyone tried that?  I'm curious to know how this is all supposed to work out when you have a controller in LAG mode.  I almost never use ap-managers if I can avoid it.  I just got a 5508 last week, so I'll try some stuff over the next couple of weeks.


Regards,
Scott

bknapp1948 Thu, 02/11/2010 - 11:11

We have several 5508's and have been struggling getting OfficeConnect working.  All of our controllers use LAG.  At this point it appears that an entire 5508 needs to be dedicated to OfficeConnect AP's.  The reason for this has been pointed out by other responders.  The NAT address check box needs to be checked and the NAT Address address supplied.  Once this is done, the 5508 will always supply that address to AP's attempting to connect.


We have tried not using LAG and using multiple Mgmt interfaces as another responder tried, but found that connection results were very flakey for internal AP's


We will continue to watch this post and contribute any of our findings

481567 Wed, 03/03/2010 - 12:22

I have a 5508 WLAN controller with the WPLUS 100 AP license. I want to run this controller as both a guest anchor and the office extend feature at the same time. My question is this: How would the ports be configured on the WLAN controller? Would I have seperate interfaces for Guest and Office Extend? Would the Office Extend port sit on the private side of the network or public. Would you recommend a seperate VLAN for this port? Can you point me to some good documentation dedicated to the office extend feature? I need something that outlines the Controller port config & AP config?

481567 Thu, 11/18/2010 - 11:04

I want to do the same thing with my 5508. I would like to run my Hotspot

, Guest Access and Office Extend from the same controller. Any documentation or recommen

dations would be appreciated.


Thanks,

Gordon

rchester Fri, 12/17/2010 - 02:53

I am configuring office extend and guest anchor on the same controller today, I will update with the result

rchester Fri, 12/17/2010 - 05:36

A bit of fiddleing with the NAT rules on the customers Checkpoint and evrything worked fine. They have turned off auto translation and some other funnys because of merged networks (two corporates)


The remote worker location on vlan red dmz controller,

The guest users on vlan blue same dmz controller.

The dmz controller is the auto anchor for guest wlan sourced at the main controller on internal network.


Basicaly the configuration for both features are not dependant on each other but the routing, and natting accross the outside,dmz and inside interfaces have to be configured precisley to nat inbound from tinternet to the dmz controller but no nat from main wlc across the inside interface to the controller


In summary it works but firewall is the challenge

Vinay Sharma Fri, 12/17/2010 - 06:57

So guys it seems that tweaking the firewall does the trick. thanks for sharing the info. Has someone else tried with firewall settings?


thanks,

Vinay

Tony Davis Thu, 03/17/2011 - 15:32

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

rchester Wed, 05/04/2011 - 08:43

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

king.jason Mon, 09/12/2011 - 20:24

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.

Per Johansson Mon, 09/12/2011 - 22:51

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?

George Stefanick Mon, 09/12/2011 - 22:58

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

Per Johansson Mon, 09/12/2011 - 23:02

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

king.jason Tue, 09/13/2011 - 00:00

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.

king.jason Tue, 09/13/2011 - 00:23

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.

Per Johansson Tue, 09/13/2011 - 05:29

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

king.jason Tue, 09/13/2011 - 06:21

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

Per Johansson Tue, 09/13/2011 - 06:27

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

king.jason Tue, 09/13/2011 - 06:31

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.

jbeauchamp1 Wed, 11/23/2011 - 21:32

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.

weterry Wed, 11/23/2011 - 23:58

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

George Stefanick Fri, 11/25/2011 - 09:24

Thanks Terry I didnt know that ...


This is only if you use a "inside" controller as your O/E controller as well. Correct ...

jbeauchamp1 Thu, 11/24/2011 - 20:12

weterry thanks so much that did the trick! I know OE is somewhat new to TAC, but wish I hadn't spent 4 hours + 2 more days without hearing from them. Cheers!

weterry Thu, 11/24/2011 - 20:21

I'll see what I can do to spread the word about this particular "feature".  Unfortunately it is different in all 3 versions of 7.0, so that is greatly adding to the confusion.

jbeauchamp1 Thu, 11/24/2011 - 20:24

I still can't understand why the default wouldn't be disabled. The only time you would ever want it enabled is if you had a WLC dedicated for OEAP's in your DMZ....just food for thought. Thanks again, saved my bacon!

ahmed.morsy Tue, 05/10/2016 - 09:07
  • SOLVED 
  • You can control the address(es) are sent in the CAPWAP discovery responses when NAT is enabled on the Management Interface using the following command:

config network ap-discovery nat-ip-only { enable | disable }

Here:

enable — Enables use of NAT IP only in a discovery response. This is the default. Use this command if all the APs are outside the NAT gateway.

disable —Enables use of both NAT IP and non-NAT IP in a discovery response. Use this command if APs are on the inside and outside the NAT gateway; for example, Local Mode and OfficeExtend APs are on the same Cisco WLC.

So ... run the following Command on the controller 

config network ap-discovery nat-ip-only disable 

I used v8.0.121.0 release this command solve my Problem 

Hi,


The fix to this DMZ issues listed above have not worked for our new deployment. We have a dedicaed WLC2504 in a DMZ with a private IP assigned. A static NAT IP assigned and UDP-5246 and UDP-5247 are allowed.


The Firmware on the controller is 7.0.220.0.


The link below is also another reference document used however the discovery message back to the ap600 is the private address.

http://www.cisco.com/en/US/products/ps11579/products_tech_note09186a0080b7f10e.shtml


The syslog from the ap600 shows the incorrect discovery response at 13:56:56.719.


*Apr 10 13:56:46.751: CAPWAP State: Init.

*Apr 10 13:56:46.753: CAPWAP State: Discovery.

*Apr 10 13:56:46.779: Starting Discovery.

*Apr 10 13:56:46.780: CAPWAP State: Discovery.

*Apr 10 13:56:46.873: Discovery Request sent to [EXTERNAL_IP] with discovery type set to 0

*Apr 10 13:56:46.911: Discovery Response from [EXTERNAL_IP]

*Apr 10 13:56:46.912: Dot11 binding decode: Discovery Response

*Apr 10 13:56:56.719: Selected MWAR '[HOSTNAME]' (index 0).

*Apr 10 13:56:56.719: Ap mgr count=1

*Apr 10 13:56:56.719: Go join a capwap controller

*Apr 10 13:56:56.719: Choosing AP Mgr with index 0, IP = [INTERNAL_IP], load = 0..


*Apr 10 13:56:46.751: CAPWAP State: Init.
*Apr 10 13:56:46.753: CAPWAP State: Discovery.
*Apr 10 13:56:46.779: Starting Discovery.
*Apr 10 13:56:46.780: CAPWAP State: Discovery.
*Apr 10 13:56:46.873: Discovery Request sent to [EXTERNAL_IP] with discovery type set to 0
*Apr 10 13:56:46.911: Discovery Response from [EXTERNAL_IP]
*Apr 10 13:56:46.912: Dot11 binding decode: Discovery Response
*Apr 10 13:56:56.719: Selected MWAR '[HOSTNAME]' (index 0).
*Apr 10 13:56:56.719: Ap mgr count=1
*Apr 10 13:56:56.719: Go join a capwap controller
*Apr 10 13:56:56.719: Choosing AP Mgr with index 0, IP = [INTERNAL_IP], load = 0..



Has anyone else seen these issues with this version although is showing as being supported with this configuration?




Trent

weterry Tue, 04/10/2012 - 09:09

Looks like you are seeing:

CSCts52998    WLC 2504 doesn't respond to discover requests with Public AP manager IP

Resolved in 7.0.230.0 or 7.2.103.0

JASON WELCH Mon, 02/18/2013 - 07:41

I'm not sure if you ever got this working or not, but you also need this command entered at the command prompt of the controller that you enabled the NAT address on "

config network ap-discovery nat-ip-only disable"

This makes it so the controller will pass both the NAT address and the private internal address for CAPWAP discovery when an AP joins.  This works fine for me, I'm running version 7.2.103

Hope that helps.
Robert Mueller Mon, 08/24/2015 - 11:59

Hi,

how can I force internal APs to use the internal management IP of the 5508 WLC (7.6.130.0)?

All works fine, internal and external OE600 APs can successfully join. But internal APs seem to prefer the NAT IP of the WLC which means they create their own tunnel from a remote office instead of using the company WAN which creates performance issues. A workaround is to block the NAT IP in the firewall of each remote office but it would be nicer if the WLC would tell the internal APs where to go in the first place.

Thanks!

glen.leichty Mon, 10/26/2015 - 08:46

Robert,

 

We had the same issue, but only at our facilities that have direct internet access.  As all our internal AP's are assigned a static IP address in a specific range used only for AP's, we block internet access for those IP addresses on the firewall.  As the AP's cannot access the internet, they revert back to the internal address and connect without issue.

 

Hope this is helpful.

Actions

This Discussion

 

 

Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode