WiNG 5.X How-To Guide

(1)

WiNG 5.X How-To Guide

Captive Portals

(2)

MOTOROLA, MOTO, MOTOROLA SOLUTIONS and the Stylized M Logo are trademarks or registered trademarks of Motorola Trademark Holdings, LLC and are used under license. All other trademarks are the property of their respective owners.

(3)

Table of Contents ... 3

1. Overview ... 4

1.1 Captive Portal Policies ... 4

1.2 Wireless LANs ... 11

1.3 Switch Virtual Interfaces... 11

2. Configuration Examples ... 13

2.1 Centralized Deployments ... 13

2.2 Campus Deployments ... 23

2.3 Campus Deployments with Anchor Controllers ... 48

2.4 Trustpoints... 90

2.5 Captive Portal Page Customization ... 93

2.6 Externally Hosted Pages ... 108

3. Verification ... 114

3.1 Web Based Guest User Provisioning ... 114

3.2 Capture and Redirection ... 116

4. Appendix ... 119

(4)

Page 4

1. Overview

Captive portals provide secure authenticated or un-authenticated access to Wireless LANs using standard Web browsers. Captive portals function by capturing and redirecting a wireless user’s Web browser session to a landing page where the user must enter their credentials, accept terms and agreement or supply specific information before being permitted access to the Wireless network.

Captive portals can be utilized for multiple applications including guest / visitor access, hotspots or BYOD and are now common in most enterprise environments. Captive portals have become a very popular means for authenticating guest / visitor users as they provide administrators with the means for implementing authentication without deploying 802.1X or distributing pre-shared keys. More recently captive portals have also become a popular mechanism for on-boarding devices for secure guest access applications by re-directing corporate or guest / visitor user’s web-browser sessions to a service which can quickly provision the device to connect to a secure network.

1.1 Captive Portal Policies

In WiNG 5 the captive portal operation is controlled using captive portal policies which are assigned to Wireless LANs as well as the WiNG 5 devices that are performing the capture and redirection. Each captive portal policy defines:

1. The WiNG 5 devices that are to perform the capture and redirection. 2. The captive portal type (authenticated vs. non-authenticated). 3. The captive portal connection mode (HTTP or HTTPS).

4. The maximum number of simultaneous users per Access Point.

5. Login, welcome, failed and terms of condition web page source and customization.

When enabling captive portal services in a WiNG 5 network, there are three main choices that need to be made. The first choice is to decide which WiNG 5 devices are to perform the captive portal capture and redirection. The second choice is to determine if and how the captive portal authenticates the users, a terms and conditions page is presented. The third choice determines where in the network the captive portal pages are hosted. Captive portal pages can be hosted on the Wireless Controllers, Access Points , external HTTP server or an external appliance providing secure guest access provisioning.

The choice as to how authentication is performed, where the captive portal pages are hosted and which devices perform the capture and redirection will largely depend on the specific type of deployment. This guide aims to provide examples for various common captive portal deployment types for campus, and distributed deployments. The appendix provides additional information for customizing pages and provisioning the captive portal policy for secure guest access applications.

(5)

Page 5

1.1.1 Captive Portal Server Mode

The server mode parameter determines which WiNG 5 devices are performing the capture and re-direction. Capture and redirection can be performed on a Dependent / Independent Access Point or on a RFS X000 Wireless Controller. The WiNG 5 captive portal implementation is very flexible as it allows the captive portal services to reside anywhere within the WiNG 5 network. For example the capture and redirection can be performed directly by the Access Points at the edge of the network, centrally on the RFS X000 Wireless Controllers managing the Access Points or on dedicated RFS X000 Wireless Controllers deployed within an isolated network or DMZ.

Server Mode Description

Internal (Self) Capture and redirection is provided by the Access Point that is servicing the captive portal enabled Wireless LAN.

Centralized Capture and redirection is provided by a designated RFS X000 Wireless Controller on the network defined using an IPv4 address or hostname. The RFS X000 Wireless Controller can either be managing the Dependent / Independent Access Points or be a dedicated device deployed over the intermediate network.

Centralized Controller Capture and redirection is provided by a cluster of RFS X000 Wireless Controllers that are managing the Dependent / Independent Access Points using a virtual hostname.

Table 1.1.1 – Captive Portal Server Modes

1.1.1.1 Internal (Self)

The Internal (Self) server mode enables capture and redirection on the Dependent / Independent Access Points servicing the captive portal enabled Wireless LAN. The Internal (Self) captive portal server mode is typically enabled for deployments with:

1. Centrally managed remote Dependent / Independent Access Points using Level 2 MINT links: a. Wireless LAN traffic is locally bridged by the Access Points to an isolated VLAN that is

serviced by an Internet router at each remote site.

b. Wireless LAN traffic is locally routed by an AP6511 or AP71XX series Access Point directly connected to the public Internet.

2. Standalone or Virtual Controller based deployments using Independent Access Points. The Wireless LAN traffic is locally bridged by the Access Points to an isolated VLAN that is serviced by an Internet router at the site.

When enabled each remote Access Point servicing the captive portal enabled Wireless LAN will perform the captive portal capture and redirection internally. The Wireless LAN users are mapped to a locally bridged VLAN for which each Access Point has a Switched Virtual Interface (SVI) defined. The SVI can either have a static or dynamic (DHCP) IPv4 address assigned. The capture, redirection and presentation of the captive portal pages are performed using the SVI on each Access Point the wireless device is associated to.

(6)

Page 6

1.1.1.2 Centralized

The Centralized server mode enables capture and redirection on a specific RFS X000 Wireless Controller within the WiNG 5 system when traffic is being tunneled to the RFS X000 Wireless Controller managing the Dependent / Independent Access Points. The capture and redirection can either be provided by the RFS X000 Wireless Controller that is managing the Access Points or a dedicated RFS X000 Wireless Controller deployed in an isolated network or DMZ. The Centralized server mode is typically enabled for deployments with:

1. Branches with a single RFS X000 Wireless Controller managing Dependent / Independent Access Points.

2. Campuses with a single dedicated RFS X000 Wireless Controller deployed in the data center / DMZ that is providing the captive portal capture and redirection. The Dependent / Independent Access Points are managed by a separate pair of RFS X000 Wireless Controllers.

