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?
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.
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.
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.
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.
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..........
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.
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.
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
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?
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.
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
So guys it seems that tweaking the firewall does the trick. thanks for sharing the info. Has someone else tried with firewall settings?
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.
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
Has anyone tried office extend with NAT and with 126.96.36.199 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 188.8.131.52:
We've got a bunch of the aironet 600s working with a 5508 controller (running 184.108.40.206) 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.
- 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.
- (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 220.127.116.11 so maybe this i fixed in 18.104.22.168?
Hummm. O/E w/ 600's is supported only on 22.214.171.124 ...
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...
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 126.96.36.199 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?)
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 188.8.131.52. 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.
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, 184.108.40.206 didn't have any support for Local connected APs when NAT was enabled. This was enhanced in 220.127.116.11 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 18.104.22.168.......
In 22.214.171.124 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 126.96.36.199 Release Note).