Transcript
Introduction 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 licencing 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 licences for each AP, this can also cause this ‘campus’ based solution uneconomical compared to other vendors.
Solution 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 licence, 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 6.3.1.2-4.0. 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)
Users bssids (tunnels)
650 3200XM 256 2048 256 2048
3400 4096 4096
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 – 6.3.1.2 IAP OS - 6.3.1.2-4.0.0.3
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.
•
Setup tunnel configuration so that a tunnel is created to each IAP.
•
Setup the authenticated guest role.
•
Setup captive portal profile and assign the default role created above.
•
Setup logon role and assign captive portal profile created above.
•
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.
•
Assign this aaa-profile for wired authentication.
1.4.2 IAP Configuration •
Configure ssid with type of corporate.
•
Configure ssid vlan to be that configured on controller, in this case vlan 12.
•
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.
•
Configure the IAP DHCP scope as centralised L2.
•
Add the VPN configuration as such.
•
The routing profile needs to point all traffic into the tunnel.
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 aaaprofile 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.
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.”
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.