The Centralized server mode requires the IPv4 address or hostname of the RFS X000 Wireless Controller that is performing the capture and redirection to be defined in the captive portal policy. The capture and redirection can either be performed locally on the RFS X000 Wireless Controller that is managing the Access Points or a dedicated RFS X000 Wireless Controller deployed elsewhere in the network. The only requirement is that the RFS X000 Wireless Controller performing the capture and redirection must be reachable via the MINT protocol.

The Wireless LAN users are mapped to a tunneled VLAN for which the designated RFS X000 Wireless Controller that is performing the capture and redirection has a Switched Virtual Interface (SVI) defined. The SVI can either have a static or dynamic (DHCP) IPv4 address assigned. The capture, redirection and presentation of the captive portal pages are performed using the SVI on the designated RFS X000 Wireless Controller.

When a wireless device associates to a captive portal enabled Wireless LAN, the device will receive its IP address from the local Internet router or a DHCP server operating on the designated RFS X000 Wireless Controller. The tunneled VLAN is typically assigned to one of the designated RFS X000 Wireless

Controllers Gigabit Ethernet interfaces or is internally routed or NATed to the Internet. Upon launching a web-browser the devices HTTP session will be captured and re-directed by the SVI to the captive portal pages either hosted locally on the designated RFS X000 Wireless Controller or externally on a HTTP server.

(7)

Page 7

1.1.1.3 Centralized Controller

The Centralized Controller server mode enables capture and redirection on a cluster of RFS X000 Wireless Controllers managing Dependent / Independent Access Points when redundancy is required. The capture and redirection is provided by one of the RFS X000 Wireless Controllers in the cluster that is operating as the designated forwarder for the tunneled VLAN. The cluster can be configured as active / active or active / standby as required.

The Centralized Controller server mode requires a non-resolvable virtual hostname to be defined in the captive portal policy which is shared between the RFS X000 Wireless Controllers in the cluster. One of the RFS X000 Wireless Controllers will become the designative forwarder for the tunneled VLAN and during normal operation will provide capture and redirection. If the RFS X000 Wireless Controller that is elected as the designated forwarder fails or is taken down for maintenance, the second RFS X000 Wireless Controller will become the designated forwarder and provide the capture and redirection. The Wireless LAN users are mapped to a tunneled VLAN for which the RFS X000 Wireless Controllers in the cluster Switched Virtual Interfaces (SVI) defined. The SVIs can either have a static or dynamic (DHCP) IPv4 address assigned. The capture, redirection and presentation of the captive portal pages are performed using the SVI on the RFS X000 Wireless Controller that is the designated forwarder for the tunneled VLAN.

When a wireless device associates to a captive portal enabled Wireless LAN, the device wil l receive its IP address from an external DHCP server typically running on the Internet router or firewall. The tunneled VLAN is typically assigned to one of the designated RFS X000 Wireless Controllers Gigabit Ethernet interfaces to a local Internet router / firewall. Upon launching a web-browser the devices HTTP session will be captured and re-directed by the SVI to the captive portal pages either hosted locally on the RFS X000 Wireless Controllers or externally on a HTTP server.

In WiNG 5.3 and above the centralized controller mode can also be utilized to forward captive portal traffic to a cluster of RFS X000 Wireless Controllers deployed in an isolated network or DMZ. This special use case provides redundancy by leveraging VRRP to determine which RFS X000 Wireless Controller in the isolated network provides the captive portal capture and redirection. The RFS X000 Wireless

(8)

Page 8

1.1.2 Connection Modes

Each captive portal policy allows administrators to define the connection mode for the captive portal which can be HTTP (default) or HTTPS. The choice of which mode to use will depend on how the captive portal is being utilized:

1. The HTTP connection mode is typically utilized for captive portal deployments when no

credentials are exchanged over the captive portal enabled Wireless LAN. A typical application for HTTP is when open access is being provided to users who have to accept and terms and

conditions page before being permitted access to the network.

2. The HTTPS connection mode is typically utilized for captive portal deployments when credentials are exchanged over the captive portal enabled Wireless LAN. A typical application for HTTPS is guest / visitor access when users have to enter valid credentials before being permitted access to the network.

As the captive portal enabled Wireless LAN typically has no encryption, the HTTPS mode is useful for securing credential exchanges over the Wireless LAN. When enabled the Dependent / Independent Access Point or RFS X000 Wireless Controller will use a signed certificate installed in the default or user defined Trustpoint to secure the web-browser sessions. The user’s web-browsers will be captured and re-directed to a landing page using HTTPS port 443.

As the HTTPS connection mode utilizes PKI and trust to secure the web-browser sessions, a publically signed certificate is typically deployed on the Dependent / Independent Access Points or RFS X000 Wireless Controllers providing the capture and redirection. By default a self-signed certificate is installed on each WiNG 5 device which is assigned to the HTTPS service used for capture and redirection, however as the users web-browsers or operating systems will not have the corresponding CA root CA certificates the user’s web browsers will display a certificate error when the HTTPS connection is made. To overcome these certificate errors a public or privately signed certificate that the users web-browsers or operating system trusts must be installed on the WiNG 5 devices providing the captive portal capture and redirection. For enterprise deployments this can be a certificate signed by the enterprise private certificate authority where the root CA certificates are pre-installed on the managed devices. For public or guest / visitor applications the certificates are typically signed by a well-known public certificate authority that the web-browsers or operating systems already trust. Most current operating systems and web-browsers have root CA certificates for popular certificate authorities pre-installed.

(9)

Page 9

1.1.3 Access Types

Each captive portal policy supports an Access Type which determines how the user session is

authenticated. WiNG 5 supports a number of different Access Types to support various different captive portal deployments. For example the RADIUS type is typically enabled for guest / visitor access where user credentials are authenticated against an internal or external RADIUS server.

The Logging or No Authentication types are typically enabled for public Hotspot deployments when a terms and conditions page are displayed to the user for which they must agree before being permitted access to the network or secure guest access applications when the session is captured and redirected to an external server for provisioning.

The Custom type is designed for deployments with a customized RADIUS backend which can

