01-30-2012 09:41 AM
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?
01-30-2012 11:28 AM
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.
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base
01-30-2012 11:40 AM - edited 01-30-2012 11:55 AM
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
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
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.
01-30-2012 02:49 PM
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!