Wireless Access

Hi,

i have configured RAP to work with the VRRP ip adresse , and i have done a NAT-T to the VRRP ip address.

i have provisioned my RAP with the VRRP IP address .

my RAP works very well with the master controller , but when the master goes down , my RAP don't establish the contact with the second controller

It will not work if the VRRP is behind a NAT.  Instead you should (1) give both controllers individual public addresses and (2) have a DNS a-record with the two public address, where the RAP will have a single fqdn, and try the first address, then the second.  Please see herE:  http://community.arubanetworks.com/t5/Controller-Based-WLANs/Can-RAP-s-do-DNS-master-discovery/ta-p/175220

@Cjoseph ,i'm using NAT-T (the transversal NAT) and the VRRP virtual address.

in the RAP VRD they do not mention of this.

Hi!

Is this a master redundancy or a master-local setup?

You should check the things, Rajaguru mentioned. I´ve deployed several setup where we use a UDP 4500 port forward to an internal VRRP.

Cheers,

I've just deployed a new AOS8 Cluster and learned the hard way that RAPs are not supported when the Controllers are behind NAT. I now have to build a separate pair of controllers for RAPs, and these will sit behind NAT. I've some questions that I can't seem to find answers for in the User Manual or RAP VRD and would be grateful for any assistance:

Each controller will be NATd to its own public IP address.

The Public IP addresses will be used in 2 x public DNS A records (i.e. rap.domain.com) which the RAPs will use to locate the controllers.

Do these controller public IP addresses need to be configured as the LMS/Backup LMS? (or perhaps as the Secondary Managed Device - which is new in AOS8 - what's the difference?)

Will the new 2 x controllers be standalone with no database replication?

Can they be managed by the Virtual Mobility Masters which are managing the internal AOS Cluster?

If so, can the licenses be shared between the internal controllers and the RAP controllers?

Also, would I need to create a new Domain to separate shared config for the new RAPs (i.e. /md/InternalControllers/Device1..2 & /md/RAPControllers/Device1...2)

Would you deploy the new RAP controllers in a DMZ (with outside aggregation and inside network services intefaces as per VRD), or just on the internal network (simpler configuration)?

Any help is much appreciated!

---

@Meeko wrote:

I've just deployed a new AOS8 Cluster and learned the hard way that RAPs are not supported when the Controllers are behind NAT. I now have to build a separate pair of controllers for RAPs, and these will sit behind NAT. I've some questions

 

 

 

---

hi Meeko - can you clarify what you mean by "raps are not supported when behind nat" - who told you that and what was the reason ? nat-t ipsec by its very definition should be nat tolerant.

Hi RAPs are not supported in AOS Clustering when the MDs are behind a NAT device. I discovered this after testing in my lab and opening a 3 week case with Aruba TAC; which eventually was escelated and I was told it's not supported. There is currently no mechanism for the Cluster to communicate their NAT IPs to the RAPs so the RAPs have no means of establishing AAC and S-AAC tunnels.

---

@Meeko wrote:

Hi RAPs are not supported in AOS Clustering when the MDs are behind a NAT device. I discovered this after testing in my lab and opening a 3 week case with Aruba TAC; which eventually was escelated and I was told it's not supported. There is currently no mechanism for the Cluster to communicate their NAT IPs to the RAPs so the RAPs have no means of establishing AAC and S-AAC tunnels.

---

thanks for that Meeko - i understand what you mean. To me, not having thought that through kind of defeats the whole purpose of it :( Since RAP almost always implies an inbound port NAT somewhere in the path. Sadly there are many online resources extolling the virtues of RAP + cluster, just it's missing a big caveat asterisk next to it.

I wonder if you can hack at it with DNAT and put the NAT ip in the cluster-group, so that the internally the NAT IP is dnated to the controller-ip. Ugly but might work. 

to your other questions, yes, you would normally put the public ip of the nat device in lms and backup-lms. It seems to me that on the surface the bkup-lms and secondary master provide pretty similar function - the only question may be about the behavior when a controller goes away. For lms/bkup-lms, and the lms goes away, the ap will try again after 30 seconds to its primary lms, then after 20 seconds of timeout it will failover to backup. Including dhcp renewals etc., takes about 75 seconds - not sure if the secondary master is faster or slower or same.

the 2 controllers can be standlone and you can use a partial cpsec configuration in order to sync the whitelist. I am not sure how it plays with 8.x , but in 6.x you can do this and it will sync the rap whitelist

Master1
cluster-root-ip 192.168.1.10 ipsec <per-shared_key>

Master2
cluster-member-ip 192.168.2.10 ipsec <per-shared_key>

Mostly the RAP controllers I have seen have resided in a DMZ, generally with only 4500/udp port forwarded inwards and something making sure what comes out the services side is legit. Having said that, some do just bring it all the way inside the network with no additional firewall on the network side.

Hi,

Thanks for your reply. With regard to the DNAT "workaround", the Cluster Profile must contain the physical addresses of the controllers and these must be the actual public addresses so I'm not sure that would work.

I'll get this setup in a lab and test the difference between LMS/Secondary Master to see if there are any differences. I'll go with a DMZ deployment if that is most common (and also in the VRD).

Do you know if the RAP controllers can also be managed by the Mobillity Master that is also managing the internal cluster and whether the licenses can be shared?

---

@Meeko wrote:

 

Do you know if the RAP controllers can also be managed by the Mobillity Master that is also managing the internal cluster and whether the licenses can be shared?

---

sorry I don't know - maybe someone else will chime in on that one.

Sure you could manage them with the same MM. You just need to make sure you inject them at the appropriate spot in the hierarchy for config propagation.

I´m seriously hoping that Aruba can fix this issue instead of having people deploy complex workarounds or deploying additional "RAP controllers". Seems quite easy to add a field to the clustering-configuration for each controller to put what their NAT:ed public IP is and APs provisioned as RAPs could first try reaching the internal one and if not available try the public one.

I´m not going to my customers telling them to buy more controllers because of this, it´s embarrasing. I´d rather wait with clustering.

Cheers,

Hi, 

1. Have you configured an L2TP pool on the Standby Controller? 

2. I suppose it is a Cert based RAP. Is the RAP whitelist synced between the controllers? 

3. Are there enough Licenses on the Standby? 

Check the output of: 

1. show datapath session table | include <RAP-public-IP> 

2. show crypto isakmp sa 

3. show crypto ipsec sa 

4. show log all 100 | include <RAP-Name> 

Thanks, 
Rajaguru Vincent