authenticate users using user-supplied information such as a name, loyalty ID, email address or phone number. This type of deployment typically utilizes a customized RADIUS server which can authenticate sessions using information other than usernames / passwords.

Access Type Description

Custom Authenticates users against a customized back-end RADIUS server using custom user supplied information.

Logging Generates a logging record and permits access.

RADIUS Authenticates users against RADIUS using username and password.

No Authentication No authentication is performed.

Table 1.1.3 – Access Types

1.1.4 Web Page Source

Captive portal pages can be hosted internally on an Dependent / Independent Access Point, RFS X000 Wireless Controller or on an external HTTP server. The captive portal supports the following page types:

1. login.html – Is presented to user’s web-browser when the RADIUS type is enabled.

2. welcome.html – Is presented to the user’s web-browser upon successful RADIUS authentication or when the Logging or No Authentication types are enabled.

3. fail.html – Is presented to the user’s web-browser upon a failed RADIUS access attempt. 4. agreement.html – Is presented to the user’s web-browser when the user must agree to the

defined terms and conditions.

The captive portal pages can be system generated or fully customized. Each captive portal policy supports three different web-page source options that determine if a system generated or customized pages are used and if the pages are hosted locally on a WiNG 5 device performing the capture and redirection or externally on a HTTP server.

1.1.4.1 Internal

(10)

Page 10 The system generated pages are automatically installed into a subdirectory under flash:/hotspot/ on the WiNG 5 device. The subdirectory name will match the captive portal policy name assigned to the device. If multiple captive portal policies are assigned to a device, a sub-directory for each captive portal instance will be created on the device.

1.1.4.2 Advanced

The Advanced source option allows administrators to upload customized login, welcome, fail and

agreement pages into the WiNG 5 devices performing the capture and redirection. The Advanced source option must be selected when customized pages are being hosted on a WiNG 5 device. Using the Internal option and uploading customized pages will result in the customized pages over-written. Customized pages are typically based on the default system generated pages automatically created when the default Internal source option is selected. The system generated pages are downloaded from a WiNG 5 device to a TFTP or FTP server where they are modified using a standard HTML editor. The customized pages along with logos and other files are then uploaded onto one or more WiNG 5 devices. In WiNG 5.2.12 and WiNG 5.4 (and above), customized pages can be simultaneously uploaded to multiple Access Points using the captive-portal-page-upload command. Prior to these releases the captive portal pages had to be manually uploaded to each individual Access Point. This command allows customized pages and images had to be quickly distributed to multiple Dependent / Independent Access Points across multiple sites. The customized content is zipped into a TAR archive and then distributed.



Note: The advanced source must b e selected whenever customized login, welcome, fail and agreement pages are b eing hosted on a WiNG 5 device. Failure to select this option will result in the customized pages b eing replaced with system generated pages.

1.1.4.3 Externally Hosted

The Externally Hosted source option allows administrators to host customized pages on a centralized HTTP server or re-direct users re-direct users web-browsers to a specific URL or external portal. The Externally Hosted source option allows administrators to define specific URLs for the login, welcome, fail and agreement pages. The pages that are displayed will depend on the Access type defined in the policy. Externally hosted pages are useful for the following applications:

1. When customized pages are too large to be uploaded onto the WiNG 5 devices

2. When web-browsers need to be re-directed to specific URLs such as Intranet or public sites. 3. BYOD when external portals are utilized for on-boarding and authentication.

4. Paid access when external portals are utilized for billing and authentication.

When captive portal pages are hosted externally, the captive portal users must be permitted access to the IPv4 addresses or hostnames where the redirect URLs reside. By default a captive portal enabled

Wireless LAN will only permit DHCP, DNS and access to the internally hosted system generated or customizes pages and access to any other external site will be denied.

To permit access to externally hosted content, a DNS Whitelist policy must be defined and assigned to the Captive Portal policy. The DNS Whitelist policy includes the IP address(es) or hostname(s) of one or more HTTP servers hosting the customized content. Once assigned captive portal users sessio ns can be re-directed to the permitted external hosts. Access to non-permitted hosts will still be denied. This

capability is often referred to as a walled garden.

(11)

Page 11

1.2 Wireless LANs

Captive portal services are enabled on a per Wireless LAN basis. Each Wireless LAN is assigned to one or more Access Point radios typically using profiles. Each Wireless LAN defines the SSID name that is advertised to wireless devices, the users VLAN assignment, authentication and encryption options. Administrators can use captive portal authentication as a primary or secondary means of authenticating wireless users. Captive portal authentication is typically enabled on Wireless LANs with no encryption allowing guest / visitor users to connect to the network with minimum configuration. When used as a primary means of authentication, all wireless user’s web-browser sessions are captured and re-directed to the captive portal landing page. Depending on the captive portal configuration, the wireless users may be required to provide credentials or must agree to terms and conditions before being permitted access to the network.

Captive portals may also be used as a secondary means of authentication when EAP , EAP-MAC or MAC authentication is enabled on the Wireless LAN and no encryption is enabled. When enabled as secondary authentication the wireless user’s web-browser sessions will only be captured and re-directed to the captive portal landing page if the EAP or MAC authentication fails. If EAP or MAC authenti cation is successful, the wireless users are permitted access to the Wireless LAN bypassing the captive portal. The VLAN configuration for the captive portal enabled Wireless LAN will vary based on the WiNG 5 deployment:

 Centrally Managed Branch Deployments – The guest / visor VLAN will typically be locally bridged by the Access Points. The Wireless Controllers managing the remote Access Points are removed from the data-path and 802.1Q tagging provides the separation of the private and guest / visitor traffic.

 Campus Deployments – The guest / visor VLAN will typically be tunneled to the RFS X000 Wireless Controllers managing the Access Points at the site. The RFS X000 Wireless Controllers managing the Access Points provide the separation of the private and guest / visitor traffic.  Campus Deployments with Anchor Controllers – The guest / visitor VLAN will be tunneled to one

or more RFS X000 Wireless Controllers deployed in an isolated network or DMZ via the RFS X000 Wireless Controllers managing the Dependent / Independent Access Points. The Wireless Controllers in the DMZ provide the separation of the private and guest / visitor traffic.

