Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

ARUBA ACCESS POINT TUNNELING TO CONTROLLER

This thread has been viewed 28 times
  • 1.  ARUBA ACCESS POINT TUNNELING TO CONTROLLER

    Posted Sep 17, 2014 03:07 AM

    Hi guys,

     

    I would like to understand more about how the Aruba access points connects back to controller. I understand that I can configure DHCP option 43 to 'tell' the access points which controllers to connect to. When the access points connects to the controller, does the access point 'tunnels' all end-user traffic and control traffic to the controller? If that is the case, end-user traffic will originate from the controller?

     

    If that is so, if my topology includes 2 locations where the controller is at HQ and the access points are at the branch office, can I have certain traffic local to the access point to direct connect to devices locally and traffic that needs to connect at the HQ to tunnel back? Is this controlled on the SSID itself?



  • 2.  RE: ARUBA ACCESS POINT TUNNELING TO CONTROLLER

    Posted Sep 17, 2014 05:15 AM

     

     

    Hi,

     

    that's a decision for each VAP you configure in the AP-Group. There are four different forward modes (tunnel, bridge, split-tunnel, decrypt-tunnel). There you can decide whether the data is tunneled to the controller using GRE, bridge directly to the LAN, or a mix of both (corporate traffic goes through the tunnel, internet access goes into the LAN.

     

    For the control traffic there is a seperate tunnel for every access point. You can check that if you enter this via CLI: show datapath tunnel table

     

    Here is the ouput from Aruba OS Guide:

     

    Tunnel: The AP handles all 802.11 association requests and responses, but sends all 802.11 data packets, action frames and EAPOL frames over a GRE tunnel to the controller for processing. The controller removes or adds the GRE headers, decrypts or encrypts 802.11 frames and applies firewall rules to the user traffic as usual. Both remote and campus APs can be configured in tunnel mode.

     

    Bridge: 802.11 frames are bridged into the local Ethernet LAN. When a remote AP or campus 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. The 802.11e and 802.11k action frames are also processed by the AP, which then sends out responses as needed. An AP in bridge mode does not support captive portal authentication. Both remote and campus APs can be configured in bridge mode. Note that you must enable the control plane security feature on the controller before you configure campus APs in bridge mode.

     

    Split-Tunnel: 802.11 frames are either tunneled or bridged, depending on the destination (corporate traffic goes to the controller, and Internet access remains local). A remote AP in split-tunnel forwarding mode handles all 802.11 association requests and responses, encryption/decryption, and firewall enforcement. the 802.11e and 802.11k action frames are also processed by the remote AP, which then sends out responses as needed.

     

    Decrypt-Tunnel: Both remote and campus APs can be configured in decrypttunnel mode. When an AP uses decrypt-tunnel forwarding mode, that AP decrypts and decapsulates all 802.11 frames from a client and sends the 802.3 frames through the GRE tunnel to the controller, which then applies firewall policies to the user traffic. When the controller sends traffic to a client, the controller sends 802.3 traffic through the GRE tunnel to the AP, which then converts it to encrypted 802.11 and forwards to the client. This forwarding mode allows a network to utilize the encryption/decryption capacity of the AP while reducing the demand for  processing resources on the controller. APs in decrypt-tunnel forwarding mode also manage all 802.11 association requests and responses, and process all 802.11e and 802.11k action frames. APs using decrypt-tunnel mode do have some limitations that not present for APs in regular tunnel forwarding mode. You must enable the control plane security feature on the controller before you configure campus APs in decrypt-tunnel forward mode.

     

     

    To your problem with the two locations:

     

    First question: How the branch office is connected to your HQ?

     

    But what you are looking for looks like Split-Tunnel mode. Traffic which is for devices in the HQ, goes through the tunnel. Devices which are locally are bridged to the network. It is a configuration on the VAP/SSID.



  • 3.  RE: ARUBA ACCESS POINT TUNNELING TO CONTROLLER

    Posted Sep 18, 2014 10:12 PM
    Hi tnordmann,

    Thanks for your response. My setup has an HQ at different location via a MPLS connection from an ISP. The branch office, we will have new access points that needs to connect back to the HQ.

    And yes, it looks like I would need to setup split-tunnel. If I configure this for my branch office, I will configure an AP-group and all APs in that should will be configured as 'split-tunnel'? I haven't seen the GUI yet so I believe somewhere there I can configure what IP address subnets will be split-tunneled?


  • 4.  RE: ARUBA ACCESS POINT TUNNELING TO CONTROLLER

    Posted Sep 18, 2014 10:48 PM

     

    Also pertinent your decision are your crypto requirements and whether you are running HA+fast-failover (which currently doesn't support remote APs and has other limitations if your software isn't the latest.)