1. technology and computing
2. hardware
3. computer networking
4. router

WiNG 5.X How-To Guide
Captive Portals
Part No. TME-12-2012-01 Rev. A
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.
© 2012 Motorola Solutions, Inc. All Rights Reserved.
Table of Contents
Table of Contents ............................................................................................................................ 3
1.
2.
3.
4.
Overview .................................................................................................................................. 4
1.1
Captive Portal Policies ..................................................................................................... 4
1.2
Wireless LANs ................................................................................................................ 11
1.3
Switch Virtual Interfaces................................................................................................. 11
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
Verification ........................................................................................................................... 114
3.1
Web Based Guest User Provisioning .......................................................................... 114
3.2
Capture and Redirection .............................................................................................. 116
Appendix .............................................................................................................................. 119
4.1
Configuration Examples ............................................................................................... 119
WiNG 5.X How-To Guide – Captive Portals
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.
The following section provides a detailed overview of the key parameters that can be defined for each
captive portal policy.
Page 4
WiNG 5.X How-To Guide – Captive Portals
1.1.1
Captive Portal Server Mode
The server mode parameter determines which WiNG 5 devices are performing the capture and redirection. 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.
2.
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.
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.
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 from a DHCP server integrated directly into the Access Point.
The VLAN is either 802.1Q tagged out the Access Points Gigabit Ethernet interface or is internally routed
and NATed to the Internet. Upon launching a web-browser the devices HTTP session will be captured
and re-directed by the SVI on the Access Point to captive portal pages either hosted locally within the
Access Point or externally on a HTTP server.
Page 5
WiNG 5.X How-To Guide – Captive Portals
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.

Note: No redundancy is provided with the centralized option as only a single device can b e defined. If
redundancy is required the centralized controller option must b e utilized.
Page 6
WiNG 5.X How-To Guide – Captive Portals
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
Controllers managing the Dependent / Independent Access Points tunnels the traffic to the RFS X000
Wireless Controllers in the isolated network which perform the capture and redirection. Authentication (if
required) is provided by the RFS X000 Wireless Controllers managing the Access Points.
Page 7
WiNG 5.X How-To Guide – Captive Portals
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 redirected 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.
HTTP mode is useful for open access captive portal applications that require terms and condition pages
to be presented to users before providing access to the network. As no credentials are exchanged over
the captive portal enabled Wireless LAN no security is required. When enabled the users web-browser
sessions will be captured and re-directed to the terms and conditions landing page using HTTP port 880.
The user must agree to the terms and conditions page before being permitted access to the network. No
public or privately signed certificates are required.
Page 8
WiNG 5.X How-To Guide – Captive Portals
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
The Internal (default) source option will create system generated login, welcome, fail and agreement
pages on the WiNG 5 devices performing the capture and redirection. The system generated pages
support minimum customization which is performed within the captive portal policy. The system generated
pages are created as soon as the captive portal policy is assigned to the WiNG 5 device using a profile or
override.
Page 9
WiNG 5.X How-To Guide – Captive Portals
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 sessions 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.

Note: A DNS Whitelist Policy must b e defined when customized content is hosted on an external host. The
DNS Whitelist policy permits access to specific hosts using IPv4 addresses or hostnames.
Page 10
WiNG 5.X How-To Guide – Captive Portals
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.

Campus Deployments with Anchor Controllers – The Access Points tunnel the traffic to one or
more RFS X000 Wireless Controllers in an isolated network or DMZ via the RFS X000 Wireless
Page 11
WiNG 5.X How-To Guide – Captive Portals
Controllers managing the Dependent / Independent Access Points. Each RFS X000 Wireless
Controllers in the isolated network or DMZ will require an SVI and IPv4 address on the VLAN the
captive portal traffic is tunneled to. Additionally a VRRP virtual IP address will be required for
redundant deployments. The SVIs and VRRP virtual IP addresses are typically defined on each
RFS X000 Wireless Controllers as overrides with static IPv4 addresses assigned.
Page 12
WiNG 5.X How-To Guide – Captive Portals
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.
Figure 2.1 – Centralized Deployment
Page 13
WiNG 5.X How-To Guide – Captive Portals
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.

1
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 b e 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.
Using the Web-UI select Configuration  Services  Captive Portals  Add:
Page 14
WiNG 5.X How-To Guide – Captive Portals
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:
Running-Configuration Changes:
!
captive-portal TMELABS-GUESTS
access-type no-auth
terms-agreement
!
Page 15
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Wireless  Wireless LANs  Add:
Page 16
WiNG 5.X How-To Guide – Captive Portals
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:
3
Select Security then set the Authentication to PSK/None. Check the option Captive Portal
Enable then assign the Captive Portal Policy created in the previous step. Click OK then Exit:
Page 17
WiNG 5.X How-To Guide – Captive Portals
4
The Captive Portal policy has been defined:
5
Commit and Save the changes:
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
!
Page 18
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Profiles  <ap-profile-name>  Edit:
Page 19
WiNG 5.X How-To Guide – Captive Portals
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:
3
Select Interface  Virtual Interfaces  Add. Add the Guest / Visitor VLAN Id to the VLAN ID
field then check the option Use DHCP to Obtain IP. Click OK then Exit:
Page 20
WiNG 5.X How-To Guide – Captive Portals
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:
5
Select Services then assign the Captive Portal policy to the profile. Click OK, Exit then Exit
again:
Page 21
WiNG 5.X How-To Guide – Captive Portals
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
!
Page 22
WiNG 5.X How-To Guide – Captive Portals
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.
Figure 2.2 – Campus Deployment
Page 23
WiNG 5.X How-To Guide – Captive Portals
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:
2
Name the policy then click Continue:
Page 24
WiNG 5.X How-To Guide – Captive Portals
3
Set the Server Type to onboard-self then click OK, Exit then Exit again:
4
A AAA policy has now been defined:
5
Commit and Save the changes:
Running-Configuration Changes:
!
aaa-policy INTERNAL-AAA
authentication server 1 onboard controller
!
Page 25
WiNG 5.X How-To Guide – Captive Portals
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.

1
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.
Using the Web-UI select Configuration  Management  <policy>  Edit:
Page 26
WiNG 5.X How-To Guide – Captive Portals
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:
4
Commit and Save the changes:
Page 27
WiNG 5.X How-To Guide – Captive Portals
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
snmp-server user snmptrap v3 encrypted des auth md5 0 motorola
snmp-server user snmpoperator v3 encrypted des auth md5 0 operator
snmp-server user snmpmanager v3 encrypted des auth md5 0 motorola
!
Page 28
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Services  RADIUS  Groups  Add:
Page 29
WiNG 5.X How-To Guide – Captive Portals
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:
3
Select User Pools then click Add:
Page 30
WiNG 5.X How-To Guide – Captive Portals
4
Name the User Pool then click Continue and Exit:
5
Select Server Policy then click Add:
Page 31
WiNG 5.X How-To Guide – Captive Portals
6
Name the policy then assign the User Pool name created above. Click OK then Exit:
7
Commit and Save the changes:
Running-Configuration Changes:
!
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
!
Page 32
WiNG 5.X How-To Guide – Captive Portals
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.

1
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 b oth Controllers.
Using the Web-UI select Configuration  Services  Captive Portals  Add:
Page 33
WiNG 5.X How-To Guide – Captive Portals
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:
3
The Captive Portal policy has been defined:
4
Commit and Save the changes:
Running-Configuration Changes:
!
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
!
Page 34
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Wireless  Wireless LANs  Add:
Page 35
WiNG 5.X How-To Guide – Captive Portals
2
Name the Wireless LAN and SSID then set the Bridging Mode to Tunnel. Define the VLAN id
where the captive portal user traffic is being mapped then click OK:
3
Select Security then set the Authentication to PSK/None. Check the option Captive Portal
Enable then assign the Captive Portal Policy created in the previous step. Click OK then Exit:
Page 36
WiNG 5.X How-To Guide – Captive Portals
4
The Captive Portal policy has been defined:
5
Commit and Save the changes:
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
!
Page 37
WiNG 5.X How-To Guide – Captive Portals
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:
2
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:
Page 38
WiNG 5.X How-To Guide – Captive Portals
3
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-22
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface vlan21
ip address dhcp
ip dhcp client request options all
interface pppoe1
use management-policy ACCESS-POINTS
use firewall-policy default
ntp server 192.168.10.6
service pm sys-restart
router ospf
!
Page 39
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Devices  <controller-1>  Edit:
Page 40
WiNG 5.X How-To Guide – Captive Portals
2
Select Profile Overrides  Interface  Virtual Interfaces  Add. Define the Guest / Visitor
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.22/24 has been defined.
Click OK then Exit:
Page 41
WiNG 5.X How-To Guide – Captive Portals
3
Select Configuration  Devices  <controller-2>  Edit:
Page 42
WiNG 5.X How-To Guide – Captive Portals
4
Select Profile Overrides  Interface  Virtual Interfaces  Add. Define the Guest / Visitor
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:
5
Commit and Save the changes:
Page 43
WiNG 5.X How-To Guide – Captive Portals
Running-Configuration Changes:
!
!
rfs6000 00-23-68-64-43-5A
rfs6000 5C-0E-8B-17-E8-F6
use profile CAMPUS-RFS6000
use profile CAMPUS-RFS6000
use rf-domain CAMPUS
use rf-domain CAMPUS
hostname rfs6000-1
hostname rfs6000-2
!
!
! Configuration removed for brevity
! Configuration removed for brevity
!
!
ip default-gateway 192.168.20.1
ip default-gateway 192.168.20.1
interface me1
interface me1
ip address 192.168.0.1/24
ip address 192.168.0.1/24
interface vlan20
interface vlan20
ip address 192.168.20.22/24
ip address 192.168.20.23/24
interface vlan25
!
interface vlan25
description Captive\ Portal
description Captive\ Portal
ip address 192.168.25.22/24
ip address 192.168.25.23/24
cluster name CAMPUS
cluster name CAMPUS
cluster member ip 192.168.20.23
cluster member ip 192.168.20.22
cluster master-priority 254
cluster master-priority 128
logging on
logging on
logging console warnings
logging console warnings
logging buffered warnings
logging buffered warnings
!
Page 44
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Profiles  <controller-profile-name>  Edit:
Page 45
WiNG 5.X How-To Guide – Captive Portals
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:
3
Select Services then assign the Captive Portal and RADIUS Server policies. Click OK then
Exit:
Page 46
WiNG 5.X How-To Guide – Captive Portals
4
Commit and Save the changes:
Running-Configuration Changes:
!
profile rfs6000 CAMPUS-RFS6000
ip name-server 192.168.10.6
ip domain-name tmelabs.local
!
! Configuration removed for brevity
!
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
!
! Configuration removed for brevity
!
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
!
Page 47
WiNG 5.X How-To Guide – Captive Portals
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