1.3 Switch Virtual Interfaces

Switched Virtual Interfaces (SVIs) are a critical component to a captive portal solution as they allow the WiNG 5 devices to provide the capture and redirection of the wireless user’s browser traffic. Each WiNG 5 device that provides captive portal capture and redirection will require an SVI on the VLAN that the

Wireless LAN traffic is mapped to. The SVIs can have a static or dynamic IPv4 address assigned. The SVI configuration for the devices will vary based on the WiNG 5 deployment:

 Centrally Managed Distributed Deployments – Each remote Access Points will bridge the

Wireless LAN user traffic locally. Each remote Dependent / Independent Access Point will require an SVI and IPv4 address on the VLAN the captive portal traffic is bridged to. The SVIs are typically defined in the Access Point profile(s) and receive enabled for DHCP.

 Campus Deployments – The Access Points will tunnel the traffic to the RFS X000 Wireless Controllers managing the local Access Points. Each RFS X000 Wireless Controller managing Dependent / Independent Access Points will require an SVI and IPv4 address on the VLAN the captive portal traffic is tunneled to. The SVIs are typically defined on each RFS X000 Wireless Controllers as overrides with static IPv4 addresses assigned.

(12)

(13)

Page 13

2. Configuration Examples

The following section provides step-by-step configuration examples for common captive portal customer deployments including centrally managed Access Points, campus deployments and campus deployments with anchor controllers. Each deployment scenario will provide an overview of the solution as well as example Captive Portal policy, Wireless LAN and SVI configuration.

2.1 Centralized Deployments

In this example the remote Dependent / Independent Access Points are adopted and managed by a cluster of centralized NX9x00 Integrated Services Platforms using Level 2 MINT links . The remote

Dependent / Independent Access Points are adopted and managed over VLAN 21 and communicate with the centralized Controllers over a private WAN / MPLS service via a local branch router. As no traffic can be tunneled to the centralized NX9x00 Integrated Services Platforms, the captive portal Wireles s LAN traffic is locally bridged by the remote Dependent / Independent Access Points onto an isolated guest VLAN 25.

For capture and redirection each remote Dependent / Independent Access Points has an SVI on the guest / visitor VLAN which obtains an IPv4 address dynamically from a DHCP server operating on the Internet router / firewall connected to VLAN 25. The Internet router / firewall provides dynamic IPv4 addressing for the Dependent / Independent Access Points in addition to providing IP addressing and default gateway services for the guest / visitor users at the site.

(14)

Page 14

2.1.1 Captive Portal Policy

A captive portal policy will be defined that enables captive portal capture and redirection on the Access Points and requires guest / visitor users to agree to terms and conditions prior to being permitted access to the Internet. The captive portal policy will be assigned to the Guest Wireless LAN as well as the Access Point profile.



Note: For this example the default terms and conditions page hosted on the Access Points will b e displayed. The content of the default terms and conditions page can be modified to suit the customer’s requirements. Alternatively a customized terms and conditions page can b e defined and uploaded to the remote Access Points using the captive-portal-page-upload command after changing the Web Page Source in the captive portal policy from Internal to Advanced.

(15)

Page 15 2 Name the policy then set the Captive Portal Server Mode to Internal (Self). Set the Access

Type to No authentication required then check the option Terms and Conditions page. Click OK then Exit:

3 The Captive Portal policy has been defined:

4 Commit and Save the changes:

(16)

Page 16

2.1.2 Wireless LAN

A Wireless LAN with captive portal enforcement enabled will be defined that maps guest / visitor users to a locally bridged VLAN 25. The captive portal enabled Wireless LAN will be mapped to the Access Points 2.4 GHz radios using Access Point profiles.

(17)

Page 17 2 Name the Wireless LAN and SSID then set the Bridging Mode to Local. Define the VLAN id

where the captive portal user traffic is being mapped then click OK:

(18)

Page 18 4 The Captive Portal policy has been defined:

Running-Configuration Changes: ! wlan TMELABS-GUEST ssid TMELABS-GUEST vlan 25 bridging-mode local encryption-type none authentication-type none

use captive-portal TMELABS-GUESTS captive-portal-enforcement

(19)

Page 19

2.1.3 Access Point Profile

Each remote Access Points will provide the captive portal capture and redirection for the guest / visitor Wireless LAN. Using a profile each remote Access Point will be assigned the Captive Portal policy and will have the captive portal enabled Wireless LAN mapped to their 2.4 GHz radios. In addition each remote Access Point will have a Switched Virtual Interface (SVI) defined for VLAN 25 which will be enabled for DHCP. For isolation VLAN 25 will be also 802.1Q tagged out of the Access Points Ge1 interfaces.

(20)

Page 20 2 Select Interface  Ethernet Ports  ge1  Edit. Add the Guest / Visitor VLAN Id to the

Allowed VLAN list then click OK and Exit. Note in this example the Ge1 port has already been defined as a Trunk and the Native and Corporate VLANs assigned:

(21)

Page 21 4 Select Interface  Radios  radio1  Edit. Select the WLAN Mapping / Mesh Mapping tab

then under WLANs select the Guest / Visitor Wireless LAN created earlier and add it to the radio. Click OK then Exit:

(22)

Page 22 6 Commit and Save the changes:

Running-Configuration Changes:

!

profile ap6532 STORES-AP6532 ip name-server 192.168.10.6 ip domain-name tmelabs.local

!

! Configuration removed for brevity !

interface radio1

wlan TMELABS-GUEST bss 1 primary

interface radio2 interface ge1

switchport mode trunk

switchport trunk native vlan 21 no switchport trunk native tagged

switchport trunk allowed vlan 21-25

ip dhcp trust qos trust dscp qos trust 802.1p interface vlan21 ip address dhcp

ip dhcp client request options all

interface vlan25 ip address dhcp

interface pppoe1

use management-policy ACCESS-POINTS use firewall-policy default

use captive-portal server TMELABS-GUESTS

ntp server 192.168.10.6 service pm sys-restart router ospf

(23)

Page 23

2.2 Campus Deployments

