Aruba Bootcamp – Remote AP v6 - Home - Airheads …community.arubanetworks.com/aruba/attachments/aruba... · · 2013-02-22Aruba Bootcamp – Remote AP v6.1 12-12 ... is terminated

CONFIDENTIAL © Copyright 2011. Aruba Networks, Inc. All rights reserved

Aruba Bootcamp – Remote AP v6.1

12-1



12-2



12-3

The Secure Remote Access Point Service (Remote AP module) allows users at remote locations that are equipped with APs to connect to an Aruba controller over the internet. Since the internet is involved, data traffic between the controller and the remote AP is VPN encapsulated, and control traffic between the controller and AP is encrypted. For additional security, you have the choice of encrypting data as well as control traffic. Ideally suited for small remote offices, home offices, telecommuters, mobile executives, and for business continuity applications, Aruba’s Remote AP software module extends the enterprise network to any remote location by enabling seamless wireless data and voice wherever a user finds an internet-connected ethernet port.



12-4

Aruba Networks incorporates all of the benefits of a secure, centralized wireless and mobility infrastructure. We then take those benefits and extend them beyond the usual corporate office environment. Only Aruba can extend enterprise mobility to any place, any where: a truly global LAN. No matter where users are, they can get access to corporate resources. They connect the exact same way they do in the office, they authenticate exactly the same, they use all of their usual applications, Wi-Fi VoIP phones, from anywhere. The data is as secure as it would be in the office, no matter what network transport it traverses. Remote AP provides transparent user access. There is no need to remember to use VPN software, no need additional authentication mechanisms, and a consistent access to resources and services as if the user were sitting at their desk. Network administrators gain time and simplicity by only having a single infrastructure component to manage. There is a single place to apply policy, a single platform for management and troubleshooting.



12-5

Deployment Scenario 1: The remote AP and controller reside in a private network which is used to secure AP-to-controller communication. (Aruba recommends this deployment when AP-to-controller communications on a private network need to be secured.) In this scenario, the remote AP uses the controller’s IP address on the private network to establish the IPSec VPN tunnel. This can also be done by enabling Cpsec on the controller for Campus APs Deployment Scenario 2: The remote AP is on the public network or behind a NAT device and the controller is on the public network. The remote AP must be configured with the tunnel termination point which must be a publicly-routable IP address. In this scenario, a routable interface is configured on the controller in the DMZ. The remote AP uses the controller’s IP address on the public network to establish the IPSec VPN tunnel. Deployment Scenario 3: The remote AP is on the public network or behind a NAT device and the controller is also behind a NAT device. (Aruba recommends this deployment for remote access.) The remote AP must be configured with the tunnel termination point which must be a publicly-routable IP address. In this scenario, the remote AP uses the public IP address of the corporate firewall. The firewall forwards traffic to an existing interface on



12-6

By default, user data is not encrypted by the AP, only control traffic. User data should already be encrypted between the end station and Aruba switch so it adds unnecessary overhead to “double-encrypt” this traffic. While Aruba does offer an option to “double-encrypt” traffic, it is not recommended. The AP will first try to establish a native IPSec connection to the switch (IP protocol type 50). If this is unsuccessful, the AP will use NAT-T and encapsulate the IPSec frames in UDP (port 4500). Either IPSec or UDP port 4500 must be open and allowed through both firewalls. The connection will initiate from the AP to the switch. So the ports must be opened outbound from the branch office, and inbound at HQ.



12-7

The double encryption feature applies only for traffic to and from a wireless client that is connected to a tunneled SSID. When this feature is enabled, all traffic (which is already encrypted using Layer-2 encryption) is re-encrypted in the IPSec tunnel. When this feature is disabled, the wireless frame is only encapsulated inside the IPSec tunnel. All other types of data traffic between the controller and the AP (wired traffic and traffic from a split-tunneled SSID) are always encrypted in the IPSec tunnel. Aruba recommends that double-encryption not be turned on for inter-device communication over untrusted networks, as doing so is redundant and adds significant processing overhead for APs.



12-8

Traditional Remote AP operation tunneled all traffic back to the Aruba Mobility Controller and relied on the clients traffic to be centrally encrypted. The IPSec tunnels provide a means to continue to use the same addressing scheme on the remote network as is in the corporate network. Using the same network provides easy access to corporate IP resources. A bridge SSID could also be provisioned to locally bridge traffic directly out of the wired interface for the AP, usually used to provide guest access on the RAP. Split-Tunneling is used to route Internet bound traffic locally while backhauling traffic bound for the corporate site over an IPSec tunnel. Authentication is still centralized in this method.