Note: This configuration example can also b e followed for deployments using a single RFS X000 Wireless
Controller in the isolated network or DMZ.
Page 48
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Wireless  AAA Policy  Add:
Page 49
WiNG 5.X How-To Guide – Captive Portals
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:
5
Commit and Save the changes:
Page 50
WiNG 5.X How-To Guide – Captive Portals
Running-Configuration Changes:
!
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.

1
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.
Using the Web-UI select Configuration  Management  <policy>  Edit:
Page 51
WiNG 5.X How-To Guide – Captive Portals
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:
4
Commit and Save the changes:
Page 52
WiNG 5.X How-To Guide – Captive Portals
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
snmp-server user snmptrap v3 encrypted des auth md5 0 motorola
snmp-server user snmpoperator v3 encrypted des auth md5 0 operator
snmp-server user snmpmanager v3 encrypted des auth md5 0 motorola
!
Page 53
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Services  RADIUS  Groups  Add:
Page 54
WiNG 5.X How-To Guide – Captive Portals
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:
3
Select User Pools then click Add:
Page 55
WiNG 5.X How-To Guide – Captive Portals
4
Name the User Pool then click Continue and Exit:
5
Select Server Policy then click Add:
Page 56
WiNG 5.X How-To Guide – Captive Portals
6
Name the policy then assign the User Pool name created above. Click OK then Exit:
7
Commit and Save the changes:
Running-Configuration Changes:
!
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
!
Page 57
WiNG 5.X How-To Guide – Captive Portals
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.

1
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.
Using the Web-UI select Configuration  Services  Captive Portals  Add:
Page 58
WiNG 5.X How-To Guide – Captive Portals
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 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:
3
The Captive Portal policy has been defined:
4
Commit and Save the changes:
Running-Configuration Changes:
!
captive-portal TMELABS-GUEST
connection-mode https
server host virtual.tmelabs.local
server mode centralized-controller hosting-vlan-interface 125
use aaa-policy INTERNAL-AAA
!
Page 59
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Wireless  Wireless LANs  Add:
Page 60
WiNG 5.X How-To Guide – Captive Portals
2
Name the Wireless LAN and SSID then set the Bridging Mode to Tunnel. Define the VLAN id
where the captive portal user traffic is being mapped then click OK:
3
Select Security then set the Authentication to PSK/None. Check the option Captive Portal
Enable then assign the Captive Portal Policy created in the previous step. Click OK then Exit:
Page 61
WiNG 5.X How-To Guide – Captive Portals
4
The Captive Portal policy has been defined:
5
Commit and Save the changes:
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
!
Page 62
WiNG 5.X How-To Guide – Captive Portals
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:
2
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:
Page 63
WiNG 5.X How-To Guide – Captive Portals
3
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-22
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface vlan21
ip address dhcp
ip dhcp client request options all
interface pppoe1
use management-policy ACCESS-POINTS
use firewall-policy default
ntp server 192.168.10.6
service pm sys-restart
router ospf
!
Page 64
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Devices  <controller-1>  Edit:
Page 65
WiNG 5.X How-To Guide – Captive Portals
2
Select Profile Overrides  Interface  Virtual Interfaces  Add. Define the 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:
Page 66
WiNG 5.X How-To Guide – Captive Portals
3
Select Configuration  Devices  <controller-2>  Edit:
Page 67
WiNG 5.X How-To Guide – Captive Portals
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:
5
Commit and Save the changes:
Page 68
WiNG 5.X How-To Guide – Captive Portals
Running-Configuration Changes:
!
!
rfs6000 00-23-68-64-43-5A
rfs6000 5C-0E-8B-17-E8-F6
use profile CAMPUS-RFS6000
use profile CAMPUS-RFS6000
use rf-domain CAMPUS
use rf-domain CAMPUS
hostname rfs6000-1
hostname rfs6000-2
!
!
! Configuration removed for brevity
! Configuration removed for brevity
!
!
ip default-gateway 192.168.20.1
ip default-gateway 192.168.20.1
interface me1
interface me1
ip address 192.168.0.1/24
ip address 192.168.0.1/24
interface vlan20
interface vlan20
ip address 192.168.20.22/24
ip address 192.168.20.23/24
interface vlan125
!
interface vlan125
description VRRP\ Helper
description VRRP\ Helper
ip address 192.168.25.10/24
ip address 192.168.25.10/24
cluster name CAMPUS
cluster name CAMPUS
cluster member ip 192.168.20.23
cluster member ip 192.168.20.22
cluster master-priority 254
cluster master-priority 128
logging on
logging on
logging console warnings
logging console warnings
logging buffered warnings
logging buffered warnings
!
Page 69
WiNG 5.X How-To Guide – Captive Portals
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.

1
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).
Using the Web-UI select Configuration  Profiles  <controller-profile-name>  Edit:
Page 70
WiNG 5.X How-To Guide – Captive Portals
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.
3
Select Advanced  MINT Protocol  IP  Add. In the IP Address field enter the Management
IP address of the Active RFS 4000 Wireless Controller in the isolated network or DMZ. In this
example the Primary RFS 4000 Wireless Controller is assigned the management IP address
192.168.30.20/24. Click OK then Exit:
Page 71
WiNG 5.X How-To Guide – Captive Portals
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:
5
Select Services then assign the Captive Portal and RADIUS Server policies. Click OK then
Exit:
Page 72
WiNG 5.X How-To Guide – Captive Portals
6
Commit and Save the changes:
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
!
! Configuration removed for brevity
!
use radius-server-policy INTERNAL-AAA
!
! Configuration removed for brevity
!
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
!
! Configuration removed for brevity
!
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
!
Page 73
WiNG 5.X How-To Guide – Captive Portals
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.

1
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 b oth RFS 4000 Wireless Controllers.
Using the Web-UI select Configuration  Services  Captive Portals  Add:
Page 74
WiNG 5.X How-To Guide – Captive Portals
2
Name the policy then set the Captive Portal Server Mode to Centralized Controller. Set the
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:
3
The Captive Portal policy has been defined:
4
Commit and Save the changes:
Running-Configuration Changes:
!
captive-portal TMELABS-GUEST
connection-mode https
server host virtual.tmelabs.local
server mode centralized-controller hosting-vlan-interface 25
!
Page 75
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Devices  Auto-Provisioning Policy  Add:
Page 76
WiNG 5.X How-To Guide – Captive Portals
2
Name the policy DENY-ADOPTION then click Continue and Exit:
3
Commit and Save the changes:
Running-Configuration Changes:
!
auto-provisioning-policy DENY-ADOPTION
!
Page 77
WiNG 5.X How-To Guide – Captive Portals
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.
1
Using the Web-UI select Configuration  Devices  <controller-1>  Edit:
Page 78
WiNG 5.X How-To Guide – Captive Portals
2
Select Profile Overrides  Interface  Virtual Interfaces  Add. Define the Guest / Visitor
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.20/24 has been defined.
Click OK then Exit:
Page 79
WiNG 5.X How-To Guide – Captive Portals
3
Select Profile Overrides  VRRP  Add. Define the Guest / Visitor VLAN Id in the Virtual
Router ID and Interface fields then set the Priority to 200. This device will become the VRRP
master and own the virtual IP during normal operation. 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:
Page 80
WiNG 5.X How-To Guide – Captive Portals
4
Select Configuration  Devices  <controller-2>  Edit:
Page 81
WiNG 5.X How-To Guide – Captive Portals
5
Select Profile Overrides  Interface  Virtual Interfaces  Add. Define the Guest / Visitor
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.21/24 has been defined.
Click OK then Exit:
Page 82
WiNG 5.X How-To Guide – Captive Portals
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:
7
Commit and Save the changes:
Page 83
WiNG 5.X How-To Guide – Captive Portals
Running-Configuration Changes:
!
!
rfs4000 00-23-68-22-9D-E4
rfs4000 5C-0E-8B-1A-FE-A0
use profile DMZ-RFS4000
use profile DMZ-RFS4000
use rf-domain DMZ
use rf-domain DMZ
hostname rfs4000-dmz-1
hostname rfs4000-dmz-2
!
!
! Configuration removed for brevity
! Configuration removed for brevity
!
ip default-gateway 192.168.30.1
!
ip default-gateway 192.168.30.1
interface vlan25
interface vlan25
ip address 192.168.25.20/24
ip address 192.168.25.21/24
interface vlan30
interface vlan30
ip address 192.168.30.20/24
ip address 192.168.30.21/24
cluster name DMZ
cluster name DMZ
cluster member ip 192.168.30.21
cluster mode standby
cluster master-priority 254
cluster member ip 192.168.30.20
logging on
cluster master-priority 128
logging console warnings
logging on
logging buffered warnings
logging console warnings
vrrp 25 priority 200
logging buffered warnings
vrrp 25 timers advertise 1
vrrp 25 priority 100
vrrp 25 ip 192.168.25.10
vrrp 25 timers advertise 1
vrrp 25 preempt
vrrp 25 ip 192.168.25.10
vrrp 25 interface vlan25
vrrp 25 preempt
no vrrp 25 sync-group
vrrp 25 interface vlan25
no vrrp 25 monitor critical-resource
no vrrp 25 sync-group
no vrrp 25 delta-priority
no vrrp 25 monitor critical-resource
!
no vrrp 25 delta-priority
!
Page 84
WiNG 5.X How-To Guide – Captive Portals
2.3.2.4 Wireless Controller Profile
The cluster of RFS 4000 Wireless Controllers tunnel will provide the captive portal capture and redirection
using a virtual hostname which resides on the RFS 4000 Wireless Controllers in the isolated network.
Using a profile each RFS 4000 Wireless Controller will be assigned the Captive Portal policy. In addition
both RFS 4000 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 6000 Wireless Controllers
management interfaces in the private network. Finally an Auto-Provisioning policy will be assigned and
MLCP disabled so that the RFS 4000 Wireless Controllers will not be able to adopt any Independent /
Dependent Access Points.