In this example the Dependent / Independent Access Points are adopted and managed by a cluster of RFS 6000 Wireless Controllers at the site using Level 1 MINT links. The Dependent / Independent Access Points are adopted and managed over VLAN 21 and communicate with the Controllers over a high-speed local area network. As this deployment utilizes Level 1 MINT links, the captive portal Wireless LAN traffic (VLAN 25) will be tunneled from the Dependent / Independent Access Points to the cluster of RFS 6000 Wireless Controllers at the site.

For capture and redirection each RFS 6000 Wireless Controller in the cluster will include an SVI with a static IPv4 address on VLAN 25. For redundancy both RFS 6000 Wireless Controllers will be able to provide capture and redirection using a virtual hostname which is shared between the Controllers in the cluster. The local Internet router / firewall provides dynamic IPv4 addressing and is the default gateway for the guest / visitor users at the site. The guest / visitor traffic will be bridged to VLAN 25 where the Internet / firewall resides using 802.1Q tagging enabled on each RFS 6000 Wireless Controllers uplink port.

(24)

Page 24

2.2.1 AAA Policy

Each guest / visitor user will be authenticated by the integrated AAA server on the cluster of RFS 6000 Wireless Controllers. An AAA policy needs to be defined to tell the WiNG 5 system where to forward the authentication requests when a guest / visitor user provides their credentials on the captive portal login page. The AAA policy will be assigned to the captive portal enabled Wireless LAN.

1 Using the Web-UI select Configuration  Wireless  AAA Policy  Add:

(25)

Page 25 3 Set the Server Type to onboard-self then click OK, Exit then Exit again:

4 A AAA policy has now been defined:

!

aaa-policy INTERNAL-AAA

authentication server 1 onboard controller

(26)

Page 26

2.2.2 Management Policy

To allow front desk personnel to create guest / visitor user accounts on the cluster of RFS 6000 Wireless Controllers, a special administrative user account must be defined in the Management policy assigned to the Controllers. This will allow front desk personnel to login to the web-based management interface on RFS 6000 Wireless Controllers to create guest / visitor user IDs, passwords and define time limits as guest / visitors check into the site.



Note: Front desk personnel are only provided limited access to the RFS 6000 Wireless Controllers and will not b e ab le to view or change configuration parameters.

(27)

Page 27 2 Click Add. Enter a User Name and Password then set the Administrator Role to Web User.

Click OK then Exit:

3 A guest administrative user account has now been defined:

(28)

Page 28 Running-Configuration Changes: ! management-policy WIRELESS-CONTROLLERS no http server https server ssh

user admin password 0 motorola role superuser access all

user guestadmin password 0 hellomoto role web-user-admin

(29)

Page 29

2.2.3 RADIUS Server Policy, Groups and User Pools

The cluster of RFS 6000 Wireless Controllers will authenticate the guest / visitor users internally using an integrated RADIUS server running on both Controllers. Guest / visitor user accounts created by front desk personnel will be automatically assigned to an internal user pool and group which is synchronized on both Controllers. Upon expiration the guest / visitor user accounts are automatically purged from the system. To authenticate guest / visitor users a RADIUS Server policy, Group and User Pool need to be defined. The Group determines authorization and permissions for the guest / visitor users such as permitted Wireless LANs, time of day, day of week and bandwidth restrictions. The RADIUS Server policy is assigned to the RFS 6000 Wireless Controllers using their profile. All guest / visitor users will be created in the User Pool and will be assigned to the guest Group.

(30)

Page 30 2 Name the policy then check the option Guest User Group. In the WLAN SSID field enter the

exact SSID name for the captive portal enabled Wireless LAN and add it to the list. Optionally enable Time of Day, Day of Week and Rate Limits then click OK and Exit:

(31)

Page 31 4 Name the User Pool then click Continue and Exit:

(32)

Page 32 6 Name the policy then assign the User Pool name created above. Click OK then Exit:

!

radius-group TMELABS-GUEST guest

policy ssid TMELABS-GUEST policy day mo

policy day tu policy day we policy day th policy day fr

policy time start 08:00 end 18:00

!

radius-user-pool-policy TMELABS-GUEST

!

radius-server-policy INTERNAL-AAA

use radius-user-pool-policy TMELABS-GUEST

(33)

Page 33

2.2.4 Captive Portal Policy

A captive portal policy will be defined that enables captive portal capture and redirection on the cluster of RFS 6000 Wireless Controllers and requires guest / visitor users to provide valid credentials prior to being permitted access to the Internet. The guest / visitor users will be authenticated via the Integrated AAA services running on the RFS 6000 Wireless Controllers over a secure HTTPS connection. The captive portal policy will be assigned to the Guest Wireless LAN as well as the Controller profile.



Not: For this example the default login, welcome, failed and agreement pages hosted on the RFS 6000 Wireless Controllers will b e displayed. The content of the default pages can b e modified to suit the customer’s requirements then uploaded onto both Controllers.

(34)

Page 34 2 Name the policy then set the Captive Portal Server Mode to Centralized Controller. Set the

Access Type to RADIUS Authentication and assign the AAA Policy created earlier. Set the Hosting VLAN Interface to the Guest / Visitor VLAN ID then in the Captive Portal Server field enter a non-resolvable hostname. Finally set the Connection Mode to HTTPS then click OK and Exit:

!

captive-portal TMELABS-GUEST connection-mode https

server host virtual.tmelabs.local

server mode centralized-controller hosting-vlan-interface 25 use aaa-policy INTERNAL-AAA

(35)

Page 35

2.2.5 Wireless LAN

A Wireless LAN with captive portal enforcement enabled will be defined that maps guest / visitor users to VLAN 25 which is tunneled to the cluster of RFS 6000 Wireless Controllers at the site. The captive portal enabled Wireless LAN will be mapped to the Access Points 2.4 GHz radios using Access Point profiles.

(36)

Page 36 2 Name the Wireless LAN and SSID then set the Bridging Mode to Tunnel. Define the VLAN id

(37)

Running-Configuration Changes: ! wlan TMELABS-GUEST ssid TMELABS-GUEST vlan 25 bridging-mode tunnel encryption-type none authentication-type none

use captive-portal TMELABS-GUEST captive-portal-enforcement

