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 18.104.22.168-4.0. This is outlined in section 1.8
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.
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.
The following versions were used for this demonstration.
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.
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.
The following outlines the steps necessary to complete the configuration.
1.4.1 Controller configuration
1.4.1 IAP Configuration
This completes the configuration needed.
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.
The captive portal from the controller is then served. Note the name on the certificate is different from the default ‘securelogin.arubanetworks.com’.
After entering credentials, the user is place in the authenticated role.
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.
When a user connects they are placed into the role define in the aaa-profile above instead of the default wired-aaa profile.
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.”
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.
The user then has this initial role applied at the controller.
I can't seem to add the whole solution in the post. Tried to add the remaining parts, but keeps failing.....probably too many pics.
See attached guide
Let see if im understanding
You will use one controller 650
All instant APS
1 PEFNG firewall license( You do not need 1 AP license or any other license)
This will use Controller Captive portal FOR Aruba Instant AP cluster users...
With this you will be able also to have many cluster and for EACH cluster you need one PEFNG license but at the end the idea is having the Controller just for the Captive portal Looks...
So the captive portal cost in this case is the Wireless Controller 650 + 1 PEFNG License
One PEFNG licesnse for each cluster.
Can you confirm me if i understood them correctly?
1 controller and 1 x PEFNG license.
You can have as many clusters as you like. For the controller it is just GRE tunnels with wired users.
But is what i said in there?
the captive portal value will be what it cost a 650 controller for all the IAP devices????
@NightShade1 wrote:But is what i said in there?the captive portal value will be what it cost a 650 controller for all the IAP devices???? CheersCarlos
Yeah, that is what is costs, for all the IAPs, to have the portal from the controller.
If the customer is not bothered by having a simple, text based captive portal, then you just have Instants only.
If they want a decent portal for a guest-only solution, this could be a deal winner.
Awsome tutorial Clark
I hope you win at least one IAP 225!
This is the most useful tutorial for me at least of the one i have read ;P
I get custumers in which they are not happy with the captive portal of the instant... but they are wiht the controller, but the controller based cost more... this hybrid make it cost effective!
Clark another question
So the max user limit is referred to Guet users... not actually devices that has nothing to do with the guest network..
I got 2 SSIDS
On corporate i got 500 devices connected
But in Guest i got 40 devices connecting
In this scanario a 650 would work as ill be using the limit of 40 users on guest network and the limit is 256.
The other scenario
This is referred to the what??
For each cluster ill have just one GRE tunnel running?? im kind of confused here can you clarify this one???
it is total users, there is no distinguishing between corp and guest users.
I prefer per-ap tunnel, which greates one tunnel per ap. The reason is that the tunnel is created to the IAP ip, not the VC ip. If your master IAP fails, then everything breaks.
This model with per-ap tunnel, it will create 1 tunnel per vlan per ap.
In a normal campus deployment, 1 gre tunnel is created per bssid,which is why I said you should pay attention to this limit, if you have lots of aps with several vlans.
Remember all the traffic goes to the controller so you might want to pay attention as well to the stated limit for firewall throughput and sessions, if you intend to get close to the platform limit for number of users.
Sorry for my ignorance but in this case no matter how many ssid's are on the IAP, all the traffic gets tunneled to the controller, not just the "guest" traffic correct?
This would be a perfect solution if it was just guest traffic only but the route you created seems to indicate an all or nothing solution.
I came up with this main for guest-only. It is possible to have corp as well and you could break out the corp traffic locally, but crucially the internet traffic must go into the tunnel.
It is sort of easier to understand if everything goes into the tunnel.
Feel free to give it some kudos.
@NightShade1 wrote:Helloi was wonderibg if its possible this scenariohaving one controller in a central sitehaving many instant cluster in different sitesusing the internet of each remote site after authenticating?i van easily achive this in a normal controller based enviroment with split tunnel.. But it is possible doing this somehow with this????imean tjat the internet being used on the remote site its tje one on the remote site, and not the one of the central site.cheersCarlos
Unfortunatley this is not possible due to the way that captive portal works. Even if you have the dns traffic tunneled through the central controller, it still won't work. What happens with captive portal is this,
So basically, because of step 3. this traffic must go through the controller in order to send the http-redirect, and hence get the captive portal.
I did try exactly what you suggested, but it doesn't work. All internet traffic must be tunnelled through the controller.
Hope that helps.
this is working fine when we use the per-ap tunnel. But if we want to configure the GRE-tunnel from the VC-address, this isn't working anymore: All clients connected on the masterIAP (who has the VC-address at the moment) can work without any problem; but if there is a client on an other IAP than the master, the connection through the tunnel fails. Traffic is not redirected to the tunnel between VC-IP and controller-IP
What I understand is that all traffic should be redirected to the masterIAP which will send the traffic through the tunnel, is this correct?
Am I missing something? Is there a special configuration needed for this to work?
EDIT: Discard my question, the customer didn't tagged the Guest vlan on the uplink ports...
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.