1
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).
Using the Web-UI select Configuration  Profiles  <controller-profile-name>  Edit:
Page 85
WiNG 5.X How-To Guide – Captive Portals
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.
3
Select Advanced  MINT Protocol  IP  Add. In the IP Address field enter the Management
IP address of the Active RFS 6000 Wireless Controller in the private network. In this example
the Primary RFS 6000 Wireless Controller is assigned the management IP address
192.168.20.22/24. Click OK then Exit:
Page 86
WiNG 5.X How-To Guide – Captive Portals
4
Select Advanced  MINT Protocol  IP  Add. In the IP Address field enter the Management
IP address of the Standby RFS 6000 Wireless Controller in the private network. In this example
the Primary RFS 6000 Wireless Controller is assigned the management IP address
192.168.20.23/24. Click OK then Exit:
5
Select Services then assign the Captive Portal policy. Click OK:
Page 87
WiNG 5.X How-To Guide – Captive Portals
6
Select Adoption then assign the Auto-Provisioning policy. Click OK:
7
Select Advanced  MINT Protocol then un-check the options MLCP IP and MLCP VLAN. This
will disable the RFS 4000 Wireless Controllers ability to respond to MLCP requests from
Access Points during adoption. Click OK then Exit:
Page 88
WiNG 5.X How-To Guide – Captive Portals
8
Commit and Save the changes:
Running-Configuration Changes:
!
profile rfs4000 DMZ-RFS4000
mint link ip 192.168.30.20
mint link ip 192.168.30.21
no mint mlcp vlan
no mint mlcp ip
bridge vlan 25
bridging-mode tunnel
ip igmp snooping
ip igmp snooping querier
!
! Configuration removed for brevity
!
interface me1
interface up1
description UPLINK
switchport mode trunk
switchport trunk native vlan 30
switchport trunk native tagged
switchport trunk allowed vlan 25,30
ip dhcp trust
qos trust dscp
qos trust 802.1p
!
! Configuration removed for brevity
!
use firewall-policy default
use auto-provisioning-policy DENY-ADOPTION
use captive-portal server TMELABS-GUEST
ntp server 192.168.10.6
no auto-learn-staging-config
service pm sys-restart
router ospf
!
Page 89
WiNG 5.X How-To Guide – Captive Portals
2.4 Trustpoints
The HTTPS captive portal connection mode requires Public Key Infrastructure (PKI) to provide privacy
and mutual authentication. In WiNG 5 certificates are installed into Trustpoints which can be used by the
HTTPS service for securing credential exchanges over a captive portal Wireless LAN and device
management.
By default each WiNG 5 device includes a self-signed certificate which is that installed into a default
Trustpoint. As the certificate is self-signed there is no ability for the wireless user’s web-browser or
operating system to verify the server certificate used by the HTTPS service. While the default Trustpoint
can be used for demonstrations or lab trials, it is recommended that a signed certificate be installed into a
new Trustpoint that is assigned to the HTTPS service when the HTTPS captive portal connection mode is
enabled. This will greatly enhance the end user experience and reduce support calls.
A signed certificate can be issued from a public or private certificate authority. For guest / visitor access
applications it is recommended that the certificates be signed by a certificate authority that the guest /
visitors web-browsers or operating systems already trusts. For enterprise applications the certificates can
be signed by a private enterprise certificate authority which may be already trusted by the managed
devices.
This section provides a step-by-step example of how to generate an RSA keypair and certificate signing
request for WiNG 5 devices which can be signed by public or private certificate authority. The signed
certificate and CA root certificate can then be installed into a Trustpoint on the WiNG 5 devices and
assigned to the HTTPS service. In this example a common RSA keypair and signed certificate will be
installed on two RFS 4000 Wireless Controllers and assigned to the HTTPS service using device
overrides. The common name field can be set to an IPv4 address, hostname or wildcard depending on
which WiNG 5 device it is being installed on. In this example the common name will use the hostname
virtual.tmelabs.local matching the virtual hostname assigned using the captive portal policy.