(38)

Page 38

2.2.6 Access Point Profile

The Access Points will tunnel the guest / visitor user traffic to the cluster of RFS 6000 Wireless Controllers where the capture and redirection and authentication will be performed. Using a profile the captive portal enabled Wireless LAN will be assigned to each Access Points 2.4 GHz radio.

1 Using the Web-UI select Configuration  Profiles  <ap-profile-name>  Edit:

(39)

!

interface radio1

ip dhcp client request options all interface pppoe1

(40)

Page 40

2.2.7 Wireless Controller Overrides

To provide captive portal capture and redirection each RFS 6000 Wireless Controller will have a Switched Virtual Interface (SVI) defined for VLAN 25 with a static IPv4 address assigned. The SVI and static IPv4 addressing will be defined on each individual RFS 6000 Wireless Controller device as an override.

(41)

Page 41 2 Select Profile Overrides  Interface  Virtual Interfaces  Add. Define the Guest / Visitor

(42)

(43)

VLAN Id in the VLAN ID field then check the option None. In the Primary Address field enter a static Address and Subnet Mask length. In this example 192.168.25.23/24 has been defined. Click OK then Exit:

(44)

Page 44 Running-Configuration Changes:

!

rfs6000 00-23-68-64-43-5A use profile CAMPUS-RFS6000 use rf-domain CAMPUS hostname rfs6000-1

!

! Configuration removed for brevity ! ip default-gateway 192.168.20.1 interface me1 ip address 192.168.0.1/24 interface vlan20 ip address 192.168.20.22/24 interface vlan25

description Captive\ Portal ip address 192.168.25.22/24

cluster name CAMPUS

cluster member ip 192.168.20.23 cluster master-priority 254 logging on

logging console warnings logging buffered warnings !

!

rfs6000 5C-0E-8B-17-E8-F6 use profile CAMPUS-RFS6000 use rf-domain CAMPUS hostname rfs6000-2

!

! Configuration removed for brevity ! ip default-gateway 192.168.20.1 interface me1 ip address 192.168.0.1/24 interface vlan20 ip address 192.168.20.23/24 interface vlan25

description Captive\ Portal ip address 192.168.25.23/24

cluster name CAMPUS

(45)

Page 45

2.2.8 Wireless Controller Profile

The cluster of RFS 6000 Wireless Controllers will provide the captive portal capture and redirection using a virtual hostname which is shared within the cluster. Using a profile each Controller will be assigned the Captive Portal and RADIUS Server policies and will tag the guest / visitor traffic out their up1 ports on VLAN 25.

(46)

Page 46 2 Select Interface  Ethernet Ports  up1  Edit. Add the Guest / Visitor VLAN Id to the

Allowed VLAN list then click OK and Exit. Note in this example the up1 port has already been defined as a Trunk and the Native and Corporate VLANs assigned:

(47)

Running-Configuration Changes: ! profile rfs6000 CAMPUS-RFS6000 ip name-server 192.168.10.6 ip domain-name tmelabs.local !

use radius-server-policy INTERNAL-AAA

crypto ikev1 policy ikev1-default

isakmp-proposal default encryption aes-256 group 2 hash sha crypto ikev2 policy ikev2-default

isakmp-proposal default encryption aes-256 group 2 hash sha crypto ipsec transform-set default esp-aes-256 esp-sha-hmac crypto ikev1 remote-vpn

crypto ikev2 remote-vpn crypto auto-ipsec-secure interface me1

interface up1 description UPLINK switchport mode trunk

switchport trunk native vlan 20 switchport trunk native tagged

switchport trunk allowed vlan 20,23,25

ip dhcp trust qos trust dscp qos trust 802.1p

!

use firewall-policy default

use auto-provisioning-policy CAMPUS

use captive-portal server TMELABS-GUEST

ntp server 192.168.10.6 no auto-learn-staging-config service pm sys-restart router ospf

(48)

Page 48

2.3 Campus Deployments with Anchor Controllers

In this example the Dependent / Independent Access Points are adopted and managed by a cluster of RFS 6000 Wireless Controllers in the private network using Level 1 MINT links. The Dependent / Independent Access Points are adopted and managed over VLAN 21 and communicate with the RFS 6000 Wireless Controllers over a high-speed local area network. The guest / visitor Wireless LAN traffic (VLAN 25) is tunneled from the Dependent / Independent Access Points to the cluster of RFS 6000 Wireless Controllers managing the Access Points.

The guest / visitor traffic is then tunneled over static MINT links to a cluster of RFS 4000 Wireless Controllers in the isolated network that perform the captive portal capture redirection using a virtual hostname. User authentication is provided by the RFS 6000 Wireless Controllers managing the Dependent / Independent Access Points. This model allows the guest / visitor traffic to be completely isolated from the internal private network.

Figure 2.3 – Campus Deployment with Anchor Controllers

(49)

Page 49 This deployment leverages Virtual Router Redundancy Protocol (VRRP) to provide redundancy for the captive portal capture and redirection on the cluster of RFS 4000 Wireless Controllers. VRRP is enabled on VLAN 25 on the RFS 4000 Wireless Controllers which use a virtual IP address and hostname to provide the captive portal capture and redirection. Each RFS 4000 Wireless Controller has a unique SVI defined on VLAN 25 and share a VRRP virtual IP address (one is master, one is backup). During normal operation the RFS 4000 operating as the VRRP master provides the capture and redirection services. To forward the captive portal capture and redirection traffic to the cluster of RFS 4000 Wireless, an SVI is defined on an isolated VLAN 125 on both RFS 6000 Wireless Controllers in the private network with their IP addresses set to the VRRP virtual IP address assigned to the RFS 4000 Wireless Controllers. The isolated VLAN is not extended between the RFS 6000 Wireless Controllers. These SVIs allow the RFS 6000 Wireless Controllers to redirect the captive portal traffic over MINT to the VRRP virtual IP interface in the isolated network.

2.3.1 RFS 6000 Wireless Controllers

– Private Network

2.3.1.1 AAA Policy

Each guest / visitor user will be authenticated by the integrated AAA server on the cluster of RFS 6000 Wireless Controllers. An AAA policy needs to be defined to tell the WiNG 5 system where to forward the authentication requests when a guest / visitor user provides their credentials on the captive portal login page. The AAA policy will be assigned to the captive portal enabled Wireless LAN.

(50)

Page 50 2 Name the policy then click Continue:

3 Set the Server Type to onboard-self then click OK, Exit then Exit again:

4 A AAA policy has now been defined:

(51)

!

aaa-policy INTERNAL-AAA

authentication server 1 onboard controller

!

2.3.1.2 Management Policy

To allow front desk personnel to create guest / visitor user accounts on the cluster of RFS 6000 Wireless Controllers, a special administrative user account must be defined in the Management policy assigned to the Controllers. This will allow front desk personnel to login to the web-based management interface on RFS 6000 Wireless Controllers to create guest / visitor user IDs, passwords and define time limits as guest / visitors check into the site.



Note: Front desk personnel are only provided limited access to the RFS 6000 Wireless Controllers and will not b e ab le to view or change configuration parameters.

(52)

Page 52 2 Click Add. Enter a User Name and Password then set the Administrator Role to Web User.

Click OK then Exit:

3 A guest administrative user account has now been defined:

(53)

Page 53 Running-Configuration Changes: ! management-policy WIRELESS-CONTROLLERS no http server https server ssh

user admin password 0 motorola role superuser access all

user guestadmin password 0 hellomoto role web-user-admin

(54)

Page 54

2.3.1.3 RADIUS Server Policy, Groups and User Pools

The cluster of RFS 6000 Wireless Controllers will authenticate the guest / visitor users internally using an integrated RADIUS server running on both RFS 6000 Wireless Controllers. Guest / visitor user accounts created by front desk personnel will be automatically assigned to an internal user pool and group which is synchronized on both Controllers. Upon expiration the guest / visitor user accounts are automatically purged from the system.

To authenticate guest / visitor users a RADIUS Server policy, Group and User Pool need to be defined. The Group determines authorization and permissions for the guest / visitor users such as permitted Wireless LANs, time of day, day of week and bandwidth restrictions. The RADIUS Server policy is assigned to the RFS 6000 Wireless Controllers using their profile. All guest / visitor users will be created in the User Pool and will be assigned to the guest Group.

(55)

Page 55 2 Name the policy then check the option Guest User Group. In the WLAN SSID field enter the

exact SSID name for the captive portal enabled Wireless LAN and add it to the list. Optionally enable Time of Day, Day of Week and Rate Limits then click OK and Exit:

(56)

Page 56 4 Name the User Pool then click Continue and Exit:

(57)

Page 57 6 Name the policy then assign the User Pool name created above. Click OK then Exit:

!

radius-group TMELABS-GUEST guest

policy ssid TMELABS-GUEST policy day mo

policy day tu policy day we policy day th policy day fr

policy time start 08:00 end 18:00

!

radius-user-pool-policy TMELABS-GUEST

!

radius-server-policy INTERNAL-AAA

use radius-user-pool-policy TMELABS-GUEST

(58)

Page 58

2.3.1.4 Captive Portal Policy

A captive portal policy will be defined that enables captive portal capture and redirection on the cluster of RFS 6000 Wireless Controllers and requires guest / visitor users to provide valid credentials prior to being permitted access to the Internet. The guest / visitor users will be authenticated via the Integrated AAA services running on the RFS 6000 Wireless Controllers over a secure HTTPS connection. The captive portal policy will be assigned to the Guest Wireless LAN as well as the Controller profile.



Note: For this example the authentication for the captive portal users will b e controlled b y the captive portal policy assigned to the RFS 6000 Wireless Controllers. The captive portal page locations and formatting will b e controlled using the captive portal policy assigned to the RFS 4000 Wireless Controllers in the isolated network which perform the actual capture and redirection.

(59)

Access Type to RADIUS Authentication and assign the AAA Policy created earlier. Set the Hosting VLAN Interface to an isolated internal VLAN ID (VLAN 125 in this example) then in the Captive Portal Server field enter a non-resolvable hostname. Finally set the Connection Mode to HTTPS then click OK and Exit:

!

server mode centralized-controller hosting-vlan-interface 125 use aaa-policy INTERNAL-AAA

(60)

Page 60

2.3.1.5 Wireless LAN

A Wireless LAN with captive portal enforcement enabled will be defined that maps guest / visitor users to VLAN 25 which is tunneled to the cluster of RFS 6000 Wireless Controllers at the site. The captive portal enabled Wireless LAN will be mapped to the Access Points 2.4 GHz radios using Access Point profiles.

(61)

Page 61 2 Name the Wireless LAN and SSID then set the Bridging Mode to Tunnel. Define the VLAN id

(62)

Running-Configuration Changes: ! wlan TMELABS-GUEST ssid TMELABS-GUEST vlan 25 bridging-mode tunnel encryption-type none authentication-type none

use captive-portal TMELABS-GUEST captive-portal-enforcement

(63)

Page 63

2.3.1.6 Access Point Profile

The Access Points will tunnel the guest / visitor user traffic to the cluster of RFS 6000 Wireless Controllers where the capture and redirection and authentication will be performed. Using a profile the captive portal enabled Wireless LAN will be assigned to each Access Points 2.4 GHz radio.

1 Using the Web-UI select Configuration  Profiles  <ap-profile-name>  Edit:

(64)

!

interface radio1

ip dhcp client request options all interface pppoe1

(65)

Page 65

2.3.1.7 Wireless Controller Overrides

For captive portal capture and redirection to function on the RFS 4000 Wireless Controllers in the isolated network, each RFS 6000 Wireless Controller will have a Switched Virtual Interface (SVI) defined on an isolated VLAN 125 with their IP addresses set to the VRRP virtual IP defined on the RFS 4000 Wireless Controllers. The SVI and static IP addresses are defined on each individual RFS 6000 Wireless Controller device as an override.

(66)

Page 66 2 Select Profile Overrides  Interface  Virtual Interfaces  Add. Define the isolated VLAN Id in

(67)

(68)

Page 68 4 Select Profile Overrides  Interface  Virtual Interfaces  Add. Define an isolated VLAN Id in

