Wireless Access

Reply

RAP Redundancy won't work with VRRP

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

 


Raouf CHAHBOUNE
ICT Network & Security Engineer
CCNP R/S | CCNA Security | ACMP|ACCP|ACDX



[If my post is helpful please give kudos, or mark as solved if it answers your post.]
Aruba Employee

Re: RAP Redundancy won't work with VRRP

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 

Thanks,
Rajaguru Vincent
CWNA | CWSP | CWAP | CWDP | ACMP
Guru Elite

Re: RAP Redundancy won't work with VRRP

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

 

 

 



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Re: RAP Redundancy won't work with VRRP

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

in the RAP VRD they do not mention of this.

 


Raouf CHAHBOUNE
ICT Network & Security Engineer
CCNP R/S | CCNA Security | ACMP|ACCP|ACDX



[If my post is helpful please give kudos, or mark as solved if it answers your post.]

Re: RAP Redundancy won't work with VRRP

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,

Christoffer Jacobsson | Aranya AB
Aruba: ACMX #537 ACCP | CWNP: CWNA CWDP CWSP CWAP
Occasional Contributor I

Re: RAP Redundancy won't work with VRRP

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!

 

 

 

Frequent Contributor I

Re: RAP Redundancy won't work with VRRP


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.

 

Occasional Contributor I

Re: RAP Redundancy won't work with VRRP

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.

Frequent Contributor I

Re: RAP Redundancy won't work with VRRP


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.

 

 

Occasional Contributor I

Re: RAP Redundancy won't work with VRRP

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?

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: