Cisco Unified Wireless Network Solution – Guest Wireless
Background
Public WLAN has caused mobile workers to become accustomed to being able to access their corporate network from practically anywhere. This paradigm of public access has extended to the enterprise itself and brings a well-founded apprehension over how to secure internal company information and infrastructure assets.
Cisco proposes Unified Wireless Network Solution for Guest Access to provide users with Internet access in a secure manner.
Wireless Guest Access Overview
Ideally, the implementation of a wireless guest network uses as much of an enterprise’s existing wireless and wired infrastructure as possible to avoid the cost and complexity of building a physical overlay network. Assuming this is the case, the following additional elements and functions are needed:
- A dedicated guest WLAN/SSID—Implemented throughout the campus wireless network wherever guest access is needed.
- Guest traffic segregation—Requires implementing Layer 2 or Layer 3 techniques across the campus network to restrict where guests are allowed to go.
- Access control—Involves using embedded access control functionality within the campus network or implementing an external platform to control guest access to the Internet from the enterprise network.
- Guest user credential management—A process by which a sponsor can create temporary credentials in behalf of a guest. This function might be resident within an access control platform or it might be a component of AAA or some other management system.
Wireless Guest Access using a Centralized Controller Architecture
Figure 1
As shown in Figure 1, a controller is located in the enterprise’s DMZ where it performs an anchor function. This anchor controller is responsible for terminating EoIP tunnels that originate from other campus WLAN controllers throughout the network. Remote controllers are responsible for termination, management, and standard operation of the various WLANs provisioned throughout the enterprise, including one or more guest WLANs.
Guest WLANs, instead of being bridged locally to a corresponding VLAN, are bridged via an EoIP tunnel to the anchor controller. Specifically, guest WLAN data frames are bridged via LWAPP to the campus Wireless LAN Controller and via EoIP for the campus WLC to a guest VLAN defined at the anchor WLC. In this way, guest user traffic is forwarded to the Internet transparently, with no visibility by, or interaction with, other traffic in the enterprise.
WLAN Controller Guest Access
The Guest Access solution is self-contained and does not require any external platforms to perform access control, web portal, or AAA services. All these functions are configured and run within the anchor controller. However, the option exists to implement one or all of these functions externally.
Supported Platforms
The anchor function, which includes tunnel termination, web authentication, and access control is supported on the following WLC platforms (using version 8.1 or later):
- WLC 2504
- WLC 5508
- WLC 5520
- WiSM-2
- WLC 8510
- WLC 8540
The following WLC platforms cannot be used for anchor functions, but can be used for standard controller deployments and guest mobility tunnel origination (foreign WLC) to a designated anchor controller(s):
- Cisco WLAN Controller Module for Integrated Service Routers (ISR-SM)
- WLC 7500
- Virtual WLC
Anchor Controller Deployment Guidelines
This section provides guidelines for deploying an anchor controller to support wireless guest access.
Anchor Controller Positioning
Because the anchor controller is responsible for termination of guest WLAN traffic and subsequent access to the Internet, it is typically positioned in the enterprise Internet DMZ.
Figure 2
In doing so, rules can be established within the firewall to precisely manage communications between authorized controllers throughout the enterprise and the anchor controller. Such rules might include filtering on source or destination controller addresses, UDP port 16666 for inter-WLC communication, and IP protocol ID 97 Ethernet in IP for client traffic. Other rules that might be needed include the following:
- UDP 161 and 162 for SNMP
- UDP 69 for TFTP
- TCP 80, 443 and 8443 for HTTP, or HTTPS for GUI access
- TCP 23 or 22 for Telnet, or SSH for CLI access
- UDP 123 for NTP
- TCP 514 for Syslog
- UDP 1812 and 1813 RADIUS
The firewall can be used to protect the anchor controller from outside threats.
For the best possible performance and because of its suggested positioning in the network, it is strongly recommended that the guest anchor controller be dedicated to supporting guest access functions only.
DHCP Services
As previously described, guest traffic is transported at Layer 2 via EoIP. Therefore, the first point at which DHCP services can be implemented is either locally on the anchor controller or the controller can relay client DHCP requests to an external server.
Routing
Guest traffic egress occurs at the anchor controller. Guest WLANs are mapped to a dynamic interface/VLAN on the anchor. This interface might connect to an interface on a firewall, therefore, a client’s default gateway IP is that of the firewall. For ingress routing, it is assumed the guest VLAN is directly connected to a DMZ interface on a firewall. The guest (VLAN) subnet is known as a directly connected network and advertised accordingly.
Proxy – Web Filtering
The deployment of a Proxy in Transparent mode in the DMZ can help to enforce enterprise security policies. A proxy is able to monitor, log or even filter guest web traffic that falls into unauthorised categories. Traffic reports might be useful for troubleshooting, tracking or just having more visibility about guest users’ traffic.
Another option would be to enable some URL Blocking features if the firewall supports them for an extra layer of security.
Anchor Controller Redundancy N+1
A “guest N+1” was introduced in Release 4.1. This feature supports an automatic ping function that enables a foreign controller to proactively ping anchor controllers to verity control and data path connectivity. In the event of failure or an active anchor becomes unreachable, the foreign controller does the following:
- Automatically detects that the anchor has become unreachable.
- Automatically disassociates any wireless clients that were previously associated with the unreachable anchor.
- Automatically re-associates wireless client(s) to an alternate anchor WLC. With guest N+1 redundancy, two or more anchor WLCs can be defined for a given guest WLAN.
Figure 3
Keep in mind the following in regards to guest N+1 redundancy:
- A given foreign controller load balances wireless client connections across the list of anchor controllers configured for the guest WLAN. There is currently no method to designate one anchor as primary with one or more secondary anchors.
- Wireless clients that are associated with an anchor WLC that becomes unreachable are re-associated with another anchor defined for the WLAN. When this happens, the client is redirected to the web portal authentication page and required to re-submit their credentials.
Note Multicast traffic is not supported over guest tunnels.
Web Portal Authentication
The Cisco Centralized Guest Access solution offers a built-in web portal that is used to solicit guest credentials for authentication and offers simple branding capabilities, along with the ability to display disclaimer or acceptable use policy information.
Figure 4
As is typical for most web-based authentication systems, in order for guest clients to be redirected to the WLC web authentication page, they must launch a web browser session and attempt to open a destination URL. For redirection to work correctly, the following conditions must be met:
- DNS resolution- When a client associates to a web policy WLAN for authentication, all traffic is blocked except DHCP and DNS. Therefore, the DNS servers must be reachable from the anchor controller.
- Resolvable Home Page URL—The home page URL of a guest user must be globally resolvable by DNS.
- HTTP Port 80—If the home page of a user is resolvable, but connects to a web server on a port other than port 80, they are not redirected. Again, the user is required to open a URL that uses port 80 to be redirected to the WLC web authentication page.
Note: In addition to port 80, there is an option to configure one additional port number that the controller can monitor for redirection.
Guest User Authentication
These are the alternatives for Guest authentication:
- The controller checks its local database for username and password and, if present, grants access – Guest credentials, once applied, are stored locally on the (anchor) WLC and remain there until expiration of the “Lifetime” variable as defined in the guest template. A sponsor is permitted to create and assign guest credentials to controllers that have web-policy configured WLANs.
- External Authentication using ISE or Cisco Secure ACS and Microsoft User Databases – The anchor controller/guest WLAN can be configured to forward web portal authentication to an external RADIUS server.
- Guest Pass-through -Bypass user authentication altogether and allow open access. However, an enterprise may still need to present an acceptable use policy or disclaimer page to users before granting access. If this is the case, then a guest WLAN can be configured for web policy pass through. In this scenario, a guest user is redirected to a portal page containing disclaimer information. Pass through mode also has an option for a user to enter an e-mail address before connecting.
Guest Access Configuration:
For configuration details refer to Cisco Enterprise Mobility8-1 Deployment Guide.
Summary:
The following are some benefits for Wireless Guest Access using a Centralized Controller Architecture:
- The Campus/Foreign WLC provides segmentation by anchoring guest traffic to the anchor controller.
- There is inherent benefit of not having guest traffic traverse the internal network. Only internal access the guest user needs is guest portal for Central Web Authentication (CWA) and possibly DNS.
- While it might sound risky to implement a guest access solution, when implemented correctly, an enterprise that implements a guest access solution will most likely improve their overall security posture as a result of the network audits associated with the implementation process.
- Authentication and authorization control of guests based on variables including date, duration, and bandwidth.
- An audit mechanism to track who is currently using, or has used, the network.
- It provides wider coverage by including areas such as lobbies and other common areas that otherwise might not have been wired for network connectivity.
- It removes the need for designated guest access areas or rooms.
References: