Guest only solution using IAP-GRE tunnel with Controller - Mar 2014

Not applicable

The tutorial was by:Michael_Clarke



On many occasions there is a customer requirement to provide a simple guest-only wireless solution, and rightly or wrongly, it has been decided that this network should be completely segregated from the existing corporate network.  Whilst the Aruba Instant AP solution is the logical and economical solution to this, the internal captive portal on the IAP is unacceptable in look and feel for many customers, and does not provide the professional captive portal that they may want.


Another alternative is to use the Clearpass Guest solution to provide a rich and highly customisable captive portal page.  However, given that these solutions are on separate and new networks, the provision of an additional server to host the Clearpass VM in addition to the licensing costs makes this solution uneconomical.


The inbuilt controller captive portal, whilst not as feature rich as Clearpass, is professional enough for many guest-only requirements.  However, with the addition of AP and PEFNG licenses for each AP, this can also cause this ‘campus’ based solution uneconomical compared to other vendors.




The following was developed to specifically address the needs of a guest-only design, whilst still providing a professional looking captive portal page.  The method outlined below makes use of the Aruba Instant VPN tunnel feature to an Aruba controller.  This has the advantage of not requiring licences on the controller for each AP, but in fact only needs 1 x PEFNG license, making this solution very economical compared to a normal campus controller based solution and IAP with Clearpass, and makes it very competitive compared to other vendors.


This solution is fully reproducible and has been deployed in live environments.



Although the features used herein are fully supported, TAC may initially have some trouble getting their head around this ,as it is an uncommon use of such features.





This setup is primarily for a guest only solution.  It is possible to configure this for additional dot1x ssids, but this is not recommended.

All traffic also must flow through the controller.  Due to the nature of how captive portal works, it is not possible to break the traffic out locally after authentication.



Although redundancy is not considered here, it may be possible with the new ‘automatic GRE creation’ feature on AOS 6.4 and IAP  This is outlined in section 1.8



1.1       Hardware


The Aps are the Aruba Instant version and don’t terminate on the controller, so it is possible to have many more Aps in the solution than would otherwise be possible with Campus Aps.  You must however ensure that your solution is scaled properly, in particular taking note of the following parameters.


  • Max users
  • Max bssids (tunnels)










bssids (tunnels)





NOTE:  3000 series controllers are only able to have a total dhcp scope size of 512.  If you expect more than 512 users, use an external dhcp server or the firewall.


1.2       Software


The following versions were used for this demonstration.


  • AOS –
  • IAP OS -

Previous testing/deployment was also done with AOS 6.2.x.


NOTE:  The 600 series controllers are not mentioned in the AOS 6.3 User Guide, Table 215, IAP-VPN Scalability.  Although, this is a fully working solution, there is no guarantee that support for this model will not be removed.




1.3       Topology


The following diagram shows the logical and physical layout of the IAP-Guest-tunnel solution.



The subnet for the IAPs must NOT exist on the controller.







All user traffic is tunnelled to the controller and treated as wired users.


1.4       Configuration


The following outlines the steps necessary to complete the configuration.


1.4.1     Controller configuration


  • Setup ip addressing on controller with default gateway to point to the internet firewall.  User subnets should be isolated on the controller with ‘ip nat inside’.  Ensure the IAP subnet does NOT exist on the controller.
  • Setup DHCP scope for users on controller or external DHCP server as appropriate.
  • Install 1 x PEFNG licence on controller.
  • Create a server certificate for the controller.  The default cannot be used, because the IAP will also intercept the traffic and the internal IAP portal will be displayed after the controller portal.

 Pic 1 - server cert.jpg


  • Setup tunnel configuration so that a tunnel is created to each IAP.

Pic 2 - tunnel config.jpg


  • Setup the authenticated guest role.

Pic 3 - guest-auth role.jpg


  • Setup captive portal profile and assign the default role created above.

Pic 4 - captive portal.jpg


  • Setup logon role and assign captive portal profile created above.

Pic 5 - guest-logo role.jpg


  • Setup aaa-profile with initial role to be the logon role created above.  Create and assign user derivation rules, if it is a requirement to have certain devices bypass the captive portal.

Pic 6 - aaa profile.jpg


  • Assign this aaa-profile for wired authentication.

Pic 7 - wired auth.jpg



1.4.1     IAP Configuration


  • Configure ssid with type of corporate.

Pic 8 - IAP wlan.jpg


  • Configure ssid vlan to be that configured on controller, in this case vlan 12.

Pic 9 - IAP vlan.jpg


  • Configure ssid security and access to be open and no restrictions respectively.  Note, it is probably recommended to set the access rules, but this will also be handled by the controller.

Pic 10 - IAP security.jpg


Pic 11 - IAP Access.jpg


  • Configure the IAP DHCP scope as centralised L2.

Pic 12 - DHCP.jpg


  • Add the VPN configuration as such.

Pic 12 - tunnel controller.jpg


  • The routing profile needs to point all traffic into the tunnel.

Pic 13 - tunnel routing.jpg


This completes the configuration needed.


1.5       Testing


A client can now be connected to the IAP.  All traffic will get tunnelled to the controller, where a aaa-profile is applied and the user is placed in the guest-logon role.


Pic 14 - connected logon.jpg


The captive portal from the controller is then served.  Note the name on the certificate is different from the default ‘’.


Pic 15 - captive portal.jpg


After entering credentials, the user is place in the authenticated role.


Pic 16 - connected auth.jpg


1.6       Multiple Portals and Multi-tenanted environments


It is also possible to use this deployment for the provision of different captive portals for different sites, or multi-tenanted environments.


This can be achieved by applying a aaa-profile to the vlan itself.  Note, that an extra vlan added to the tunnel configuration will create an additional tunnel and counts towards the platform limit.


Note, there is a limit of 16 captive portal profiles on the controllers.


Pic 17 - vlan aaa.jpg


When a user connects they are placed into the role define in the aaa-profile above instead of the default wired-aaa profile.


Pic 18 - vlan auth.jpg


1.7        Troubleshooting


There may initially be issues with the tunnels not coming up.  This is generally resolved by rebooting the controller.  The user should instantly connect and get an ip address from the scope on the controller.


The encaps and decaps should also be seen in the output for ‘show datapath tunnel table’ on the controller.



1.8       Redundancy and Failover


Due to issues and inconsistent behaviour with GRE tunnels terminating on a controller VRRP, this has not been considered.  The IAP VPN setup should specify the tunnel host as being the vlan ip of the controller.  If a backup controller has been deployed then the appropriate tunnels should be setup on the backup controller as well.  In the event of a failure of the primary controller, the VPN configuration on the IAP will need to be updated manually.


1.8.1     Automatic GRE creation and AOS 6.4 and IAP 4.0


There is an interesting new feature on the both controller and IAP for automatic GRE tunnel creation.  The IAP User Guide states “When this feature is enabled on the IAP, no manual

configuration is required on Aruba Controller to create the GRE tunnel.”


Pic 19 - Aruba GRE.jpg


Initial testing with this feature did not work until the tunnel configuration was manually added to the controller.


Due to lack of a redundant controller, this was not tested.  However, in terms of redundancy this is most promising for having a failover configuration that does not require manual intervention by an administrator.


1.9       Dot1x ssids and IAP tunnels


It is also possible to have additional ssids such as a corporate dot1x tunnel through to the controller as well.


Typically, the IAP-VPN is used primarily to tunnel corporate traffic back to the Aruba controller.  In this case, since we are using the tunnel for guest access as well, the corporate traffic also needs to be routed into the tunnel.  Although, we may be able to break out corporate traffic locally, this is not considered.


The authentication needs to be handled by the IAP since the ssid needs to be WPA2-AES.  Following authentication, the user is placed into a role on the controller.  Since the controller is not handling the authentication, this role is simple the initial role within the aaa-profile.  This initial role needs to have the appropriate rights for the corp users, typically allowall.


Pic 20 - dot1x aaa.jpg


The user then has this initial role applied at the controller.


Pic 21 - dot1x auth.jpg


Version history
Revision #:
1 of 1
Last update:
‎04-14-2014 01:21 PM
Updated by:
Labels (2)
Search Airheads
Showing results for 
Search instead for 
Did you mean: