Occasional Contributor II

Need further in depth explanation of security of data whilst using tunnel forwarding mode , please

We want to segregate  our  user data from a third-party's data on our WLAN. We have a shared wireless controller .  If we have a separate SSID for the third-party on the same APs as our own SSIDs, I want to find out if they would theoretically be able to view our data on the LAN, after the 802.11 frame from their clients get onto the wire from our AP  connecting to the controller. ( they can potentially secure their own data by use of client vpns on their devices )

My first question is this :

The Aruba validated reference design guide describes tunnel forwarding mode in the following paragraph:

"In the tunnel and decrypt-tunnel forwarding modes, user traffic flows transparently across the network
in a GRE tunnel. In tunnel mode, device traffic is not converted to an Ethernet frame and placed in a
VLAN until it reaches the mobility controller. In decrypt-tunnel mode, the traffic is decrypted but is still
tunneled using GRE. The user VLAN does not exist at the AP that is providing access, so the VLAN
the user is actually placed into does not need to exist there either."

What does this guide mean by "the traffic is decrypted ".  What encryption method is being "decrypted" in this explanation - seems like a contradiction if they suggest that user traffic is transparent, but traffic is "decrypted" at the controller, rather than the AP when using the tunnel forwarding mode.


scenario A :Am i correct in saying that with a captive portal ssid , with https terminating on the controller ,and the APs operating in tunnel mode that user names and passwords would be encrypted all the way to the controller but that all subsequent user data would be sent in the clear and not encrypted on our LAN between the AP and the controller, merely tunnelled using GRE.


scenario B : Am I correct in saying that if we used WPA2 - Enterprise SSID for authentication with AES encryption , that user data would only be encrypted on the "air" and that data would be sent in the clear, encapsulated in a GRE tunnel to the controller from the AP.  


My final question is - does each separate Wi-Fi client's 802.11 frame in tunnel forwarding mode have its own GRE tunnel connection to the controller ?


many thanks



Guru Elite

Re: Need further in depth explanation of security of data whilst using tunnel forwarding mode , ple

If you use tunnel, which is default (not decrypt tunnel), the traffic will be wifi encrypted all the way back to the controller (WPA2-AES or whatever you are using).

If you use decrypt tunnel, the traffic is Wifi encrypted back to the access point, and then tunneled back to the controller decrypted but encapsulted.


The first method philosophically is more secure end to end.  With regards to captive portal, if the wifi traffic is not encrypted (non-ssl), it will be tunneled in that format back to the controller.  SSL or VPN traffic initiated by the client will be encrypted between the client and the terminating endpoint.


I hope that helps..


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.4 User Guide
InstantOS 8.3 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
Sign up for Security Alerts
Aruba Technical Webinars
Occasional Contributor II

Re: Need further in depth explanation of security of data whilst using tunnel forwarding mode , ple

thankyou ! that helps a lot .  

Super Contributor I

Re: Need further in depth explanation of security of data whilst using tunnel forwarding mode , ple


Note that "decrypt-tunnel" APs configured as "remote" should re-encrypt via IPsec, but you lose some features (like HA) if you configure that way.  Also note the control plane security setting.  It does not apply to client traffic.


As to your third question you can view the GRE/IPSEC tunnels with "show datapath tunnel."  Looks to me like one per radio per SSID, plus some control-plane IPsec per-AP.




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