1
Note: The common name (CN) field in the signed certificate identifies the device to the web -b rowser. The
CN field can contain a hostname, IP address or wildcard depending on th e application. For remote Access
Point deployments using HTTPS, each remote Access Point will require a static IP address and certificate
with the CN field set to each individual Access Points static IP address.
Generate a 2048-bit RSA keypair and name it. The RSA keypair will be installed on multiple
RFS 4000 Wireless Controllers in a cluster:
rfs4000-dmz-1# crypto key generate rsa rfs4000-dmz 2048
RSA Keypair successfully generated
2
View the installed RSA keypairs:
rfs4000-dmz-1# show crypto key rsa
-------------------------------------------------------------------------------#
KEY NAME
KEY LENGTH
-------------------------------------------------------------------------------1
rfs4000-dmz
2048
2
default_rsa_key
1024
--------------------------------------------------------------------------------
Page 90
WiNG 5.X How-To Guide – Captive Portals
3
Generate a Certificate Signing Request (CSR) using the RSA keypair created above. The CSR
in this example uses a wildcard in the common name field so that it can be installed on
multiple RFS 4000 Wireless Controllers. The CSR will also be exported to a TFT P server where
it can then be signed by a private or public CA:
rfs4000-dmz-1# crypto pki export request use-rsa-key rfs4000-dmz subject-name virtual.t
melabs.local us tn "Johnson City" "Motorola Solutions" "Field Enablement" email
[email protected] tftp://192.168.10.10/rfs4000-dmz.csr
Successfully generated and exported certificate request
4
Import the Root CA Certificate issued from the public or private CA that signed the CSR
generated above. In the below example the Root CA Certificate with the filename tmelabsca.cer is imported from the TFTP server 192.168.10.10 and is installed into the Trustpoint
named TMELABS-CA:
rfs4000-dmz-1# crypto pki authenticate TMELABS-CA tftp://192.168.10.10/PKI/tmelabs-ca.cer
Successfully imported CA certificate
rfs4000-dmz-2# crypto pki authenticate TMELABS-CA tftp://192.168.10.10/PKI/tmelabs-ca.cer
Successfully imported CA certificate
5
Import the signed Certificate issued from the public or private CA. In the below example the
signed Certificate with the filename rfs4000-dmz.cer is imported from the TFTP server
192.168.10.10 and is installed into the Trustpoint named TMELABS-CA:
rfs4000-dmz-1# crypto pki import certificate TMELABS-CA tftp://192.168.10.10/PKI/rfs4000-dmz.cer
Signed certificate for Trustpoint TMELABS-CA sucessfully imported
rfs4000-dmz-2# crypto pki import certificate TMELABS-CA tftp://192.168.10.10/PKI/rfs4000-dmz.cer
Signed certificate for Trustpoint TMELABS-CA sucessfully imported
6
View the Trustpoints:
rfs4000-dmz-1# show crypto pki trustpoints TMELABS-CA
Trustpoint Name: TMELABS-CA
------------------------------------------------------------------------------CRL present: no
Server Certificate details:
Key used: rfs4000-dmz
Serial Number: 03e7
Subject Name:
C=US, ST=Tennessee, L=Johnson City, O=Motorola Solutions, OU=Field Enablement, CN= virtual.tmelabs.local,
[email protected]
Issuer Name:
C=US, ST=TN, L=Johnson City, O=Motorola Solutions, OU=Field Enablement, CN=TMELABS -CA, [email protected]
Valid From : Tue Nov 13 18:24:41 2012 UTC
Valid Until: Fri Nov 11 18:24:41 2022 UTC
Page 91
WiNG 5.X How-To Guide – Captive Portals
CA Certificate details:
Serial Number: b856023e82ea96b8
Subject Name:
C=US, ST=TN, L=Johnson City, O=Motorola Solutions, OU=Field Enablement, CN=TMELABS -CA, [email protected]
Issuer Name:
C=US, ST=TN, L=Johnson City, O=Motorola Solutions, OU=Field Enablement, CN=TMELABS -CA, [email protected]
Valid From : Mon Jan 23 01:56:35 2012 UTC
Valid Until: Tue Jan 22 01:56:35 2013 UTC
rfs4000-dmz-2# show crypto pki trustpoints TMELABS-CA
Trustpoint Name: TMELABS-CA
------------------------------------------------------------------------------CRL present: no
Server Certificate details:
Key used: rfs4000-dmz
Serial Number: 03e7
Subject Name:
C=US, ST=Tennessee, L=Johnson City, O=Motorola Solutions, OU=Field Enablement, CN=virtual.tmelabs.local,
[email protected]
Issuer Name:
C=US, ST=TN, L=Johnson City, O=Motorola Solutions, OU=Field Enablement, CN=TMELABS-CA, [email protected]
Valid From : Tue Nov 13 18:24:41 2012 UTC
Valid Until: Fri Nov 11 18:24:41 2022 UTC
CA Certificate details:
Serial Number: b856023e82ea96b8
Subject Name:
C=US, ST=TN, L=Johnson City, O=Motorola Solutions, OU=Field Enablement, CN=TMELABS-CA, [email protected]
Issuer Name:
C=US, ST=TN, L=Johnson City, O=Motorola Solutions, OU=Field Enablement, CN=TMELABS-CA, [email protected]
Valid From : Mon Jan 23 01:56:35 2012 UTC
Valid Until: Tue Jan 22 01:56:35 2013 UTC
7
Assign the Trustpoint to the devices as overrides:
rfs4000-dmz-1# self
rfs4000-dmz-1(config-device-00-23-68-22-9D-E4)# trustpoint https TMELABS-CA
rfs4000-dmz-1(config-device-00-23-68-22-9D-E4)# end
rfs4000-dmz-1# commit write
rfs4000-dmz-2# self
rfs4000-dmz-2(config-device-5C-0E-8B-1A-FE-A0)# trustpoint https TMELABS-CA
rfs4000-dmz-2(config-device-5C-0E-8B-1A-FE-A0)# end
rfs4000-dmz-2# commit write
Page 92
WiNG 5.X How-To Guide – Captive Portals
2.5 Captive Portal Page Customization
Each of the captive portal pages can be fully customized to suit the specific customer’s requirements and
the customization can be performed by anyone who is familiar with HTML editing. Customized login,
welcome, fail and agreement pages are typically based on the default pages included with the WiNG 5
system which are downloaded, modified then uploaded back to the WiNG 5 devices or deployed on an
external HTTP server.
The following highlights the procedure used for customizing captive portal pages when the pages are
hosted on a WiNG 5 device.
1.
Create a captive portal with the web page source set to Internal. This will generate the required
default pages on the WiNG 5 device which can then be downloaded and modified. Ensure the
correct connection mode (HTTP or HTTPS) is defined in the captive portal policy as this impacts
the HTML code in the pages.
2.
Using TFTP or FTP download the login.html, welcome.html, fail.html and agreement.html
pages from the WiNG 5 device. The pages will be located in the flash:/hotsport/captive-portal policy-name> folder on the device.
3.
Customize each page following the guidelines in this section so that mandatory elements are
maintained.
4.
If customized pages are hosted on a WiNG 5 device, modify the captive portal policy so that the
web page source is set to Advanced. This will ensure that the customized pages are not
overwritten with default pages.
5.
Upload the customized pages and images onto the WiNG 5 device.
2.5.1
Captive Portal Policy
When customized captive portal pages are hosted on a WiNG 5 device the web page source in the
captive portal policy must be changed from Internal to Advanced. This ensures that the customized
pages will not be overwritten by the default pages if the captive portal policy is modified at a later date.
Page 93
WiNG 5.X How-To Guide – Captive Portals
If the customized captive portal pages are being hosted on an external HTTP server, a DNS whitelist
policy will need to be defined, the web page source changed to Externally Hosted and the URL for each
page defined. Externally hosted captive portal pages are covered in section 2.6.
2.5.2
Customizing Pages
Each captive portal page includes standard HTML elements which can be customized as well as
mandatory elements which must be maintained. The default pages include standard CSS which provides
the formatting, layout and colors for the pages as well as various java scripts which are used to pass
information to the WiNG 5 device performing the capture and redirection. The login and welcome pages
also include a HTML forms which are used to authenticate and logout the users.
When the default pages are generated the appropriate java and form scripts are automatically generated
in the default HTML pages. This includes if the terms and conditions page is required as well as the TCP
port used by the captive portal service. While these variables can be modified it is recommended that the
terms and conditions requirement and correct connection mode are defined prior to generating the default
pages that are being modified.
2.5.2.1 Login Page
The login.html page includes two java scripts and a HTML form which must be maintained in the
customized page. The java scripts must be included as -is with no modification; however the HTML form
can be reformatted to suit the specific application as long as the action, method and input strings, names
and values are maintained:
Java Script (between the </head> and <body> tags):
<script language=javascript>
//Function to get param value from URL.
function getQueryVariable(variable) {
var query = window.location.search.substring(1);
var vars = query.split("?");
for (var i=0;i<vars.length;i++) {
var pair = vars[i].split("=");
if (pair[0] == variable) {
if (pair[0] == "Qv") {
return vars[i].substr(3, vars[i].length);
}
return pair[1];
}
}
alert('Query Variable ' + variable + ' not found');
}
</script>
<script type="text/javascript">
function clear()
{
document.getElementById('f_user').value = "";
Page 94
WiNG 5.X How-To Guide – Captive Portals
document.getElementById('f_pass').value = "";
return true;}
</script>
HTML Form (between the <body> and </body> tags):
<table style="width: 100%;" cellpadding="0" cellspacing="0">
<form name="frmLogin" id="frmLogin" action="/cgi -bin/hslogin.cgi" method="POST" onReset="return clear()"
onSubmit="return check()">
<tbody>
<tr>
<td colspan="2" class="form-text">Username:</td>
</tr>
<tr>
<td colspan="2"><input style="width: 250px;" name="f_user" type="text"></td>
</tr>
<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td colspan="2" class="form-text">Password:</td>
</tr>
<tr>
<td colspan="2"><input style="width: 250px;" name="f_pass" type="password"></td>
</tr>
<tr>
<td colspan="2">
<input size="64" name="f_hs_server" id="f_hs_server" type="hidden">
<input name="f_Qv" id="f_Qv" type="hidden">
</td>
</tr>
<tr>
<td colspan="2" class="form-message"><input name="agree" value="yes" type="checkbox">I agree
to these <a href="agreement.html" target="_blank">terms and conditions</a></td>
</tr>
<tr>
<td style="text-align: left;"><input name="submit" value="Sign In" type="submit"></td>
<td style="text-align: right;"><input name="reset" value="Reset" type="r eset"></td>
</tr>
<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td colspan="2" class="form-message">Please contact the front desk if you have not been issued
a username and password.</td>
</tr>
Page 95
WiNG 5.X How-To Guide – Captive Portals
</tbody></form>
</table>
Java Script (before the </body> tags):
<script language=javascript>
var hs_server = "NONE";
var port = 444;
var postToUrl = "/cgi-bin/hslogin.cgi";
hs_server = getQueryVariable("hs_server");
Qv = getQueryVariable("Qv");
postToUrl = ":" + port + postToUrl;
document.getElementById("f_hs_server").value = hs_server
document.getElementById("f_Qv").value = Qv
document.getElementById("frmLogin").action = "https://" + hs_server + postToUrl;
</script>
Page 96
WiNG 5.X How-To Guide – Captive Portals
2.5.2.2 Welcome Page
The welcome.html page includes various java scripts and a HTML form. Some java scripts can be
optionally removed if required as they are used to display the remaining time for the session, however the
first and last java scripts must be maintained as-is for the logout URL to function. The HTML form can be
reformatted to suit the specific application as long as the action, method and input strings, names and
values are maintained. If the remaining time is not required, these elements can be safely removed from
the form table:
Java Script (between the </head> and <body> tags):
<script language=javascript>
//Function to get param value from URL.
function getQueryVariable(variable) {
var query = window.location.search.substring(1);
var vars = query.split("?");
for (var i=0;i<vars.length;i++) {
var pair = vars[i].split("=");
if (pair[0] == variable) {
if (pair[0] == "Qv") {
return vars[i].substr(3, vars[i].length);
}
return pair[1];
}
}
alert('Query Variable ' + variable + ' not found');
}
</script>
<script language="JavaScript">
//Function to get param value from URL.
function getQueryVariable(variable) {
var query = window.location.search.substring(1);
var vars = query.split("?");
for (var i=0;i<vars.length;i++) {
var pair = vars[i].split("=");
if (pair[0] == variable) {
if (pair[0] == "Qv") {
return vars[i].substr(3, vars[i].length);
}
return pair[1];
}
}
alert('Query Variable ' + variable + ' not found');
}
Page 97
WiNG 5.X How-To Guide – Captive Portals
(function() {
function listenEvent( o, evtType, fn ) {
if(o.addEventListener) {
o.addEventListener(evtType, fn, false);
return true;
} else if(o.attachEvent) {
// For MSIE
return o.attachEvent("on"+evtType, fn);
} else {
return false;
}
}
// Gets the timeout from the URL
function getTimeout() {
var rez = window.location.search.match(/timeout=( \d+)/);
if(rez&&rez.length==2) {
return parseInt(rez[1],10)
}
return -1;
// No timeout found
}
listenEvent( window, 'load', function() {
var timeout = getTimeout();
var txt='', days, hrs, mins, secs, days_str='', hrs_str='', mins_str='', secs_str='';
if(timeout==0) {
txt = "Your allotted time has expired.<br/>Please purchase a new voucher.";
} else {
if(timeout == -1) {
txt = "Your session is valid till the expiry date/time on your voucher.";
} else {
var seconds_remaining = timeout; // in seconds
var interval = setInterval(function() {
days_str='', hrs_str='', mins_str='', secs_str='';
seconds_remaining -= 1;
if(seconds_remaining<=0) {
clearInterval(interval);
txt = '';
document.getElementById('txt').innerHTML = txt;
alert("Your voucher duration is over. Please buy a new one if required.");
} else {
days = Math.floor(seconds_remaining/86400.0);
hrs = Math.floor((seconds_remaining%86400.0)/3600.0);
mins = Math.floor(((seconds_remaining%86400.0)%3600.0)/60);
secs = Math.floor(((seconds_remaining%86400. 0)%3600.0)%60.0);
if(days>0) {
days_str = days.toString() + " Days ";
}
Page 98
WiNG 5.X How-To Guide – Captive Portals
if(hrs>0) {
hrs_str = hrs.toString() + " Hrs ";
}
if(mins>0) {
mins_str = mins.toString() + " Minutes ";
}
if(secs>0) {
secs_str = secs.toString() + " Seconds ";
}
txt = days_str + hrs_str + mins_str + secs_str;
}
document.getElementById('txt').innerHTML = txt;
},1000);
}
}
document.getElementById('txt').innerHTML = txt;
});
})();
HTML Form (between the <body> and </body> tags):
<table style="width: 100%;" cellpadding="0" cellspacing="0">
<form name="frmLogin" id="frmLogin" action="/cgi-bin/hslogout.cgi" method="POST">
<tbody>
<tr>
<td colspan="2">
<input size="64" name="f_hs_server" id="f_hs_server" type="hidden">
<input name="f_Qv" id="f_Qv" type="hidden">
</td>
</tr>
<tr>
<td colspan="2" class="form-text" style="text-align: center;">Session Time Remaining:</td>
</tr>
<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td colspan="2" class="form-text" id="txt" style="text-align: center;"></td>
</tr>
<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td colspan="2" style="text-align: center;"><input name="submit" value="Disconnect"
Page 99
WiNG 5.X How-To Guide – Captive Portals
type="submit"></td>
</tr>
<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td colspan="2" class="form-message"> </td>
</tr>
<p class="content-message">Click Disconnect to end this session.</p>
</tbody></form>
</table>
Java Script (before the </body> tag):
<script language=javascript>
var hs_server = "NONE";
var port = 444;
var postToUrl = "/cgi-bin/hslogout.cgi";
hs_server = getQueryVariable("hs_server");
Qv = getQueryVariable("Qv");
postToUrl = ":" + port + postToUrl;
document.getElementById("f_hs_server").value = hs_server
document.getElementById("f_Qv").value = Qv
document.getElementById("frmLogin").action = "https://" + hs_server + postToUrl;
</script>
Page 100
WiNG 5.X How-To Guide – Captive Portals
2.5.2.3 Failed Page
The fail.html page includes various java scripts and a URL that redirects the user back to the login page.
All the java scripts can be optionally removed if required:
Java Script (between the </head> and <body> tags):
<script language=javascript>
//Function to get param value from URL.
function getQueryVariable(variable) {
var query = window.location.search.substring(1);
var vars = query.split("?");
for (var i=0;i<vars.length;i++) {
var pair = vars[i].split("=");
if (pair[0] == variable) {
if (pair[0] == "Qv") {
return vars[i].substr(3, vars[i].length);
}
return pair[1];
}
}
alert('Query Variable ' + variable + ' not found');
}
</script>
Logout URL (between in the <body> and </body> tags):
<a class="NAV" href="/TMELABS-GUEST/login.html">Try Again</>
Java Script (between the <body> </body> tags):
<script type="text/javascript">
(function() {
// Gets the timeout from the URL
function getTimeout() {
var rez = window.location.search.match(/timeout=( \d+)/);
if(rez&&rez.length==2) {
return parseInt(rez[1],10)
}
return -1;
// No timeout found
}
function listenEvent( o, evtType, fn ) {
if(o.addEventListener) {
o.addEventListener(evtType, fn, false);
return true;
} else if(o.attachEvent) {
// For MSIE
Page 101
WiNG 5.X How-To Guide – Captive Portals
return o.attachEvent("on"+evtType, fn);
} else {
return false;
}
}
listenEvent(window, 'load', function() {
var timeout = getTimeout();
var txt = '';
if(timeout==0 || timeout==-1) {
} else {
txt="<center><h2>Authentication Failed.</h2></center><br><center><h4>Your allotted time has
expired.<br/>Please purchase a new voucher.</h4></center><br><br><br><center>"
}
document.getElementById('txt').innerHTML = txt;
});
})();
</script>
Java Script (before the </body> tag):
<script language=javascript>
var hs_server = "NONE";
var port = 444;
var postToUrl = "";
hs_server = getQueryVariable("hs_server");
Qv = getQueryVariable("Qv");
postToUrl = "https://" + hs_server + ":" + port + "/";
var links = document.getElementsByTagName("a");
for (var i=0;i<links.length;i++)
{
if (links[i].href.match(/login.html/gi))
{
links[i].href = links[i].href.replace(/^https?: \/\/[0-9a-zA-Z._-]+:?[0-9]*\//gi,
postToUrl);
links[i].href = links[i].href + "?hs_server=" + hs_server;
links[i].href = links[i].href + "?Qv=" + Qv
}
}
</script>
Page 102
WiNG 5.X How-To Guide – Captive Portals
2.5.2.4 Agreement Page
The agreement.html page includes one java script which must be maintained as -is:
Java Script (before the </body> tag:
<script language=javascript>
var hs_server = "NONE";
var port = 444;
var postToUrl = "/cgi-bin/hslogin.cgi";
hs_server = getQueryVariable("hs_server");
Qv = getQueryVariable("Qv");
postToUrl = ":" + port + postToUrl;
document.getElementById("f_hs_server").value = hs_server
document.getElementById("f_Qv").value = Qv
document.getElementById("frmLogin").action = "h ttps://" + hs_server + postToUrl;
</script>
2.5.3
Distributing Customized Pages
Customized pages can be uploaded individually to individual devices using the copy command in the CLI
as well as the file management facility in the operations tab within the WiNG 5 UI. Individual file uploads
are fine when the captive portal pages are hosted on a small number of devices, however this is very
inefficient when distributing customized captive portal pages to large numbers of devices such as remote
Access Points.
To address this limitation WiNG 5.4 includes various enhancements to aid in simplifying the distribution of
customized pages to remote Access Points. Both enhancements allow a .tar archive of the customized
content to be uploaded to the Controller. The archive is assigned to the captive portal policy so that the
Controller knows which pages to deploy for each captive portal enabled Wireless LAN. The archived
pages can either be automatically uploaded to the remote Access Points upon adoption or distributed
using the CLI or WiNG 5 UI.

Note: The .tar file must b e compatible with Linux. When archiving files using Windows it is recommended
that WinAce or IZArc b e used as the .tar files from other Windows applications may not b e compatible.
Page 103
WiNG 5.X How-To Guide – Captive Portals
2.5.3.1 Web Page Auto Upload
The web page auto upload enhancement allows customized pages to be automatically distributed to
remote Access Points upon adoption. Upon adoption each Access Point will request the pages from the
Controller. If the pages on the Controller are newer than the pages on the Access Point, the Controller will
upload the .tar archive to the Access Point over MINT. The Access Points will then un-tar the archive and
install the pages into the appropriate directory.
1
Using the Web-UI select Operations  <device>  Captive Portal Pages  CP Page Image
File. In the Captive Portal List select the captive portal policy the pages apply to then enter the
TFTP or FTP server information where the .tar archive resides and the Path / Filename. Click
Load Image. Note for redundant Controller deployments the archive will need to be installed
onto both Controllers:
2
Once uploaded a dialog message will be displayed. Click OK:
Page 104
WiNG 5.X How-To Guide – Captive Portals
3
Once the .tar archive has been uploaded to the Controller(s), modify the captive portal policy
and enable the Web Page Auto Upload option. Note that this only applies when the Advanced
web page source option is selected. Click OK then Exit:
4
Commit and Save the changes:
Running-Configuration Changes:
!
server host virtual.tmelabs.local
webpage-location advanced
use aaa-policy EXTERNAL-AAA
webpage-auto-upload
!
Page 105
WiNG 5.X How-To Guide – Captive Portals
2.5.3.2 Captive Portal Page Upload
Secondly the customized pages and content can be distributed to remote Access Points using the
captive-portal-page-upload command or Captive Portal Pages within the WiNG 5 UI. For this feature the
customized pages and content are archived (tar) then distributed to the remote Access Points. The pages
can be distributed to individual remote Access Points, Access Points in a specific RF Domain or all
Access Points.
1
Using the Web-UI select Operations  <device>  Captive Portal Pages  CP Page Image
File. In the Captive Portal List select the captive portal policy the pages apply to then enter the
TFTP or FTP server information where the .tar archive resides and the Path / Filename. Click
Load Image. Note for redundant Controller deployments the archive will need to be installed
onto both Controllers. A history of the page distribution is available in the Status window:
Page 106
WiNG 5.X How-To Guide – Captive Portals
2
Once uploaded a dialog message will be displayed. Click OK:
3
Using the Web-UI select Operations  <rf-domain-name>. In the Captive Portal List select the
captive portal policy the pages apply to. Verify the Upload Via RF-Domain option is selected
then click Upload Pages. The status of the upload will be displayed in the Upload History
window:
Page 107
WiNG 5.X How-To Guide – Captive Portals
2.6 Externally Hosted Pages
The captive portal login, welcome, failed and agreement pages can be optionally hosted on an external
HTTP server. This is useful for large scale deployments when complex customized pages need to be
deployed or the web-browsers session needs to be redirected to an external secure guest access
provisioning server.
To enable externally hosted pages the web page source in the captive portal policy is set to Externally
Hosted and the URLs are defined for each page type. The URL can include the IPv4 address or FQDN of
the server hosting each page as well as the path and page name. When secure guest access is deployed
only the login URL needs to be specified as the web-browsers session will be captured and redirected to
the XpressConnect server where the device can be provisioned for secure access.
By default a captive portal will only permit limited access to the network for unauthenticated devices. To
permit access to the externally hosted pages a DNS whitelist policy must be defined and assigned to the
captive portal policy. The DNS whitelist can include the IPv4 addresses and/or hostnames of the external
hosts you wish to permit access to. This provides a walled garden for unauthenticated devices as it
permits access to only the hosts you specify until the user has been permitted access to the captive portal
network.
For secure guest access applications or BYOD the access type in captive portal policy can be configured
in a number of different ways depending on the specific deployment model required. For example the
RADIUS access type can be enabled with no AAA policy assigned to lock the users into the captive portal
network. The users will only be permitted access to the XpressConnect server and cannot break out of
the walled garden. Once their device has been provisioned by the XpressConnect server, their device will
automatically associate and authenticate to a secured Wireless LAN.
A different approach would be to permit secured and non-secured guest access. The access type can be
set to no authentication with a terms and conditions page assigned. With some minor customization to the
login page the guest / visitor users can either elect to provision their devices using the XpressConnect
server or accept the terms and conditions page and be permitted access to the non-secured Wireless
LAN. The guest / visitor users can also be authenticated via RADIUS if desired.
Page 108
WiNG 5.X How-To Guide – Captive Portals
2.6.1
DNS Whitelist Policy
A DNS whitelist policy will be defined that permits access to a HTTP server deployed in the isolated
network or DMZ that is hosting customized login, fail and agreement pages. The servers IPv4 address
192.168.25.5 will be added to the DNS whitelist which will be assigned to the captive portal policy.
1
Using the Web-UI select Configuration  Services  Captive Portals  DNS Whitelist  Add:
Page 109
WiNG 5.X How-To Guide – Captive Portals
2
Enter a Name then click Add Row. Enter the IP Address, Hostname or FQDN of the HTTP
server then click OK and Exit. In this example customized pages are hosted on a HTTP server
in the isolated network with the IPv4 address 192.168.25.5:
3
Commit and Save the changes:
Running-Configuration Changes:
!
dns-whitelist TMELABS-GUEST
permit 192.168.25.5
!
Page 110
WiNG 5.X How-To Guide – Captive Portals
2.6.2
Captive Portal Policy
An existing captive portal policy will be modified to redirect captive portal users to the externally hosted
pages hosted on the HTTP server (192.168.25.5) deployed in the isolated network or DMZ. The DNS
whitelist policy will be assigned to permit guest / visitor access to the HTTP server which hosts the login,
fail and agreement pages. The web page source will be changed to externally hosted and the URL for
each page defined. The welcome page will URL will be defined to redirect users to the company websi te.
1
Using the Web-UI select Configuration  Services  Captive Portals  Edit:
Page 111
WiNG 5.X How-To Guide – Captive Portals
2
Assign the DNS Whitelist policy then click OK:
3
Select the Web Page tab then set the Web Page Source to Externally Hosted. Define the Login,
Agreement, Welcome and Fail URLs. Do not use a HTTPS prefix! Click OK then Exit:
4
Commit and Save the changes:
Page 112
WiNG 5.X How-To Guide – Captive Portals
Running-Configuration Changes:
!
captive-portal TMELABS-GUEST
connection-mode https
server host virtual.tmelabs.local
server mode centralized-controller hosting-vlan-interface 25
terms-agreement
webpage-location external
webpage external login http://192.168.25.5/login.html
webpage external welcome http://www.motorolasolutions.com
webpage external fail http://192.168.25.5/fail.html
webpage external agreement http://192.168.25.5/agreement.html
!
Page 113
WiNG 5.X How-To Guide – Captive Portals
3. Verification
3.1 Web Based Guest User Provisioning
The following outlines the procedure for creating a guest / visitor account on an RFS X000 Wireless
Controller using the web-based management interface. The front desk personal will use the special Web
User role account defined in the Controllers management policy to login to the management interface.
This will present a special UI which will permit the creation and printing of guest / visitor accounts.
When a guest / visitor account is created on the system it will be mapped to a user pool and group so that
the user can be authenticated using the integrated RADIUS server. The accounts will be automatically
purged 24 hours upon expiration.
1
2
Using a web-browser connect to the management interface on the RFS 000 Wireless
Controller that is authenticating the guest / visitor users. Login using an account which has
the Web User role assigned:
From the list select the user pool for which the guest / visitor account is to be created on then
click Create New User. In this example the user pool TMELABS-GUEST has been selected:
Page 114
WiNG 5.X How-To Guide – Captive Portals
3
Define a Username, Password and optionally enter an Email address and Telephone number.
Select a User Group then define the Start Date/Time and End Date/Time the account is valid
for. Click Create User. Note you can also print the information as a voucher if required:
Running-Configuration Changes:
radius-user-pool-policy TMELABS-GUEST
!
user tuZFq3ME password 0 8EBIn8Vuvs group TMELABS -GUEST guest expiry-time 18:00 expiry-date
11:13:2012 start-time 14:00 start-date 11:13:2012 email-id [email protected] telephone 5552221212
!
Page 115
WiNG 5.X How-To Guide – Captive Portals
3.2 Capture and Redirection
The following provides an overview of the re-direct URLs as well as the different types of pages
presented to captive portal users. The pages in this example are based on the default login, welcome,
failed and agreement pages generated by the WiNG 5 system which have been customized using the
captive portal policy:
1
When a user that is connected to a captive portal enabled Wireless LAN opens their web browser and attempts to access a web-site, their web-browser session will be captured and
re-directed to a login or terms and conditions page. Depending on the captive portal policy
configuration, the connection will either be HTTP (port 444) or HTTPS (port 880) and will
include either the IP address or virtual-hostname of the WiNG 5 device that has performed the
capture and redirection. The URL will also include the captive portal policy name, the name of
the page being displayed as well as various strings of information used by WiNG:
2
If authentication is enabled, a login page will be displayed. The login page will require the
Wireless LAN user to enter valid credentials before being permitted access to the Wireless
LAN. The login page can optionally include terms and conditions which the user must agree
before being permitted access to the Wireless LAN. The user can be authenticated locally on
an RFS X000 Wireless Controller or against an external RADIUS server:
Page 116
WiNG 5.X How-To Guide – Captive Portals
3
If the authentication succeeds, the web-browser will be redirected to a welcome page. The
welcome page typically displays a message as well as presents information such as the
remaining time for the session:
4
If the authentication fails, the web-browser is redirected to a failed page. The failed page
typically includes a message as well as a URL so that the user can attempt the login again:
Page 117
WiNG 5.X How-To Guide – Captive Portals
5
If no authentication with a terms and conditions page is enabled, the web -browser is
redirected to an agreement page. The agreement page typically includes the terms and
conditions the user must agree to before being permitted access to the Wireless LAN.
Page 118
WiNG 5.X How-To Guide – Captive Portals
4. Appendix
4.1 Configuration Examples
4.1.1
Centralized Deployment
NX 9000 Startup-Config:
!
! Configuration of NX9500 version 5.4.0.0-047R
!
!
version 2.1
!
!
firewall-policy default
no ip dos smurf
no ip dos twinge
no ip dos invalid-protocol
no ip dos router-advt
no ip dos router-solicit
no ip dos option-route
no ip dos ascend
no ip dos chargen
no ip dos fraggle
no ip dos snork
no ip dos ftp-bounce
no ip dos tcp-intercept
no ip dos broadcast-multicast-icmp
no ip dos land
no ip dos tcp-xmas-scan
no ip dos tcp-null-scan
no ip dos winnuke
no ip dos tcp-fin-scan
no ip dos udp-short-hdr
no ip dos tcp-post-syn
no ip dos tcphdrfrag
no ip dos ip-ttl-zero
no ip dos ipspoof
no ip dos tcp-bad-sequence
no ip dos tcp-sequence-past-window
no ip-mac conflict
Page 119
WiNG 5.X How-To Guide – Captive Portals
no ip-mac routing conflict
no stateful-packet-inspection-l2
!
!
mint-policy global-default
!
wlan-qos-policy default
qos trust dscp
qos trust wmm
!
radio-qos-policy default
!
captive-portal TMELABS-GUESTS
access-type no-auth
terms-agreement
!
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
!
smart-rf-policy STORES
!
auto-provisioning-policy DATACENTER
adopt ap6532 precedence 1 profile STORES-AP6532 rf-domain STORE1 ip 192.168.21.0/24
!
!
management-policy ACCESS-POINTS
no http server
ssh
user admin password 0 hellomoto role superuser access all
no snmp-server manager v2
no snmp-server manager v3
!
management-policy WIRELESS-CONTROLLERS
telnet
no http server
https server
Page 120
WiNG 5.X How-To Guide – Captive Portals
ssh
user admin password 0 hellomoto role superuser access all
snmp-server user snmpoperator v3 encrypted des auth md5 0 operator
snmp-server user snmptrap v3 encrypted des auth md5 0 motorola
snmp-server user snmpmanager v3 encrypted des auth md5 0 motorol a
!
l2tpv3 policy default
!
profile nx9000 DATACENTER-NX9000
ip name-server 192.168.10.6
ip domain-name tmelabs.local
no autoinstall configuration
no autoinstall firmware
no ap-upgrade auto
ap-upgrade count 20
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
crypto load-management
interface ge1
switchport mode trunk
switchport trunk native vlan 20
switchport trunk native tagged
switchport trunk allowed vlan 20
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge2
ip dhcp trust
qos trust dscp
qos trust 802.1p
use management-policy WIRELESS-CONTROLLERS
use firewall-policy default
use auto-provisioning-policy DATACENTER
ntp server 192.168.10.6
no auto-learn-staging-config
service pm sys-restart
Page 121
WiNG 5.X How-To Guide – Captive Portals
!
profile ap6532 STORES-AP6532
ip name-server 192.168.10.6
ip domain-name tmelabs.local
no autoinstall configuration
no autoinstall firmware
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
crypto load-management
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
!
rf-domain DATACENTER
location Johnson\ City\ TN
contact [email protected]
Page 122
WiNG 5.X How-To Guide – Captive Portals
timezone EST5EDT
country-code us
!
rf-domain STORE1
location Johnson\ City\ TN
contact [email protected]
timezone EST5EDT
country-code us
control-vlan 21
!
rf-domain default
no country-code
!
nx9000 B4-C7-99-6C-86-5F
use profile DATACENTER-NX9000
use rf-domain DATACENTER
hostname nx9000-1
license AAP <string>
ip default-gateway 192.168.20.1
interface vlan20
ip address 192.168.20.26/24
logging on
logging console debugging
logging buffered warnings
!
ap6532 00-23-68-31-20-A4
use profile STORES-AP6532
use rf-domain STORE1
hostname ap6532-1
!
ap6532 00-23-68-86-44-A0
use profile STORES-AP6532
use rf-domain STORE1
hostname ap6532-2
!
ap6532 5C-0E-8B-33-EE-70
use profile STORES-AP6532
use rf-domain STORE1
hostname ap6532-3
!
!
end
Page 123
WiNG 5.X How-To Guide – Captive Portals
4.1.2
Campus Deployment
RFS6000 Cluster Startup-Config:
!
! Configuration of RFS6000 version 5.4.0.0-047R
!
!
version 2.1
!
!
firewall-policy default
no ip dos smurf
no ip dos twinge
no ip dos invalid-protocol
no ip dos router-advt
no ip dos router-solicit
no ip dos option-route
no ip dos ascend
no ip dos chargen
no ip dos fraggle
no ip dos snork
no ip dos ftp-bounce
no ip dos tcp-intercept
no ip dos broadcast-multicast-icmp
no ip dos land
no ip dos tcp-xmas-scan
no ip dos tcp-null-scan
no ip dos winnuke
no ip dos tcp-fin-scan
no ip dos udp-short-hdr
no ip dos tcp-post-syn
no ip dos tcphdrfrag
no ip dos ip-ttl-zero
no ip dos ipspoof
no ip dos tcp-bad-sequence
no ip dos tcp-sequence-past-window
no ip-mac conflict
no ip-mac routing conflict
no stateful-packet-inspection-l2
!
!
Page 124
WiNG 5.X How-To Guide – Captive Portals
mint-policy global-default
!
wlan-qos-policy default
qos trust dscp
qos trust wmm
!
radio-qos-policy default
!
aaa-policy INTERNAL-AAA
authentication server 1 onboard controller
!
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
!
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
!
ap300 default-ap300
interface radio1
interface radio2
!
smart-rf-policy CAMPUS
!
auto-provisioning-policy CAMPUS
adopt ap6532 precedence 2 profile CAMPUS-AP6532 rf-domain CAMPUS ip 192.168.21.0/24
!
radius-group TMELABS-GUEST
guest
policy ssid TMELABS-GUEST
policy day mo
policy day tu
policy day we
policy day th
Page 125
WiNG 5.X How-To Guide – Captive Portals
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
!
!
management-policy ACCESS-POINTS
no http server
no ftp
ssh
user admin password 0 hellomoto role superuser access all
no snmp-server manager v2
no snmp-server manager v3
!
management-policy WIRELESS-CONTROLLERS
no http server
https server
no ftp
ssh
user admin password 0 hellomoto role superuser access all
user guestadmin password 0 hellomoto role web-user-admin
snmp-server user snmpoperator v3 encrypted des auth md5 0 operator
snmp-server user snmptrap v3 encrypted des auth md5 0 motorola
snmp-server user snmpmanager v3 encrypted des auth md5 0 motorola
!
l2tpv3 policy default
!
profile rfs6000 CAMPUS-RFS6000
ip name-server 192.168.10.6
ip domain-name tmelabs.local
no autoinstall configuration
no autoinstall firmware
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
Page 126
WiNG 5.X How-To Guide – Captive Portals
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
interface ge1
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge2
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge3
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge4
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge5
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge6
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge7
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge8
ip dhcp trust
Page 127
WiNG 5.X How-To Guide – Captive Portals
qos trust dscp
qos trust 802.1p
interface wwan1
interface pppoe1
use management-policy WIRELESS-CONTROLLERS
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
!
profile ap6532 CAMPUS-AP6532
ip name-server 192.168.10.6
ip domain-name tmelabs.local
no autoinstall configuration
no autoinstall firmware
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
crypto load-management
interface radio1
wlan TMELABS-GUEST bss 1 primary
interface radio2
interface ge1
description UPLINK
switchport mode trunk
switchport trunk native vlan 21
no switchport trunk native tagged
switchport trunk allowed vlan 21-22
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface vlan21
ip address dhcp
ip dhcp client request options all
Page 128
WiNG 5.X How-To Guide – Captive Portals
interface pppoe1
use management-policy ACCESS-POINTS
use firewall-policy default
ntp server 192.168.10.6
service pm sys-restart
router ospf
!
rf-domain CAMPUS
location JohnsonCityTN
contact [email protected]
timezone EST5EDT
country-code us
use smart-rf-policy CAMPUS
!
rf-domain default
no country-code
!
rfs6000 00-23-68-64-43-5A
use profile CAMPUS-RFS6000
use rf-domain CAMPUS
hostname rfs6000-1
license AP <string>
license AAP <string>
license ADVANCED-WIPS <string>
license ADSEC <string>
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
Page 129
WiNG 5.X How-To Guide – Captive Portals
use rf-domain CAMPUS
hostname rfs6000-2
license AP <string>
license AAP <string>
license ADVANCED-WIPS <string>
license ADSEC <string>
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
cluster mode active
cluster member ip 192.168.20.22
cluster master-priority 128
logging on
logging console warnings
logging buffered warnings
!
ap6532 00-23-68-31-20-A4
use profile CAMPUS-AP6532
use rf-domain CAMPUS
hostname ap6532-1
!
ap6532 00-23-68-86-44-A0
use profile CAMPUS-AP6532
use rf-domain CAMPUS
hostname ap6532-2
!
ap6532 5C-0E-8B-33-EE-70
use profile CAMPUS-AP6532
use rf-domain CAMPUS
hostname ap6532-3
!
!
end
Page 130
WiNG 5.X How-To Guide – Captive Portals
4.1.3
Campus Deployment with Anchor Controllers
RFS 6000 Cluster Startup-Config:
!
! Configuration of RFS6000 version 5.4.0.0-047R
!
!
version 2.1
!
!
firewall-policy default
no ip dos smurf
no ip dos twinge
no ip dos invalid-protocol
no ip dos router-advt
no ip dos router-solicit
no ip dos option-route
no ip dos ascend
no ip dos chargen
no ip dos fraggle
no ip dos snork
no ip dos ftp-bounce
no ip dos tcp-intercept
no ip dos broadcast-multicast-icmp
no ip dos land
no ip dos tcp-xmas-scan
no ip dos tcp-null-scan
no ip dos winnuke
no ip dos tcp-fin-scan
no ip dos udp-short-hdr
no ip dos tcp-post-syn
no ip dos tcphdrfrag
no ip dos ip-ttl-zero
no ip dos ipspoof
no ip dos tcp-bad-sequence
no ip dos tcp-sequence-past-window
no ip-mac conflict
no ip-mac routing conflict
no stateful-packet-inspection-l2
!
!
Page 131
WiNG 5.X How-To Guide – Captive Portals
mint-policy global-default
!
wlan-qos-policy default
qos trust dscp
qos trust wmm
!
radio-qos-policy default
!
aaa-policy INTERNAL-AAA
authentication server 1 onboard controller
!
captive-portal TMELABS-GUEST
connection-mode https
server host virtual.tmelabs.local
server mode centralized-controller hosting-vlan-interface 125
use aaa-policy INTERNAL-AAA
!
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
!
ap300 default-ap300
interface radio1
interface radio2
!
smart-rf-policy CAMPUS
!
auto-provisioning-policy CAMPUS
adopt ap6532 precedence 2 profile CAMPUS-AP6532 rf-domain CAMPUS ip 192.168.21.0/24
!
radius-group TMELABS-GUEST
guest
policy ssid TMELABS-GUEST
policy day mo
policy day tu
policy day we
policy day th
Page 132
WiNG 5.X How-To Guide – Captive Portals
policy day fr
policy time start 08:00 end 18:00
!
radius-user-pool-policy TMELABS-GUEST
user guest password 0 hellomoto
!
radius-server-policy INTERNAL-AAA
use radius-user-pool-policy TMELABS-GUEST
!
!
management-policy ACCESS-POINTS
no http server
ssh
user admin password 0 hellomoto role superuser access all
no snmp-server manager v2
no snmp-server manager v3
!
management-policy WIRELESS-CONTROLLERS
no http server
https server
ssh
user admin password 0 hellomoto role superuser access all
user guestadmin password 0 hellomoto role web-user-admin
snmp-server user snmpoperator v3 encrypted des auth md5 0 operator
snmp-server user snmptrap v3 encrypted des auth md5 0 motorola
snmp-server user snmpmanager v3 encrypted des auth md5 0 motorola
!
l2tpv3 policy default
!
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
ip name-server 192.168.10.6
ip domain-name tmelabs.local
no autoinstall configuration
no autoinstall firmware
use radius-server-policy INTERNAL-AAA
crypto ikev1 policy ikev1-default
Page 133
WiNG 5.X How-To Guide – Captive Portals
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
interface ge1
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge2
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge3
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge4
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge5
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge6
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge7
Page 134
WiNG 5.X How-To Guide – Captive Portals
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge8
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface wwan1
interface pppoe1
use management-policy WIRELESS-CONTROLLERS
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
!
profile ap6532 CAMPUS-AP6532
ip name-server 192.168.10.6
ip domain-name tmelabs.local
no autoinstall configuration
no autoinstall firmware
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
crypto load-management
interface radio1
wlan TMELABS-GUEST bss 1 primary
interface radio2
interface ge1
description UPLINK
switchport mode trunk
switchport trunk native vlan 21
no switchport trunk native tagged
switchport trunk allowed vlan 21-22
ip dhcp trust
Page 135
WiNG 5.X How-To Guide – Captive Portals
qos trust dscp
qos trust 802.1p
interface vlan21
ip address dhcp
ip dhcp client request options all
interface pppoe1
use management-policy ACCESS-POINTS
use firewall-policy default
ntp server 192.168.10.6
service pm sys-restart
router ospf
!
rf-domain CAMPUS
location JohnsonCityTN
contact [email protected]
timezone EST5EDT
country-code us
use smart-rf-policy CAMPUS
!
rf-domain default
no country-code
!
rfs6000 00-23-68-64-43-5A
use profile CAMPUS-RFS6000
use rf-domain CAMPUS
hostname rfs6000-1
license AP <string>
license AAP <string>
license ADVANCED-WIPS <string>
license ADSEC <string>
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
cluster member ip 192.168.20.23
cluster master-priority 254
logging on
Page 136
WiNG 5.X How-To Guide – Captive Portals
logging console warnings
logging buffered warnings
!
rfs6000 5C-0E-8B-17-E8-F6
use profile CAMPUS-RFS6000
use rf-domain CAMPUS
hostname rfs6000-2
license AP <string>
license AAP <string>
license ADVANCED-WIPS <string>
license ADSEC <string>
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
cluster mode active
cluster member ip 192.168.20.22
cluster master-priority 128
logging on
logging console warnings
logging buffered warnings
!
ap6532 00-23-68-31-20-A4
use profile CAMPUS-AP6532
use rf-domain CAMPUS
hostname ap6532-1
!
ap6532 00-23-68-86-44-A0
use profile CAMPUS-AP6532
use rf-domain CAMPUS
hostname ap6532-2
!
ap6532 5C-0E-8B-33-EE-70
use profile CAMPUS-AP6532
use rf-domain CAMPUS
hostname ap6532-3
!
Page 137
WiNG 5.X How-To Guide – Captive Portals
!
end
RFS 4000 Cluster Startup-Config:
!
! Configuration of RFS4000 version 5.4.0.0-047R
!
!
version 2.1
!
!
firewall-policy default
no ip dos smurf
no ip dos twinge
no ip dos invalid-protocol
no ip dos router-advt
no ip dos router-solicit
no ip dos option-route
no ip dos ascend
no ip dos chargen
no ip dos fraggle
no ip dos snork
no ip dos ftp-bounce
no ip dos tcp-intercept
no ip dos broadcast-multicast-icmp
no ip dos land
no ip dos tcp-xmas-scan
no ip dos tcp-null-scan
no ip dos winnuke
no ip dos tcp-fin-scan
no ip dos udp-short-hdr
no ip dos tcp-post-syn
no ip dos tcphdrfrag
no ip dos ip-ttl-zero
no ip dos ipspoof
no ip dos tcp-bad-sequence
no ip dos tcp-sequence-past-window
no ip-mac conflict
no ip-mac routing conflict
no stateful-packet-inspection-l2
!
!
Page 138
WiNG 5.X How-To Guide – Captive Portals
mint-policy global-default
!
meshpoint-qos-policy default
!
wlan-qos-policy default
qos trust dscp
qos trust wmm
!
radio-qos-policy default
!
captive-portal TMELABS-GUEST
connection-mode https
server host virtual.tmelabs.local
server mode centralized-controller hosting-vlan-interface 25
webpage internal org-name Motorola Solutions
webpage internal org-signature &copy 2012 Motorola Solutions. All Rights Reserved.
!
ap300 default-ap300
interface radio1
interface radio2
!
auto-provisioning-policy AAA
!
auto-provisioning-policy DENY-ADOPTION
!
!
management-policy WIRELESS-CONTROLLERS
no http server
https server
ssh
user admin password 0 hellomoto role superuser access all
snmp-server user snmpoperator v3 encrypted des auth md5 0 operator
snmp-server user snmptrap v3 encrypted des auth md5 0 motorola
snmp-server user snmpmanager v3 encrypted des auth md5 0 motorol a
!
l2tpv3 policy default
!
profile rfs4000 DMZ-RFS4000
mint link ip 192.168.20.22
mint link ip 192.168.20.23
no mint mlcp vlan
no mint mlcp ip
Page 139
WiNG 5.X How-To Guide – Captive Portals
bridge vlan 25
bridging-mode tunnel
ip igmp snooping
ip igmp snooping querier
ip name-server 192.168.10.6
ip domain-name tmelabs.local
no autoinstall configuration
no autoinstall firmware
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 radio1
interface radio2
interface up1
description UPLINK
switchport mode trunk
switchport trunk native vlan 30
switchport trunk native tagged
switchport trunk allowed vlan 25,30
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge1
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge2
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge3
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface ge4
ip dhcp trust
qos trust dscp
Page 140
WiNG 5.X How-To Guide – Captive Portals
qos trust 802.1p
interface ge5
ip dhcp trust
qos trust dscp
qos trust 802.1p
interface wwan1
interface pppoe1
use management-policy WIRELESS-CONTROLLERS
use firewall-policy default
use auto-provisioning-policy DENY-ADOPTION
use captive-portal server TMELABS-GUEST
ntp server 192.168.10.6
no auto-learn-staging-config
service pm sys-restart
router ospf
!
rf-domain DMZ
location JohnsonCityTN
contact [email protected]
timezone EST5EDT
no country-code
!
rf-domain default
no country-code
!
rfs4000 00-23-68-22-9D-E4
use profile DMZ-RFS4000
use rf-domain DMZ
hostname rfs4000-dmz-1
license AP DEFAULT-6AP-LICENSE
ip default-gateway 192.168.30.1
interface vlan25
ip address 192.168.25.20/24
interface vlan30
ip address 192.168.30.20/24
cluster name DMZ
cluster member ip 192.168.30.21
cluster master-priority 254
logging on
logging console warnings
logging buffered warnings
vrrp 25 description CAPTIVE-PORTAL
Page 141
WiNG 5.X How-To Guide – Captive Portals
vrrp 25 priority 200
vrrp 25 timers advertise 1
vrrp 25 ip 192.168.25.10
vrrp 25 preempt
vrrp 25 interface vlan25
no vrrp 25 sync-group
no vrrp 25 monitor critical-resource
no vrrp 25 delta-priority
!
rfs4000 5C-0E-8B-1A-FE-A0
use profile DMZ-RFS4000
use rf-domain DMZ
hostname rfs4000-dmz-2
license AP DEFAULT-6AP-LICENSE
ip default-gateway 192.168.30.1
interface vlan25
ip address 192.168.25.21/24
interface vlan30
ip address 192.168.30.21/24
cluster name DMZ
cluster mode standby
cluster member ip 192.168.30.20
cluster master-priority 128
logging on
logging console warnings
logging buffered warnings
vrrp 25 description CAPTIVE-PORTAL
vrrp 25 priority 100
vrrp 25 timers advertise 1
vrrp 25 ip 192.168.25.10
vrrp 25 preempt
vrrp 25 interface vlan25
no vrrp 25 sync-group
no vrrp 25 monitor critical-resource
no vrrp 25 delta-priority
!
!
end
Page 142
WiNG 5.X How-To Guide – Captive Portals
Page 143