12-9

All forwarding modes support band steering, 802.11k and station blacklisting.



12-10

This is the traditional RAP mode of operation, tunneling all traffic back to the corporate site. Guest access can be provided in tunnel mode, but it will also be tunneled back to the corporate site. Management frames as per local-probe response and association on APs. The AP, and not the controller, handles all 802.11 association requests and responses. Frames are GRE tunneled to the controller to an untrusted tunnel. 100% of station frames are tunneled to the controller. The controller removes or adds the GRE headers, decrypts or encrypts 802.11 frames and applies firewall rules to the user traffic as usual Users are visible in the command “show user”.



12-11

In bridge mode guest traffic is authenticated via a Pre-Shared Key (PSK) and is locally bridged. There is no firewall to protect these users and DHCP should be supplied by the local site. When a Campus or Remote AP is in bridge mode, the AP (and not the controller) handles all 802.11 association requests and responses, encryption/decryption processes, and firewall enforcement. Any 802.11e and 802.11k action frames are also processed by the AP, which then sends out responses as needed. Frames are bridged between wired and wireless interfaces. No frames are tunneled to the controller. Users are not visible in the command show user.



12-12

In Split-Tunnel mode the user traffic is terminated on the RAP, and from there a decision is made to either tunnel traffic to the corporate site or to route the traffic locally on the wired interface. Traffic tunneled back to the corporate site is re-encrypted, and a stateful firewall protects users from Internet traffic on the APs wired interface. Typically, the AP has ACLs that forward corporate traffic through the tunnel and source NAT the non-corporate traffic to the Internet. Data frames are either GRE tunneled to the controller to a trusted tunnel or NAT’d and bridged on the wired interface according to user role and session ACL. Data frames continuing to the controller for routing to corporate are already (usually) encrypted by the client so there is no further encryption (unless configured to do so). Management frames (PAPI) however are encrypted using a vpn between the remote access point and the controller. Users are not visible in the command show user. Typically, the station obtains an IP address from a VLAN on the controller. The Remote AP, and not the controller, handles all 802.11 association requests and responses, encryption/decryption, and firewall enforcement. 802.11e and 802.11k action frames are also processed by the remote AP, which then sends out responses as needed.



12-13

This is a simple illustration of configuring a role and policies for remote use. These same policies or a superset or subset of policies can be attached to other roles such as internal users as illustrating aruba firewall flexibility.



12-14

This slide illustrates a more complete solution with 2 AP Groups and 3 roles.



12-15

Persistent - SSID configuration obtained from the controller. Designed for 802.1x SSIDs. Always – Supports PSK ESSID only. SSID configuration stored in flash on AP. Standard - SSID configuration obtained from the controller. Backup – Supports PSK ESSID only. SSID configuration stored in flash on AP.



12-16

For Remote AP, the following are required: TFTP (UDP 69) - when the AP has corrupted image NAT-T (UDP 4500)

After the RAP IPSec connection is formed, all PAPI/GRE are tunneled through this IPSec nat-t session. Optional ports are optional for specific application server or network management station:

Remote packet capture with Ethereal/WireShark (UDP 5555-5560) Remote packet capture with AiroPeek (UDP 5000) AirMagnet Enterprise analyzer (UDP 2500-2501) SNMP (UDP 161 & 162)

Protocols Needed for usual AP to Controller Operation DHCP (UDP 67 & 68) FTP(TCP 21 & 22) TFTP (UDP port 69) NTP (UDP port 123) SYSLOG (UDP port 514) PAPI (UDP port 8211) GRE (protocol 47)



12-17

Configure an AP group and Roles A Separate AP group is created which contains all the profile configurations for remote AP, create separate firewall policies for remote users accessing corporate network Configure the VPN Server The IPSec VPN server must be configured on the controller terminating remote APs. The combination of Layer-2 Tunneling Protocol and Internet Protocol Security (L2TP/IPSec) is a highly secure technology that enables VPN connections across public networks such as the Internet. The remote AP will be a VPN client that connects to the VPN server on the controller. .



12-18