the VLAN ID field then check the option None. In the Primary Address field define the VRRP virtual IP Address and Subnet Mask length used on the RFS 4000 Wireless Controllers in the DMZ . Click OK then Exit:

(69)

!

rfs6000 00-23-68-64-43-5A use profile CAMPUS-RFS6000 use rf-domain CAMPUS hostname rfs6000-1

!

! Configuration removed for brevity ! ip default-gateway 192.168.20.1 interface me1 ip address 192.168.0.1/24 interface vlan20 ip address 192.168.20.22/24 interface vlan125 description VRRP\ Helper ip address 192.168.25.10/24

cluster name CAMPUS

logging console warnings logging buffered warnings !

!

rfs6000 5C-0E-8B-17-E8-F6 use profile CAMPUS-RFS6000 use rf-domain CAMPUS hostname rfs6000-2

!

! Configuration removed for brevity ! ip default-gateway 192.168.20.1 interface me1 ip address 192.168.0.1/24 interface vlan20 ip address 192.168.20.23/24 interface vlan125 description VRRP\ Helper ip address 192.168.25.10/24

cluster name CAMPUS

(70)

Page 70

2.3.1.8 Wireless Controller Profile

The cluster of RFS 6000 Wireless Controllers tunnel will forward captive portal capture and redirection traffic to a virtual hostname which resides on the RFS 4000 Wireless Controllers in the isolated network or DMZ. Using a profile each RFS 6000 Wireless Controller will be assigned the Captive Portal and RADIUS Server policies. In addition both RFS 6000 Wireless Controllers will be configured to tunnel the guest / visitor traffic for VLAN 25 over statically defined IP based MINT links which terminate on the RFS 4000 Wireless Controllers management interfaces in the isolated network.



Note: If a firewall resides b etween the private and isolated networks, the firewall must b e configured to permit UDP port 24576 (MINT traffic).

(71)

Page 71 2 Select Network  Bridge VLAN  Add. Add the Guest / Visitor VLAN Id to the VLAN field then

set the Bridging Mode to Tunnel. Click OK then Exit.

(72)

Page 72 4 Select Add. In the IP Address field enter the Management IP address of the Standby RFS 4000

Wireless Controller in the isolated network or DMZ. In this example the Standby RFS 4000 Wireless Controller is assigned the management IP address 192.168.30.21/24. Click OK then Exit:

(73)

Running-Configuration Changes: ! profile rfs6000 CAMPUS-RFS6000 mint link ip 192.168.30.20 mint link ip 192.168.30.21 bridge vlan 25 bridging-mode tunnel ip igmp snooping

ip igmp snooping querier

!

use radius-server-policy INTERNAL-AAA

!

interface me1 interface up1 description UPLINK switchport mode trunk

switchport trunk native vlan 20 switchport trunk native tagged switchport trunk allowed vlan 20,23 ip dhcp trust

qos trust dscp qos trust 802.1p

!

use firewall-policy default

use auto-provisioning-policy CAMPUS

use captive-portal server TMELABS-GUEST

ntp server 192.168.10.6 no auto-learn-staging-config service pm sys-restart router ospf

(74)

Page 74

2.3.2 RFS 4000 Wireless Controllers

– DMZ

2.3.2.1 Captive Portal Policy

A captive portal policy will be defined on the RFS 4000 Wireless Controllers that closely mirrors the captive portal policy defined on the RFS 6000 Wireless Controllers. The Captive Portal Policy on the RFS 6000 Wireless Controllers defines the remote virtual hostname used for capture and redirection as well as how the users are authenticated. The RFS 6000 Wireless Controllers simply forward the capture and redirected traffic to the RFS 4000 Wireless Controllers.

The captive portal policy on the RFS 4000 Wireless Controllers defines the same non-resolvable virtual hostname but also the captive portal page location and customization. In this example the default internal captive portal pages will be utilized which will be hosted on the RFS 4000 Wireless Controllers. The captive portal policy will be assigned to the Controller profile.



Note: For this example the default login, welcome, failed and agreement pages hosted on the RFS 4000 Wireless Controllers in the isolated network will b e displayed. The content of the default pages can b e modified to suit the customer’s requirements then uploaded onto both RFS 4000 Wireless Controllers.

(75)

Access Type to RADIUS Authentication but do not assign an AAA Policy. Set the Hosting VLAN Interface to guest / visitor VLAN Id (VLAN 25 in this example) then in the Captive Portal Server field enter the non-resolvable hostname define on the RFS 6000 Wireless Controllers. Finally set the Connection Mode to HTTPS then click OK and Exit:

!

server mode centralized-controller hosting-vlan-interface 25

(76)

Page 76

2.3.2.2 Auto-Provisioning Policy

As the RFS 4000 Wireless Controllers in the isolated network are dedicated to providing captive portal capture and redirection, we do not want Access Points to adopt to these devices. To disable adoption an Auto-Provisioning policy will be defined and assigned to the Controller profile with no rules which will deny all adoptions by default.

(77)

Page 77 2 Name the policy DENY-ADOPTION then click Continue and Exit:

!

auto-provisioning-policy DENY-ADOPTION

(78)

Page 78

2.3.2.3 Wireless Controller Overrides

To provide captive portal capture and redirection each RFS 4000 Wireless Controller will have a Switched Virtual Interface (SVI) defined for VLAN 25 with a static IPv4 address assigned. Additionally VRRP will be enabled on VLAN 25 with a virtual IP assigned to provide high-availability in the event that one of the RFS 4000 Controllers fails. The SVI and static IPv4 addressing will be defined on each individual RFS 4000 Wireless Controller device as an override.

(79)

(80)

Page 80 3 Select Profile Overrides  VRRP  Add. Define the Guest / Visitor VLAN Id in the Virtual

(81)

(82)

(83)

Page 83 6 Select Profile Overrides  VRRP  Add. Define the Guest / Visitor VLAN Id in the Virtual

Router ID and Interface fields. In the Virtual IP Addresses field enter the VRRP virtual IP address shared between RFS 4000 Controllers for capture and redirection. In this example 192.168.25.10 has been defined. Set the Advertisement Interval value to 1 then click OK then Exit: