Setting up RAPs on small network

[bedwards@shamrockbank.com]

I have a 650 controller that I have finally got configured for campus access in our small location -- currently 3 APs, employee and guest ssid's -- it is working great!

I am wanting to add 6 RAPs to this configuration, 3 would be for work at home employee's, or traveling employees.  The other 3 would be single purpose, one wired computer hooked to the RAP with no wireless turned on.

Looking at the VBN Validated Reference Design, solution guide -- I am getting confused -- will I need another 802.1X profile, or can I use the existing employee profile?

Is there any notes for adding RAPs to an existing campus network?

Barry

[cjoseph]

You can use the existing profile.

To add rap to a campus setup you need:

- public address
- perimeter firewall rule statically natting the public address from your firewall to the management ip address of your controller
- perimeter firewall rule permitting udp 4500
- vpn pool on the controller for remote maps
- Mac addresses of the aps in the rap white list with ap name and ap group

It can be as simple as that.

[sathya]

Hi Barry,

An important thing that you have to consider when deploying a RAP, which is whether all data has to be tunneled to the HQ or just the corporate data. If you only require corporate data to be tunneled back then you should be using RAPs in split tunnel mode. If you want all the traffic to be tunneled back to HQ then you should use tunneled mode. This will require changes to the VAP profile, but you wont need a new 802.1X profile if you decide to use the same authentication servers.

If your using split tunnel mode, then the user role for the authenticated users should be modified to tunnel corporate traffic and scr-nat other internet traffic to the internet or to local subnet at the remote site. In this case the AAA profile will change as the user role for authenticated remote users is different than that for campus users, however your 802.1X profile can remain the same.

A sample user role for split-tunnel user will be as follows

 !

netdestination internal-network   

network 10.0.0.0 255.0.0.0

 !

ip access-list session remote-employee  

alias internal-network   alias internal-network any  permit  

user any any  route src-nat

!

ip access-list session sip-acl  

any any svc-sip-udp  permit queue high  

any any svc-sip-tcp  permit queue high

 !

 ip access-list session common  

user any udp 68  deny  

any any svc-dhcp  permit  

any any svc-icmp  permit  

user   alias dns-servers svc-dns  permit

 !

 user-role remote-employee  

access-list session common-dhcp  

access-list session sip-session-allow  

access-list session remote-employee

!

the "route scar-Nat" action will dynamically scr-nat the user traffic based on the destination.

The configuration on tunnel and split-tunnel forwarding mode is available in the VAP profile.

If your using tunnel mode for remote users too then you can use the same user role (unless you want different access rights for remote users), AAA profile and VAP rpofile that you used for campus.  Remember that you have to setup the VPN server module in the controller and add the RAPs to the RAP whitelist for RAP deploments.

For the RAPs that just require wired access, you have to configure the wired port profile with a wired ap profile and a AAA profile. You can then create a sepearte AP group or use AP specific settings to remove or add SSIDs & wired access to a RAP or a group of RAPs in an AP group.

For home users you should also consider configuring a backup SSID in bridge mode as this will help them get past the captive portal when they connect to the hotels.

Make sure that the LMS IP in the AP system profile used in the ap group for RAPs is a public address. If a NAT device is used for natting the traffic on the public IP  back to the controller then all the firewalls leading up to the controller should  permit UDP 4500.

Regards,

Sathya

[The.racking.monkey]

Another quick tip. Be mindful of latency on the circuits from remote sites/homes. If you leverage dot1x from there, and latency is high, some clients get upset and don't connect reliably. Obviously this is a client/dot1x aspect, not Aruba!