Configure VPN Authentication Before you enable VPN authentication, you must configure the authentication server(s) and server group that the controller will use to validate the remote AP. When you provision the remote AP, you configure IPSec settings for the AP, including the username and password. This username and password must be validated by an authentication server before the remote AP is allowed to establish a VPN tunnel to the controller. The authentication server can be any type of server supported by the controller, including the controller’s internal database. Provision the AP The VPN client settings must be configured on the AP to instruct it to use IPSec to connect to the controller. You must provision the AP before you install it at its remote location. To provision the AP, the AP must be physically connected to the local network or directly connected to the controller. When connected and powered on, the AP must also be able to obtain an IP address from a DHCP server on the local network or from the controller.



12-19

Assign the appropriate profiles to the vap, you can create new profiles as well



12-20

WLAN virtual-ap ”RAP" VLAN 100 forward-mode split-tunnel rap-operation standard



12-21

Create a new ap-system profile and add the Controller IP address or the public IP address that the remote AP will build the IPSec tunnel to



12-22

Example: Netdestination Corporate Network network 10.0.0.0 255.0.0.0 Define an IP access list to direct internal traffic through the IPSec tunnel and route other traffic via the local subnet. For all non-corporate traffic, the source address of the packet is the IP address of the Remote AP. ip access-list session split-tunnel any any svc-dhcp permit user alias Corporate-Network any permit alias Corporate-Network user any permit user any any route src-nat Assign this access list to the role for the remote corporate users. You can create a new role user-role remote-user-Corporate access-list session split-tunnel You can reuse an existing role and apply the policy to the specific AP group user-role "authenticated” access-list session "split-tunnel" ap-group "RAP" position 3



12-23

ip local pool ”rap-pool" ”172.16.100.100" ”172.16.100.200"



12-24

crypto isakmp key ***** address "0.0.0.0" netmask "0.0.0.0"



12-25

Ike pre-shared key must match VPN server key User Name and Password is used for L2TP/PAP authentication. This entry matches a user in the internal database. When you click on generate an entry is generated in the internal DB which corresponds to the user name and password shown in the above screen. One username/password can be created for the entire AP group or there can be a separate entry for each AP (configurable)



12-26

Statically assign the controller IP or the public IP to the Remote AP which it will use to build the IPSec tunnel, The AP can use dhcp for its own IP address



12-27

LAN wizard creates the Virtual AP

Group, WLAN, Mode of Operation, radio, VLAN, encryption, auth server, role and policies,

AP Wizard will Configure and Provision either prospective RAPs or currently connected RAPs.



12-28

Under Monitoring if you see IPSec up in the Access Points Field , the AP is functioning in Remote mode.



12-29

Remote-AP DHCP Server You can configure the internal DHCP server on the remote AP to provide an IP address for the “backup” SSID if the controller is unreachable. If configured, the remote AP DHCP server intercepts all DHCP requests and assigns an IP address from the configured DHCP pool. Session ACL for AP: Stateful access list for RAP This ACL is applied to Ethernet 0 to control inbound traffic from the Internet to the RAP. The Session ACL is applied to the interface to protect users from inbound traffic from the Internet DSCP Heartbeat for WAN or slow links (0-63) Prioritize AP heartbeats to prevent losing connectivity with the controller Corporate DNS Domain In Split Tunnel Mode this parameter dictates those domains that need to be resolved at the corporate DNS server. The remaining domains are derived locally Remote-AP local Network Access You can enable local network access between the clients (from same or different subnets and VLANs) connected to a RAP through wired or wireless interfaces in split-tunnel/bridge forwarding modes. This allows the clients to effectively communicate with each other without routing the traffic via the controller



12-30



12-31



12-32



12-33

(3200) #show crypto ipsec sa peer 10.69.3.253 Initiator IP: 10.69.3.253 Responder IP: 10.69.69.32 Initiator: No Initiator cookie:2273b334fbbc6607 Responder cookie:04d0a690d6ec73e2 SA Creation Date: Fri Feb 4 00:14:50 2011 Life secs: 7200 Initiator Phase2 ID: 10.69.32.104/255.255.255.255 Responder Phase2 ID: 0.0.0.0/0.0.0.0 Phase2 Transform: EncAlg:esp-aes256 HMAC:esp-sha-hmac Encapsulation Mode:Tunnel PFS: No OUT SPI 8eb4d600, IN SPI 61727f00 Inner IP 10.69.32.104, internal type C AP Reference count: 3



12-34

(MM800) #show vpdn l2tp configuration Enabled Hello timeout: 60 seconds DNS primary server: 10.100.135.50 DNS secondary server: 0.0.0.0 WINS primary server: 0.0.0.0 WINS secondary server: 0.0.0.0 PPP client authentication methods: PAP CHAP MSCHAP MSCHAPv2 IP LOCAL POOLS: Remote_ap: 1.1.1.1 - 1.1.1.15 (MM800) #show aaa authentication vpn VPN Authentication Profile -------------------------- Parameter Value --------- ----- Default Role RemoteAP Server Group default Max Authentication failures 0



12-35

Jul 7 14:18:04 :142003: <DBUG> |l2tp| network_thread: recv packet from 10.100.101.42, size = 20, tunnel = 3, call = 60765 Jul 7 14:18:04 :142003: <DBUG> |l2tp| handle_packet: rcvd Data packet len:20 ! Jul 7 14:18:04 :142003: <DBUG> |l2tp| write_packet: writing packet to tty Jul 7 14:18:04 :142003: <DBUG> |l2tp| write_packet: writing fd:18 bytes:24 retval:24 buf:1003b700 after sync async convertion Jul 7 14:18:04 :142003: <DBUG> |l2tp| handle_packet: after write_packet result:0 Jul 7 14:18:04 :142003: <DBUG> |l2tp| network_thread: recv packet from 10.100.101.42, size = 44, tunnel = 3, call = 60765 Jul 7 14:18:04 :142003: <DBUG> |l2tp| handle_packet: rcvd Data packet len:44 ! Jul 7 14:18:04 :142003: <DBUG> |l2tp| write_packet: writing packet to tty Jul 7 14:18:04 :142003: <DBUG> |l2tp| write_packet: writing fd:18 bytes:69 retval:69 buf:1003b700 after sync async convertion Jul 7 14:18:04 :142003: <DBUG> |l2tp| handle_packet: after write_packet result:0 Jul 7 14:18:04 :142003: <DBUG> |l2tp| network_thread: recv packet from 10.100.101.42, size = 32, tunnel = 3, call = 60765 Jul 7 14:18:04 :142003: <DBUG> |l2tp| handle_packet: rcvd Data packet len:32 ! Jul 7 14:18:04 :142003: <DBUG> |l2tp| write_packet: writing packet to tty Jul 7 14:18:04 :142003: <DBUG> |l2tp| write_packet: writing fd:18 bytes:48 retval:48 buf:1003b700 after sync async convertion Jul 7 14:18:04 :142003: <DBUG> |l2tp| handle_packet: after write_packet result:0 Jul 7 14:18:04 :142003: <DBUG> |l2tp| network_thread: recv packet from 10.100.101.42, size = 32, tunnel = 3, call = 60765 Jul 7 14:18:04 :142003: <DBUG> |l2tp| handle_packet: rcvd Data packet len:32 ! Jul 7 14:18:04 :142003: <DBUG> |l2tp| write_packet: writing packet to tty Jul 7 14:18:04 :124004: <DBUG> |authmgr| RX (sock) message of type 18, len 28 Jul 7 14:18:04 :124004: <DBUG> |authmgr| IP UP int: 1.1.1.3, ext:10.100.101.42 Jul 7 14:18:04 :124004: <DBUG> |authmgr| Tx message to Sibyte. Opcode = 17, msglen = 132 Jul 7 14:18:04 :142003: <DBUG> |l2tp| write_packet: writing fd:18 bytes:42 retval:42 buf:1003b700 after sync async convertion Jul 7 14:18:04 :142003: <DBUG> |l2tp| handle_packet: after write_packet result:0 Jul 7 14:18:04 :142003: <DBUG> |l2tp| IP UP from PPPD: TID 3, CID 60765, Inner ip 1.1.1.3 Jul 7 14:18:04 :142000: <INFO> |l2tp| Creating L2TP Tunnel from 10.100.101.42(innerip=1.1.1.3)



12-36

Aruba Bootcamp – Remote AP v6 - Home - Airheads …community.arubanetworks.com/aruba/attachments/aruba... · · 2013-02-22Aruba Bootcamp – Remote AP v6.1 12-12 ... is terminated

Documents