Alcatel-Lucent AOS-W 6.5.3.x User Manual 1160 Pages
Alcatel-Lucent AOS-W 6.5.3.x is a versatile networking device that provides a wide range of features for campus-wide wireless LAN (WLAN) deployments. It offers a comprehensive suite of security protocols, including control plane security, MAC-based authentication, and 802.1X authentication, ensuring the protection of your network and data. Additionally, the device supports IPv6, OSPFv2, and LACP, providing advanced routing and network optimization capabilities. Whether you're looking to enhance connectivity, improve security, or optimize your network performance, Alcatel-Lucent AOS-W 6.5.3.x has the features and flexibility to meet your needs.
advertisement
AOS-W 6.5.3.x
Copyright Information
Alcatel-Lucent and the Alcatel-Lucent Enterprise logo are trademarks of Alcatel-Lucent. To view other trademarks used by affiliated companies of ALE Holding, visit: enterprise.alcatel-lucent.com/trademarks
All other trademarks are the property of their respective owners. The information presented is subject to change without notice. Neither ALE Holding nor any of its affiliates assumes any responsibility for inaccuracies contained herein. (2017)
Open Source Code
This product includes code licensed under the GNU General Public License, the GNU Lesser General Public
License, and/or certain other open source licenses.
Revision 01 | June 2017 AOS-W 6.5.3.x | User Guide
Contents
About this Guide
The Basic User-Centric Networks
Understanding Basic Deployment and Configuration Tasks
Connect the Switch to the Network
OAW-40xx Series and OAW-4x50 Series Switches
Configuring a VLAN to Connect to the Network
Enabling Wireless Connectivity
Enabling Wireless Connectivity
Configuring Your User-Centric Network
Control Plane Security
Control Plane Security Overview
Configuring Control Plane Security
Managing Whitelists on Master and Local Switches
Working in Environments with Multiple Master Switches
Replacing a Switch on a Multi-Switch Network
AOS-W 6.5.3.x
| User Guide
Contents
3
56
19
35
Contents | 3
4 | Contents
Configuring Control Plane Security after Upgrading
Troubleshooting Control Plane Security
Software Licenses
Getting Started with AOS-W Licenses
Licensing Best Practices and Limitations
Centralized Licensing Overview
Configuring Centralized Licensing
Monitoring and Managing Centralized Licenses
Network Configuration Parameters
Understanding VLAN Assignments
Configuring the Loopback IP Address
Configuring the Switch IP Address
IPv6 Support
Enabling IPv6 Support for Switch and APs
Filtering an IPv6 Extension Header (EH)
Configuring a Captive Portal over IPv6
130
79
97
AOS-W 6.5.3.x | User Guide
Working with IPv6 Router Advertisements (RAs)
Understanding AOS-W Supported Network Configuration for IPv6 Clients
Understanding AOS-W Authentication and Firewall Features that Support IPv6
Understanding IPv6 Exceptions and Best Practices
Link Aggregation Control Protocol
Understanding LACP Best Practices and Exceptions
OSPFv2
Understanding OSPF Deployment Best Practices and Exceptions
Understanding OSPFv2 by Example using a WLAN Scenario
Understanding OSPFv2 by Example using a Branch Scenario
Sample Topology and Configuration
Authentication Servers
Understanding Authentication Server Best Practices and Exceptions
Understanding Servers and Server Groups
Configuring Authentication Servers
Managing the Internal Database
Configuring Authentication Timers
Authentication Server Load Balancing
MAC-based Authentication
Configuring MAC-Based Authentication
AOS-W 6.5.3.x
| User Guide
178
212
157
161
Contents | 5
6 | Contents
Branch Switch Config for Cloud Services Switches
Scalable Site-to-Site VPN Tunnels
Layer-3 Redundancy for Branch Switch Masters
WAN Failure (Authentication) Survivability
WAN Optimization through IP Payload Compression
Branch Integration with a Palo Alto Networks (PAN) Portal
Branch Switch Routing Features
Using Smart Config to create a Branch Config Group
Preventing WAN Link Failure on Virtual APs
802.1X Authentication
Understanding 802.1X Authentication
Configuring 802.1X Authentication
Enabling 802.1X Supplicant Support on an AP
Performing Advanced Configuration Options for 802.1X
Application Single Sign-On Using L2 Authentication
Device Name as User Name for Non-802.1X Authentication
Stateful and WISPr Authentication
Working With Stateful Authentication
Working With WISPr Authentication
Understanding Stateful Authentication Best Practices
215
259
291
AOS-W 6.5.3.x | User Guide
Configuring Stateful 802.1X Authentication
Configuring Stateful NTLM Authentication
Configuring Stateful Kerberos Authentication
Configuring WISPr Authentication
Certificate Revocation
Configuring the Switch as an OCSP Client
Configuring the Switch as a CRL Client
Configuring the Switch as an OCSP Responder
Certificate Revocation Checking for SSH Pubkey Authentication
OCSP Configuration for AOS-W VIA
Captive Portal Authentication
Configuring Captive Portal in the Base Operating System
Using Captive Portal with a PEFNG License
Sample Authentication with Captive Portal
Configuring Captive Portal Authentication Profiles
Enabling Optional Captive Portal Configurations
Personalizing the Captive Portal Page
Creating and Installing an Internal Captive Portal
Enabling Captive Portal Enhancements
Netdestination for AAAA Records
Virtual Private Networks
Working with VPN Authentication Profiles
Configuring a Basic VPN for L2TP/IPsec
Configuring a VPN for L2TP/IPsec with IKEv2
AOS-W 6.5.3.x
| User Guide
306
346
298
Contents | 7
8 | Contents
Configuring a VPN for Smart Card Clients
Configuring a VPN for Clients with User Passwords
Configuring Remote Access VPNs for XAuth
Working with Remote Access VPNs for PPTP
Working with Site-to-Site VPNs
Roles and Policies
Understanding Global Firewall Parameters
ClearPass Policy Manager Integration
Enabling Downloadable Role on a Switch
Virtual APs
Virtual AP Configuration Workflow
Changing a Virtual AP Forwarding Mode
Radio Resource Management (802.11k)
BSS Transition Management (802.11v)
Fast BSS Transition ( 802.11r)
Changing a Virtual AP Forwarding Mode
402
411
375
AOS-W 6.5.3.x | User Guide
Adaptive Radio Management
ARM Coverage and Interference Metrics
Assigning an ARM Profile to an AP Group
Using Multi-Band ARM for 802.11a/802.11g Traffic
Reusing Channels to Control RX Sensitivity Tuning
Configuring Non-802.11 Noise Interference Immunity
Wireless Intrusion Prevention
Working with the Reusable Wizard
Working with Intrusion Detection
Configuring Intrusion Protection
Configuring the WLAN Management System
Understanding Client Blacklisting
Working with WIP Advanced Features
AOS-W 6.5.3.x
| User Guide
450
474
Contents | 9
10 | Contents
Access Points
Understanding AP Configuration Profiles
Enable DHCP to Provide APs with IP Addresses
Optional AP Configuration Settings
Optimizing APs Over Low-Speed Links
Configuring AP Channel Assignments
Link Aggregation Support on OAW-AP220 Series, OAW-AP270 Series, and OAW-AP320 Series
Recording Consolidated AP-Provisioned Information
Secure Enterprise Mesh
Understanding Mesh Access Points
Understanding Remote Mesh Portals (RMPs)
Understanding the AP Boot Sequence
509
595
AOS-W 6.5.3.x | User Guide
Configuring Mesh Cluster Profiles
Creating and Editing Mesh Radio Profiles
Creating and Editing Mesh High-Throughput SSID Profiles
Configuring Ethernet Ports for Mesh
Configuring Remote Mesh Portals (RMPs)
Increasing Network Uptime Through Redundancy and VRRP
High Availability Deployment Models
High Availability Inter-Switch Heartbeats
High Availability Extended Switch Capacity
Migrating from VRRP or Backup-LMS Redundancy
RSTP
Understanding RSTP Migration and Interoperability
Working with Rapid Convergence
PVST+
Understanding PVST+ Interoperability and Best Practices
AOS-W 6.5.3.x
| User Guide
651
655
633
Contents | 11
12 | Contents
Link Layer Discovery Protocol
IP Mobility
Understanding Alcatel-Lucent Mobility Architecture
Configuring Advanced Mobility Functions
Understanding Bridge Mode Mobility Deployments
External Firewall Configuration
Understanding Firewall Port Configuration Among Alcatel-Lucent Devices
Ports Used for Virtual Intranet Access (VIA)
Configuring Ports to Allow Other Traffic Types
PAPI Enhanced Security
Configuring PAPI Enhanced Security
Verifying PAPI Enhanced Security
Palo Alto Networks Firewall Integration
Preconfiguration on the PAN Firewall
Configuring PAN Firewall Integration
Remote Access Points
Configuring the Secure Remote Access Point Service
Deploying a Branch/Home Office Solution
695
689
684
687
657
663
AOS-W 6.5.3.x | User Guide
Enabling Remote AP Advanced Configuration Options
Provisioning 4G USB Modems on Remote Access Points
Configuring OAW-RAP3WN and OAW-RAP3WNP Access Points
Converting an IAP to RAP or CAP
Enabling Bandwidth Contract Support for RAPs
Virtual Intranet Access
Spectrum Analysis
Understanding Spectrum Analysis
Creating Spectrum Monitors and Hybrid APs
Connecting Spectrum Devices to the Spectrum Analysis Client
Configuring the Spectrum Analysis Dashboards
Customizing Spectrum Analysis Graphs
Working with Non-Wi-Fi Interferers
Understanding the Spectrum Analysis Session Log
Viewing Spectrum Analysis Data
Recording Spectrum Analysis Data
Troubleshooting Spectrum Analysis
Dashboard Monitoring
AOS-W 6.5.3.x
| User Guide
748
749
794
Contents | 13
14 | Contents
Management Access
Configuring Certificate Authentication for WebUI Access
Enabling RADIUS Server Authentication
Connecting to an OmniVista Server
Custom Certificate Support for RAP
Implementing a Specific Management Password Policy
Configuring Centralized Image Upgrades
ClearPass Profiling with IF-MAP
833
AOS-W 6.5.3.x | User Guide
802.11u Hotspots
Hotspot Profile Configuration Tasks
Configuring Hotspot 2.0 Profiles
Configuring Hotspot Advertisement Profiles
Configuring ANQP Venue Name Profiles
Configuring ANQP Network Authentication Profiles
Configuring ANQP Domain Name Profiles
Configuring ANQP IP Address Availability Profiles
Configuring ANQP NAI Realm Profiles
Configuring ANQP Roaming Consortium Profiles
Configuring ANQP 3GPP Cellular Network Profiles
Configuring H2QP Connection Capability Profiles
Configuring H2QP Operator Friendly Name Profiles
Configuring H2QP Operating Class Indication Profiles
Configuring H2QP WAN Metrics Profiles
Configuring H2QP OSU Provider List Profiles
Adding Local Switches
Moving to a Multi-Switch Environment
Uplink Monitoring and Management
Voice and Video
Voice and Video License Requirements
Working with QoS for Voice and Video
Unified Communication and Collaboration
Understanding Extended Voice and Video Features
Advanced Voice Troubleshooting
AOS-W 6.5.3.x
| User Guide
892
920
927
Contents | 15
16 | Contents
AirGroup
AirGroup Integrated Deployment Model
Features Supported in AirGroup
ClearPass Policy Manager and ClearPass Guest Features
Auto-association and Switch-based Policy
Best Practices and Limitations
Configuring the AirGroup-CPPM Interface
Bluetooth-Based Discovery and AirGroup
mDNS Multicast Response Propagation
Troubleshooting and Log Messages
Instant AP VPN Support
External Services Interface
Understanding the ESI Syslog Parser
Sample Route-Mode ESI Topology
Understanding Basic Regular Expression (BRE) Syntax
External User Management
1038
1046
994
1069
AOS-W 6.5.3.x | User Guide
Behavior and Defaults
Understanding Basic System Defaults
Understanding Default Management User Roles
Understanding Default Open Ports
DHCP with Vendor-Specific Options
Configuring a Windows-Based DHCP Server
Enabling DHCP Relay Agent Information Option (Option-82)
802.1X Configuration for IAS and Windows Clients
Configuring Management Authentication using IAS
Window XP Wireless Client Sample Configuration
Glossary of Terms
1109
1116
1102
1086
AOS-W 6.5.3.x
| User Guide Contents | 17
Revision History
The following table lists the revisions of this document.
Table 1: Revision History
Revision
Revision 02
Change Description
Updated acronyms in the
ClearPass Policy Manager Integration
chapter.
Revision 01 Initial release.
18 | Contents AOS-W 6.5.3.x | User Guide
About this Guide
This User Guide describes the features supported in AOS-W 6.5.3.x and provides instructions and examples to configure switches and access points (APs). This guide is intended for system administrators responsible for configuring and maintaining wireless networks and assumes administrator knowledge in Layer 2 and Layer 3 networking technologies.
This chapter covers the following topics: n n n n n
What's New In AOS-W 6.5.x on page 19
What's New In AOS-W 6.5.x
This section lists the new features and enhancements introduced in AOS-W 6.5.x.
Features in AOS-W 6.5.3.0
The following features are introduced in AOS-W 6.5.3.0:
Table 2: New Features in AOS-W 6.5.3.0
Feature
Description
Starting with AOS-W 6.5.3.0, users can specify the source IP address of
AMON packets emitted from the switch.
Starting with AOS-W 6.5.3.0, users can predefine the AP mode using the
AP deployment policy. The AP deployment policy redirects all APs in the specified IP address ranges to the Instant discovery process, ensuring that the APs run only in switch-less mode.
Starting with AOS-W 6.5.3.0, switches provide device certificate for APs that do not have a TPM chip. The factory certificate of the AP is validated against the device certificate stored on the switch.
AOS-W 6.5.3.x
| User Guide About this Guide | 19
Features in AOS-W 6.5.2.0
The following features are introduced in AOS-W 6.5.2.0:
Table 3: New Features in AOS-W 6.5.2.0
Feature
Description
Starting with AOS-W 6.5.2.0, APs can run in either switch-based mode or switch-less mode. Based on the selected mode, the AP runs a different image: n n
Switch-based APs run an AOS-W image.
Switch-less APs run an Instant image.
The AP Health check feature uses ping probes to check reachability and latency levels for the connection between the AP and the switch. The recorded latency information appears in the output of the show ap ip health-check command. If the switch IP address becomes unreachable from the AP uplink, this feature records the time that the connection failed, and saves that information in a log file.
Starting with AOS-W 6.5.2.0, dynamic data for the included attributes in the
RADIUS Attribute modifier is supported. Users can configure the dynamic value for each included attribute in the RADIUS modifier.
This feature allows the AP to seamlessly switch between modes where the radio resources are either combined in a single 2x2 radio (2.4 GHz or 5
GHz), or separated in two 1x1 radios (2.4 GHz and 5 GHz).
Starting with AOS-W 6.5.2.0, inline monitoring feature is supported for
Remote APs.
Starting with AOS-W 6.5.2.0, the Roaming RADIUS Accounting Service feature offers tracking a wireless client who roams to a different AP.
Starting with AOS-W 6.5.2.0, a user has the option of specifying the source
IP for a TACACS server.
Starting with AOS-W 6.5.2.0, APs can monitor BLE asset tags to track the location of time-sensitive, high-value assets embedded with BLE tags.
Starting with AOS-W 6.5.2.0, IPM is supported in OAW-AP303H access points.
When AirMatch monitoring is enabled in the AP system profile, each AP measures its RF environment every 30 minutes by default. The switch uses this information to analyze its RF neighborhood, and can send this information in AMON messages.
The Smart Antenna setting is introduced to support the smart antenna feature on the OAW-AP335, which optimizes the selection of antenna polarization values.
Starting with AOS-W 6.5.2.0, the centralized licensing feature supports topologies where a licensing master is connected to a standalone master licensing client switch, a redundant licensing server, and a local licensing client switch.
20 | About this Guide AOS-W 6.5.3.x | User Guide
Table 3: New Features in AOS-W 6.5.2.0
Feature
Transmit Power Calculation support
Description
Starting from AOS-W 6.5.2.0 introduces the option of configuring syslog messages to originate from any IP other than the switch IP.
Starting with AOS-W 6.5.2.0, PSK RAPs support IKEv1 SHA-2 cryptographic hash function.
Starting with AOS-W 6.5.2.0, this feature allows calculation of the transmit power of each outgoing 802.11 packet so that AP adheres to the latest regulatory limits.
AOS-W 6.5.3.x
| User Guide About this Guide | 21
Table 4: New Hardware Platforms in AOS-W 6.5.2.0
Check with your local Alcatel-Lucent sales representative on new switches and APs available in your country.
Hardware
OAW-AP203H Access Point
OAW-AP203R Series Remote
Access Points
OAW-AP303H Access Point
Description
The OAW-AP203H access point is an IEEE 802.11ac standard highperformance flex-radio wireless device ideal for hospitality and branch deployments. The AP is software configurable as either a single radio dual band or dual radio. MIMO technology allows the AP to deliver highperformance 802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a, b, and g wireless services. The AP works in conjunction with a switch.
The AP provides the following capabilities: n IEEE 802.11a, b, g, n, or ac operation as a wireless access point n n
IEEE 802.11a, b, g, n, or ac operation as a wireless air monitor
Compatible with IEEE 802.3af PoE n Centralized management configuration
For technical specifications, see the OAW-AP203H Access Point data sheet. For installation instructions, see the OAW-AP203H Access Point
Installation Guide .
The OAW-AP203R Series (OAW-AP203R and OAW-AP203RP) Remote APs are IEEE 802.11ac standard high-performance Remote APs ideal for home and branch deployments. MIMO technology allows these Remote APs to deliver high-performance 802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a, b, and g wireless services.
The Remote APs work in conjunction with a switch.
The Remote APs provides the following capabilities: n n
IEEE 802.11a, b, g, n, or ac operation as a wireless access point
IEEE 802.11a, b, g, n, or ac operation as a wireless air monitor n n n n
Compatible with IEEE 802.3at PoE
Centralized management configuration
Support for PoE-in (E0 port)/PoE-out (E2 port)
Support for selected USB peripherals n Integrated BLE radio
For technical specifications, see the OAW-AP203R Series Remote Access
Points data sheet. For installation instructions, see the OAW-AP203R Series
Remote Access Points Installation Guide .
The OAW-AP303H access point is an IEEE 802.11ac standard highperformance wireless device ideal for hospitality and branch deployments. MIMO technology allows the AP to deliver high-performance
802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting
802.11a, b, and g wireless services. The AP works in conjunction with a switch.
The AP provides the following capabilities: n IEEE 802.11a, b, g, n, or ac operation as a wireless access point n n n n
IEEE 802.11a, b, g, n, or ac operation as a wireless air monitor
Compatible with IEEE 802.3af PoE and 802.3at PoE+
Centralized management configuration
Support for PoE-in (E0 port)/PoE-out (E3 port) n n
Support for selected USB peripherals
Integrated BLE radio
For technical specifications, see the OAW-AP303H Access Point data sheet. For installation instructions, see the OAW-AP303H Access Point
Installation Guide .
22 | About this Guide AOS-W 6.5.3.x | User Guide
Table 4: New Hardware Platforms in AOS-W 6.5.2.0
Check with your local Alcatel-Lucent sales representative on new switches and APs available in your country.
Hardware
OAW-AP360 Series Outdoor
Access Points
Description
The OAW-AP360 Series (OAW-AP365 and OAW-AP367) outdoor APs support IEEE 802.11ac standard for high performance WLAN, and are equipped with two radios, which provide network access and monitor the network simultaneously. MIMO technology allows these APs to deliver high-performance 802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a, b, and g wireless services. The outdoor APs work in conjunction with a switch.
The outdoor APs provide the following capabilities: n IEEE 802.11a, b, g, n, or ac operation as a wireless access point n n n n n
IEEE 802.11a, b, g, n, or ac operation as a wireless air monitor
IEEE 802.11a, b, g, n, or ac spectrum monitor
Compatible with IEEE 802.3af PoE
Centralized management configuration
Integrated BLE Radio
For technical specifications, see the OAW-AP360 Series Outdoor Access
Points data sheet. For installation instructions, see the OAW-AP360 Series
Outdoor Access Points Installation Guide .
Features Introduced in AOS-W 6.5.1.0
The following features are introduced in AOS-W 6.5.1.0:
Table 5: New Features in AOS-W 6.5.1.0
Feature
Description
Starting with AOS-W 6.5.1.0, any-any selectors are negotiated in IKEv1 to enable the option of having numerous tunnels.
Branch Office Switch Support for Jumbo Frames
Starting with AOS-W 6.5.1.0, use the branch office switch Smart Config feature to enable or disable jumbo Ethernet frames on branch office switch ports.
Clarity Synthetic is supported for the following AP platforms: n OAW-AP207 Series access point n n
OAW-AP300 Series access points
OAW-AP310 Series access points n n
OAW-AP320 Series access points
OAW-AP330 Series access points
Starting with AOS-W 6.5.1.0, a new management role, Standard role, is supported which has all the root privileges but cannot make changes to the management users.
Starting with AOS-W 6.5.1.0, Option-82 can be customized to cater to the requirements of any Internet Service Provider (ISP) using the Alcatel-Lucent switch. To facilitate customization using a XML definition, multiple parameters for Circuit ID and Remote ID options of DHCP Option-82 have been introduced.
AOS-W 6.5.3.x
| User Guide About this Guide | 23
Table 5: New Features in AOS-W 6.5.1.0
Feature
Description
The users can now configure RADIUS modifier profile to customize the attributes that are included, excluded and modified in the RADIUS request before it is sent to the authentication server. The RADIUS modifier profile can be configured and applied to either Access- Request or Accounting-
Request or both on a RADIUS authentication server.
High Availability on the Backup
Starting with AOS-W 6.5.1.0, high availability is supported on the backup
LMS.
The Hotspot feature includes several enhancements.
n
A new Hotspot 2.0 Query Protocol (H2QP)
defines the list of Online Sign-Up (OSU) providers to be sent in the
ANQP IE. If a customer device cannot find a service from a known operator, the device receives a notification from the hotspot that additional Online Signup services are available.
n n n
The
is enhanced to support a service provider's network QoS by
mapping the service provider's Layer-3 QoS priorities
(defined via DHCP ) to an over-the-air Layer 2 priority.
The
is enhanced to send WNM notification requests to clients when the authentication server request it. Those WNM notification requests allow the hotspot feature to send clients the URLs of servers that allow the client to access information about how to
,
correct connection errors , or
.
The Hotspot 2.0 profile also allows network administrators to specify if the hotspot uses
an OSU Server-only authenticated layer 2 Encryption
. This network type is then dedicated to provisioning clients using the OSU functionality.
Intelligent Power Monitoring (IPM) is a feature that actively measures the power utilization of an AP and dynamically adapts to the power resources.
Whenever a new client joins the network, a unicast or a multicast Router
Advertisements (RA) is sent to from the router to the client. If it is a multicast packet then existing clients also receive the RA, which results in increasing the traffic. Starting with AOS-W 6.5.1.0, this issue is addressed by enabling IPv6 proxy RA to snoop incoming unsolicited Router
Advertisement and Router Solicitations packets.
Frame drop counters are used by APs to track frame loss when sending/receiving data packets. The AP records when the frames are dropped and compiles the stats, allowing clients to monitor frame loss within individual queques.
Starting with AOS-W 6.5.1.0, the High Availability Alerting feature is introduced to enable the switch provide the high availability status information to customers.
When an AP identifies a device, randomized MAC addresses advertised by the device will be filtered from those associated with the network. The MAC address associated with the network will be displayed in the RSSI report, while the unassociated addresses are excluded.
Starting with AOS-W 6.5.1.0, XLP-based switches are supported with null encryption for IKEv1 as an encryption algorithm. This helps in reducing the load on the local router for internet destined traffic.
24 | About this Guide AOS-W 6.5.3.x | User Guide
Table 5: New Features in AOS-W 6.5.1.0
Feature
Description
The PAPI Enhanced Security configuration provides protection to Alcatel-
Lucent devices, OmniVista, Mobility Access Switches, HP Switches, and
ALE against malicious users sending fake messages that results in security challenges.
QoS Enhancements
AOS-W 6.5.1.0 introduces the following enhanced traffic QoS features: n
QoS for AP Management Traffic : Management traffic on the AP can now
be marked with Differentiated Service Code Point (DSCP) values in the
AP system profile, to apply a priority level to AP management traffic.
n n
DSCP to 802.1P mapping : The AP system profile is also enhanced to
map DSCP QoS priorities to 802.1p priorities at the AP's media access control (MAC) level.
Extensible Authentication Protocol (EAP) traffic can be assigned to a specific Wi-Fi Multimedia (WMM) traffic class via the AP's SSID profile by enabling the WMM Access Class of
EAP traffic parameter in the WLAN SSID profile. By default, EAP traffic is mapped to the default "best effort" traffic class.
The switches perform load balancing of RADIUS accounting packets that are destined to external RADIUS Servers to ensure accounting load gets distributed.
AOS-W 6.5.1.0 supports Spectrum Analysis on OAW-AP300 Series access points.
New RADIUS VSAs are introduced to support the traffic steering and
Hotspot 2.0 features.
The ARM traffic steering feature encourages clients that support both Wi-Fi and 3G/4G cellular connections to move from a Wi-Fi connection to a cellular connection when the device moves out of a Wi-Fi coverage area, or when the Wi-Fi connection supports lower data rates than the cellular connection. ARM traffic steering prevents clients that have been disassociated from the network from reassociating for a customizable blackout interval. ARM traffic steering is disabled by default.
iOS mobile devices such as an iPhone, iPad, or iPod automatically blacklist an SSID if that device receives more than two deauthentication message within a five-minute period. To protect iOS devices from blacklisting an
SSID due to repeated traffic steering attempts, AOS-W limits the number of traffic steering attempts for these devices to no more than one steering attempt every five minutes.
AOS-W 6.5.1.0 supports WAN optimization through IP payload compression in OAW-4450 switches.
If one or more subscription WebCC licenses expire so that a switch has fewer active WebCC subscription licenses than AP licenses, that switch will no longer be able to download WebCC updates from the cloud or perform classification using cloud lookup.
AOS-W 6.5.3.x
| User Guide About this Guide | 25
Table 6: New Hardware Platforms in AOS-W 6.5.1.0
Hardware
OAW-AP207 Series
Description
OAW-AP207 Series access point supports IEEE 802.11ac standards for high-performance WLAN, and is equipped with a dual 2x2 radio. Multiple-
Input Multiple-Output (MIMO) technology allows the AP to deliver highperformance 802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a/b/g wireless services. OAW-AP207 Series access point works in conjunction with a switch.
OAW-AP207 Series access point provides the following capabilities: n
Wireless transceiver n n n n
IEEE 802.11a/b/g/n/ac operation as a wireless access point
IEEE 802.11a/b/g/n/ac operation as a wireless air monitor
Compatibility with IEEE 802.3af Power over Ethernet (PoE)
Centralized management configuration and upgrade n Integrated Bluetooth Low Energy (BLE) radio
For more information, see the OAW-AP207 Series Access Points Installation
Guide .
OAW-AP300 Series
APM-210
The OAW-AP300 Series (OAW-AP304 and OAW-AP305) access points support IEEE 802.11ac standards for high-performance WLAN, and are equipped with a dual 2x2 radio on 2.4 GHz and 3x3 radio on 5 GHz, which provide network access and monitor the network simultaneously. These
APs deliver high-performance 802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a/b/g wireless services. Multi-
User Multiple-Input Multiple-Output (MU-MIMO) is enabled when operating in 5 GHz mode for optimal performance. The OAW-AP300
Series access points work in conjunction with a switch.
The OAW-AP300 Series access points provide the following capabilities: n IEEE 802.11a/b/g/n/ac operation as a wireless access point n n n n n
IEEE 802.11a/b/g/n/ac operation as a wireless air monitor
IEEE 802.11a/b/g/n/ac spectrum monitor
Compatible with IEEE 802.3af PoE and IEEE 802.3at PoE+
Centralized management configuration and upgrade
Integrated BLE radio
For more information, see the OAW-AP300 Series Access Points Installation
Guide .
AOS-W 6.5.1.0 introduces the support for the APM-210, a highperformance dual-radio 3x3:3 MIMO 802.11ac wireless Access Point
Module (APM).
This product enhances the Ericsson Pico Radio Base Station by enabling
Wi-Fi access as an add-on to indoor WCDMA or 3GPP cellular coverage.
26 | About this Guide AOS-W 6.5.3.x | User Guide
Features Introduced in AOS-W 6.5.0.0
The following features are introduced in AOS-W 6.5.0.0:
Table 7: New Features in AOS-W 6.5.0.0
Feature Description
App and App Category Visibility
Starting with AOS-W 6.5.0.0, a Branch switch classifies traffic into multiple priorities and shapes the egress traffic to match the actual upstream bandwidth.
Starting with AOS-W 6.5.0.0, the AppRF page in Dashboard has been renamed to Traffic Analysis .
Blocked Sessions is a newly added tab that displays WebCC and AppRF sessions which are blocked by ACL through system logging or on the WebUI interface.
The cellular handoff assist feature can help a dual-mode, 3G/4G-capable
Wi-Fi device such as an iPhone, iPad, or Android client at the edge of Wi-Fi network coverage switch from Wi-Fi to an alternate 3G/4G radio that provides better network access. This setting can now be applied to individual virtual APs via the wlan virtual-ap profile.
AOS-W 6.5.0.0 introduces the following enhancements to the centralized licensing feature:
Support for the Web Content Classification (WebCC) license. This license is a subscription-based, per-AP license that supports web content classification features on an AP for the duration of the subscription period
(up to 10 years per license).
Support for multi-version licensing, which allows centralized licensing clients to run a different version of AOS-W than the primary and backup licensing servers. If a license is introduced in a newer version of AOS-W, the primary and backup licensing servers set can still distribute licenses to licensing clients running an older version of AOS-W, even if the licensing client does not recognize the newer license type.
Support for multiple master/local domains; topologies where multiple master switches have one or more attached local switches.
Clarity Synthetic enables the switch to select and convert any OAW-AP200
Series access point to client mode. The converted AP acts like a WiFi client and starts synthetic data transaction within the network to monitor and detect the network health.
Central or any other cloud solution can manage branch switches, access points, user/device profiles, and/or services (UCC, AppRF, FW and so on) over ZTP or Activate server.
The OCSP configuration for AOS-W VIA is simplified with four parameters removed: OCSP responder's URL for IKE, OCSP responder's CN for IKE,
OCSP responder's URL for EAP, OCSP responder's CN for EAP. New parameter to enable OCSP responder is added to the aaa authentication via connection-profile command and corresponding change in the WebUI is done.
Starting with AOS-W 6.5.0.0, if the number of MAC addresses exceeds the maximum limit set for the port, you can configure appropriate options so that the new MAC entries are dropped and a warning message is logged in syslog. The values for level of security and auto-recovery interval (in seconds) can also be set.
AOS-W 6.5.3.x
| User Guide About this Guide | 27
Table 7: New Features in AOS-W 6.5.0.0
Feature
Description
AOS-W 6.5.0.0 introduces the support for customizing authentication
Reply-Message to captive portal users in the log-in page for better user experience. The purpose behind the Reply-Message is to return appropriate information to the captive portal system.
IP Classification Based Firewall
Remote Telnet or SSH Session from the Switch
A new parameter is introduced to use the host name of a device as the user name (instead of the MAC address) of the device when a client is authenticated by non-802.1X method of authentication.
A new command is introduced to provide an ability to lock down all console ports, for example, micro USB, mini USB on the switch to enable high level security.
This feature provides capability for ARM to move to another 80 MHz channel or downgrade to 40MHz dynamically.
A new parameter is introduced to enable PortFast/PortFast on Trunk to reduce the time taken for wired clients connected to an AP to detect the link before they send data traffic.
HP TPM based switches can now inter-operate with the Alcatel-Lucent switches and create the IKE / IPSec tunnels.
AOS-W supports the functionality where the non- Alcatel-Lucent devices can fragment the large IKE_AUTH packets using the standards described in the RFC 7383 – Internet Key Exchange Protocol Version 2 (IKEv2) message fragmentation when the Alcatel-Lucent device acts as a responder and not as an initiator.
This enhancement is introduced to resolve issues that occur with distributed channel/power algorithm, random channel assignment, and reduction in interference channel.
The IP-Classification Based Firewall has been introduced to block traffic sent or received from those IP addresses classified as malicious. It also helps in identifying the geographical location of the malicious IP address.
This features assists in monitoring bandwidth usage by clients/hosts with
IPv6 addresses, over radius protocol. This information is used for billing purpose.
This features allows Captive Portal whitelist to support IPv6 addresses for netdestination.
This feature enables an Alcatel-Lucent switch to act as an NTP server so that the devices that do not have access to internet can synchronize their clocks.
Starting with AOS-W 6.5.0.0, the switch stores the consolidated APprovisioned information for all APs connected to the switch in a .txt file.
This information helps troubleshoot any AP that does not come UP after an upgrade from AOS-W 6.5.0.0 to a later AOS-W version.
Starting with AOS-W 6.5.0.0, an administrator can initiate a remote telnet or SSH session from the switch to a remote host. The host can be a switch or a non-Alcatel-Lucent host.
28 | About this Guide AOS-W 6.5.3.x | User Guide
Table 7: New Features in AOS-W 6.5.0.0
Feature
Description
The secondary master switch feature in AOS-W 6.5.0.0 provides seamless connectivity by allowing an access point to terminate on a secondary master switch in the event of the master switch failing.
Starting with AOS-W 6.5.0.0, the smart config which is used to manage branch switches has been enhanced to allow a vlan to get an IP address using DHCP. To configure the vlan the dhcp-client and dhcp-pool parameters are introduced in the User VLANs table.
Starting with AOS-W 6.5.0.0, the ZTP feature is enhanced to support 16
VLANs (Static IP Management) per managed node as against just four in the earlier versions of AOS-W.
This new feature allows switches to accept the subnets published by AOS-
W VIA clients. This feature is disabled by default.
AOS-W 6.5.0.0 supports Wi-Fi Calling in the switch. Wi-Fi calling service allows cellular users to make or receive calls using a Wi-Fi network instead of using the carrier’s cellular network.
AOS-W 6.5.3.x
| User Guide About this Guide | 29
Table 8: New Hardware Platforms in AOS-W 6.5.0.0
Hardware
OAW-AP310 Series
Description
The OAW-AP310 Series (OAW-AP314 and OAW-AP315) wireless access points support IEEE 802.11ac standards for a high-performance WLAN.
This device is equipped with two single-band radios that provide network access and monitor the network simultaneously. OAW-AP310 Series access points deliver high-performance 802.11n 2.4 GHz and 802.11ac 5
GHz functionality, while also supporting 802.11a/b/g wireless services.
Multi-User Multiple-Input Multiple-Output (MU-MIMO) is enabled when operating in 5 GHz mode for optimal performance. The OAW-AP310
Series wireless access points work in conjunction with a switch and provides the following capabilities: n n
IEEE 802.11a/b/g/n/ac wireless access point
IEEE 802.11a/b/g/n/ac wireless air monitor n n n n
IEEE 802.11a/b/g/n/ac spectrum monitor
Compatible with IEEE 802.3at and 802.3af PoE
Support for MCS8 and MCS9
Centralized management, configuration, and upgrades n Integrated Bluetooth Low Energy (BLE) radio
For more information, see the OAW-AP310 Series Wireless Access Point
Installation Guide .
OAW-AP330 Series The OAW-AP330 Series (OAW-AP334 and OAW-AP335) wireless access points support IEEE 802.11ac standards for high-performance WLAN. This device is equipped with two dual-band radios, which provide network access and monitor the network simultaneously. This access point delivers high-performance 802.11n 2.4 GHz and 802.11ac 5 GHz functionality, while also supporting 802.11a/b/g wireless services. Multi-User Multiple-
Input Multiple-Output (MU-MIMO) is enabled when operating in 5 GHz mode for optimal performance. The OAW-AP330 Series wireless access points work in conjunction with a switch.
The OAW-AP330 Series wireless access points provides the following capabilities: n IEEE 802.11a/b/g/n/ac wireless access point n n n n
IEEE 802.11a/b/g/n/ac wireless air monitor
IEEE 802.11a/b/g/n/ac spectrum monitor
Compatible with IEEE 802.3at power sources
Centralized management, configuration, and upgrades n Integrated Bluetooth Low Energy (BLE) radio
For more information, see the OAW-AP330 Series Wireless Access Point
Installation Guide .
Table 9: Deprecated Hardware Platforms in AOS-W 6.5.0.0
Hardware
Hardware Models Not Supported from AOS-
W 6.5.0.0
OAW-AP120 Series OAW-AP120, OAW-AP121, OAW-AP124, and OAW-
AP125 access points
OAW-4306 Series switches OAW-4306, OAW-4306G, and switches
OAW-4x04 Series switches OAW-4504XM, OAW-4604, and OAW-4704 switches
OAW-S3 and OAW-6000 switches
OAW-S3 and OAW-6000 switches
Last Supported Release
AOS-W 6.4.4.x
AOS-W 6.4.4.x
AOS-W 6.4.4.x
AOS-W 6.4.4.x
30 | About this Guide AOS-W 6.5.3.x | User Guide
Fundamentals
Configure your switch and AP using either the Web User Interface (WebUI) or the Command Line Interface
(CLI).
WebUI
Each switch supports up to 320 simultaneous WebUI connections. The WebUI is accessible through a standard
Web browser from a remote management console or workstation. The WebUI includes configuration wizards that walk you through easy-to-follow configuration tasks. The wizards are: n n n n n n
AP—basic AP configuration
Switch—basic switch configuration
Campus WLAN—create and configure new WLAN(s) associated with the “default” ap-group
Remote AP—basic Remote AP configuration
WIP—define Wireless Intrusion Protection (WIP) policy
AirWave—switches running AOS-W 6.3 and later can use the OmniVista wizard to quickly and easily connect the switch to an OmniVista server.
In addition to the wizards, the WebUI includes a dashboard that provides enhanced visibility into your wireless network’s performance and usage. This allows you to easily locate and diagnose WLAN issues. For details on the WebUI Dashboard, see
CLI
The CLI is a text-based interface accessible from a local console connected to the serial port on the switch or through a Telnet or Secure Shell (SSH) session.
By default, you can access the CLI from the serial port or from an SSH session. You must explicitly enable Telnet on your switch in order to access the CLI via a Telnet session.
When entering commands remember that: n n n n commands are not case sensitive the space bar or tab key completes your partial keyword the backspace key erases your entry one letter at a time the question mark ( ? ) lists available commands and options
Remote Telnet or SSH Session from the Switch
Starting from AOS-W 6.5, an administrator can initiate a remote telnet or SSH session from the switch to a remote host. The host can be a switch or a non-Alcatel-Lucent host.
This feature is supported from the SSH session of the switch.
To initiate a telnet session from the switch to a remote host:
1. Initiate an SSH session to the switch.
2. In the enable mode, execute the telnet <user> <remote-host> [<port-num>] command.
user : User name of the remote host.
remote-host : IPv4 or IPv6 address of the remote host.
port-num : Telnet port number of the remote host. This is an optional parameter.
3. Once successfully connected, the remote host prompts the credentials. Enter the remote host credentials.
AOS-W 6.5.3.x
| User Guide About this Guide | 31
To initiate an SSH session from the switch to a remote host:
1. Initiate an SSH session to the switch.
2. In the enable mode, execute the ssh <user-at-host> command.
user-at-host : Username and IPv4 or IPv6 address of the remote host in the user@host format.
Once successfully connected, the remote host prompts the credentials.
3. Enter the remote host credentials.
To end the remote host session, execute the exit command. The remote host displays the following message:
(remote-host) #exit
Connection closed by foreign host.
(host) #
Limitations
This feature has few limitations. They are: n n n
This feature is supported from the SSH session of the switch only.
There is an inactivity timeout for the CLI sessions. When an administrator initiates a remote session (inner) from the switch’s SSH session (outer), and the remote session takes more time than the inactivity timeout session, the outer session times out although the inner session is active. The administrator has to log back in to the outer session once logged off from the inner session.
Designated telnet client control keys do not work for remote telnet sessions. When an administrator initiates a remote telnet session (inner) from the switch’s SSH session (outer), the designated telnet client control keys functions for the outer SSH session only. The administrator should designate unique control keys for each remote telnet sessions.
Related Documents
The following guides are part of the complete documentation for the Alcatel-Lucent user-centric network: n n n n n n
Alcatel-Lucent Switch Installation Guides
Alcatel-Lucent Access Point Installation Guides
AOS-W Quick Start Guide
AOS-W User Guide
AOS-W CLI Reference Guide
AOS-W Release Notes
Conventions
The following conventions are used throughout this document to emphasize important concepts:
32 | About this Guide AOS-W 6.5.3.x | User Guide
Table 10: Typographical Conventions
Type Style italics
Description
This style is used to emphasize important terms and to mark the titles of books.
system items commands
<arguments>
[optional]
This fixed-width font depicts the following: n n n
Sample screen output
System prompts
Filenames, software devices, and specific commands when mentioned in the text
In the command examples, this bold font depicts text that you must type exactly as shown.
In the command examples, italicized text within angle brackets represents items that you should replace with information appropriate to your specific situation. For example:
# send < text message >
In this example, you would type “send” at the system prompt exactly as shown, followed by the text of the message you wish to send. Do not type the angle brackets.
Command examples enclosed in brackets are optional. Do not type the brackets.
{Item A | Item
B}
In the command examples, items within curled braces and separated by a vertical bar represent the available choices. Enter only one choice. Do not type the braces or bars.
The following informational icons are used throughout this guide:
Indicates helpful suggestions, pertinent information, and important things to remember.
Indicates a risk of damage to your hardware or loss of data.
Indicates a risk of personal injury or death.
AOS-W 6.5.3.x
| User Guide About this Guide | 33
Contacting Support
Table 11: Contact Information
Contact Center Online
Main Site http://enterprise.alcatel-lucent.com
Support Site https://support.esd.alcatel-lucent.com
Email [email protected]
Service & Support Contact Center Telephone
North America 1-800-995-2696
Latin America
EMEA
Asia Pacific
Worldwide
1-877-919-9526
+800 00200100 (Toll Free) or +1(650)385-2193
+65 6240 8484
1-818-878-4507
34 | About this Guide AOS-W 6.5.3.x | User Guide
Chapter 1
The Basic User-Centric Networks
This chapter describes how to connect an Alcatel-Lucent switch and Alcatel-Lucent AP to your wired network.
After completing the tasks described in this chapter, see
for information on configuring APs.
This chapter describes the following topics: n n n n n n n n n
Understanding Basic Deployment and Configuration Tasks on page 35
Switch Configuration Workflow on page 38
Connect the Switch to the Network on page 39
OAW-40xx Series and OAW-4x50 Series Switches on page 40
Using the LCD Screen on page 42
Configuring a VLAN to Connect to the Network on page 45
Enabling Wireless Connectivity on page 49
Configuring Your User-Centric Network on page 49
Understanding Basic Deployment and Configuration Tasks
This section describes typical deployment scenarios and the tasks you must perform while connecting to a
Alcatel-Lucent switch and Alcatel-Lucent AP to your wired network. For details on performing the tasks mentioned in these scenarios, refer to the other procedures within the Basic User-Centric Networks section of this document.
Deployment Scenario #1: Switch and APs on Same Subnet
Figure 1 Switch and APs on Same Subnet
In this deployment scenario, the APs and switch are on the same subnetwork and will use IP addresses assigned to the subnetwork. The router is the default gateway for the switch and clients.There are no routers between the APs and the switch. APs can be physically connected directly to the switch. The uplink port on the switch is connected to a layer-2 switch or router.
For this scenario, you must perform the following tasks:
1. Run the initial setup wizard.
n
Set the IP address of VLAN 1.
AOS-W 6.5.3.x
| User Guide The Basic User-Centric Networks | 35
n
Set the default gateway to the IP address of the interface of the upstream router to which you will connect the switch.
2. Connect the uplink port on the switch to the switch or router interface. By default, all ports on the switch are access ports and will carry traffic for a single VLAN.
3. Deploy APs. The APs will use the Alcatel Discovery Protocol (ADP) to locate the switch.
4. Configure the SSID(s) with VLAN 1 as the assigned VLAN for all users.
Deployment Scenario #2: APs All on One Subnet Different from Switch Subnet
Figure 2 APs All on One Subnet Different from Switch Subnets
In this deployment scenario, the APs and the switch are on different subnetworks and the APs are on multiple subnetworks. The switch acts as a router for the wireless subnetworks (the switch is the default gateway for the wireless clients). The uplink port on the switch is connected to a layer-2 switch or router; this port is an access port in VLAN 1.
For this scenario, you must perform the following tasks:
1. Run the initial setup wizard.
36 | The Basic User-Centric Networks AOS-W 6.5.3.x | User Guide
n n
Set the IP address for VLAN 1.
Set the default gateway to the IP address of the interface of the upstream router to which you will connect the switch.
2. Connect the uplink port on the switch to the switch or router interface.
3. Deploy APs. The APs will use DNS or DHCP to locate the switch.
4. Configure VLANs for the wireless subnetworks on the switch.
5. Configure SSIDs with the VLANs assigned for each wireless subnetwork.
Each wireless client VLAN must be configured on the switch with an IP address. On the uplink switch or router, you must configure static routes for each client VLAN, with the switch’s VLAN 1 IP address as the next hop.
Deployment Scenario #3: APs on Multiple Different Subnets from Switches
Figure 3 APs on Multiple Different Subnets from Switches
In this deployment scenario, the APs and the switch are on different subnetworks and the APs are on multiple subnetworks. There are routers between the APs and the switch. The switch is connected to a layer-2 switch or router through a trunk port that carries traffic for all wireless client VLANs. An upstream router functions as the default gateway for the wireless users.
AOS-W 6.5.3.x
| User Guide The Basic User-Centric Networks | 37
This deployment scenario does not use VLAN 1 to connect to the layer-2 switch or router through the trunk port. The initial setup prompts you for the IP address and default gateway for VLAN 1; use the default values. In later steps, you configure the appropriate VLAN to connect to the switch or router as well as the default gateway.
For this scenario, you must perform the following tasks:
1. Run the initial setup.
n
Use the default IP address for VLAN 1. Since VLAN 1 is not used to connect to the layer-2 switch or router through the trunk port, you must configure the appropriate VLAN in a later step.
n
Do not specify a default gateway (use the default “none”). In a later step, you configure the default gateway.
2. Create a VLAN that has the same VLAN ID as the VLAN on the switch or router to which you will connect the switch. Add the uplink port on the switch to this VLAN and configure the port as a trunk port.
3. Add client VLANs to the trunk port.
4. Configure the default gateway on the switch. This gateway is the IP address of the router to which you will connect the switch.
5. Configure the loopback interface for the switch.
6. Connect the uplink port on the switch to the switch or router interface.
7. Deploy APs. The APs will use DNS or DHCP to locate the switch.
8. Now configure VLANs on the switch for the wireless client subnetworks and configure SSIDs with the VLANs assigned for each wireless subnetwork.
Switch Configuration Workflow
The tasks in deploying a basic user-centric network fall into two main areas: n n
Configuring and connecting the switch to the wired network (described in this section)
Deploying APs (described later in this section)
The following workflow lists the tasks to configure an Alcatel-Lucent switch. Click any of the links below for details on the configuration procedures for that task.
1. Connect the switch to the network.
2. Set the system clock. For more information, see
Setting the System Clock on page 885 .
3. View current licenses installed on the switch. For more information, see
Installing a License on page 91 .
4. For topologies similar to deploying access points on multiple different subnets from switches, see
Deployment Scenario #3: APs on Multiple Different Subnets from Switches on page 37
5. Configure a VLAN to the switch to your network. For more information see,
not need to perform this step if you are using VLAN 1 to connect the switch to the wired network.sasds.
6. The Switch IP address is used by the switch to communicate with external devices such as APs. For more information, see
Configuring the Switch IP Address on page 114
. Optionally, you can configure a loopback address for the switch. For more information, see
Configuring the Loopback IP Address on page 113
. You do not need to perform this step if you are using the VLAN 1 IP address as the switch’s IP address. Disable spanning tree on the switch if necessary.
7. Specify additional connectivity parameters for the switch to configure a trunk port between the switch and another layer-2 switch as shown in
Deployment Scenario #3: APs on Multiple Different Subnets from
Switches on page 37 For more information, see
Configuring a VLAN to Connect to the Network on page 45
.
Optionally, configure the primary and secondary uplinks. This step applies only if you have the redundant cellular link.
38 | The Basic User-Centric Networks AOS-W 6.5.3.x | User Guide
8. Configure ports for the switch. For more information, see
Configuring Ports on page 110 .
Connect the Switch to the Network
To connect the switch to the wired network, run the initial setup to configure administrative information for the switch.
Initial setup can be done using the browser-based Setup Wizard or by accessing the initial setup dialog via a serial port connection. Both methods are described in the AOS-W Quick Start Guide and are referred to throughout this chapter as “initial setup.”
This section describes the steps in detail.
Running Initial Setup
Connecting to the Switch After Initial Setup
After you complete the initial setup, the switch reboots using the new configuration. (See the
AOS-W Quick Start
n
(CLI). (Refer to Management Access on page 833
for information on how to access the CLI and enter configuration commands.)
You can connect an Ethernet cable from a PC to an Ethernet port on the switch. You can then use one of the following access methods: l l l
Use the VLAN 1 IP address to start an SSH session where you can enter CLI commands.
Enter the VLAN 1 IP address in a browser window to start the WebUI.
WebUI Wizards.
AOS-W 6.5.3.x
| User Guide The Basic User-Centric Networks | 39
This chapter and the user guide in general focus on CLI and standard WebUI configuration examples. However, basic switch configuration and WLAN/LAN creation can be completed using the alternative wizards from within the WebUI. If you wish to use a configuration wizard, navigate to Configuration > Wizards , click on the desired wizard, and follow the imbedded help instructions within the wizard.
OAW-40xx Series and OAW-4x50 Series Switches
The OAW-40xx Series and OAW-4x50 Series switches are new switch platforms introduced in conjunction with
AOS-W 6.4.x and 6.2, respectively. These switches provide new functionality and improved capabilities over previous switches. However, a OAW-40xx Series and OAW-4x50 Series switch also introduces some changes that you must keep in mind when adding it to your network.
New Port Numbering Scheme
The OAW-40xx Series and OAW-4x50 Series switches use a different port numbering scheme than older model switches. All other switch platforms use a slot/port numbering scheme. Both the OAW-40xx Series and OAW-
4x50 Series switches use slot/module/port instead.
It is important to consider this when migrating an older switch to either the OAW-40xx Series or OAW-4x50
Series. If you load a configuration from a switch, that switch will not have network connectivity because any interface configuration will not be recognized. For information about migrating to OAW-40xx Series and OAW-
4x50 Series switches, see the AOS-W 6.2 Release Notes .
OAW-4x50 Series Switches Individual Port Behavior
The first two ports on the OAW-4x50 Series switches, 0/0/0 and 0/0/1 are dual media ports and can be used for any purpose. Ports 0/0/2 through 0/0/5 are fiber-based ports that can be used for any purpose. If the fiberbased ports are connected with RJ45 or Small Form-factor Pluggable (SFP) transceivers, these ports can function as 1 GBps ports. For accessing the switch, port 0/0/0 to 0/0/5 can be used when 0/0/2 through 0/0/5 are connected with RJ45 or SFP transceivers.
The following table describes the connector and speed supported for each physical interfaces of the OAW-4x50
Series switches.
Table 12: OAW-4x50 Series Switches Ports
Port Type Ports
10/100/1000 BASE-T Dual Media
Ports
0/0/0-0/0/1
Connector Type
RJ45 or SFP
Speed
1 GBps
10G BASE-X 0/0/2-0/0/5
SFP+
RJ45 or SFP
10 GBps
1 GBps
Switch Port-Security MAC Address Limitation
Starting from AOS-W 6.5, the MAC address limitation, a port-security feature, is enhanced for the OAW-40xx
Series and OAW-4x50 Series Switches. You can enable or disable this functionality using the WebUI or the CLI.
In earlier versions of AOS-W, the option to configure the maximum number of MAC addresses that a port can support is available. The enhancement to this MAC address limitation feature in this release of AOS-W is that if the number of MAC addresses exceeds the maximum limit set for the port, the new MAC entries are dropped.
The switchport port-security command is enhanced to include parameters for setting the levels of security and autorecovery interval time. You can set appropriate values for the level parameter to log a warning
40 | The Basic User-Centric Networks AOS-W 6.5.3.x | User Guide
message Max bridge entries limit hit on the port # in syslog and/or to shut down the port. For level , the default value is logging.
When a port-security error occurs, the switch shuts down the port so that no traffic is received by the switch on this port. You can use the clear command to resolve the port-security error and bring UP the port.
In the WebUI
To configure the maximum number of MAC addresses for a port, perform the following steps:
1. Navigate to Configuration > NETWORK > Ports .
2. Under the Port Selection group, select a port.
3. Under the Configure Selected Port <slot/module/port> group box, enter a value for the Maximum number of mac address text box. The range of value you can configure for this option must be between
1 and 16,384.
4. Click Apply .
In the CLI
To enable the port-security feature on the switch, execute the following command:
(host) (config) #interface gigabitethernet 0/0/0
(host) (config-if) #switchport port-security maximum <num> where
<num> represents the maximum MAC address range for the port. You can set a value from 1 to 16,384.
You can set the level of security and autorecovery interval using the level and interval parameters, respectively.
(host) (config-if)#switchport port-security maximum 25 level ?
drop The packet will be dropped on crossing the limit logging The packet will be dropped and a message will be logged shutdown The packet will be dropped, message will be logged and the port will be shutdown
(host) (config-if)#switchport port-security maximum 25 level shutdown interval ?
<seconds> Time in seconds. Supported range (1-65535)
The sample command to set the values for maximum MAC addresses, levels of security for packet handling, and the autorecovery interval time is as follows:
(host) (config-if) #switchport port-security maximum 20 level shutdown interval 100
The level of security can be set to drop, logging, or shutdown. The default value for level is logging. The autorecovery interval time (in seconds) to clear the port error must be in the range of 1-65,535.
To disable this port-security feature on the switch, execute the following command:
(host) (config) #interface gigabitethernet 0/0/0
(host) (config-if) #no switchport port-security maximum
To display any port-security error, execute the following command:
(host) #show port status
Port Status
-----------
Slot-Port PortType AdminState OperState PoE Trusted SpanningTree
----------------------------------------------------
0/0/0 GE Enabled Up N/A Yes Forwarding
0/0/1
0/0/2
GE
GE
Enabled
Enabled
Down
Down
N/A
N/A
Yes
Yes
Disabled
Disabled
0/0/3
0/0/4
0/0/5
GE
GE
GE
Enabled
Enabled
Enabled
Down
Down
Down
N/A Yes
N/A Yes
N/A Yes
Disabled
Disabled
Disabled
AOS-W 6.5.3.x
| User Guide The Basic User-Centric Networks | 41
PortMode Speed Duplex SecurityError
-------- ----------------------
Access 1 Gbps Full
Access Auto Auto
No
No
Access
Access
Access
Access
Auto
Auto
Auto
Auto
Auto
Auto
Auto
Auto
No
No
No
No
The SecurityError column in the output displays the error corresponding to the port.
To clear off the port-security error before bringing the port UP, execute the following command:
(host) #clear port-security-error gigabitethernet 0/0/0
Supported Combinations of the Alcatel-Lucent OAW-40xx Series Switches
A small OAW-40xx Series switches deployment with switch redundancy can be configured as a single master/single local, master/master-backup/multiple local switches for very small AP clusters/deployments (256
APs and under). If the APs managed by a OAW-40xx Series master switch exceeds 256 APs, a OAW-4x50 Series switch must be used. In no instance can a OAW-40xx Series switch act as a master for any OAW-4x50 Series switch, regardless of total AP count.
Supported Configurations n n n n
OAW-4005— master/local only up to 16 APs maximum within the master cluster.
OAW-4005— master+master-backup and up to 8 local switches (OAW-4005and OAW-4010 switches only) up to 64 APs maximum within the master cluster.
OAW-4024— master+master-backup and up to 8 local switches (OAW-4005, OAW-4010, and OAW-4024 switches) up to 64 APs maximum within the master cluster.
OAW-4030— master+master-backup and up to 32 local switches (any OAW-40xx Series switch) up to 256
APs maximum within the master cluster.
Using the LCD Screen
Some switches are equipped with an LCD panel that displays a variety of information about the switch’s status and provides a menu that allows for basic operations such as initial setup and reboot. The LCD panel displays two lines of text with a maximum of 16 characters on each line. When using the LCD panel, the active line is indicated by an arrow next to the first letter.
The LCD panel is operated using the two navigation buttons to the left of the screen.
n n
Menu: Allows you to navigate through the menus of the LCD panel.
Enter: Confirms and executes the action currently displayed on the LCD panel.
The LCD has four modes: n n n n
Boot: Displays the boot up status.
LED Mode: Displays the mode that the STATUS LED is in.
Status: Displays the status of different components of the switch, including Power Supplies and AOS-W version.
Maintenance: Allows you to execute some basic operations of the switch such as uploading an image or rebooting the system.
42 | The Basic User-Centric Networks AOS-W 6.5.3.x | User Guide
Table 13: LCD Panel Mode: Boot
Function/Menu Options Displays
Displays boot status "Booting AOS-W...
Table 14: LCD Panel Mode: LED Mode
Function/Menu Options Displays
Administrative LED MODE: ADM - displays whether the port is administratively enabled or disabled.
Duplex
Speed
Exit Idle Mode
LED MODE: DPX - displays the duplex mode of the port.
LED MODE: SPD - displays the speed of the port.
EXIT IDLE MENU
Table 15: LCD Panel Mode: Status
Function/Menu Options Display Output
AOS-W
PSU
Version AOS-W X.X.X.X
Status Displays status of the power supply unit.
PSU 0: [OK | FAILED | MISSING]
PSU 1: [OK | FAILED | MISSING]
Fan Tray
Exit Status Menu
Displays fan tray status.
FAN STATUS: [OK | ERROR | MISSING]
FAN TEMP: [OK | HIGH | SHUTDOWN]
EXIT STATUS
AOS-W 6.5.3.x
| User Guide The Basic User-Centric Networks | 43
Table 16: LCD Panel Mode: Maintenance
Function/Menu Options Display Output
Upgrade Image Upgrade the software image on the selected partition from a predefined location on the attached USB flash device.
Partition [0 | 1] Upgrade Image [no | yes]
Upload Config
Factory Default
Media Eject
System Reboot
Uploads the switch’s current configuration to a predefined location on the attached USB flash device.
Upload Config [no | yes]
Allows you to return the switch to the factory default settings.
Factory Default [no | yes]
Completes the reading or writing of the attached USB device.
Media Eject [no | yes]
Allows you to reboot the switch.
Reboot [no | yes]
System Halt
Exit Maintenance Menu
Allows you to halt the switch.
Halt [no | yes]
EXIT MAINTENANCE
Using the LCD and USB Drive
You can upgrade your image or upload a saved configuration by using your USB drive and your LCD commands.
For more information on copying and transferring AOS-W image and configuration files, see
Upgrading an Image
1. Copy a new switch image onto your USB drive into a directory named /Alcatel-Lucentimage .
2. Insert your USB drive into the switch’s USB slot. Wait for 30 seconds for the switch to mount the USB.
3. Navigate to Upgrade Image in the LCD’s Maintenance menu. Select a partition and confirm the upgrade
(Y/N) and then wait for switch to copy the image from the USB drive to the system partition.
4. Execute a system reboot either from the LCD menu or from the command line to complete the upgrade.
Uploading a Saved Configuration
1. Make a copy of a switchconfiguration (with the .cfg file extension), and save the copied file with the name
Alcatel-Lucent_usb.cfg
.
2. Move the saved configuration file onto your USB drive into a directory named /Alcatel-Lucentimage .
44 | The Basic User-Centric Networks AOS-W 6.5.3.x | User Guide
3. Insert your USB drive into the switch’s USB slot. Wait for 30 seconds for the switch to mount the USB.
4. Navigate to Upload Config in the LCD’s Maintenance menu. Confirm the upload (Y/N) and then wait for the upload to complete.
5. Execute a system reboot either from the LCD menu or from the command line to reload from the uploaded configuration.
For detailed upgrade and instruction, see the Upgrade chapter in the Release Notes.
Disabling LCD Menu Functions
For security purposes, you can disable all LCD menu functions by disabling the entire menu functionality using the following commands:
(host) (config) #lcd-menu
(host) (lcd-menu) #disable menu
To prevent inadvertent menu changes, you can disable individual LCD menu functions using the following commands:
(host) (lcd-menu) #disable menu maintenance ?
factory-default Disable factory default menu media-eject Disable media eject menu on LCD system-halt Disable system halt menu on LCD system-reboot Disable system reboot menu on LCD upgrade-image Disable image upgrade menu on LCD upload-config Disable config upload menu on LCD
To display the current LCD functionality from the command line, use the following command:
(host) (config) #show lcd-menu
Configuring a VLAN to Connect to the Network
You must follow the instructions in this section only if you need to configure a trunk port between the switch and another layer-2 switch (shown in
Deployment Scenario #3: APs on Multiple Different Subnets from
This section shows how to use both the WebUI and CLI for the following configurations (subsequent steps show how to use the WebUI only): n n
Create a VLAN on the switch and assign it an IP address.
Optionally, create a VLAN pool. A VLAN pool consists of two more VLAN IDs which are grouped together to efficiently manage multi-switch networks from a single location. For example, policies and virtual application configurations map users to different VLANs which may exist at different switches. This creates redundancy where one switch has to back up many other switches. With the VLAN pool feature you can control your configuration globally.
VLAN pooling should not be used with static IP addresses.
n n n
Assign to the VLAN the ports that you will use to connect the switch to the network. (For example, the uplink ports connected to a router are usually Gigabit ports.) In the example configurations shown in this section, a switch is connected to the network through its Gigabit Ethernet port 1/25.
Configure the port as a trunk port.
Configure a default gateway for the switch.
AOS-W 6.5.3.x
| User Guide The Basic User-Centric Networks | 45
Creating, Updating, and Viewing VLANs and Associated IDs
You can create and update a single VLAN or bulk VLANS using the WebUI or the CLI. See
.
In the WebUI configuration windows, clicking the Save Configuration button saves configuration changes so they are retained after the switch is rebooted. Clicking the Apply button saves changes to the running configuration but the changes are not retained when the switch is rebooted. A good practice is to use the Apply button to save changes to the running configuration and, after ensuring that the system operates as desired, click Save
Configuration .
You can view VLAN IDs in the CLI.
(host) #show vlan
Creating, Updating, and Deleting VLAN Pools
VLAN pooling should not be used with static IP addresses.
You can create, update, and delete a VLAN pool using the WebUI or the CLI. See
Creating a Named VLAN on page 107
.
Use the CLI to add existing VLAN IDS to a pool.
(host) (config) #vlan-name <name>
(host) (config) #vlan mygroup <vlan-IDs>
To confirm the VLAN pool status and mappings assignments, use the show vlan mapping command:
(host) #show vlan mapping
Assigning and Configuring the Trunk Port
The following procedures configures a Gigabit Ethernet port as trunk port.
In the WebUI
To configure a Gigabit Ethernet port:
1. Navigate to Configuration > Network > Ports .
2. In the Port Selection section, click the port that will connect the switch to the network. In this example, click port 25.
3. For Port Mode, select Trunk .
4. For Native VLAN, select a VLAN from the scrolling list, then click the left (<--) arrow.
5. Click Apply .
In the CLI
To configure a Gigabit Ethernet port:
(host)(config) #interface gigabitethernet <slot>/<module>/<port>
(host)(config-if) #switchport mode trunk
(host)(config-if) #switchport trunk native vlan <id>
To confirm the port assignments, use the show vlan command:
(host) (config) #show vlan
46 | The Basic User-Centric Networks AOS-W 6.5.3.x | User Guide
Configuring the Default Gateway
The following configurations assign a default gateway for the switch.
In the WebUI
To configure the default gateway:
1. Navigate to Configuration > Network > IP > IP Routes .
2. To add a new static gateway, click the Add button below the static IP address list.
a. In the IP Address field, enter an IP address in dotted-decimal format.
b. In the Cost field, enter a value for the path cost.
c. Click Add .
3. You can define a dynamic gateway using DHCP, PPPOE or a cell uplink interface. In the Dynamic section, click the DHCP , PPPoE or Cellular checkboxes to select one or more dynamic gateway options. If you select more than one dynamic gateway type, you must also define a cost for the route to each gateway. The switch will first attempt to obtain a gateway IP address using the option with the lowest cost. If the switch is unable to obtain a gateway IP address, it will then attempt to obtain a gateway IP address using the option with the next-lowest path cost.
4. Click Apply .
In the CLI
To configure the default gateway: ip default-gateway <ipaddr>|{import cell|dhcp|pppoe}|{ipsec <name>} <cost>
Configuring the Loopback IP Address for the Switch
You must configure a loopback address if you are not using a VLAN ID address to connect the switch to the network (see
Deployment Scenario #3: APs on Multiple Different Subnets from Switches on page 37 ).
After you configure or modify a loopback address, you must reboot the switch.
If configured, the loopback address is used as the switch’s IP address. If you do not configure a loopback address for the switch, the IP address assigned to the first configured VLAN interface IP address. Generally,
VLAN 1 is configured first and is used as the switch’s IP address.
AOS-W allows the loopback address to be part of the IP address space assigned to a VLAN interface. In the example topology, the VLAN 5 interface on the switch was previously configured with the IP address
10.3.22.20/24. The loopback IP address in this example is 10.3.22.220.
You configure the loopback address as a host address with a 32-bit netmask. The loopback address should be routable from all external networks.
Spanning tree protocol (STP) is enabled by default on the switch. STP ensures a single active path between any two network nodes, thus avoiding bridge loops. Disable STP on the switch if you are not employing STP in your network.
In the WebUI
To configure a loopback IP address:
1. Navigate to Configuration > Network > Switch > System Settings .
AOS-W 6.5.3.x
| User Guide The Basic User-Centric Networks | 47
2. Enter the IP address under Loopback Interface.
3. On this window, you can also turn off spanning tree. Click No for Spanning Tree Enabled.
4. Click Apply at the bottom of the window (you might need to scroll down the window).
5. At the top of the window, click Save Configuration .
You must reboot the switch for the new IP address to take effect.
6. Navigate to the Maintenance > Switch > Reboot Switch window.
7. Click Continue .
In the CLI
To configure a loopback IP address:
(host)(config) #interface loopback ip address <A.B.C.D>
(host)(config) #no spanning-tree
(host)(config) #write memory
(host)(config) #reload
The switch returns the following messages:
Do you really want to reset the system(y/n):
Enter y to reboot the switch or n to cancel.
System will now restart!
...
Restarting system.
To verify that the switch is accessible on the network, ping the loopback address from a workstation on the network.
Configuring the System Clock
You can manually set the clock on the switch, or configure the switch to use a Network Time Protocol (NTP) server to synchronize its system clock with a central time source. For more information about setting the switch’s clock, see
Setting the System Clock on page 885 .
Installing Licenses
AOS-W consists of a base operating system with optional software modules that you can activate by installing license keys. If you use the Setup Wizard during the initial setup phase, you will have the opportunity to install software licenses at that time. Refer to
for detailed information on Licenses.
Connecting the Switch to the Network
Connect the ports on the switch to the appropriately-configured ports on an L2 switch or router. Make sure that you have the correct cables and that the port LEDs indicate proper connections. Refer to the Installation
Guide for the switch for port LED and cable descriptions.
In many deployment scenarios, an external firewall is situated between various Alcatel-Lucent devices.
Firewall Configuration on page 684
describes the network ports that must be configured on the external firewall to allow proper operation of the network.
To verify that the switch is accessible on the network:
48 | The Basic User-Centric Networks AOS-W 6.5.3.x | User Guide
n n
If you are using VLAN 1 to connect the switch to the network (
Deployment Scenario #2: APs All on One
Subnet Different from Switch Subnet on page 36
and
Deployment Scenario #3: APs on Multiple Different
Subnets from Switches on page 37 ), ping the VLAN 1 IP address from a workstation on the network.
If you created and configured a new VLAN (
Deployment Scenario #3: APs on Multiple Different Subnets from Switches on page 37
), ping the IP address of the new VLAN from a workstation on the network.
Enabling Wireless Connectivity
Wireless users can connect to the SSID but because you have not yet configured authentication, policies, or user roles, they will not have access to the network. Other chapters in the AOS-W User Guide describe how to build upon this basic deployment to configure user roles, firewall policies, authentication, authentication servers, and other wireless features.
Enabling Wireless Connectivity
Wireless users can connect to the SSID but because you have not yet configured authentication, policies, or user roles, they will not have access to the network. Other chapters in the AOS-W User Guide describe how to build upon this basic deployment to configure user roles, firewall policies, authentication, authentication servers, and other wireless features.
n
Configuring Your User-Centric Network
Configuring your switch and AP is done through either the Web User Interface (WebUI) or the command line interface (CLI).
WebUI is accessible through a standard Web browser from a remote management console or workstation.
The WebUI includes configuration wizards that step you through easy-to-follow configuration tasks. Each wizard has embedded online help. The wizards are: l l
AP Wizard—basic AP configurations including LAN, Remote, LAN Mesh and Remote Mesh deployment scenarios
Switch Wizard—basic switch configuration including system settings, Control Plane security, cluster settings and licenses l l
WLAN/LAN Wizard—creating and configuring new WLANs and LANs associated with the “default” apgroup. Includes campus only and remote networking.
License Wizard—installation and activation of software licenses (see
Software Licenses on page 79 )
Clicking Cancel from the Wizards return you to where you launched the wizard. Any configuration changes you entered are not saved.
n
The command line interface (CLI) allows you to configure and manage switches. The CLI is accessible from a local console connected to the serial port on the switch or through a Telnet or Secure Shell (SSH) session from a remote management console or workstation.
By default, you can only access the CLI from the serial port or from an SSH session. To use the CLI in a Telnet session, you must explicitly enable Telnet on the switch.
Replacing a Switch
The procedures below describe the steps to replace an existing standalone master switch and/or a redundant master switch. Best practices are to replace the backup master switch first, and replace the active master switch
AOS-W 6.5.3.x
| User Guide The Basic User-Centric Networks | 49
only after the new backup switch is operational on the network. When you remove the active switch from the network to replace it, the new backup switch takes over the active switch role. When you add a second switch to the network, that second switch automatically assumes the role of a backup switch.
This procedure assumes that the existing switches have been upgraded to AOS-W 6.2.x or later. If your switches are running earlier version of AOS-W, upgrade them to 6.2.x or later before attempting to migrate them to a newer switch model, such as a OAW-40xx Series or OAW-4x50 Series switch.
Transferring Licenses
To replace a switch with manually added licenses, you will need to transfer those licenses to the new switch as part of the replacement process.
If the switch being replaced was returned to Alcatel-Lucent as an RMA, the license keys on the RMA switch cannot be directly transferred to a new device, and must be regenerated. To generate a new license key for a switch returned as an RMA:
1. Access the My Networking Portal (MNP) at http://hpe.com/networking/mynetworking/ .
2. Log in to MNP using the HPE Passport.
3. Click View licenses or Transfer licenses to new platform . All available licenses are displayed.
4. Select the >> icon at the right end of the record to verify the license details before transferring it.
5. Click Transfer License at the bottom of the page.
6. Select a switch from the AOS Controller Type drop-down list.
7. Enter the serial number of the switch in the Serial number text box; or enter the passphrase of the switch in the PassPhrase text box.
8. Select the license to be transferred.
9. Click Transfer at the bottom of the page. A new license key is generated, which you can apply to the switch.
Procedure Overview
The procedure to replace a backup or active master switch is comprised of the following tasks:
1.
Change the VRRP Priorities for a Redundant Master Pair on page 51
2.
Back Up the Flash File System on page 51
3.
Stage the New Switch on page 51
4.
Add Licenses to the New Switch on page 52
5.
Backup Newly Installed Licenses on page 52
6.
Import and Restore Flash Backup on page 52
7.
8.
9.
Modify the Host Name on page 54
10.
Modify Topology Settings on page 54
11.
Save your Configuration on page 55
12.
Remove the Existing Switch on page 55
If your switch does not have any manually added licenses, skip steps 3, 4 and 6 of the following procedure.
50 | The Basic User-Centric Networks AOS-W 6.5.3.x | User Guide
Change the VRRP Priorities for a Redundant Master Pair
If your deployment uses VRRP to define the primary master in a pair of redundant master switches, and you are replacing only the primary master switch, and you must change the VRRP priority levels of the switches so the primary master switch has a lower priority than the backup master switch. This will allow the configuration from the backup master to be copied to the new master switch, and prevent an old or inaccurate configuration from being pushed to the local switches.
For details on changing VRRP priorities, see
Configuring VRRP Redundancy on page 643
.
Back Up the Flash File System
To start the migration process, access the backup or master switch being replaced and create a backup of the flash file system. You can create a backup file using the WebUI or command-line interfaces.
In the WebUI
To back up the flash from the WebUI, log in to the current backup or master switch and create a flash backup using the procedure below.
1. Navigate to Maintenance > File >Backup Flash .
2. Select Create Backup .
3. Select Copy Backup to create a copy of the backup file. By default, the flash backup file is named flashbackup.tar.gz
.
4. Next, move the backup the flash file system to an external server. Navigate to Maintenance>Copy Files .
5. In the Source Selection section, select Flash File System .
6. In the Destination Selection section, select one of the server options to move the flash backup off the switch, and enter the name of the flash backup file to be exported.
In the CLI
To create a flash backup from the command-line interface, access the active master switch and issue the backup flash command, as shown in the example below.
(host) #backup flash
Please wait while we tar relevant files from flash...
Please wait while we compress the tar file...
File flashbackup.tar.gz created successfully on flash.
Please copy it out of the switch and delete it when done.
(active_host) #dir
-rw-r--r-drwxr-xr-x
-rw-r--r-drwx------
1 root
4 root
1 root
2 root root root root root
17338 Dec
1024 Dec
21760 Dec
1024 Dec
6 08:34 default.cfg
6 08:34 fieldCerts
6 09:29 flashbackup.tar.gz
5 08:20 tpm
(host) #copy flash: flashbackup.tar.gz tftp: <your TFTP server IP> flashbackup.tar.gz
Stage the New Switch
The next step in the procedure is to stage the new backup master or active master switch with basic IP connectivity. Power up the new switch, connect a laptop computer to the switch's serial port, and follow the prompts to configure basic settings, as shown below:
Auto-provisioning is in progress. Choose one of the following options to override or debug...
'enable-debug' : Enable auto-provisioning debug logs
'disable-debug' : Disable auto-provisioning debug logs
'mini-setup' : Stop auto-provisioning and start mini setup dialog for branch role
'full-setup' : Stop auto-provisioning and start full setup dialog for any role
Enter Option (partial string is acceptable): full-setup
AOS-W 6.5.3.x
| User Guide The Basic User-Centric Networks | 51
Are you sure that you want to stop auto-provisioning and start full setup dialog? (yes/no): yes
Reading configuration from factory-default.cfg
***************** Welcome to the Alcatel-Lucent OAW-4550 setup dialog *****************
This dialog will help you to set the basic configuration for the switch.
These settings, except for the Country Code, can later be changed from the
Command Line Interface or Graphical User Interface.
Enter System name [Alcatel-Lucent OAW-4550]:
Enter Switch Role (master|local|standalone) [master]:
Enter VLAN 1 interface IP address [172.16.0.254]: 10.79.100.109
Enter VLAN 1 interface subnet mask [255.255.255.0]:
Enter IP Default gateway [none]: 10.79.100.1
Enter Country code (ISO-3166), <ctrl-I> for supported list: US
You have chosen Country code US for United States (yes|no)?: yes
Enter Time Zone [PST-8:0]:
Enter Time in UTC [02:24:44]: 02:36:44
Enter Date (MM/DD/YYYY) [12/3/2012]:
Enter Password for admin login (up to 32 chars): ******
Re-type Password for admin login: ******
Enter Password for enable mode (up to 15 chars): ******
Re-type Password for enable mode: ******
Do you wish to shutdown all the ports (yes|no)? [no]:
If you accept the changes the switch will restart!
Type <ctrl-P> to go back and change answer for any question
Do you wish to accept the changes (yes|no)yes
Creating configuration... Done.
System will now restart!
Add Licenses to the New Switch
Use the license add command in the command-line interface or navigate to Configuration > Network >
Switch > License Management to add new or transferred licenses to the new switch.
Do not reboot the switch at the end of this step. Do not save the configuration or write it to memory. Reboot only after the flash memory and the licenses have been restored.
(host) #license add <key>
Backup Newly Installed Licenses
Use the license export command in the command-line interface or click Export Database in the
Configuration > Network > Switch > License Management page of the WebUI to back up the newly installed licenses to the backup license database.
Do not reboot the switch at the end of this step. Do not save the configuration or write it to memory. Reboot only after the flash memory and the licenses have been restored.
(host) #license export <filename>
Import and Restore Flash Backup
Import and restore the backup flash file system from the original switch to the new switch,
Do not reboot the switch at the end of this step. Do not save the configuration or write it to memory. Reboot only after the flash memory and the licenses have been restored.
52 | The Basic User-Centric Networks AOS-W 6.5.3.x | User Guide
In the WebUI
To import and restore a flash backup using the WebUI:
1. Access the new switch and navigate to Maintenance > File> Copy Files .
2. In the Source Selection section, choose any of the server options or select USB Drive if the flash backup is on USB storage.
3. In the Destination Selection section, choose Flash File System .
4. Enter the filename of the flash backup and click Apply . By default, the flash backup file is named flashbackup.tar.gz
.
5. Next, navigate to Maintenance>File>Restore Flash and select Restore .
In the CLI
To import and restore a flash backup file using the command-line interface, use the copy and restore flash commands. The following example copies a backup file from a USB drive.
(host) #copy usb: Partition 1 flashbak2_7200.tar.gz flash: flashbackup.tar.gz
....File flashbak2_7200.tar.gz copied to flash successfully.
(host) #dir
-rw-r--r--
-rw-r--r--
-rw-r--r-drwxr-xr-x
-rwxr-xr-x
-rw-r--r--
-rw-r--r-drwx------
1 root
1 root
2 root
3 root
1 root
1 root
2 root
2 root root root root root root root root root
10182 Dec
9726 Nov 30 21:36 default.cfg.2012-11-30_21-36-23
10977 Dec
4096 Dec
78205 Dec
1796 Nov 30 19:12 license_backup.db
10977 Dec
4096 Dec
2 18:39 default.cfg
2 18:39 default.cfg.2012-12-02_18-39-27
2 18:25 fieldCerts
2 19:41 flashbackup.tar.gz
2 18:39 original.cfg
2 18:25 tpm
(host) #restore flash
Please wait while we uncompress /flash/config/flashbackup.tar.gz...
Please wait while we untar /flash/config/flashbackup.tar.gz...
Flash restored successfully.
Please reload (reboot) the switch for the new files to take effect.
Restore Licenses
Issue the license import command in the command-line interface or click Import Database in the
Configuration > Network > Switch > License Management page of the WebUI to import licenses from the license database to the new switch.
(host) #license import <filename>
Do not save the configuration or write to memory at the end of this step.
Reboot the Switch
Once all the licenses have been restored, issue the reload command in the command-line interface or navigate to Maintenance>Reboot Switch in the WebUI to reboot the new switch. After rebooting, the switch should not be on the network (or a reachable subnet) with the switch it will replace. This is to prevent a possible IP address conflict.
Do not save the configuration or write to memory at the end of this step.
(host) #reload
Do you want to save the configuration(y/n): n
AOS-W 6.5.3.x
| User Guide The Basic User-Centric Networks | 53
Do you really want to restart the system(y/n): y
System will now restart!
Modify the Host Name
Issue the hostname command in the command-line interface to give the new switch a unique hostname. (The flash restoration process gave the new switch the same name as the existing switch.)
Do not save the configuration or write to memory at the end of this step.
(host)(config) #hostname <hostname>
Modify Topology Settings
This is required when migrating to a newer switch model. New switch models such as the OAW-40xx Series and
OAW-4x50 Series switches use a different port numbering scheme than other Alcatel-Lucent switches. Ports on the newer switch models are numbered slot/module/port . Older switch ports are numbered slot/port . As a result, flash backup files restored from older switches onto a newer model switches can cause the newer switch lose network connectivity, as the imported port settings don't match up with the switch hardware. Additionally, all ports will become untrusted when you import a configuration from an older model switch to a newer model switch.
Use the interface range and switchport commands to reconfigure the VLANs and IP interfaces to match the port scheme of that hardware model. To avoid network conflicts, this process must be completed before the switch is connected to the management network.
If you are replacing a switch with the same switch model, you can skip this step and continue to
The following commands adjust the port configuration on the new switch .
(host) (config) #interface range gigabitethernet <slot>/<module-start>/<port-start>-<moduleend>/<port-end>
(host) (config-range) #switchport access vlan <id>
Because the physical ports don't match, the port trust is removed by default, and needs to be re-enabled. In the example below, the Trusted column shows that the port trust is disabled for all ports.
(host) #show port status
Port Status
-----------
Slot-Port PortType adminstate operstate poe
-----------------------------------
0/0/0 GE Enabled Up Enabled
Trusted SpanningTree PortMode
-------
No
------------
Disabled
--------
Access
0/0/1
0/0/2
0/0/3
0/0/4
0/0/5
GE
GE
GE
GE
GE
Enabled
Enabled
Enabled
Enabled
Enabled
Down
Down
Down
Down
Down
Enabled
Enabled
Enabled
Enabled
Enabled
No
No
No
No
No
Disabled
Disabled
Disabled
Disabled
Disabled
Access
Access
Access
Access
Access
Use the interface range command to re-apply port trust to all of the gigabit Ethernet ports on the switch.
Then issue the show port status command to verify port trust has been restored.
(host) (config) #interface range gigabitethernet <slot>/<module-start>/<port-start>-<moduleend>/<port-end>
(host) (config-range) #trusted
(host) #show port status
Port Status
54 | The Basic User-Centric Networks AOS-W 6.5.3.x | User Guide
-----------
Slot-Port PortType adminstate operstate poe
-----------------------------------
0/0/0 GE Enabled Down Enabled
Trusted SpanningTree PortMode
-------
Yes
------------
Disabled
--------
Access
0/0/1
0/0/2
GE
GE
Enabled
Enabled
Down
Down
Enabled
Enabled
Yes
Yes
Disabled
Disabled
Access
Access
0/0/3
0/0/4
0/0/5
GE
GE
GE
Enabled
Enabled
Enabled
Down
Down
Down
Enabled Yes
Enabled Yes
Enabled Yes
Disabled
Disabled
Disabled
Access
Access
Access
Save your Configuration
Now, you must save the configuration settings on the new switch. Issue the write memory command in the command-line interface, or click the Configuration tab and select the Save Configuration button at the top of the WebUI page.
(host) (config) #write memory)
Remove the Existing Switch
If you are only replacing a backup switch, remove the existing backup switch, then connect the replacement switch to the network. If you are replacing both an active switch and a backup switch, replace the backup switch first.
When the active master switch is removed from the network, the backup master immediately assumes the role of active master, and all active APs associate to the new active master switch within a few seconds. Therefore, when you add another switch to the network, it will, by default, assume the role of a backup switch.
If you changed the VRRP priorities of your redundant master switches prior to replacing the primary master switch, you may wish to change them back once the new primary master is active on the network.
AOS-W 6.5.3.x
| User Guide The Basic User-Centric Networks | 55
Chapter 2
Control Plane Security
AOS-W supports secure IPsec communications between a switch and campus or remote APs using public-key self-signed certificates created by each master switch. The switch certifies its APs by issuing them certificates. If the master switch has any associated local switches, the master switch sends a certificate to each local switch, which in turn sends certificates to their own associated APs. If a local switch is unable to contact the master switch to obtain its own certificate, it is not be able to certify its APs, and those APs cannot communicate with their local switch until master-local communication has been reestablished. You create an initial control plane security configuration when you first configure the switch using the initial setup wizard. The AOS-W initial setup wizard enables control plane security by default, so it is very important that the local switch be able to communicate with its master switch when it is first provisioned.
Some AP model types have factory-installed digital certificates. These AP models use their factory-installed certificates for IPsec, and do not need a certificate from the switch. Once a campus or remote AP is certified, either through a factory-installed certificate or a certificate from the switch, the AP can failover between local switches and still stay connected to the secure network, because each AP has the same master switch as a common trust anchor.
Starting with AOS-W 6.2, the switch maintains two separate AP whitelists; one for campus APs and one for
Remote APs. These whitelists contain records of all campus APs or remote APs connected to the network. You can use a campus or AP whitelist at any time to add a new valid campus or remote AP to the secure network, or revoke network access to any suspected rogue or unauthorized APs.
The control plane security feature supports IPv4 campus and remote APs only. Do not enable control plane security on a switch that terminates IPv6 APs.
When the switch sends an AP a certificate, that AP must reboot before it can connect to its switch over a secure channel. If you are enabling control plane security for the first time on a large network, you may experience several minutes of interrupted connectivity while each AP receives its certificate and establishes its secure connection.
HP Platform interoperating with Alcatel-Lucent Switches
Following HP TPM based switches can now inter-operate with the Alcatel-Lucent switches and create the IKE /
IPSec tunnels.
n n n n n n n n n n n
2930F
5400R/v3 3810
5400R/v2 (compat. mode)
3800
2920
2530
2620
5400/v2
5400/v1
3500
2615
AOS-W 6.5.3.x
| User Guide Control Plane Security | 56
n n
2915
8200
These HP platforms are running version k.16.02.
Topics in this chapter include: n n n n n n n n
Control Plane Security Overview on page 57
Configuring Control Plane Security on page 57
Managing AP Whitelists on page 59
Managing Whitelists on Master and Local Switches on page 66
Working in Environments with Multiple Master Switches on page 70
Replacing a Switch on a Multi-Switch Network on page 73
Configuring Control Plane Security after Upgrading on page 76
Troubleshooting Control Plane Security on page 77
Control Plane Security Overview
Switches using control plane security only send certificates to APs that you have identified as valid APs on the network. If you want closer control over each AP that is certified, you can manually add individual campus and remote APs to the secure network by adding each AP's information to the whitelists when you first run the initial setup wizard. If you are confident that all APs currently on your network are valid APs, then you can use the initial setup wizard to configure automatic certificate provisioning to send certificates from the switch to each campus or remote AP, or to all campus and remote APs within specific ranges of IP addresses.
The default automatic certificate provisioning setting requires that you manually enter each campus AP’s information into the campus AP whitelist, and each remote AP's information into the remote AP whitelist. If you change the default automatic certificate provisioning values to let the switch send certificates to all APs on the network, that new setting ensures that all valid APs receive a certificate, but also increases the chance that you will certify a rogue or unwanted AP. If you configure the switch to send certificates to only those APs within a range of IP addresses, there is a smaller chance that a rogue AP receives a certificate, but any valid AP with an
IP address outside the specified address ranges will not receive a certificate, and can not communicate with the switch (except to obtain a certificate). Consider both options carefully before you complete the control plane security portion of the initial setup wizard. If your switch has a publicly accessible interface, you should identify the APs on the network by IP address range. This prevents the switch from sending certificates to external or rogue campus APs that may attempt to access your switch through that publicly accessible interface.
Configuring Control Plane Security
When you initially deploy the switch, you create your initial control plane security configuration using the initial setup wizard. These settings can be changed at any time using the WebUI or the command-line interfaces.
If you are configuring control plane security for the first time after upgrading from AOS-W 5.0 or earlier, see
Configuring Control Plane Security after Upgrading on page 76
for details on enabling this feature using the WebUI or CLI.
In the WebUI
1. Navigate to Configuration > Network > Switch .
2. Select the Control Plane Security tab.
57 | Control Plane Security AOS-W 6.5.3.x | User Guide
3. Configure the following control plane security parameters:
Table 17: Control Plane Security Parameters
Parameter
Control Plane
Security
Auto Cert
Provisioning
Description
Select enable or disable to turn the control plane security feature on or off. This feature is enabled by default.
Addresses allowed for Auto Cert
Number of AP
Whitelist Entries
When you enable the control plane security feature, you can select this checkbox to turn on automatic certificate provisioning. When you enable this feature, the switch attempts to send certificates to all associated campus APs. Auto certificate provisioning is disabled by default.
NOTE: If you do not want to enable automatic certificate provisioning the first time you enable control plane security on the switch, you must identify the valid APs on your network by adding those to the campus AP whitelist. For details, see
Viewing the Master or Local Switch Whitelists on page 68
.
After you have enabled automatic certificate provisioning, you must select either
Auto Cert Allow all or Addresses Allowed for Auto Cert .
The Addresses Allowed for Auto Cert section allows you to specify whether certificates are sent to all associated APs, or just APs within one or more specific IP address ranges. If your switch has a publicly accessible interface, you should identify your campus and Remote APs by IP address range. This prevents the switch from sending certificates to external or rogue campus APs that may attempt to access your switch through that interface.
Select All to allow all associated campus and remote APs to receive automatic certificate provisioning. This parameter is enabled by default.
Select Addresses Allowed for Auto Cert to send certificates to a group of campus or remote APs within a range of IP addresses. In the two fields below, enter the start and end IP addresses, then click Add . Repeat this procedure to add additional IP ranges to the list of allowed addresses. If you enable both control plane security and auto certificate provisioning, all APs in the address list receives automatic certificate provisioning.
Remove a range of IP addresses from the list of allowed addresses by selecting the
IP address range from the list and clicking Delete.
This parameter is the total number of APs in the remote AP and campus AP
Whitelists. This number is also a link to a combined whitelist that displays all campus and remote AP entries.
4. Click Apply .
The master switch generates its self-signed certificate and begins distributing certificates to campus APs and any local switches on the network over a clear channel. After all APs have received a certificate and have connected to the network using a secure channel, access the Control Plane Security window and turn off auto certificate provisioning if that feature was enabled. This prevents the switch from issuing a certificate to any rogue APs that may appear on your network at a later time.
Figure 4 Control Plane Security Settings
AOS-W 6.5.3.x
| User Guide Control Plane Security | 58
In the CLI
Use the commands below to configure control plane security via the command line interface on a standalone or master switch. Descriptions of the individual parameters are listed in
, above.
(host)(config) #control-plane-security
(host)(Control Plane Security Profile) #auto-cert-allow-all
(host)(Control Plane Security Profile) #auto-cert-allowed-addrs <ipaddress-start> <ipaddressend>
(host)(Control Plane Security Profile) #auto-cert-prov
(host)(Control Plane Security Profile) #cpsec-enable
View the current control plane security settings using the following command:
(host) #show control-plane-security
Managing AP Whitelists
Campus or Remote APs appear as valid APs in the campus or Remote AP whitelists when you manually enter their information into the campus or Remote AP whitelists through the WebUI or CLI of a switch or after a switch sends a certificate to an AP as part of automatic certificate provisioning and the AP connects to the switch over a secure tunnel. APs that are not approved or certified on the network are included in the campus
AP whitelists, but these APs appear in an unapproved state.
Use the AP whitelists to grant valid APs secure access to the network or to revoke access from suspected rogue
APs. When you revoke or remove an AP from the campus or remote AP whitelists on a switch that uses control plane security, that AP is not able to communicate with the switch again, except to obtain a new certificate.
If you manually add APs to the AP whitelists (rather than automatically adding the APs as part of automatic certificate provisioning), make sure that the AP whitelists have been synchronized to all other switches on the network before enabling control plane security.
Adding an AP to the Campus or Remote AP Whitelists
You can add an AP to the campus AP or remote AP whitelists over the WebUI or CLI.
In the WebUI
To add an AP to the campus AP or Remote AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Select the whitelist to which you want to add an AP. The Whitelist tab displays status information for the
Campus AP Whitelist by default. To add a Remote AP to the Remote AP whitelist, click the Remote AP link before you proceed to
.
59 | Control Plane Security AOS-W 6.5.3.x | User Guide
Figure 5 Control Plane Security Settings
4. Click Entries in the upper right corner of the whitelist status window.
5. Click New .
6. Define the following parameters for each AP you want to add to the AP whitelist.
Table 18: AP Whitelist Parameters
Parameter Description
Campus AP whitelist configuration parameters
AP MAC Address
AP Group
MAC address of campus AP that supports secure communications to and from its switch.
Name of the AP group to which the campus AP is assigned. If you do not specify an AP group, the AP uses default as its AP group.
AP Name Name of the campus AP. If you do not specify a name, the AP uses its MAC address as AP name.
Description Brief description of the campus AP.
Remote AP whitelist configuration parameters
AP MAC Address
User Name
AP Group
AP Name
Description
IP-Address
MAC address of the remote AP, in colon-separated octets.
Name of the end user who provisions and uses the remote AP.
Name of the AP group to which the Remote AP is assigned.
Name of the Remote AP. If you do not specify a name, the AP uses its MAC address as AP name.
Brief description of the Remote AP.
The static inner IP address to be assigned to the Remote APs.
7. Click Add .
In the CLI
To add an AP to the campus AP whitelist:
(host) #whitelist-db cpsec add mac-address <name> ap-group <ap_group>
AOS-W 6.5.3.x
| User Guide Control Plane Security | 60
ap-name <ap_name> description <description>
To add an AP to the remote AP whitelist:
(host) #whitelist-db rap add mac-address <mac-address> ap-group <ap-group> ap-name <ap-name> description <description> full-name <name> remote-ip <inner-ip-adr>
Viewing AP Whitelist Status
The WebUI displays either a status of the selected AP whitelist or a table of entries in the selected AP whitelist.
The status page displays the current status of the AP whitelist and for switches in a master/local switch topology, it displays the AP whitelist synchronization status between switches. When the status of an entry in the AP whitelist changes, the AP whitelist status is updated automatically. The table of entries page displays the status of each AP on the AP whitelist.
The Configuration > Wireless > AP Installation > Whitelist tab displays the status of the campus AP whitelist by default. To view the status of remote AP whitelist, click the Remote AP link.
The following table describes the contents of the status page.
Table 19: Whitelist Status Information
Status Entry Description
Campus AP whitelist status information
Control Plane Security
Total entries
Approved entries
Shows if the control plane security is enabled or disabled on the switch.
This status entry is also a link to the control plane security configuration tab.
Number of entries in the campus AP whitelist.
Number of entries in the campus AP whitelist that have been approved by the switch.
Unapproved entries
Certified entries
Number of entries in the campus AP whitelist that have not been approved by the switch.
Number of entries in the campus AP whitelist that have an approved certificate from the switch.
Certified hold entries
Revoked entries
Number of entries in the campus AP whitelist that have been certified with a factory certificate but request to be certified again. Such APs are not approved as secure until you manually change the status and verify that it is not compromised.
NOTE: If an AP is in the hold state because of connectivity problems, then the AP recovers and moves out of the hold state when connectivity is restored.
Number of entries in the campus AP whitelist that has been manually revoked.
Marked for deletion entries Number of entries in the campus AP whitelist that has been marked for deletion, but not removed from the Remote AP whitelist.
Remote AP whitelist configuration parameters
61 | Control Plane Security AOS-W 6.5.3.x | User Guide
Table 19: Whitelist Status Information
Status Entry Description
Total entries Number of entries in the Remote AP whitelist.
Revoked entries
Marked for deletion entries
Number of entries in the Remote AP whitelist that has been manually revoked.
Number of entries in the Remote AP whitelist that has been marked for deletion, but not removed from the Remote AP whitelist.
The Remote AP whitelist entries page displays only the information you manually configure. The campus AP whitelist entries page displays both user-defined settings and additional information that is updated when the status of a campus AP changes.
Table 20: Additional Campus AP Status Information
Parameter
Cert Type
Description
The type of certificate used by the campus AP.
n switch-cert : The campus AP is using a certificate signed by the switch.
n factory-cert : The campus AP is using a factory-installed certificate.
State
Revoked
Revoked Text
Last Update
The state of a campus AP.
n n unapproved-no-cert: The campus AP has no certificate and is not approved.
unapproved-factory-cert: The campus AP has a pre-installed certificate which is not approved.
n n n approved-ready-for-cert: The campus AP is approved as valid and is ready to receive a certificate.
certified-factory-cert : The campus AP already has a factory certificate. If a campus AP has a factory-cert type of certificate and is in certified-factory-cert state, then a new certificate is not reissued to the campus AP when you enable automatic certificate provisioning.
certified-switch-cert: The campus AP has an approved certificate from the switch.
n certified-hold-factory-cert : The campus AP is certified with a factory certificate but requests to be certified again. Such APs are not approved as secure until you manually change the status and verify that it is not compromised.
NOTE: If an AP is in this state due to connectivity problems, then the AP recovers and leaves this hold state as soon as connectivity is restored.
n certified-hold-switch-cert : An AP is put in this state when the switch thinks the AP has been certified with a switch certificate but the AP requests to be certified again. Because this is not a normal condition, the AP is not approved as a secure AP until a network administrator manually changes the status of the AP to verify that it is not compromised.
NOTE: If an AP is in the hold state because of connectivity problems, then the AP recovers and moves out of the hold state when connectivity is restored.
Shows if the secure status of the AP is revoked.
Brief description for revoking the campus AP.
Time and date of the last AP status update.
To view information about the campus and remote AP whitelists using the CLI, use the following commands:
(host) #show whitelist-db cpsec
AOS-W 6.5.3.x
| User Guide Control Plane Security | 62
ap-group <ap_group> ap-name <ap_name> cert-type {factory-cert|switch-cert} mac-address <name> page <num> start <offset> state {approved-ready-for-cert| certified-factory-cert| unapproved-factory-cert| unapproved-no-cert}
(host) #show whitelist-db cpsec-status
(host) #show whitelist-db rap apgroup <rap-group> apname <rap-name> fullname <rap-fullname> long mac-address <mac-address> page <page-number> start <offset>
(host) #show whitelist-db rap-status
Modifying an AP in the Campus AP Whitelist
Use the following procedures to modify the AP group, AP name, certificate type, state, description, and revoked status of an AP in the campus AP whitelist.
In the WebUI
To modify an AP in the campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Click the Entries>> button.
4. Select the checkbox of the AP that you want to modify, then click Modify .
If your campus AP whitelist is large and you cannot immediately locate the AP that you want to modify, select the Search link. The Whitelist Search tab displays the fields AP Group , Cert Type , AP MAC
Address , AP Name , and State that allow you to search for an AP. Specify the values of the AP that you want to locate in these fields, then click Search . The campus AP whitelist displays a list of APs that match your search criteria. Select the checkbox of the AP that you want to modify, then click Modify .
5. Modify the settings of the selected AP. Some of the following parameters are available when adding an
AP to the campus AP whitelist and are described in
n
AP Group : The name of the AP group to which the campus AP is assigned.
n n
AP Name : The name of the campus AP. If you not specify a name, the AP uses its MAC address as a name.
Cert-type : The type of certificate used by the AP.
n n n l l switch-cert: The campus AP is using a certificate signed by the switch.
factory-cert: The campus AP is using a factory-installed certificate.
State : When you click the State drop-down list to modify this parameter, you may choose one of the following options: l l approved-ready-for-cert: The AP has been approved state and is ready to receive a certificate.
certified-factory-cert: The AP is certified and has a factory-installed certificate.
Description : Brief description of the campus AP.
Revoked : Click the Revoked checkbox to revoke an invalid or rogue AP.
63 | Control Plane Security AOS-W 6.5.3.x | User Guide
n
Revoke Text : When the Revoked checkbox is selected, enter a brief comment describing why the AP is being revoked.
6. Click Update to update the campus AP whitelist entry with its new settings.
In the CLI
To modify an AP in the campus AP whitelist:
(host) #whitelist-db cpsec modify mac-address <name> ap-group <ap_group> ap-name <ap_name> cert-type {switch-cert|factory-cert} description <description> mode {disable|enable} revoke-text <revoke-text> state {approved-ready-for-cert|certified-factory-cert}
Revoking an AP from the Campus AP Whitelist
You can revoke an invalid or rogue AP either by modifying its revoke status (as described in
parameter. When revoking an invalid or rogue AP, enter a brief description why the AP is being revoked. When you revoke an AP from the campus AP whitelist, the campus AP whitelist retains the information of the AP. To revoke an invalid or rogue AP and permanently remove it from the whitelist, delete that entry (as described in ).
In the WebUI
To revoke an AP from the campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Click the Entries>> button.
4. Select the checkbox of the AP that you want to revoke, then click Revoke .
If your campus AP whitelist is large and you cannot immediately locate the AP that you want to revoke, select the Search link. The Whitelist Search tab displays the fields AP Group , Cert Type , AP MAC
Address , AP Name , and State that allow you to search for an AP. Specify the values of the AP that you want to locate in these fields, then click Search . The campus AP whitelist displays a list of APs that match your search criteria. Select the checkbox of the AP that you want to revoke, then click Revoke .
5. Enter a brief description why the AP is being revoked, then click Update .
In the CLI
To revoke an AP via the campus AP whitelist:
(host) #whitelist-db cpsec revoke mac-address <name> revoke-text <revoke-text>
Deleting an AP from the Campus AP Whitelist
Before deleting an AP from the campus AP whitelist, verify that auto certificate provisioning is either not enabled or enabled only for IP addresses that do not include the AP being deleted. If you enable automatic certificate provisioning for an AP that is still connected to the network, you cannot delete it from the campus
AP whitelist; the switch immediately re-certifies the AP and recreates its whitelist entry.
In the WebUI
To delete an AP from the campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
AOS-W 6.5.3.x
| User Guide Control Plane Security | 64
3. Click the Entries>> button.
4. Select the checkbox of the AP you want to delete, then click delete .
If your campus AP whitelist is large and you cannot immediately locate the AP that you want to delete, select the Search link. The Whitelist Search tab displays the fields AP Group , Cert Type , AP MAC
Address , AP Name , and State that allow you to search for an AP. Specify the values of the AP that you want to locate in these fields, then click Search . The campus AP whitelist displays a list of APs that match your search criteria. Select the checkbox of the AP that you want to delete, then click Delete .
In the CLI
To delete an AP from the campus AP whitelist:
(host) #whitelist-db cpsec del mac-address <name>
Purging a Campus AP Whitelist
Before adding a new local switch to a network using control plane security, purge the campus AP whitelist on the new switch. After adding the new switch to the hierarchy, the entries in the campus AP whitelist of the new switch merge into the whitelist for all other master and local switches. If you add any old or invalid AP entries to the campus AP whitelist, all switches in the hierarchy will trust those APs, creating a potential security risk. For additional information on adding a new local switch using control plane security to your network, see
Replacing a Local Switch on page 73
In the WebUI
To purge a campus AP whitelist:
1. Navigate to Configuration > Wireless > AP Installation .
2. Click the Whitelist tab.
3. Click the Entries>> button.
4. Click Purge .
In the CLI
To purge a campus AP whitelist:
(host) #whitelist-db cpsec purge
Offloading a Switch Whitelist to ClearPass Policy Manager
This feature allows to externally maintain AP whitelist in a ClearPass Policy Manager (CPPM) server. The switch, if configured to use an external server, can send a RADIUS access request to a CPPM server. The MAC address of the AP is used as a username and password to construct the access request packet. The CPPM server validates the RADIUS message and returns the relevant parameters for the authorized APs.
The following supported parameters are associated with the following VSAs. The CPPM server sends them in the RADIUS access accept packet for authorized APs: n n n ap-group: Alcatel-Lucent-AP-Group ap-name: Alcatel-Lucent-Location-ID ap-remote-ip: Alcatel-Lucent-AP-IP-Address
The following defaults are used when any of the supported parameters are not provided by the CPPM server in the RADIUS access accept response: n n ap-group: The default ap-group is assigned to the AP.
ap-name: The MAC address of the AP is used as the AP name.
65 | Control Plane Security AOS-W 6.5.3.x | User Guide
There is no change in the RAP role assignment. The RAP is assigned the role that is configured in the VPN default-rap profile.
In the WebUI
To assign a CPPM server to a RAP:
1. Configure a CPPM server using the switch WebUI: a. Navigate to Configuration > Security > Authentication > Servers .
b. Select Radius Server to display the CPPM Server List.
c. To configure a CPPM server, enter the name for the server and click Add .
d. Select the name to configure server parameters. Select the Mode check box to activate the authentication server.
e. Click Apply .
2. Create a server group that contains the CPPM server.
3. Navigate to Configuration > All Profile Management > Wireless LAN > VPN Authentication > default-rap > Server Group .
4. Select the CPPM server from the Server Group drop-down list.
5. Click Apply .
To assign a CPPM server to a RAP that was initially an Instant AP:
1. Make sure that a CPPM server is configured on the switch.
2. Navigate to Configuration > All Profile Management > Wireless LAN > VPN Authentication > default-iap > Server Group .
3. Select the CPPM server from the Server Group drop-down list.
4. Click Apply .
In the CLI
To add a CPPM server to a RAP:
Configure a radius server with CPPM server as host address. In this example cppm-rad is the CPPM server name and cppm-sg is the server group name.
(host)(config) #aaa authentication-server radius cppm-rad
Add this server to a server group:
(host)(config) #aaa server-group cppm-sg
(host) (Server Group "cppm-sg") #auth-server cppm-rad
Add this server group to the default-rap vpn profile:
(host)(config) #aaa authentication vpn default-rap
(host)(VPN Authentication Profile "default-rap") #server-group cppm-sg
Managing Whitelists on Master and Local Switches
Every switch using the control plane security feature maintains a campus AP whitelist, a local switch whitelist and a master switch whitelist. The contents of these whitelists vary, depending upon the role of the switch, as shown in the table below.
AOS-W 6.5.3.x
| User Guide Control Plane Security | 66
Table 21: Control Plane Security Whitelists
Switch Role
On a (standalone) master switch with no local switches:
Campus AP Whitelist
Master Switch
Whitelist
The campus AP whitelist contains entries for the secure campus
APs associated with that switch.
The master switch whitelist is empty, and does not appear in the
WebUI.
On a master switch with local switches:
On a local switch:
The campus AP whitelist contains an entry for every secure campus AP on the network, regardless of the switch to which it is connected.
The master switch whitelist is empty, and does not appear in the
WebUI.
The campus AP whitelist contains an entry for every secure campus AP on the network, regardless of the switch to which it is connected.
The master switch whitelist contains the
MAC and the IP addresses of the master switch.
Local Switch
Whitelist
The local switch whitelist is empty, and does not appear in the WebUI.
The local switch whitelist contains an entry for each associated local switch.
The local switch whitelist is empty, and does not appear in the WebUI.
Figure 6 Local Switch Whitelist on a Master Switch
If your deployment includes both master and local switches, then the campus AP whitelist on every switch contains an entry for every secure AP on the network, regardless of the switch to which it is connected. The master switch also maintains a whitelist of local switches using control plane security. When you change a campus AP whitelist on any switch, that switch contacts the other connected switches to notify them of the change.
The master switch whitelist on each local switch contains the IP and MAC addresses of its master switch. If your network has a redundant master switch, then this whitelist contains more than one entry. You rarely need to delete the master switch whitelist. Although you can delete an entry from the master switch whitelist, you should do so only if you have removed a master switch from the network.
Campus AP Whitelist Synchronization
The current sequence number in the AP Whitelist Sync Status field shows the number of changes to the campus AP whitelist made on that switch. Each switch compares its campus AP whitelist against whitelists on other switches every two minutes by default. If a switch detects a difference, it sends its changes to the other switches on the network. If all other switches on the network have successfully received and acknowledged all whitelist changes made on that switch, every entry in the sequencenumber column in the local switch or master switch whitelists has the same value as the sequence number displayed in the AP Whitelist Sync
67 | Control Plane Security AOS-W 6.5.3.x | User Guide
Status field. If a switch in the master or local switch whitelist has a lower sequence number, that switch may still be waiting to complete its update, or receive its update acknowledgment. In the example in
, the master switch has a current sequence number of 3, and each sequence number in its local switch whitelist also shows a value of 3, indicating that both local switches have received and acknowledged all three campus AP whitelist changes made on the master switch. For additional information on troubleshooting whitelist synchronization, see
Verifying Whitelist Synchronization on page 78 .
You can view a switch’s current sequence number via the CLI:
(host) #show whitelist-db cpsec-seq
Viewing the Master or Local Switch Whitelists
The following sections describe the commands to view and delete entries in a master or local switch whitelist.
In the WebUI
To view the master or local switch whitelists:
1. Access the switch’s WebUI, and navigate to Configuration > AP Installation.
2. Select the Whitelist tab.
The master and local switch tables each include the following information:
Table 22: Master and Local Switch Whitelist Information
Field
MAC-Address
Description
On a local switch whitelist: MAC address of the master switch.
On a master switch whitelist: MAC address of a local switch.
IP-Address
Sequence Number
Remote Sequence Number
Null Update Count
On a local switch whitelist: IP address of the master switch.
On a master switch whitelist: IP address of a local switch.
The number of times the switch in the whitelist received and acknowledged a campus AP whitelist change from the switch whose WebUI you are currently viewing.
For deployments with both master and local switches: n
The sequence number on a master switch should be the same as the remote sequence number on the local switch.
n The sequence number on a local switch should be the same as the remote sequence number on the master switch.
The number of times that the switch whose WebUI you are viewing received and acknowledged a campus AP whitelist change from the switch in the whitelist.
For deployments with both master and local switches: n n
The remote sequence number on a master switch should be the same as the sequence number on the local switch.
The remote sequence number on a local switch should be the same as the sequence number on the master switch.
The number of times the switch checked its campus AP whitelist and found nothing to synchronize with the other switch. The switch compares its control plane security whitelist against whitelists on other switches every two minutes by default. If the null update count reaches five, the switch sends an
“empty sync” heartbeat to the remote switch to ensure the sequence numbers on both switches are the same, then resets the null update count to zero.
AOS-W 6.5.3.x
| User Guide Control Plane Security | 68
In the CLI
To view the master or local switch whitelists via the command-line interface, issue the following commands:
(host) #show whitelist-db cpsec-master-switch-list [mac-address <mac-address>]
(host) #show whitelist-db cpsec-local-switch-list [mac-address <mac-address>]
Deleting an Entry from the Master or Local Switch Whitelist
You do not need to delete a master switch from the master switch whitelist during the course of normal operation. However, if you remove a local switch from the network, you should also remove the local switch from the local switch whitelist on the master switch. If the local switch whitelist contains entries for switches no longer on the network, then a campus AP whitelist entry can be marked for deletion but is not physically deleted, as the switch is waiting for an acknowledgment from another switch no longer on the network. This can increase network traffic and reduce memory resources on the switch.
In the WebUI
To delete an entry from the master or local switch whitelist:
1. Navigate to Configuration > Switch.
2. Select the Control Plane Security tab.
3. To delete an entry from the Local Switch Whitelist: In the Local Switch List For AP Whitelist Sync section, click the Delete button by each switch entry you want to remove.
Or,
To delete an entry from the Master Switch Whitelist: In the Master Switch List For AP Whitelist Sync section, click Delete by each switch entry you want to remove.
4. Click Apply .
In the CLI
To delete an entry from the master or local switch whitelist:
(host) #whitelist-db cpsec-master-switch-list del mac-address <mac-address>
(host) #whitelist-db cpsec-local-switch-list del mac-address <mac-address>
Purging the Master or Local Switch Whitelist
There is no need to purge a master switch whitelist during the course of normal operation. If, however, you are removing a switch from the network, you can purge its switch whitelist after it has been disconnected from the network. To clear a local switch whitelist entry on a master switch that is still connected to the network, select that individual whitelist entry and delete it using the delete option.
In the WebUI
To purge a switch whitelist:
1. Navigate to Configuration > Switch .
2. Select the Control Plane Security tab.
3. To clear the Local Switch whitelist: In the Local Switch List For AP Whitelist Sync section, click Purge.
Or,
4. To clear the Master Switch whitelist: In the Master Switch List For AP Whitelist Sync section, click
Purge .
69 | Control Plane Security AOS-W 6.5.3.x | User Guide
In the CLI
To purge a switch whitelist:
(host) #whitelist-db cpsec-master-switch-list purge
(host) #whitelist-db cpsec-local-switch-list purge
Working in Environments with Multiple Master Switches
This section describes the configuration steps required in a multiple master switches network.
Configuring Networks with Clusters of Master Switches
If your network includes multiple master switches each with their own hierarchy of APs and local switches, you can allow APs from one hierarchy to failover to any other hierarchy by defining a cluster of master switches.
Each cluster has one master switch as its cluster root, and all other master switches as cluster members. The master switch operating as the cluster root creates a self-signed certificate, then certifies its own local switches and APs. Next, the cluster root sends a certificate to each cluster member, which in turn certifies its own local switches and APs. Because all switches and APs in the cluster have the same trust anchor, the APs can switch to any other switch in the cluster and still remain securely connected to the network.
Figure 7 A Cluster of Master Switches using Control Plane Security
To create a switch cluster, you must first define the root master switch and set an IPsec key or select a certificate for communications between the cluster root and cluster members.
You must use the command-line interface to configure certificate authentication for cluster members. The WebUI supports cluster authentication using IPsec keys only. If your master and local switches use a pre-shared key for authentication, they create the IPsec tunnel using IKEv1. If your master and local switches use certificates for authentication, the IPsec tunnel is created using IKEv2.
Creating a Cluster Root
Use the WebUI to identify a switch as a cluster root, and use an IPsec key to secure communication between the cluster root and cluster members. Use the command-line interface to create a cluster root using an IPsec key, factory-installed certificate, or custom certificate.
In the WebUI
To create a cluster root:
AOS-W 6.5.3.x
| User Guide Control Plane Security | 70
1. Access the WebUI of the switch you want to identify as the cluster root, and navigate to Configuration >
Switch .
2. Click the Cluster Setting tab.
3. For the cluster role, select Root.
4. In the Cluster Member IPsec Keys section, enter the switch IP address of a member switch in the cluster.
If you want to use a single key for all member switches, use the IP address 0.0.0.0
.
5. In the IPsec Key and Retype IPsec Key fields, enter the IPsec key for communication between the specified member switch and the cluster root.
6. Click Add .
7.
Optional : repeat steps 4-6 to add another member switch to the cluster.
8. Click Apply.
In the CLI
To create a cluster root, access the command-line interface of the switch you want to identify as the root of the switch cluster, then issue one of the following commands: n n n
To authenticate cluster members using a custom certificate:
(host)(config) #cluster-member-custom-cert member-mac <mac> ca-cert <ca> server-cert <cert> suite-b <gcm-128|gcm-256>]
To authenticate cluster members using a factory-installed certificate:
(host)(config) #cluster-member-factory-cert member-mac <mac>
To authenticate cluster members using an IPsec key:
(host)(config) #cluster-member-ip <ip-address> ipsec <key>
The <ip-address> parameter in this command is the IP address of a member switch in the cluster, and the <key> parameter in each command is the IPsec key for communication between the specified member switch and the cluster root. Use the IP address 0.0.0.0
in this command to set a single IPsec key for all member switches, or repeat this command as desired to define a different IPsec key for each cluster member.
Creating a Cluster Member
Once you have identified the cluster root, you must then identify the member switches in the cluster.
Use the WebUI to identify a switch as a cluster member, and use an IPsec key to secure communication between the cluster member and the cluster root. Use the command-line interface to create a cluster member and secure communications between that member and the cluster root using an IPsec key, factory-installed certificate, or custom certificate.
In the WebUI
To create a cluster member:
1. Access the WebUI of the cluster member switch, and navigate to Configuration > Switch.
2. Click the Cluster Setting tab.
3. For the cluster role, select Member .
4. In the Switch IP Address field, enter the IP address of the root switch in the cluster.
5. In the IPsec Key and Retype IPsec Key fields, enter the IPsec key for communication between the specified member switch and the cluster root. This parameter must be have the same value as the key defined for the cluster member in
Creating a Cluster Root on page 70
.
6. Click Add .
7. Click Apply .
71 | Control Plane Security AOS-W 6.5.3.x | User Guide
In the CLI
To create a cluster root via the CLI, access each of the member master switches and define the IPsec key or certificate for communication between that switch and the cluster root.
(host)(config) #cluster-root-ip <ip-address> ipsec <key> ipsec-custom-cert root-mac-1 <root-mac-address-1> [master-mac2 <mac2>] ca-cert <ca> servercert <cert> [suite-b <gcm-128 | gcm-256>] ipsec-factory-cert root-mac-1 <root-mac-address-1> root-mac-2 <root-mac-address-2>
In this command the <ip-address> parameter is the IP address of the root master switch in the cluster. If you are using an IPsec key, the <key> parameter in this command must be have the same value as the key defined for the cluster member via the cluster-member-ip command.
Viewing Switch Cluster Setting
You can view the switch cluster configuration using the WebUI or CLI.
In the WebUI
To view the current cluster configuration:
1. Navigate to Configuration > Switch .
2. Click the Cluster Setting tab.
n
If you are viewing the WebUI of a cluster root, the output of this command displays the IP address of the
VLAN on the cluster member used to connect to the cluster root.
n
If you are viewing the WebUI of a cluster member, the output of this command displays the IP address of the VLAN on the cluster root used to connect to the cluster member.
In the CLI
To view your current cluster configuration, issue the CLI commands described in
Table 23: CLI Commands to Display Cluster Settings
Command show cluster-switches show cluster-config
Description
When you issue this command from the cluster root , the output of this command displays the IP address of the VLAN the cluster member uses to connect to the cluster root.
If you issue this command from a cluster member , the output of this command displays the IP address of the VLAN the cluster root uses to connect to the cluster member.
When you issue this command from the cluster root , the output of this command shows the cluster role of the switch, and the IP address of each active member switch in the cluster.
When you issue this command from a cluster member , the output of this command shows the cluster role of the switch, and the IP address of the cluster root.
Configuring Networks with a Backup Master Switch
If your network includes a redundant backup master switch, you must synchronize the database from the primary master to the backup master at least once after all APs are communicating with their switches over a secure channel. This ensures that all certificates, IPsec keys, and campus AP whitelist entries are synchronized to the backup switch. You should also synchronize the database any time the campus AP whitelist changes (APs are added or removed to ensure that the backup switch has the latest settings).
Master and backup switches can be synchronized using either of the following methods:
AOS-W 6.5.3.x
| User Guide Control Plane Security | 72
n n
Manual Synchronization : Issue the database synchronize command in enable mode to manually synchronize databases from your primary switch to the backup switch.
Automatic Synchronization : Schedule automatic database backups using the database synchronize period command in configuration mode.
If you add a new backup switch to an existing switch, you must add the backup switch as the lower priority switch. If you do not add the backup switch as a lower priority switch, your control plane security keys and certificates may be lost. If you want the new backup switch to become your primary switch, increase the priority of that switch to a primary switch after you have synchronized your data.
Replacing a Switch on a Multi-Switch Network
The procedure to replace a switch within a multi-switch network varies, depending upon the role of that switch, whether the network has a single master switch or a cluster of master switches, and whether or not the switch has a backup.
The following sections describe the steps to replace an existing switch. To add a new local switch to a network, or to permanently remove a local switch without replacing it, see
Viewing the Master or Local Switch Whitelists on page
.
Replacing Switches in a Single Master Network
Use the procedures in this section to replace a master or local switch in a network environment with a single master switch.
Replacing a Local Switch
Use the following procedure to replace a local switch in a single-master network:
1. Disconnect the local switch from the network.
2. If you plan on moving the local switch to another location on the network, purge the campus AP whitelist on the switch.
Access the command-line interface on the old local switch and issue the whitelist-db cpsec purge command.
or,
Access the local switch WebUI, navigate to Configuration > AP Installation > Campus AP Whitelist and click Purge .
3. Once you purge the campus AP whitelist, you must inform the master switch that the local switch is no longer available using one of these two methods:
This step is very important ; unused local switch entries in the local switch whitelist can significantly increase network traffic and reduce switch memory resources.
n n
Access the command-line interface on the master switch, and issue the whitelist-db cpsec-localswitch-list del mac-address <local--mac> command.
Access the master switch WebUI, navigate to Configuration > Switch > Control Plane Security , select the entry for the local switch you want to delete from the local switch whitelist, and click Delete .
4. Install the new local switch, but do not connect it to the network yet. If the switch has been previously installed on the network, you must ensure that the new local switch has a clean whitelist.
5. Purge the local switch whitelist using one of the following two methods: n
Access the command-line interface on the new local switch and issue the whitelist-db cpsec purge command.
73 | Control Plane Security AOS-W 6.5.3.x | User Guide
n
Access the local switch WebUI, navigate to Configuration > AP Installation > Campus AP Whitelist and click Purge .
6. Now connect the new local switch to the network. It is very important that the local switch be able to contact the master switch the first time it connects to the network, because the master switch certifies the local switch's control plane security certificate the first time the local switch contacts its master.
7. Once the local switch has a valid control plane security certificate and configuration, the local switch receives the campus AP whitelist from the master switch and starts certifying approved APs.
8. APs associated with the new local switch reboots and creates new IPsec tunnels to their switch using the new certificate keys.
Replacing a Master Switch with No Backup
Use the following procedure to replace a master switch that does not have a backup switch:
1. Remove the old master switch from the network.
2. Install and configure the new master switch, then connect the new master to the network. The new master switch generates a new certificate when it first becomes active.
3. If the new master switch has a different IP address than the old master switch, change the master IP address on the local switches to reflect the address of the new master.
4. Reboot each local switch to ensure the local switches obtain their certificate from the new master. Each local switch begins using a new certificate signed by the master switch.
5. APs are now no longer able to securely communicate with the switch using their current key, and must obtain a new certificate. Access the campus AP whitelist on any local switch, and change all APs in a
“certified” state to an “approved” state. The new master switch sends the approved APs new certificates.
The APs reboot and create new IPsec tunnels to their switch using the new certificate key.
If the master switch does not have any local switches, you must recreate the campus AP whitelist by turning on automatic certificate provisioning or manually reentering the campus AP whitelist entries.
Replacing a Redundant Master Switch
The control plane security feature requires you to synchronize databases from the primary master switch to the backup master switch at least once after the network is up and running. This ensures that all certificates, keys, and whitelist entries are synchronized to the backup switch. Because the AP whitelist may change periodically, you should regularly synchronize these settings to the backup switch. For details, see
Networks with a Backup Master Switch on page 72
.
When you install a new backup master switch, you must add it as a lower priority switch than the existing primary switch. After you install the backup switch on the network, synchronize the database from the existing primary switch to the new backup switch to ensure that all certificates, keys, and whitelist entries required for control plane security are added to the new backup switch configuration. If you want the new switch to act as the primary switch, you can increase that switch’s priority after the settings have been synchronized.
Replacing Switches in a Multi-Master Network
Use the following procedures to replace a master or local switch in a network environment with a multiple master switches.
Replacing a Local Switch in a Multi-Master Network
The procedure to replace a local switch in a network with multiple master switches is the same as the procedure to replace a local switch in a single-master network. To replace a local switch in a multi-master network, follow the procedure described in
Replacing a Local Switch on page 73
AOS-W 6.5.3.x
| User Guide Control Plane Security | 74
Replacing a Cluster Member Switch with no Backup
The control plane security feature allows APs to fail over from one switch to another within a cluster. Therefore, cluster members or their local switches may have associated APs that were first certified under some other cluster member (or the cluster root). If you permanently remove a cluster member whose APs were all originally certified under the cluster member being removed, its associated APs do not need to reboot in order to connect to a different switch. If, however, you remove a cluster member whose associated APs were originally certified under a different cluster member, those APs need to reboot and be re-certified before they can connect to a different switch. If the cluster member you are removing has local switches, the local switches also reboot so they can be updated with new certificates, then pass the trust update to their terminating APs.
To replace a cluster member that does not have a backup switch:
1. On the cluster master to be removed, clear the cluster root IP address by accessing the command-line interface and issuing the no cluster-root-ip <cluster-root-ip> ipsec <clusterkey> command.
2. Remove the cluster member from the network.
3. If the cluster master you removed has any associated APs, you must reboot those APs so they receive an updated certificate.
4. If the cluster member you removed has any associated local switches, reboot those local switches so they receive a new certificate and then pass that trust update to their APs.
5. Remove the cluster master from the cluster root’s master switch list by accessing the command-line interface on the cluster root and issuing the whitelist-db cpsec-master-switch-list del mac-address
<cluster-master-mac> command.
This step is very important . Unused local switch entries in the local switch whitelist can significantly increase network traffic and reduce switch memory resources.
6. Remove the old cluster member from the network. Remember, that switch still has campus AP whitelist entries from the entire cluster. You may want to delete or revoke unwanted entries from the campus AP whitelist.
Now, you must install the new cluster member switch according to the procedure described in
. The new cluster member obtains a certificate from the cluster root when it first becomes active.
7. If the new cluster member has any associated APs, reboot those APs so they obtain a trust update.
8. If the new cluster member has any local switches, reboot the local switches associated with the new cluster member. The local switches obtain a new certificate signed by the cluster member, and then pass that trust update to their associated APs.
Replacing a Redundant Cluster Member Switch
The control plane security feature requires you to synchronize databases from the primary switch to the backup switch at least once after the network is up and running. This ensures that all certificates, keys, and whitelist entries are synchronized to the backup switch. Because the AP whitelist may change periodically, you should regularly synchronize these settings to the backup switch. For details, see
Backup Master Switch on page 72 .
When you install a new backup cluster member, you must add it as a lower priority switch than the existing primary switch. After you install the backup cluster member on the network, resynchronize the database from the existing primary switch to the new backup switch to ensure that all certificates, keys, and whitelist entries required for control plane security are added to the new backup switch configuration. If you want the new switch to act as the primary switch, you can increase that switch’s priority after the settings have been resynchronized.
75 | Control Plane Security AOS-W 6.5.3.x | User Guide
Replacing a Cluster Root Switch with no Backup Switch
If you replace a cluster root switch that does not have a backup switch, the new cluster root switch creates its own self-signed certificate. You then need to reboot each switch in the hierarchy in a specific order to certify all
APs with that new certificate:
1. Remove the old cluster root from the network.
2. Install and configure the new cluster root.
3. Connect the new cluster root to the network so it can access cluster masters and local switches.
4. If necessary, reconfigure the cluster masters and local switches with their new cluster root IP and master IP addresses.
5. Reboot every cluster member switch. The cluster member begins using a new certificate signed by the cluster root.
6. Reboot every local switch. Each local switch begins using a new certificate signed by the cluster member.
7. Because the cluster root is new, it does not have a configured campus AP whitelist. Access the campus AP whitelist on any local switch or cluster master, and change all APs in a “certified” state to an “approved” state. The APs get re-certified, reboot, and create new IPsec tunnels to their switch using the new certificate key.
If a cluster root switch does not have any cluster master or local switches, you must recreate the campus AP whitelist on the cluster root by turning on automatic certificate provisioning or manually reentering the campus AP whitelist entries.
Replacing a Redundant Cluster Root Switch
Best practices is to use a backup switch with your cluster root switch. If your cluster root has a backup switch, you can replace the backup cluster root without having to reboot all cluster master and local switches, minimizing network disruptions.
The control plane security feature requires you to synchronize databases from the primary switch to the backup switch at least once after the network is up at running. This ensures that all certificates, keys, and whitelist entries are synchronized to the backup switch. Because the AP whitelist may change periodically, you should regularly synchronize these settings to the backup switch. For details, see
Backup Master Switch on page 72 .
When you install a new backup cluster root, you must add it as a lower priority switch than the existing primary switch. After you install the backup cluster root on the network, resynchronize the database from the existing primary switch to the new backup switch to ensure that all certificates, keys, and whitelist entries required for control plane security are added to the new backup switch configuration. If you want the new switch to act as the primary switch, you can increase that switch’s priority after the settings have been resynchronized.
Configuring Control Plane Security after Upgrading
When you initially deploy a switch running AOS-W 6.0 or later, create your initial control plane security configuration using the initial setup wizard. However, if you are upgrading to AOS-W 6.0 from AOS-W 3.4.x or earlier releases, or if you are upgrading from AOS-W 5.0
but did not yet have control plane security enabled before the upgrade , then you can use the strategies described in
to enable and configure control plane security feature.
If you upgrade a switch running AOS-W 5.0.x to AOS-W 6.0 or later, then the switch’s control plane security settings do not change after the upgrade. If control plane security was already enabled, then it remains enabled after the upgrade. If it was not enabled previously, but you want to use the feature after upgrading, then you must manually enable it.
AOS-W 6.5.3.x
| User Guide Control Plane Security | 76
Table 24: Control Plane Security Upgrade Strategies
Automatically send Certificates to Campus
APs
1. Access the control plane security window and enable both the control plane security feature and the auto certificate provisioning option. Next, specify whether you want all associated campus APs to automatically receive a certificate, or if you want to certify only those APs within a defined range of IP addresses.
2. Once all APs have received their certificates, disable auto certificate provisioning to prevent certificates from being issued to any rogue APs that may appear on your network at a later time.
Manually Certify Campus APs
1. Identify the campus APs that should receive certificates by entering the campus APs’ MAC addresses in the campus AP whitelist.
2. If your network includes both master and local switches, wait a few minutes, then verify that the campus AP whitelist has been propagated to all other switches on the network. Access the WebUI of the master switch, navigate to Configuration >
Switch > Control Plane Security , then verify that the Current Sequence Number field has the same value as the Sequence Number entry for each local switch in the local switch whitelist. (For details, see
Verifying Whitelist Synchronization on page 78
.)
3. Enable the control plane security feature.
3. If a valid AP did not receive a certificate during the initial certificate distribution, you can manually certify the AP by adding that MAC address of the AP to the campus AP whitelist. You can also use this whitelist to revoke certificates from APs that should not be allowed access to the secure network.
If you upgraded your switch from AOS-W 5.0 or earlier and you want to use this feature for the first time, you must either add all valid APs to the campus AP whitelist, or enable automatic certificate provisioning before you enable the feature . If you do not enable automatic certificate provisioning, only the APs currently approved in the campus AP whitelist are allowed to communicate with the switch over a secure channel. Any APs that do not receive a certificate will not be able to communicate with the switch except to request a certificate.
Troubleshooting Control Plane Security
Identifying Certificate Problems
If an AP has a problem with its certificate, check the state of the AP in the campus AP whitelist. If the AP is in either the certified-hold-factory-cert or certified-hold-switch-cert states, you may need to manually change the status of that AP before it can be certified.
n n certified-hold-factory-cert : An AP is put in this state when the switch thinks the AP has been certified with a factory certificate, but the AP requests to be certified again. Because this is not a normal condition, the AP is not approved as a secure AP until you manually change the status of the AP to verify that it is not compromised. If an AP is in this state due to connectivity problems, then the AP recovers and is taken out of this hold state as soon as connectivity is restored.
certified-hold-switch-cert : An AP is put in this state when the switch thinks the AP has been certified with a switch certificate yet the AP requests to be certified again. Because this is not a normal condition, the AP is not be approved as a secure AP until a network administrator manually changes the status of the AP to verify that it is not compromised. If an AP is in this state due to connectivity problems, then the AP recovers and is taken out of this hold state as soon as connectivity is restored.
77 | Control Plane Security AOS-W 6.5.3.x | User Guide
Disabling Control Plane Security
If you disable control plane security on a standalone or local switch, all APs connected to that switch reboot then reconnect to the switch over a clear channel.
If your disable control plane security on a master switch, APs directly connected to the master switch reboot then reconnect to the master switch over a clear channel. However, its local switches continue to communicate with their APs over a secure channel until you save your configuration on the master switch. Once you save the configuration, the changes are pushed down to the local switches. At that point, any APs connected to the local switches also reboot and reconnect over a clear channel.
Verifying Whitelist Synchronization
To verify that a network of master and local switches are correctly sharing their campus AP whitelists, check the sequence numbers on the master and local switch whitelists.
n n
The sequence number value on a master switch should be the same as the remote sequence number on the local switch.
The sequence number value on a local switch should be the same as the remote sequence number on the master switch.
Figure 8 Sequence numbers on Master and Local Switches
Rogue APs
If you enable auto certificate provisioning enabled with the Auto Cert Allow All option, any AP that appears on the network receives a certificate. If you notice unwanted or rogue APs connecting to your switch via an
IPsec tunnel, verify that automatic certificate provisioning has been disabled, then manually remove the unwanted APs by deleting their entries from the campus AP whitelist.
AOS-W 6.5.3.x
| User Guide Control Plane Security | 78
Chapter 3
Software Licenses
AOS-W supports a variety of optional add-on licenses that enhance the base OS, and provide advanced features including as wireless intrusion protection, advanced cryptography, policy-based traffic management and controls, web content classification and stateful user firewalls.
AOS-W supports a centralized licensing architecture, which allows a group of connected switches to share a pool of licenses. A primary and backup service switch can share a single set of licenses, eliminating the need for a redundant license set on the backup server. Local licensing client switches maintain information sent from the licensing server, even if the licensing client switch and the licensing server switch can no longer communicate.
Getting Started with AOS-W Licenses
This chapter describes AOS-W license types and licensing features, and lists the procedures to configure a licensing solution.
Learn more about Licenses and Licensing Features
Select any of the links below to view detailed information about AOS-W license types, licensing features and examples of deployment topologies that support these features.
n n n
License Types and Usage on page 79
Licensing Best Practices and Limitations on page 82
Centralized Licensing Overview on page 83
Configure a Licensing Management Solution
The following sections describe the procedures to configure centralized licensing clusters and licensing pools, and to add, remove, and monitor individual licenses.
n n n n
Configuring Centralized Licensing on page 89
Installing a License on page 91
Monitoring and Managing Centralized Licenses on page 94
License Types and Usage
Licenses are platform independent and can be installed on any switch. Installation of the feature license unlocks that feature’s functionality for the maximum capacity of the switch.
lists the license types, and describe how licenses are consumed on the Switches.
AOS-W 6.5.3.x
| User Guide Software Licenses | 79
Table 25: Usage per License
License
AP
Usage Basis
AP
ACR
CSS
PEFNG
PEFV
PoE
RFprotect xSec
WebCC
Client Session
Client Session
AP
Switch
Switch
AP
Client/session
AP
What Consumes One License
An AP license is required for each operational LAN-connected, mesh, or remote AP, or that is advertising at least one BSSID
(virtual-AP)
This license enables AOS-W Advanced Cryptography (ACR) features. A license is required for each active client termination using Suite-B algorithms or protocols.
The Content Security Service (CSS) license provides cloud-based security for branch offices and teleworkers. This license is administered based on the number of clients using this service.
One operational AP using one or more Policy Enforcement Firewall
(PEF) features, such as intelligent application identification, policybased traffic management and controls, or stateful user firewalls.
The PEFV license allows a network administrator to apply firewall policies to clients using a VPN to connect to the switch. This license is mandatory for the Aruba VIA VPN client, but optional for all other
VPN clients. The PEFV license is purchased as a single license that enables the functionality up to the full user capacity of the switch.
This license enables support for Power over Ethernet PoE. Each license enables PoE on a port on the switch.
An RFProtect license is required for each operational AP using one or more RF Protect features, such as spectrum analysis and wireless intrusion protection (WIP).
One active client termination using Extreme Security (xSec), a cryptographically secure, Layer-2 tunneling network protocol implemented over the 802.1X protocol.
The Web Content Classification (WebCC) license is a subscriptionbased, per-AP license that supports web content classification features on an AP for the duration of the subscription period (up to
10 years per license)
Sharable vs Switch-Specific Licenses
Many licenses are consumed on a per-AP or per-user basis. These license types can be shared by a group of switches using the same centralized licensing server. The licenses that are specific to an individual switch cannot be shared among switches via centralized licensing.
Table 26: Sharable Licenses vs Switch-Specific Licenses
Sharable via a Licensing Pool Switch-Specific License
AP CSS
ACR
PEFNG
PEFV
PoE
80 | Software Licenses AOS-W 6.5.3.x | User Guide
Sharable via a Licensing Pool
RF Protect xSec
WebCC
Switch-Specific License
Evaluation vs Permanent Licenses
Each license can be either an evaluation or permanent license. A permanent license permanently enables the desired software module on a specific Alcatel-Lucent switch. You obtain permanent licenses through the sales order process only. Permanent software license keys are sent to you via email. An evaluation license allows you to evaluate the unrestricted functionality of a software module on a specific switch for 90 days (in three 30-day increments). An expired evaluation license will remain in the license database until the switch is reset using the command write erase all where all license keys are removed. An expired evaluation license has no impact on the normal operation of the switch, but it is kept in the license database to prevent abuse.
Evaluation licenses can be added on the services switch and made sharable within a licensing pool. When a sharable evaluation license is locally installed on a client switch, those license limits will be sent to the licensing server and added to the license pool as long as the evaluation period is active. When the evaluation period expires, the client with the expired license sends its revised limits to the license server. The licensing server removes the evaluation licenses from its license table, then sends updated license pool information to other clients on the network.
To determine your remaining time on an evaluation license, select the Alert flag ( )in the WebUI title bar. The
WebUI displays information about evaluation license status.
When an evaluation period expires: l
The switch automatically backs up the startup configuration and reboots itself at midnight (according to the system clock).
l
All permanent licenses are unaffected. The expired evaluation licensed feature is no longer available and is displayed as Expired in the WebUI.
Perpetual vs Subscription Licenses
A perpetual license is a purchased license that has no end date; once installed, it does not expire. Most purchased licenses are perpetual licenses. However, the Web Content and Classification (WebCC) license is a subscription license that enables WebCC features only for the duration of the subscription (1,3,5,7 or 10 years). The subscription time period starts from the time license key is generated from the licensing website.
Thirty days before the license period expires, an alert appears in the banner in the switch WebUI, warning the user that the license is ready to expire. After the license expiration date is passed, the license continues to operate as an active license for an extended grace period of 120 days. After this final grace period elapses, the license permanently expires.
Subscription licenses cannot be renewed, Once a license subscription expires, a new license subscription key must be generated and installed on the switch.
Starting with AOS-W 6.5.1, if one or more subscription WebCC licenses expire so that a switch has fewer active
WebCC subscription licenses than AP licenses, that switch will no longer be able to download WebCC updates from the cloud or perform classification using cloud lookup. The APs associated to that device can, however, continue to use the cached WebCC date currently on the switch. This has been changed from AOS-W 6.5.0, where an expired WebCC license did not impact AP or switch behavior.
AOS-W 6.5.3.x
| User Guide Software Licenses | 81
Switch License Capacity
The switch licenses are variable-capacity (see
).
In
, the total AP count is a combination of Campus AP count and Remote AP count.
Table 27: Switch AP Capacity
Switch
OAW-4550
OAW-4650
OAW-4750
OAW-4750XM
OAW-4450
OAW-4030
OAW-4024
OAW-4010
OAW-4005
Total AP Count
512
1024
2048
2048
256
64
32
32
16 n n n n n
Licensing Best Practices and Limitations
When calculating AP licenses, determine the normal AP load of your switch and add a backup load in case of failure. A reasonable estimate when calculating user licenses is 20 users per AP. Do not forget to consider occasional large assemblies or gatherings, and allow for the maximum quantity required at any given time.
All active APs run AP, PEFNG and RFProtect services (if enabled). If your switch does not have equal amounts of these licenses, the number of active APs are restricted to the lowest number of AP, PEFNG or
RFProtect licenses.
If a Mesh node is configured for client service (for example, it advertises a BSSID ), it consumes one AP license. Mesh nodes with no virtual APs do not consume an RFProtect license.
Back up the switch’s configuration ( backup flash command) and back up the license database ( license export filename ) before making any changes.
(host) # backup flash
Please wait while we tar relevant files from flash...
Please wait while we compress the tar file...
Checking for free space on flash...
Copying file to flash...
File flashbackup.tar.gz created successfully on flash.
Please copy it out of the switch and delete it when done.
(host) # license export licensebackup.db
Successfully exported 1 licenses from the License Database to licensebackup.db
Issuing the write erase all command resets the switch to factory default and deletes all databases on the switch, including the license key management database. You must reinstall all previously-installed license keys. Issuing the write erase command on a switch running software licenses does not affect the license key management database on the switch. Rebooting or resetting a switch has no effect on a license.
82 | Software Licenses AOS-W 6.5.3.x | User Guide
n n
When you apply evaluation license keys on a switch, abnormal tampering of the device’s system clock (such as setting back the system clock) results in the disabling of software licensed modules and their supported features. This can affect network services.
The Advanced Cryptography (ACR) license includes the following caveats: l
On a platform that supports 2048 IPsec tunnels, the maximum number of Suite B IPsec tunnels supported is 2048, even if a larger capacity license is installed.
l l l l
ACR licenses are cumulative. For example, if you want to support 2048 Suite B connections, you can install two ACR licenses that support 1024 connections each.
If your switch uses an ACR license that allows fewer IPsec tunnels that is supported by that switch platform, that switch can still support IPsec tunnels using non-Suite B modes (for example, AES-CBC), up to the platform maximum.
The ACR license allows a switch to use both IPsec Suite B and 802.11i Suite B connections simultaneously. The combined number of these sessions may not exceed the ACR license maximum.
A single client using both 802.11i Suite B and IPsec Suite B connections will simultaneously consume two
ACR licenses.
AOS-W provides the ability to move a license from one standalone switch to another, for maximum flexibility in managing an organization’s network and to minimize an RMA impact. Alcatel-Lucent monitors and detects license fraud. Abnormally high volumes of license transfers for the same license certificate to multiple switches can indicate a breach of the Alcatel-Lucent end user software license agreement and will be investigated.
Centralized Licensing Overview
In order to configure a license-dependent feature on the local switch, the master switch(s) must be licensed for each of the features configured on the local switches. Centralized licensing simplifies licensing management by distributing licenses installed on one switch to other switches on the network. One switch acts as a centralized license database for all other switches connected to it, allowing all switches to share a pool of unused licenses.
The primary and backup licensing servers can share a single set of licenses, eliminating the need for a redundant license set on the backup server. Local licensing client switches maintain information sent from the licensing server, even if the licensing client switch and the licensing server switch can no longer communicate. If an AP fails over from one client switch to another, the AP will be allowed to come up even if there aren’t sufficient licenses present on the backup switch. the APs continue to stay active until they reboot. However, if there are not sufficient available licenses to bring up an AP after it reboots, that AP will not become active.
You can use the centralized licensing feature in a master-local topology with a redundant backup master, or in a multi-master network where all the masters can communicate with each other (for example, if they are all connected to a single OmniVista server). In the master-local topology, the master switch acts as the primary licensing server, and the redundant backup master acts as the backup licensing server. In a multi-master network, one switch must be designated as a primary server, and a second switch must be configured as a backup licensing server.
Centralized licensing can distribute the following license types: n n n n n
AP
PEFNG
RFProtect xSec
ACR
This section includes the following topics: n
Primary and Backup Licensing Servers
AOS-W 6.5.3.x
| User Guide Software Licenses | 83
n n n n
Communication between the License Server and License Clients
Configuring Centralized Licensing
Primary and Backup Licensing Servers
Centralized licensing allows the primary and backup licensing server switches to share a single set of licenses. If you do not enable this feature, the master and backup master switch each require separate, identical license sets. The two switches acting as primary and backup license servers must use the same version of AOS-W and must be connected on the same broadcast domain using the Virtual Router Redundancy Protocol (VRRP).
Other client switches on the network connect to the licensing server using the VRRP virtual IP address configured for that set of redundant servers. The primary licensing server uses the configured virtual IP address by default. However, if the switch acting as the primary licensing server becomes unavailable, the secondary licensing server will take ownership of the virtual IP address, allowing licensing clients to retain seamless connectivity to a licensing server.
Only one backup licensing server can be defined for each primary server.
The example below shows a primary and backup license server connected using VRRP. Licenses installed on either the primary or backup server are shared between that pair of servers. If the primary and backup switches each had 16 AP licenses, 16 PEFNG licenses, and 16 xSec licenses installed, they would share a combined pool of 32 AP, 32 PEFNG, and 32 xSec licenses. Any license client switches connected to this pair of redundant servers could also use licenses from this license pool.
Figure 9 Shared Licenses on a Primary and Backup Licensing Server
Communication between the License Server and License Clients
When you enable centralized licensing, information about the licenses already installed on the individual client switches are sent to the licensing server, where they are added into the server’s licensing table. The information in this table is then shared with all client switches as a pool of available licenses. When a client switch uses a
84 | Software Licenses AOS-W 6.5.3.x | User Guide
license in the available pool, it communicates this change to the licensing server master switch, which updates the table before synchronizing it with the other clients.
Client switches do not share information about built-in licenses to the licensing server. A switch using the centralized licensing feature will use its built-in licenses before it consumes available licenses from the license pool. As a result, when a client switch sends the licensing server information about the licenses that a client is using, it only reports licenses taken from the licensing pool, and disregards any built-in licenses used. For example, if a switch has a built-in 16-AP license and twenty connected APs, it will disregard the built-in licenses being used and report to the licensing server that it is using only four AP licenses from the license pool.
When centralized licensing is first enabled on the licensing server, its licensing table only contains information about the licenses installed on that server. When the clients contact the server, the licensing server adds the client licenses to the licensing table, then sends the clients information about the total available licenses for each license type. In the following example, the licenses installed on two client switches are imported into the license table on the license server. The licensing server then shares the total number of available licenses with other switches on the network.
Figure 10 Licenses Shared by Licensing Clients
When a new AP associates with a licensing client, the client sends updated licensing information to the server.
The licensing server then recalculates the available total, and sends the revised license count back to the clients.
If a client uses an AP license from the license pool, it also consumes a PEFNG and a RFProtect license from the pool, even if that AP has not enabled any features that would require that license. A switch cannot use more licenses than what is supported by its switch platform, regardless of how many licenses are available in the license pool.
AOS-W 6.5.3.x
| User Guide Software Licenses | 85
Figure 11 License Pool Reflecting Used licenses
Supported Topologies
The following table describes the switch topologies supported by this feature.
86 | Software Licenses AOS-W 6.5.3.x | User Guide
Table 28: Centralized Licensing Topologies
Topology
All switches are master switches .
The master and standby licensing servers must be defined.
Example
A single master switch is connected to one or more local switches .
Only the master switch can be a license server. A local switch can only be license client, not a license server.
A master and standby master are connected to one or more local switches .
The master license server will reside on the master switch, and the standby license server will reside on the standby master switch. Local switches can only be license clients, not license servers.
AOS-W 6.5.3.x
| User Guide Software Licenses | 87
Table 28: Centralized Licensing Topologies
Topology
A licensing server supports multiple master/local domains.
Starting with AOS-W 6.5, the centralized licensing feature supports topologies where multiple master switches have one or more attached local switches.
NOTE: This topology requires that all local switches are able to access the licensing server.
Example
A licensing server supports standalone and local licensing clients
Starting with AOS-W 6.5.2, the centralized licensing feature supports topologies where a licensing master is connected to a standalone master licensing client switch, a standalone master redundant licensing server, and a local licensing client switch.
NOTE: This topology requires additional configuration steps to define the license server
IP address for the local switches in this topology.
For details, see
Enabling Centralized Licensing on page 90
Multi-Version Licensing
AOS-W supports multi-version licensing, which allows centralized licensing clients to run a different version of
AOS-W than the primary and backup licensing servers. If a license is introduced in a newer version of AOS-W, the primary and backup licensing servers set can still distribute licenses to licensing clients running an older version of AOS-W, even if the licensing client does not recognize the newer license type.
This feature is only supported in deployment topologies where all are configured as master switches. Both the licensing server(s) and licensing clients must be running a version of that supports this feature. The multiversion licensing feature is not supported in a topology where a single licensing server or a pair of primary and backup licensing servers are connected to one or more local switches.
Replacing a Switch
If you need to replace the switch acting as a license server, the keys installed on the previous license server must be regenerated and added to the new license server. If you need to replace a switch acting as license client, you must regenerate the license keys installed on the client and reinstall them on the replacement client or the licensing server.
Failover Behaviors
If the primary licensing server fails, the switch acting as a backup license server will retain the shared license limits until the backup server reboots. If both the primary and the backup license servers fail, or if the backup switch reboots before the primary switch comes back up, License clients will retain the license limits sent to them by the licensing server for 30 days.
88 | Software Licenses AOS-W 6.5.3.x | User Guide
Although a client switch retains its licensing information for 30 days after it loses contact with the licensing server, if the client reboots at any time during this 30-day window, the window will restart, and the client will retain its information for another 30 days.
APs that use centralized licensing in conjunction with an AOS-W high availability feature behave differently than
APs that do not use a high availability solution. APs using VRRP redundancy, a backup LMS, or the AOS-W fast failover feature can quickly fail over to a backup switch, even if that backup switch does not have any AP licenses at the time of the failover. However, if that AP reboots, it will not obtain its licenses until the backup switch receives the required licenses from the licensing master.
Client is Unreachable
The centralized licensing feature sends keepalive heartbeats between the license server and the licensing client switches every 30 seconds. If the licensing server fails to receive three consecutive heartbeats from a client, it assumes that the licensing client is down, and that any APs associated with that client are also down or have failed over to another switch . Therefore, the licensing server adds any licenses used by that client back into the available pool of licenses. If the license server fails to contact a license client for 30 consecutive days, any licenses individually installed on that client will be removed from the server’s license database.
The WebUI of the licensing client and the licensing server both display a warning message when a licensing client and licensing server are unable to communicate.
Server is Unreachable
If a licensing client does not receive three consecutive heartbeats from the server, it assumes that the server is down, and that any APs directly associated to the server are also down or have failed over to another switch.
The client then adds any licenses used by the licensing server into to the pool of available licenses on that client. When a license client is unable to reach a license server for 30 consecutive days, it removes any shared licenses pushed to it from the licensing server, and reverts to its installed licenses. If the 30-day window has passed and the switch does not have enough installed licenses for all of its associated APs, the switch will nonetheless continue to support each AP. However, when an AP reboots and its switch does not have enough licenses, that AP will not come up.
For more information on replacing a switch using the centralized licensing feature, see
Configuring Centralized Licensing
The steps to configure centralized licensing on your network vary, depending upon whether you are enabling this feature in a network with a master-local switch topology, or in a network where all switches are configured as masters. Before you enable this feature, you must ensure that the switches are able to properly communicate with the licensing master. Once you have identified your deployment type, follow the steps in the appropriate section below.
Pre-configuration Setup in an All-Master Deployment
Follow the steps described below to configure the centralized licensing feature in a network with all master switches:
1. Ensure that the switches using this feature are associated with the same OmniVista server.
2. Identify a switch you want to designate as the primary licensing server. If that switch already has a redundant backup switch, that backup switch will automatically become the backup license server.
AOS-W 6.5.3.x
| User Guide Software Licenses | 89
3. (Optional) If your primary licensing server does not yet have a dedicated, redundant backup switch and you want to use a backup server with the centralized licensing feature, you must identify a second switch to use as the backup licensing server, and create a virtual router on the primary licensing server.
4. (Optional) Establish secure IPsec tunnels between the primary licensing server switch and the licensing client switches by enabling control plane security on that cluster of master switches or by creating site-to-site VPN tunnels between the licensing server and client switches. This step is not required, but if you do not create secure tunnels between the switches, the switches will exchange clear, unencrypted licensing information.
This step is not required for a master-local topology.
Pre-configuration Setup in a Master/Local Topology
The master switch in a master-local topology is the primary licensing server by default. If this master switch already has a redundant standby master, that redundant master will automatically act as the backup licensing server with no additional configuration. If your primary licensing server does not yet have a redundant standby switch and you want to use a backup server with the centralized licensing feature, you must identify a second switch to designate as the backup licensing server and define a virtual router on the primary licensing server.
Enabling Centralized Licensing
The following steps describe the procedure to enable centralized licensing on both the licensing master and the licensing clients.
Using the WebUI
1. Access the WebUI of the primary licensing master switch, navigate to Configuration > Switch and select the Centralized Licenses tab.
2. Select Enable Centralized Licensing .
3. (Optional) If the licensing server already has a dedicated redundant standby switch, that standby switch will automatically become the backup license server. If the primary licensing server in your deployment does not have a dedicated, redundant master switch, but you want to define a backup server for the licensing feature, follow steps a-d below: a. Select the License Redundancy option.
b. In the VRRP ID field, enter the Virtual Router ID for the Virtual Router you configured in the
Preconfiguration Setup task in the section above.
c. In the Peer’s IP address field, enter the IP address of the backup licensing server.
d. In the License Server IP field, enter the virtual IP address for the Virtual Router used for license server redundancy.
4. Click Apply .
If you are deploying centralized licensing in a topology where a licensing master is connected to a standalone master licensing client switch, a redundant licensing server, and a local licensing client switch, you must also access the command-line interface and issue the command license server-ip vrrp-ip <ip-addr> to define a
VRRP interface IP address as license server IP address for the local switches in this topology.
If you are deploying centralized licensing on a cluster of master switches, you must define the IP address that the licensing clients in the cluster use to access the licensing server.
5. Access the WebUI of a licensing client, navigate to Configuration > Switch and select the Centralized
Licenses tab.
6. Select Enable Centralized Licensing .
7. In the License Server IP field, enter the IP address the client will use to connect to the licensing server. If you have defined a backup licensing server using a virtual router ID, enter the IP address of that virtual router.
8. Click Apply .
90 | Software Licenses AOS-W 6.5.3.x | User Guide
9. Repeat steps 5-8 on each licensing client in the cluster.
Using the CLI
Access the command-line interface of the licensing server, and issue the following commands in config mode:
(host)(config) #license profile
(host)(License provisioning profile) #centralized-licensing-enable
If the licensing server already has a dedicated redundant standby switch, that standby switch will automatically become the backup license server. If the primary licensing server in your deployment does not have a redundant master switch but you want to define a backup server for the licensing feature, issue the following commands on the licensing server:
(host)(License provisioning profile) #License server-redundancy
(host)(License provisioning profile) #License-vrrp <vrId>
(host)(License provisioning profile) #Peer-ip-address <ip>
If you are deploying centralized licensing in a topology where a licensing master is connected to a standalone master licensing client switch, a redundant licensing server, and a local licensing client switch, you must issue the command license server-ip vrrp-ip <ip-addr> to define a VRRP interface IP address as the license server
IP address for the local switches in this topology.
(host)(License provisioning profile)#License server-ip vrrp-ip <ip-addr>
If you are deploying centralized licensing on a cluster of master switches, or in a topololgy with multiple master/local domains, access the command-line interface of a licensing client switch, and issue the following commands in config mode:
(host) (config) #license profile
(host) (License provisioning profile) #centralized-licensing-enable
(host) (License provisioning profile) #license server-ip <ip>
If a switch is designated as standby license server, it does not have the license-server-ip value configured.
Installing a License
The Alcatel-Lucent licensing system is switch-based. A license key is a unique alphanumerical string generated using the switch’s serial number and is valid only for that switch only. Licenses can be pre-installed at the factory so all licensed features are available upon initial setup. You can also install license features yourself.
It is recommended that you obtain a user account on the Alcatel-Lucent Software License Management website even if software license keys are preinstalled on your switch.
Enabling a New License on your Switch
The basic steps to installing and enabling a new license feature are listed below, along with references to sections in this document with more detailed information.
1. Obtain a valid Alcatel-Lucent software license from your sales account manager or authorized reseller (see
Requesting a Software License Through Email on page 92
).
2. Locate the system serial number of your switch (see
Locating the System Serial Number on page 92 ).
3. Use your system’s serial number to obtain a software license key from the Alcatel-Lucent Software License
Management website: https://licensing.alcateloaw.com/ (see
Obtaining a Software License Key on page 92).
4. Enter the software license key using one of the following procedures:
AOS-W 6.5.3.x
| User Guide Software Licenses | 91
n n n
Navigate to the Configuration > Network > Switch > System Settings page of the AOS-W WebUI and select the License tab .
Enter the software license key and click Apply (see
License Key in the WebUI on page 93 ).
Launch the License Wizard from the Configuration tab of the WebUI and click New . Enter the software license key in the space provided (see
Applying the Software License Key in the License Wizard on page
).
Use the license add command in the CLI.
5. Reload the switch to enable the license.
Enabling a New Flexible License on your Switch
1. Obtain a valid Alcatel-Lucent software license with flexible licensing support from your sales account manager or authorized reseller (see
Requesting a Software License Through Email on page 92 ). You will be
able to request a customized license count when ordering your license.
2. A single license certificate will be issued, containing the following information: l
Part number (e.g., LIC-AP-FLEX) l
Quantity (e.g., 450)
3. Follow steps 2–5 of
Enabling a New License on your Switch
to complete installation.
4. The new license limit will take effect immediately.
Requesting a Software License Through Email
To obtain either a permanent or a evaluation software license, contact your sales account manager or authorized reseller. The license details are provided via email with an attached text file. Use the text file to cut and paste the licensing information into the WebUI or command line.
Ensure that you have provided your sales person with a valid email address.
n n
The email also includes: n
The orderable part number for the license
A description of the software module type and switch for which it is valid
A unique, 32-character alphanumerical string used to access the license management website, and when in conjunction with the serial number of your switch, generates a unique software license key
Locating the System Serial Number
Each switch has a unique serial number located at the rear of the switch chassis.
You can also find the serial numbers by navigating to the Switch > Inventory page on the WebUI or by executing the show inventory command in the CLI.
Obtaining a Software License Key
To obtain a software license key, you must log in to the Alcatel-Lucent License Management website. If you are a first time user, you can use the software license certificate ID number to log in and request a new user account. If you already have a user account, log in to the site with your login credentials.
Once logged in, you are presented with several options: n
Activate a certificate : Activate a new certificate and create the software license key that you will apply to your switch.
92 | Software Licenses AOS-W 6.5.3.x | User Guide
n n n
Transfer a certificate : Transfer a software license certificate ID from one switch to another (for example, transferring licenses to a spare system).
Import preloaded certificates : For switches with licenses pre-installed at the factory, transfer all software license certificate IDs used on the sales order to this user account.
List your certificates : View all currently available and active software license certificates for your account.
Creating a Software License Key
To create a software license key, you must log in to the Alcatel-Lucent License Management website at: https://licensing.alcateloaw.com/
If you are a first time user of the licensing site, you can use the software license certificate ID number to log in and request a new user account. If you already have a user account, log in to the site with your login credentials.
1. Select Activate a Certificate.
2. Enter the certificate ID number and the system serial number of your switch.
3. Review the license agreement and select Yes to accept the agreement.
4. Click Activate it . A copy of the transaction and the software license key is emailed to you at the email address entered for your user account
The software license key is valid only for the system serial number for which you activated the certificate.
Applying the Software License Key in the WebUI
To enable the software module and functionality, you must apply the software license key to your switch.
1. Log in to your switch’s WebUI.
2. Navigate to the Configuration > Network > Switch > System Settings page and select the License tab.
3. Copy the software license key, from your email, and paste it into the Add New License Key field.
4. Click Add .
5. Reload the switch to enable the license.
Applying the Software License Key in the License Wizard
Log in to your switch’s WebUI.
1. Launch the License Wizard from the Configuration tab and click New .
2. The License Wizard helps walk you through the activation process. Click the Help tab within the License
Wizard for additional assistance.
Deleting a License
To remove a license from your system:
1. Navigate to the Configuration > Network > Switch > System Settings page and select the License tab.
2. Scroll down to the License Table and locate the license you want to delete.
3. Click Delete at the far right hand side of the license to delete the license.
If a license feature is under an evaluation license, it will not generate a key when the feature is deleted.
AOS-W 6.5.3.x
| User Guide Software Licenses | 93
Monitoring and Managing Centralized Licenses
A centralized licensing server displays a wide variety of licensing data that you can use to monitor licenses and license usage. The tables described below are available on the Network > Switch > Centralized License
Management > Information page of the Licensing server WebUI.
License Server Table
This table displays information about the different types of licenses in the license table, and how many total licenses of each type are available and used. This table includes the following information:
Table 29: License Server Table Data
Column Description
Service Type
Type of license on the licensing server.
Number of licenses in the licensing table on the licensing server.
Aggregate Licenses
Used Licenses
Remaining Licenses
Total number of licenses of each license type reported as used by the licensing clients or licensing server.
Total number of remaining licenses available in the licensing table.
License Client Table
This table displays centralized license limits applied to each licensing client. This table includes the following information:
Table 30: License Client Table Data
Column Description
Service Type
Type of license on the licensing client.
System Limit
Server Licenses
Used Licenses
Contributed Licenses
Remaining Licenses
The maximum number of licenses supported by the switch platform.
Number of licenses sent from the licensing server.
NOTE: This number is limited by the total license capacity of the switch platform. A switch cannot use more licenses than is supported by that switch platform, even if additional license are available.
Total number of licenses of each license type used by the licensing client switch.
Total number of licenses of each license type contributed by the licensing client switch.
Total number of remaining licensing available on this switch. This number is also limited by the total license capacity of the switch platform.
License Client(s) Usage Table
This table displays information about the different types of licenses in the license table, and how many total licenses of each type are available and used.
94 | Software Licenses AOS-W 6.5.3.x | User Guide
Table 31: License Clients(s) Usage Table Data
Column Description
Hostname
Name of the licensing client switch.
IP address of the licensing client switch.
IP Address
AP
PEF
RF Protect
Total number of AP licenses used by a licensing client associated with this switch.
Total number of Policy Enforcement Firewall (PEF) licenses used by a licensing client associated with this switch.
Total number of RFProtect licenses used by a licensing client associated with this switch.
xSec Module
Total number of Extreme Security (xSec) licenses used by a licensing client associated with this switch.
ACR
Last update (secs. ago)
Total number of advanced Cryptography (ACR) licenses used by a licensing client associated with this switch.
Time, in seconds, that has elapsed since the licensing client received a heartbeat response.
Aggregate License Table
This command is issued from the command-line interface of the centralized licensing server switch to view license limits sent by licensing clients.
Table 32: Aggregate License Table Data
Column Description
Hostname
Name of the licensing client switch.
IP address of the licensing client switch.
IP Address
AP
PEF
RF Protect
Total number of AP licenses sent from licensing clients associated with this switch.
Total number of Policy Enforcement Firewall (PEF) licenses sent from licensing clients associated with this switch.
Total number of RFProtect licenses sent from licensing clients associated with this switch.
xSec Module
Total number of Extreme Security (xSec) licenses sent from licensing clients associated with this switch.
ACR Total number of advanced Cryptography (ACR) licenses sent from licensing clients associated with this switch.
AOS-W 6.5.3.x
| User Guide Software Licenses | 95
License Heartbeat Table
This table displays the license heartbeat statistics between the license server and the license client.
Table 33: License Heartbeat Table Data
Column Description
IP address IP address of the licensing client.
HB Req
HB Resp
Total Missed
Last Update
Heartbeat requests sent from the licensing client.
Heartbeat responses received from the license server.
Total number of heartbeats that were not received by the licensing client.
Number of seconds elapsed since the licensing client last sent a heartbeat request.
96 | Software Licenses AOS-W 6.5.3.x | User Guide
Chapter 4
Network Configuration Parameters
n n n n
The following topics in this chapter describe some basic network configuration steps that must be performed on the switch: n n n n n
Campus WLAN Workflow on page 97
Configuring Static Routes on page 113
Configuring the Loopback IP Address on page 113
Configuring the Switch IP Address on page 114
Configuring GRE Tunnels on page 115
Jumbo Frame Support on page 127
Campus WLAN Workflow
The following workflow lists the tasks to configure a campus WLAN, with a signal SSID, that uses 802.1X
authentication. Click any of the links below for details on the configuration procedures for that task.
Using the WebUI
1.
Configure your authentication servers.
2.
Create an authentication server group,
and assign the authentication servers you configured in step 1 to that server group.
3.
Configure a firewall access policy
for a group of users
4.
and assign the firewall access policy you created in step 3 to that user role.
5.
a. Assign the user role defined in step 4 to the AAA profile's 802.1X Authentication Default Role b. Associate the server group you created in step 2 to the AAA profile.
6.
7.
Create a new virtual AP profile.
8.
Associate the virtual AP profile
to the AAA profile you created in Step 5.
9.
Associate the virtual AP profile
to the SSID profile you created in Step 6.
Using the CLI
The example below follows the suggested order of steps to configure a virtual AP using the command-line interface.
(host)(config) #aaa server-group "THR-DOT1X-SERVER-GROUP-WPA2" auth-server Internal
!
ip access-list session THR-POLICY-NAME-WPA2 user any any permit
!
(host)(config) #user-role THR-ROLE-NAME-WPA2 session-acl THR-POLICY-NAME-WPA2
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 97
!
(host)(config) #aaa server-group "THR-DOT1X-SERVER-GROUP-WPA2" auth-server Internal
!
(host)(config) #aaa profile "THR-AAA-PROFILE-WPA2" dot1x-default-role "THR-ROLE-NAME-WPA2" dot1x-server-group "THR-DOT1X-SERVER-GROUP-WPA2"
!
(host)(config) #wlan ssid-profile "THR-SSID-PROFILE-WPA2" essid "THR-WPA2" opmode wpa2-aes
!
(host)(config) #wlan virtual-ap "THR-VIRTUAL-AP-PROFILE-WPA2" ssid-profile "THR-SSID-PROFILE-WPA2" aaa-profile "THR-AAA-PROFILE-WPA2" vlan 60
!
(host)(config) #ap-group "THRHQ1-STANDARD" virtual-ap "THR-VIRTUAL-AP-PROFILE-WPA2"
Understanding VLAN Assignments
A client is assigned to a VLAN by one of several methods, in order of precedence. The assignment of VLANs are
(from lowest to highest precedence):
1. The default VLAN is the VLAN configured for the WLAN (see
Virtual AP Profiles on page 412
).
2. Before client authentication, the VLAN can be derived from rules based on client attributes (SSID, BSSID, client MAC, location, and encryption type). A rule that derives a specific VLAN takes precedence over a rule that derives a user role that may have a VLAN configured for it.
3. After client authentication, the VLAN can be configured for a default role for an authentication method, such as 802.1X or VPN.
4. After client authentication, the VLAN can be derived from attributes returned by the authentication server
( server-derived rule ). A rule that derives a specific VLAN takes precedence over a rule that derives a user role that may have a VLAN configured for it.
5. After client authentication, the VLAN can be derived from Microsoft Tunnel attributes (Tunnel-Type, Tunnel
Medium Type, and Tunnel Private Group ID). All three attributes must be present as shown below. This does not require a server-derived rule. For example:
Tunnel-Type="VLAN"(13)
Tunnel-Medium-Type="IEEE-802" (6)
Tunnel-Private-Group-Id="101"
6. After client authentication, the VLAN can be derived from Vendor Specific Attributes (VSA) for RADIUS server authentication. This does not require a server-derived rule. If a VSA is present, it overrides any previous VLAN assignment. For example:
Alcatel-Lucent-User-VLAN
Alcatel-Lucent-Named-User-VLAN
VLAN Derivation Priorities for VLAN types
The VLAN derivation priorities for VLAN is defined below in the increasing order:
1. Default or Virtual AP VLAN
2. VLAN from Initial role
3. VLAN from User Derivation Rule (UDR) role
4. VLAN from UDR
5. VLAN from DHCP option 77 UDR role (wired clients)
98 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
6. VLAN from DHCP option 77 UDR (wired clients)
7. VLAN from MAC-based Authentication default role
8. VLAN from Server Derivation Rule (SDR) role during MAC-based Authentication
9. VLAN from SDR during MAC-based Authentication
10.VLAN from Vendor Specific Attributes (VSA) role during MAC-based Authentication
11.VLAN from VSA during MAC-based Authentication
12.VLAN from Microsoft Tunnel attributes during MAC-based Authentication
13.VLAN from 802.1X default role
14.VLAN from SDR role during 802.1X
15.VLAN from SDR during 802.1X
16.VLAN from VSA role during 802.1X
17.VLAN from VSA during 802.1X
18.VLAN from Microsoft Tunnel attributes during 802.1X
19.VLAN from DHCP options role
20.VLAN from DHCP options
A VLAN from DHCP options has highest priority for VLAN derivation. Note, however, that DHCP options are not considered for derivation if the Aruba VSA ARUBA_NO_DHCP_FINGERPRINT (14) was sent for the user.
Use the following command to display user VLAN derivation related debug information:
(host) #show aaa debug vlan user [ip | ipv6 | mac]
How a VLAN Obtains an IP Address
A VLAN on the switch obtains its IP address in one of the following ways: n n
You can manually configure it. This is the default method and is described in
Assigning a Static Address to a
VLAN on page 99 . At least one VLAN on the switch must be assigned a static IP address.
Dynamically assigned from a Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol over
Ethernet (PPPoE) server.
Assigning a Static Address to a VLAN
You can manually assign a static IP address to a VLAN on the switch. At least one VLAN on the switch a static IP address.
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Interfaces page on the WebUI. Click Edit for the
VLAN you just added.
2. Select the Use the following IP address option. Enter the IP address and network mask of the VLAN interface. If required, you can also configure the address of the DHCP server for the VLAN by clicking Add .
3. Click Apply .
In the CLI
(host)(config) #interface vlan < id> ip address < address> < netmask>
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 99
Configuring a VLAN to Receive a Dynamic Address
In a branch office, you can connect a switch to an uplink switch or server that dynamically assigns IP addresses to connected devices. For example, you can connect the switch to a DSL or cable modem, or a broadband remote access server (BRAS). The following figure shows a branch office where a switch connects to a cable modem. VLAN 1 has a static IP address, while VLAN 2 has a dynamic IP address assigned via DHCP or PPPoE from the uplink device.
Figure 12 IP Address Assignment to VLAN via DHCP or PPPoE
Configuring Multiple Wired Uplink Interfaces (Active-Standby)
You can assign up to four VLAN interfaces to operate in active-standby topology. An active-standby topology provides redundancy so that when an active interface fails, the user traffic can failover to the standby interface.
To allow the switch to obtain a dynamic IP address for a VLAN, enable the DHCP or PPPoE client on the switch for the VLAN.
The following restrictions apply when enabling the DHCP or PPPoE client on the switch: n n n
You can enable the DHCP/PPPoE client multiple uplink VLAN interfaces (up to four) on the switch; these
VLANs cannot be VLAN 1.
Only one port in the VLAN can be connected to the modem or uplink switch.
At least one interface in the VLAN must be in the up state before the DHCP/PPPoE client requests an IP address from the server.
Enabling the DHCP Client
The DHCP server assigns an IP address for a specified amount of time called a lease. The switch automatically renews the lease before it expires. When you shut down the VLAN, the DHCP lease is released.
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Interfaces page.
2. Click Edit for a previously-created VLAN.
3. Select Obtain an IP address from DHCP .
4. Enter a priority value for the VLAN ID in the Uplink Priority field. All wired uplink interfaces have the same priority by default. If you want to use an active-standby topology, then prioritize each uplink interfaces by entering a different priority value (1– 4) for each uplink interface.
100 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
Figure 13 Assigning VLAN Uplink Priority—Active-Standby Configuration
5. Click Apply .
In the CLI
In this example, the DHCP client has the client ID name myclient , and the interface VLAN 62 has an uplink priority of 2:
(host)(config) #interface vlan 62
(host)(config) #uplink wired vlan 62 priority 2
(host)(config) #interface vlan 62 ip address dhcp-client client-id myclient
Enabling the PPPoE Client
To authenticate the BRAS and request a dynamic IP address, the switch must have the following configured: n n
PPPoE user name and password to connect to the DSL network
PPPoE service name: either an ISP name or a class of service configured on the PPPoE server
When you shut down the VLAN, the PPPoE session terminates.
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Interfaces page.
2. Click Edit for a previously-created VLAN.
3. Select Obtain an IP address with PPPoE.
4. Enter the service name, username, and password for the PPPoE session.
5. Enter a priority value for the VLAN ID in the Uplink Priority field. All wired uplink interfaces have the same priority by default. If you want to use an active-standby topology, then prioritize each uplink interfaces by entering a different priority value (1– 4) for each uplink interface.
6. Click Apply.
In the CLI
In this example, a PPoE service name, username, and password are assigned, and the interface VLAN 14 has an uplink priority of 3:
(host)(config) #interface vlan 14 ip address pppoe
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 101
(host)(config) #interface vlan 14 ip pppoe-service-name < service_name >
(host)(config) #interface vlan 14 ip pppoe-username < username >
(host)(config) #interface vlan 14 ip pppoe-password *****
(host)(config) #uplink wired vlan 14 priority 3
Default Gateway from DHCP/PPPoE
You can specify that the router IP address obtained from the DHCP or PPPoE server be used as the default gateway for the switch.
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Routes & DNS page.
2. For Default Gateway, you can select the following: l l
DHCP - Use DHCP when available to obtain default gateway.
PPPoE - Use PPPOE when available to obtain default gateway.
l
Cellular - Use Cell interface when available to obtain default gateway.
3. Click Apply .
In the CLI
(host) (config) #ip default-gateway import
Configuring DNS/WINS Server from DHPC/PPPoE
The DHCP or PPPoE server can also provide the IP address of a DNS server or NetBIOS name server, which can be passed to wireless clients through the switch’s internal DHCP server.
For example, the following configures the DHCP server on the switch to assign addresses to authenticated employees; the IP address of the DNS server obtained by the switch via DHCP/PPPoE is provided to clients along with their IP address.
In the WebUI
1. Navigate to the Configuration > Network > IP > DHCP Server page.
2. Select Enable DCHP Server .
3. Under Pool Configuration, select Add .
4. For Pool Name, enter employee-pool.
5. For Default Router, enter 10.1.1.254.
6. For DNS Servers, select Import from DHCP/PPPoE .
7. For WINS Servers, select Import from DHCP/PPPoE .
8. For Network, enter 10.1.1.0 for IP Address and 255.255.255.0 for Netmask.
9. Click Done .
In the CLI
Use the following commands:
(host)(config) #ip dhcp pool employee-pool default-router 10.1.1.254
dns-server import netbios-name-server import network 10.1.1.0 255.255.255.0
102 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
Configuring Source NAT to Dynamic VLAN Address
When a VLAN interface obtains an IP address through DHCP or PPPoE, a NAT pool (dynamic-srcnat) and a session ACL (dynamic-session-acl) are automatically created which reference the dynamically-assigned IP addresses. This allows you to configure policies that map private local addresses to the public address(es) provided to the DHCP or PPPoE client. Whenever the IP address on the VLAN changes, the dynamic NAT pool address also changes to match the new address.
For example, the following rules for a guest policy deny traffic to internal network addresses. Traffic to other
(external) destinations are source NATed to the IP address of the DHCP/PPPoE client on the switch.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Policies page. Click Add to add the policy guest .
2. To add a rule, click Add .
a. For Source, select any .
b. For Destination, select network and enter 10.1.0.0
for Host IP and 255.255.0.0
for Mask.
c. For Service, select any .
d. For Action, select reject .
e. Click Add .
3. To add another rule, click Add.
a. Leave Source, Destination, and Service as any.
b. For Action, select src-nat .
c. For NAT Pool, select dynamic-srcnat .
d. Click Add .
4. Click Apply.
In the CLI
Use the following commands:
(host)(config) #ip access-list session guest any network 10.1.0.0 255.255.0.0 any deny any any any src-nat pool dynamic-srcnat
Configuring Source NAT for VLAN Interfaces
The example configuration in the previous section illustrates how to configure source NAT using a policy that is applied to a user role. You can also enable source NAT for a VLAN interface to perform NAT on the source address for all traffic that exits the VLAN.
Starting with AOS-W 6.4.4, all outbound traffic now can enable NAT with the IP address of the VLAN interface as the source address; while the locally routed traffic is sent without any address translation.
Traditionally, AOS-W supported only IP NAT Inside feature where traffic performs NAT with the desired IP address of the VLAN interface as the source address which was useful for only traffic going out of uplink VLAN interface. However, for traffic which needed local routing was also going through unnecessary address translation. Now, this feature resolves this issue by allowing only outbound traffic to perform NAT.
Do not enable the NAT translation for inbound traffic option for VLAN 1, as this will prevent IPsec connectivity between the switch and its IPsec peers.
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 103
Sample Configuration
In the following example, the switch operates within an enterprise network. VLAN 1 is the outside VLAN, and traffic from VLAN 6 is source NATed using the IP address of the switch. The IP address assigned to VLAN 1 is used as the switch’s IP address; thus traffic from VLAN 6 would be source NATed to 66.1.131.5:
Figure 14 Example: Source NAT using Switch IP Address
In the WebUI
1. Navigate to the Configuration > Network > VLANs page. Click Add a VLAN to configure VLAN 6 (VLAN 1 is configured through the Initial Setup).
a. Enter 6 for the VLAN ID.
b. Click Apply .
2. Navigate to the Configuration > Network > IP > IP Interfaces page.
3. Click Edit for VLAN 6: a. Select Use the following IP address .
b. Enter 192.168.2.1
for the IP Address and 255.255.255.0
for the Net Mask.
c. Select the Enable source NAT inside for this VLAN checkbox.
d. Click Apply .
4. Click Edit for VLAN 1: a. Select Use the following IP address .
b. Enter 66.1.131.5
for the IP Address and 255.255.255.0
for the Net Mask.
c. Select the Enable source NAT outside for this VLAN checkbox.
5. Click Apply .
In the CLI
Use the following commands:
(host)(config) #interface vlan 1 ip address 66.1.131.5 255.255.255.0
(host)(config) #interface vlan 6
(host)(config) #ip address 192.168.2.1 255.255.255.0
ip nat inside ip default-gateway 66.1.131.1
(host)(config) #interface vlan 1 ip address 66.1.131.5 255.255.255.0
ip nat outside
Inter-VLAN Routing
On the switch, you can map a VLAN to a layer-3 subnetwork by assigning a static IP address and a netmask, or by configuring a DHCP or PPPoE server to provide a dynamic IP address and netmask to the VLAN interface.
104 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
The switch, acting as a layer-3 switch, routes traffic between VLANs that are mapped to IP subnetworks; this forwarding is enabled by default.
In
, VLAN 200 and VLAN 300 are assigned the IP addresses 2.1.1.1/24 and 3.1.1.1/24, respectively.
Client A in VLAN 200 is able to access server B in VLAN 300 and vice-versa, provided that there is no firewall rule configured on the switch to prevent the flow of traffic between the VLANs.
Figure 15 Default Inter-VLAN Routing
You can optionally disable layer-3 traffic forwarding to or from a specified VLAN. When you disable layer-3 forwarding on a VLAN, the following restrictions apply: n n
Clients on the restricted VLAN can ping each other, but cannot ping the VLAN interface on the switch.
Forwarding of inter-VLAN traffic is blocked.
IP mobility does not work when a mobile client roams to the restricted VLAN. You must ensure that a mobile client on a restricted VLAN is not allowed to roam to a non-restricted VLAN. For example, a mobile client on a guest VLAN will not be able to roam to a corporate VLAN.
To disable layer-3 forwarding for a VLAN configured on the switch:
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Interface page.
2. Click Edit for the VLAN for which routing is to be restricted.
3. Configure the VLAN to either obtain an IP address dynamically (via DHCP or PPPoE) or to use a static IP address and netmask.
4. Deselect (uncheck) the Enable Inter-VLAN Routing checkbox.
5. Click Apply .
In the CLI
Use the following commands:
(host)(config) #interface vlan <id>
ip address {<ipaddr> <netmask>|dhcp-client|pppoe}
no ip routing
Configuring VLANs
The switch operates as a layer-2 switch that uses a VLAN as a broadcast domain. As a layer-2 switch, the switch requires an external router to route traffic between VLANs. The switch can also operate as a layer-3 switch that can route traffic between VLANs defined on the switch.
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 105
You can configure one or more physical ports on the switch to be members of a VLAN. Additionally, each wireless client association constitutes a connection to a virtual port on the switch , with membership in a specified VLAN. You can place all authenticated wireless users into a single VLAN or into different VLANs, depending upon your network. VLANs can remain inside the switch, or they can extend outside the switch through 802.1q VLAN tagging.
You can optionally configure an IP address and netmask for a VLAN on the switch. The IP address is up when at least one physical port in the VLAN is up. The VLAN IP address can be used as a gateway by external devices; packets directed to a VLAN IP address that are not destined for the switch are forwarded according to the switch’s IP routing table.
Creating and Updating VLANs
You can create and update a single VLAN or bulk VLANs.
In the WebUI
1. Navigate to the Configuration > Network > VLANs page.
2. Click Add a VLAN to create a new VLAN. (To edit an existing VLAN, click Edit for the VLAN entry.) See
Creating Bulk VLANs In the WebUI on page 106
to create a range of VLANs.
3. In the VLAN ID field, enter a valid VLAN ID. (Valid values are from 1 to 4094, inclusive).
4. To add physical ports to the VLAN, select Port . To associate the VLAN with specific port-channels, select
Port-Channel .
5. (Optional) Click the Wired AAA Profile drop-down list to assign an AAA profile to a VLAN. This wired AAA profile enables role-based access for wired clients connected to an untrusted VLAN or port on the switch.
Note that this profile will only take effect if the VLAN or port on the switch is untrusted. If you do not assign a wired AAA profile to the VLAN, the global wired AAA profile applies to traffic from untrusted wired ports.
6. If you selected Port in step 4, select the ports you want to associate with the VLAN from the Port
Selection window.
or
If you selected Port-Channel in step 4, click the Port-Channel ID drop-down list, select the specific channel number you want to associate with the VLAN, then select the ports from the Port Selection window.
7. Click Apply .
In the CLI
Use the following commands:
(host)(config) #vlan <id>
(host)(config) #interface fastethernet|gigabitethernet <slot>/<module>/<port>
(host)(config-if) #switchport access vlan <id>
Creating Bulk VLANs In the WebUI
1. To add multiple VLANs at one time, click Add Bulk VLANs .
2. In the VLAN Range pop-up window, enter a range of VLANs you want to create at once. For example, to add VLAN IDs numbered 200-300 and 302-350, enter 200-300, 302-350.
3. Click OK .
4. To add physical ports to a VLAN, click Edit next to the VLAN you want to configure and click the port in the
Port Selection section.
5. Click Apply .
106 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
In the CLI
Use the following commands:
(host)(config) #vlan
(host)(config) #vlan range 200-300,302-350
Creating a Named VLAN
You can create, update, and delete a named VLAN. Each named VLAN has a name and needs to have one or more VLANs assigned to it. The following configurations create a named VLAN called mygroup . It has the assignment type Even , and VLAN IDs 2, 4 and 12 are assigned to this named VLAN.
AOS-W supports maximum of 256 VLANs per named VLAN.
In the WebUI
1. Navigate to Configuration > Network > VLANs.
2. Select the VLAN Pool tab to open the VLAN Pool window.
3. Click Add .
4. In the VLAN Name field, enter a name that identifies this named VLAN.
5. In the Assignment Type field, select Hash or Even from the drop-down list. See
Even and Hash Assignment Types on page 107
for information and conditions regarding Hash and Even assignment types.
The Even named VLAN assignment type is only supported in tunnel and decrypt-tunnel modes. It is not supported in split or bridge modes. It is not allowed for named VLANs that are configured directly under a virtual AP (VAP). It must only be used under named VLANs. L2 Mobility is not compatible with the existing implementation of the Even named
VLAN assignment type.
6. In the List of VLAN IDs field, enter the VLAN IDs you want to add to this pool. If you know the ID, enter each ID separated by a comma. You can also click the drop-down list to view the IDs, then select a VLAN ID to add it to the pool.
VLAN pooling should not be used with static IP addresses.
7. You must add a VLAN ID to create a named VLAN.
8. When you finish adding all the IDs, click Add . The VLAN name along with assignment type and VLAN IDs appears on the VLAN Pool window.
9. Click Apply .
10.At the top of the window, click Save Configuration .
Distinguishing Between Even and Hash Assignment Types
The VLAN assignment type determines how the switch handles a VLAN assignment.
The Hash assignment type means that the VLAN assignment is based on the station MAC address. The Even assignment type is based on an even distribution of named VLAN assignments.
The Even named VLAN assignment type maintains a dynamic latest usage level of each VLAN ID in the named
VLAN . Therefore, as users age out, the number of available addresses increases. This leads to a more even distribution of addresses.
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 107
The Even type is only supported in tunnel and decrypt-tunnel modes. It is not supported in split or bridge modes and it is not allowed for named VLAN that are configured directly under a virtual AP. It can only be used under named VLANs.
If a named VLAN is given an Even assignment and is assigned to user roles, user rules, VSA, or server derivation rules, then while applying VLAN derivation for the client “on run time,” the Even assignment is ignored and the
Hash assignment is applied with a message displaying this change.
L2 Mobility is not compatible with the existing implementation of the Even named VLAN assignment type.
Updating a Named VLAN
1. On the VLAN Pool window, click Modify next to the VLAN name you want to edit.
2. Modify the assignment type and the list of VLAN IDs. Note that you can not modify the VLAN name.
3. Click Update .
4. Click Apply .
5. At the top of the window, click Save Configuration.
Deleting a Named VLAN
1. On the VLAN Pool window, click Delete next to the VLAN name you want to delete. A prompt appears.
2. Click OK .
3. Click Apply .
4. At the top of the window, click Save Configuration .
Creating a Named VLAN Using the CLI
Named VLAN should not be used with static IP addresses.
The following example creates named VLAN called mygroup that has assignment type even .
(host)(config) #vlan-name mygroup assignment even
Viewing and Adding VLAN IDs Using the CLI
The following example shows how to view VLAN IDs in a named VLAN:
(host)(config) #show vlan
The following example shows how to add existing VLAN IDs to a named VLAN:
(host)(config) #vlan-name mygroup
(host)(config) #vlan mygroup 2,4,12
To confirm the named VLAN mappings assignments, use the following command:
(host)(config) #show vlan mapping
Role Derivation for Named VLAN Pools
You can configure Named VLANs under user rule, server derivation, user derivation, and VSA in this release.
You cannot modify a VLAN name, so choose the name carefully.
108 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
Named VLANs (single VLAN IDs or multiple VLAN IDs) can only be assigned to tunnel mode VAP’s and wired profiles. They can also be assigned to user roles, user rule derivation, server derivation, and VSA for tunnel and bridge mode.
For tunnel mode, named VLANs that have the assignment type “hash” and “even” are supported.
For bridge mode only, named VLANs with the assignment type “hash” are supported. If a named VLAN with
“even” assignment is assigned to a user rule, user role, server derivation or VSA, than the “hash” assignment is applied and the following error message displays:
"named VLAN assignment type EVEN not supported for bridge. Applying HASH algorithm to retrieve vlan-id"
L2 roaming is not supported with an even VLAN assignment.
In the CLI
To apply a named VLAN in a user rule, use the following CLI commands:
(host)(config) #aaa derivation-rules
(host)(config) #aaa derivation-rules user <string>
(host)(config) #aaa derivation-rules user test-user-rule
(host)(user-rule) #set vlan
To apply a named VLAN in a user role, use the following CLI commands:
(host)(config) #user-role test-vlan-name
(user)(config-role) #vlan test-vlan
To apply a named VLAN in server derivation, use the following CLI commands:
(host)(config) #aaa server-group test-vlan-server-group
(user)(Server Group "test-vlan-server-group") set vlan
For a named VLAN derivation using VSA, configure the RADIUS server using these values:
Aruba-Named-UserVLAN 9 String Aruba 14823
In the WebUI
To apply a named VLAN in a user rule, navigate to the WebUI page:
Security > Authentication > User Rules
To apply a named VLAN in a user role, navigate to the WebUI page:
Security > Access Control > User Roles > Add or Edit Role
To apply a named VLAN in a server derivation (server group), navigate to the WebUI page:
Security > Authentication> Servers > Server Group > <server-group_name> >Server Rules
Adding a Bandwidth Contract to the VLAN
Bandwidth contracts on a VLAN can limit broadcast and multicast traffic. AOS-W includes an internal exception list to allow broadcast and multicast traffic using the VRRP, LACP, OSPF, PVST, and STP protocols. To remove per-VLAN bandwidth contract limits on an additional broadcast or multicast protocol, add the MAC address for that broadcast/multicast protocol to the VLAN Bandwidth Contracts MAC Exception List.
The command in the example below adds the MAC address for CDP (Cisco Discovery Protocol) and VTP (Virtual
Trunking Protocol to the list of protocols that are not limited by VLAN bandwidth contracts.
(host)(config) #vlan-bwcontract-explist mac 01:00:0C:CC:CC:CC
To show entries in the VLAN bandwidth contracts MAC exception list execute the following command:
(host)(config) #show vlan-bwcontract-explist internal
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 109
Optimizing VLAN Broadcast and Multicast Traffic
Broadcast and Multicast (BCMC) traffic from APs, remote APs, or distributions terminating on the same VLAN floods all VLAN member ports. This causes critical bandwidth wastage, especially when the APs are connected to an L3 cloud where the available bandwidth is limited or expensive. Suppressing the VLAN BCMC traffic to prevent flooding can result in loss of client connectivity.
To effectively prevent flooding of BCMC traffic on all VLAN member ports, use the bcmc-optimization parameter under the interface vlan command. This parameter ensures controlled flooding of BCMC traffic without compromising the client connectivity. This option is disabled by default. You must enable this parameter for the controlled flooding of BCMC traffic.
If you enable BCMC Optimization on uplink ports, the switch-generated Layer-2 packets will be dropped.
The bcmc-optimization parameter has the following exemptions: n n
All DHCP traffic will continue to flood VLAN member ports even if you enable the bcmc-optimization parameter.
ARP broadcasts and VRRP (multicast) traffic will still be allowed.
You can configure BCMC optimization using the WebUI or CLI.
In the WebUI
1. Navigate to Configuration > Network > IP .
2. In the IP Interfaces tab, click Edit of the VLAN for configuring BCMC optimization.
3. Select the Enable BCMC check box to enable BCMC Optimization for the selected VLAN.
Figure 16 Enable BCMC Optimization
In the CLI
(host)(config) #interface vlan 1
(host)(config-subif)#bcmc-optimization
(host)(config-subif)#show interface vlan 1
Configuring Ports
Both Fast Ethernet and Gigabit Ethernet ports can be set to access or trunk mode. A port is in access mode enabled by default and carries traffic only for the VLAN to which it is assigned. In trunk mode, a port can carry traffic for multiple VLANs.
For a trunk port, specify whether the port will carry traffic for all VLANs configured on the switch or for specific
VLANs only. You can also specify the native VLAN for the port. A trunk port uses 802.1q tags to mark frames for specific VLANs, However, frames on a native VLAN are not tagged.
110 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
Classifying Traffic as Trusted or Untrusted
You can classify wired traffic based not only on the incoming physical port and channel configuration, but also on the VLAN associated with the port and channel.
About Trusted and Untrusted Physical Ports
Physical ports on the switch are trusted and usually connected to internal networks by default, while untrusted ports connect to third-party APs, public areas, or other networks to which you can apply access controls. When you define a physical port as untrusted, traffic passing through that port needs to go through a predefined access control list policy.
About Trusted and Untrusted VLANs
You can also classify traffic as trusted or untrusted based on the VLAN interface and port or channel. This means that wired traffic on the incoming port is trusted only when the port’s associated VLAN is also trusted; otherwise the traffic is untrusted. When a port and its associated VLANs are untrusted, any incoming and outgoing traffic must pass through a predefined ACL. For example, this setup is useful if your company provides wired user guest access, and you want guest user traffic to pass through an ACL to connect to a captive portal.
You can set a range of VLANs as trusted or untrusted in trunk mode. The following table lists the port, VLAN and the trust/untrusted combination to determine if traffic is trusted or untrusted. Both the port and the
VLAN have to be configured as trusted for traffic to be considered as trusted. If the traffic is classified as untrusted, then traffic must pass through the selected session access control list and firewall policies.
Table 34: Classifying Trusted and Untrusted Traffic
Port
Trusted
VLAN
Trusted
Untrusted
Untrusted
Trusted
Untrusted
Trusted
Untrusted
Traffic Status
Trusted
Untrusted
Untrusted
Untrusted
Configuring Trusted/Untrusted Ports and VLANs
You can configure an Ethernet port as an untrusted access port, assign VLANs and classify them as untrusted, and designate a policy through which VLAN traffic on this port must pass.
In the WebUI
1. Navigate to the Configuration > Network > Ports window.
2. In the Port Selection section, click the port you want to configure.
3. In the Make Port Trusted section, clear the Trusted check box to make the port untrusted. The default is trusted (checked).
4. In the Port Mode section, select Access .
5. From the VLAN ID drop-down list, select the VLAN ID whose traffic will be carried by this port.
6. In the Enter VLAN(s) section , clear the Trusted check box to make the VLAN untrusted. The default is trusted (checked).
7. In the VLAN Firewall Policy drop-down list, select the policy through which VLAN traffic must pass. You can select a policy for both trusted and untrusted VLANs.
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 111
8. From the Firewall Policy section, select the policy from the in drop-down list through which inbound traffic on this port must pass.
9. Select the policy from the out drop-down list through which outbound traffic on this port must pass.
10.To apply a policy to this session’s traffic on this port and VLAN, select the policy from the session dropdown list.
11.Click
Apply .
In the CLI
In this example,
(host)(config) #interface range fastethernet <slot/module/port>
(host)(config-if)#switchport mode access
(host)(config-if)#no trusted
(host)(config-if)#switchport access vlan <vlan>
(host)(config-if)#no trusted vlan <vlan>
(host)(config-if)#ip access-group ap-acl session vlan <vlan>
(host)(config-if)#ip access-group validuserethacl in
(host)(config-if)#ip access-group validuserethacl out
(host)(config-if)#ip access-group validuser session
Configuring Trusted and Untrusted Ports and VLANs in Trunk Mode
The following procedures configure a range of Ethernet ports as untrusted native trunks ports, assign VLANs and classify them as untrusted, and designate a policy through which VLAN traffic on the ports must pass.
In the WebUI
1. Navigate to the Configuration > Network > Ports window.
2. In the Port Selection section, click the port you want to configure.
3. For Port Mode select Trunk .
4. To specify the native VLAN, select a VLAN from the Native VLAN drop-down list.
5. Choose one of the following options to control the type of traffic the port carries: l
Allow All VLANS Except : The port carries traffic for all VLANs except those from this drop-down list.
l l
Allow VLANs : The port carries traffic for all VLANs selected from this drop-down list.
Remove VLANs: The port does not carry traffic for any VLANs selected from this drop-down list.
6. To designate untrusted VLANs on this port, click Trusted except . In the corresponding VLAN field enter a range of VLANs that you want to make untrusted . (In this format, for example: 200-300, 401-500 and so on). Only VLANs listed in this range are untrusted. To designate only one VLAN as untrusted, select a VLAN from the drop-down list.
7. To designate trusted VLANs on this port, click Untrusted except . In the corresponding VLAN field, enter a range of VLANs that you want to designate as trusted . (In this format, for example: 200-300, 401-500 and so on). Only VLANs listed in this range are trusted. To designate only one VLAN as trusted, select a VLAN from the drop-down menu.
8. To remove a VLAN, click the Remove VLANs option and select the VLAN you want to remove from the drop-down list, and click the left arrow to add it back to the list.
9. To designate the policy through which VLAN traffic must pass, click New under the Session Firewall
Policy field.
10.Enter the VLAN ID or select it from the associated drop-down list. Then select the policy, through which the
VLAN traffic must pass, from the Policy drop-down list and click Add . Both the selected VLAN and the policy appear in the Session Firewall Policy field.
11.When you are finished listing VLANs and policies, click Cancel .
112 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
12.Click
Apply.
In the CLI
Use the following examples:
(host)(config) #interface fastethernet <slot/module/port>
(host)(config-if)#description <string>
(host)(config-if)#trusted {vlan <word>}
(host)(config-range)#switchport mode trunk
(host)(config-if)#switchport trunk native vlan <vlan>
(host)(config-range)#ip access-group
(host)(config-range)#ip access-group test session vlan <vlan>
Configuring Static Routes
To configure a static route (such as a default route) on the switch, do the following:
In the WebUI
1. Navigate to the Configuration > Network > IP > IP Routes page.
2. Click Add to add a static route to a destination network or host. Enter the destination IP address and network mask (255.255.255.255 for a host route) and the next hop IP address.
3. Click Done to add the entry. Note that the route has not yet been added to the routing table.
4. Click Apply .. The message Configuration Updated Successfully confirms that the route has been added.
In the CLI
Use the following examples:
(host)(config) #ip route <address> <netmask> <next_hop>
Configuring the Loopback IP Address
The loopback IP address is a logical IP interface that is used by the switch to communicate with APs. The loopback address is used as the switch’s IP address for terminating VPN and GRE tunnels, originating requests to RADIUS servers, and accepting administrative communications. You configure the loopback address as a host address with a 32-bit netmask. The loopback address is not bound to any specific interface and is operational at all times. To use this interface, ensure that the IP address is reachable through one of the VLAN interfaces. It will be routable from all external networks.
You must configure a loopback address if you are not using VLAN1 to connect the switch to the network. If you do not configure the loopback interface address, then the first configured VLAN interface address is selected.
Generally, VLAN 1 is the factory default setting and thus becomes the switch IP address.
In the WebUI
1. Navigate to the Configuration > Network > Switch > System Settings page and locate the Loopback
Interface section.
2. Modify the IP Address as required.
3. Click Apply .
If you are use the loopback IP address to access the WebUI, changing the loopback IP address will result in loss of connectivity. It is recommended that you use one of the VLAN interface IP addresses to access the WebUI.
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 113
4. Navigate to the Maintenance > Switch > Reboot Switch page to reboot the switch to apply the change of loopback IP address.
5. Click Continue to save the configuration.
6. When prompted that the changes were written successfully to flash, click OK .
7. The switch boots up with the changed loopback IP address.
In the CLI
Use the following commands:
(host)(config) #interface loopback ip address <address>
(host)(config) #write memory
Enter the following command in Enable mode to reboot the switch :
(host) #reload
Configuring the Switch IP Address
The Switch IP address is used by the switch to communicate with external devices such as APs.
IP addresses used by the switch is not limited to the switch IP address.
You can set the Switch IP address to the loopback interface address or to an existing VLAN ID address. This allows you to force the switch IP address to be a specific VLAN interface or loopback address across multiple machine reboots. Once you configure an interface to be the switch IP address, that interface address cannot be deleted until you remove it from the switch IP configuration.
If the switch IP address is not configured then the switch IP defaults to the current loopback interface address.
If the loopback interface address is not configured then the first configured VLAN interface address is selected.
Generally, VLAN 1 is the factory default setting and thus becomes the switch IP address.
In the WebUI
1. Navigate to Configuration > Network > Switch > System Settings page.
2. Locate the Switch IP Details section.
3. Select the address you want to set the Switch IP to from the VLAN ID drop-down list. This list contains only
VLAN IDs that have statically assigned IP addresses. If you have previously configured a loopback interface
IP address, then it will also appear in this list. Dynamically assigned IP addresses such as DHCP/PPPOE do not display.
4. Click Apply .
Any change in the switch’s IP address requires a reboot.
114 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
5. Navigate to the Maintenance > Switch > Reboot Switch page to reboot the switch to apply the change of switch IP address.
6. Click Continue to save the configuration.
7. When prompted that the changes were written successfully to flash, click OK .
8. The switch boots up with the changed switch IP address. of the selected VLAN ID.
In the CLI
(host)(config) #switch-ip [loopback|vlan <valn id>]
Configuring GRE Tunnels
Switches support Generic Routing Encapsulation (GRE) tunnels between switches and other network devices that support GRE tunnels.
This section contains the following information: n n n n n n
Configuring a Layer-2 GRE Tunnel
Configuring a Layer-3 GRE Tunnel for IPv4 or IPv6
Directing Traffic into the Tunnel
About Layer-2 GRE Tunnels
Layer-2 GRE tunnels allow you to have the same VLAN in multiple locations (separated by a Layer-3 network) and be connected. The forwarding method for a Layer-2 GRE tunnel is bridging.
However, the drawback of using Layer-2 GRE tunnels is that all broadcasts are flooded through the tunnel, adding traffic load to the network and the switches.
Figure 17 Layer-2 GRE Tunnel
The traffic flow illustrated by
is as follows:
1. The frame enters the source switch (Switch-1) on VLAN 101.
The frame is bridged through Switch-1 into the Layer-2 GRE tunnel.
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 115
2. The frame is encapsulated in a GRE packet.
3. The GRE packet enters the network on VLAN 10, is routed across the network to the destination switch
(Switch-2), and then exits the network on VLAN 20.
The source IP address of the GRE packet is the IP address of the interface in VLAN 10 in Switch 1.
4. The frame is de-encapsulated and bridged out of the destination switch (Switch-2) on VLAN 101.
About Layer-3 GRE Tunnels
The benefit of Layer-3 GRE tunnels is that broadcasts are not flooded through the tunnel, so there's less wasted bandwidth and less load on the switches. The forwarding method for a Layer-3 GRE tunnel is routing.
By default, GRE tunnels are in IPv4 Layer-3 mode.
Figure 18 IPv4 Layer-3 GRE Tunnel
Figure 19 IPv6 Layer-3 GRE Tunnel
IPv6 encapsulated in IPv4 and IPv4 encapsulated in IPv6 are not supported. The only Layer-3 GRE modes supported are IPv4 encapsulated in IPv4 and IPv6 encapsulated in IPv6.
Layer-3 Tunnel Traffic FLow
The traffic flow illustrated by
and
is as follows:
1. The frame enters the source switch (Switch-1) on VLAN 101.
The IP packet within the frame is routed through Switch-1 into the Layer-3 GRE tunnel.
2. The IP packet is encapsulated in a GRE packet.
3. The GRE packet enters the network on VLAN 10, is routed across the network to destination switch (Switch-
2), and then exits the network on VLAN 20.
The source IP address of the GRE packet is the IP address of the interface in VLAN 10 in Switch 1.
4. The IP packet is de-encapsulated and routed out of the destination switch (Switch-2) on VLAN 202.
Limitations for Static IPv6 Layer-3 Tunnels
AOS-W does not support the following functions for static IPv6 Layer-3 GRE tunnels: n
IPv6 Auto-configuration and IPv6 Neighbor Discovery mechanisms do not apply to IPv6 GRE tunnels.
116 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
n
The tunnel encapsulation limit and Maximum Transmission Unit (MTU) discovery options are not supported on IPv6 GRE tunnels.
Configuring a Layer-2 GRE Tunnel
In the WebUI
To configure a Layer-2 GRE tunnel for Switch-1 and Switch-2 via the WebUI:
1. Log in to Switch-1.
2. Navigate to Configuration > Network > IP > GRE Tunnels .
The GRE Tunnels page is displayed.
Figure 20 GRE Tunnels Page
3. Highlight the line for the tunnel ID of interest and click Edit . The Edit GRE Tunnel screen appears, as shown in
Figure 21 Layer-2 GRE Tunnel UI Configuration for Switch-1
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 117
4. Enter the corresponding GRE tunnel values for this switch to configure Switch-1 based on the network shown in
5. (Optional) Select Enable Heartbeats to enable tunnel keepalive heartbeats. For more information on this feature, see
Configuring Tunnel Keepalives on page 123
6. Click Apply .
7. Next, log into Switch-2 and navigate to Configuration > Network > IP > GRE Tunnels .
8. Highlight the line for the tunnel ID of interest and click Edit .
9. Use the Edit GRE Tunnel screen to configure Switch-2 based on the network shown in
10.(Optional) Select Enable Heartbeats to enable tunnel keepalive heartbeats.
11.Click
Apply .
In the CLI
The following command example configures a Layer-2 GRE tunnel:
Referring to
Figure 17 , the following are the required configurations to create the Layer-2 GRE tunnel between
switches named Switch-1 and Switch-2:
Switch-1 Configuration
(Switch-1) (config) # interface tunnel 102 description “IPv4 Layer-2 GRE 102" tunnel mode gre 1 tunnel source vlan 10 tunnel destination 20.20.20.249
tunnel keepalive trusted tunnel vlan 101
Switch-2 Configuration
(Switch-2) (config) # interface tunnel 202 description “IPv4 Layer-2 GRE 202" tunnel mode gre 1 tunnel source vlan 20 tunnel destination 10.10.10.249
tunnel keepalive trusted tunnel vlan 101
Configuring a Layer-3 GRE Tunnel for IPv4 or IPv6
In the WebUI
The following steps describe the procedure configure an IPv4 Layer-3 GRE tunnel for Switch-1 and Switch-2 via the WebUI.
1. Log into Switch-1.
2. Navigate to Configuration > Network > IP > GRE Tunnels . The GRE Tunnels page is displayed.
118 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
Figure 22 GRE Tunnels Page
3. Highlight the line for the tunnel ID of interest and click Edit . The Edit GRE Tunnel screen appears, as shown in
Figure 23 Layer-3 IPv4 GRE Tunnel UI Configuration for Switch-1
4. Click the IP Version drop-down list and select IPv4 or IPv6.
5. Enter the corresponding GRE tunnel values for the switch.
n n
To configure an IPv4 GRE tunnel , use the values for Switch-1 based on the network shown in
To configure an IPv6 GRE tunnel , use the values for Switch-1 based on the network shown in
If a VLAN interface has IPv6 addresses configured, one of them is used as the tunnel source IPv6 address. If the selected IPv6 address is deleted from the VLAN interface, then the tunnel source IP address is reconfigured with the next available IPv6 address.
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 119
6. (Optional for an IPv4 GRE Tunnel) Click the Route ACL name drop-down list and select the name of a routing access control list (ACL) to attach a route ACL to inbound traffic on the L3 GRE tunnel interface.
When you associate a routing ACL to inbound traffic on a switch terminating a L3 GRE tunnel, that ACL can forward traffic as normal, route traffic to a nexthop router on a nexthop list, or redirect traffic over an L3
GRE tunnel or tunnel group. For more information on creating a routing ACL, see
Creating a Firewall Policy on page 376
7. (Optional for IPv4 or IPv6 GRE Tunnels) Select Enable Heartbeats to enable tunnel keepalive heartbeats.
For more information on this feature, see
Configuring Tunnel Keepalives on page 123
8. Click Apply .
9. Next, log into Switch-2 and navigate to Configuration > Network > IP > GRE Tunnels .
10.Highlight the line for the tunnel ID of interest and click Edit .
11.Enter the corresponding GRE tunnel values for this switch.
n to create an IPv4 L3 GRE tunnel, use the values for Switch-2 as shown in
n
To create an IPv6 L3 GRE tunnel ure an IPv6 GRE tunnel , use the values for Switch-2 as shown in
.
12.(Optional for an IPv4 GRE Tunnel) Click the Route ACL name drop-down list and select the name of a routing access control list (ACL) to attach a route ACL to inbound traffic on the L3 GRE tunnel interface.
13.(Optional for IPv4 or IPv6 GRE Tunnels) Select Enable Heartbeats to enable tunnel keepalive heartbeats.
14.Click
Apply .
In the CLI
The following command examples configure an IPv4 Layer-3 GRE tunnel for IPv4 between two switches.
Referring to
Figure 18 , the following are the required configurations to create the IPv4 Layer-3 GRE tunnel
between switches named Switch-1 and Switch-2:
IPv4 Switch-1 Configuration
(Switch-1) (config) # interface tunnel 104 description “IPv4 L3 GRE 104" tunnel mode gre ip ip address 1.1.1.1 255.255.255.255
tunnel source vlan 10 tunnel destination 20.20.20.249
trusted
IPv4 Switch-2 Configuration
(Switch-2) (config) # interface tunnel 204 description “IPv4 L3 GRE 204" tunnel mode gre ip ip address 1.1.1.2 255.255.255.255
tunnel source vlan 20 tunnel destination 10.10.10.249
trusted
The following command example configures a Layer-3 GRE tunnel for IPv6:
IPv6 Switch-1 Configuration
(Switch-1) (config) # interface tunnel 106 description “IPv6 Layer-3 GRE 106" tunnel mode gre ipv6 ip address 2001:1:2:1::1 tunnel source vlan 10 tunnel destination 2001:1:2:2020::1 trusted
120 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
IPv6 Switch-2 Configuration
(Switch-2) (config) # interface tunnel 206 description “IPv6 Layer-3 GRE 206" tunnel mode gre ipv6 ip address 2001:1:2:1::2 tunnel source vlan 20 tunnel destination 2001:1:2:1010::1 trusted
Directing Traffic into the Tunnel
You can direct traffic into a GRE tunnel by configuring one of the following: n n
Static route : Redirects traffic to the IP address of the tunnel.
Firewall policy (session-based ACL) : Redirects traffic to the specified tunnel ID.
About Configuring Static Routes
You can configure a static route that specifies the IP address of a tunnel as the next-hop for traffic for a specific destination. See
Configuring Static Routes on page 113
for detailed information on how to configure a static route.
While redirecting traffic into a Layer-3 GRE tunnel via a static route, be sure to use the switch's tunnel IP address as the next-hop, instead of providing the destination switch's tunnel IP address.
Referring to
Figure 18 , the following are examples of the required static route configurations to direct traffic
into the IPv4 Layer-3 GRE tunnel. for Switch-1 and Switch-2: n n
For the switch named Switch-1:
(Switch-1) (config) # ip route 20.20.202.0 255.255.255.0 1.1.1.1
For the switch named Switch-2:
(Switch-2) (config) # ip route 10.10.101.0 255.255.255.0 1.1.1.2
Configuring a Firewall Policy Rule
You can configure a firewall policy rule to redirect selected traffic into a GRE tunnel.
Traffic redirected by a firewall policy rule is not forwarded to a tunnel that is “down” (see the next section,
Configuring Tunnel Keepalives , for more information on how GRE tunnel status is determined).
From the WebUI
To direct traffic into a GRE tunnel via a firewall policy via the WebUI:
1. On the switch, navigate to the Configuration > Security > Access Control > Policies page.
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 121
Figure 24 Firewall Policies Page
2. To create a new firewall policy, click Add.
To edit an existing policy, click Edit .
The Add New Policy screen appears.
Figure 25 Adding a New Firewall Policy
3. Enter the Policy Name .
4. For Policy Type , specify Session (the default).
5. To create a new policy rule, scroll to the Rules section and click Add .
122 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
Figure 26 Specifying Firewall Rules a. Specify the IP Version .
b. Configure the Source , Destination , and Service/Application for the rule.
c. For Action , select redirect to tunnel .
d. Enter the Tunnel ID .
e. Configure any additional options.
6. When satisfied with the settings, click Add , then click Apply .
In the CLI
To direct traffic into a GRE tunnel via a firewall policy (session-based ACL) via the CLI, use the following command:
(SwitchSwitch-1)(config) #ip access-list session <name>
<source> <destination> <service> redirect tunnel <id>
Configuring Tunnel Keepalives
The switch determines the status of a GRE tunnel by sending periodic keepalive frames on the Layer-2 or Layer-
3 GRE tunnel. When you enable tunnel keepalives, the tunnel is considered “down” when the keepalives fail repeatedly.
If you configure a firewall policy rule to redirect traffic to the tunnel, traffic is not forwarded to the tunnel until it is "up." When the tunnel comes up or goes down, an SNMP trap and logging message is generated. The remote endpoint of the tunnel does not need to support the keepalive mechanism.
The switch sends keepalive frames at 60-second intervals by default and retries keepalives up to three times before the tunnel is considered down. You can change the default values of the intervals: n n n
For the interval , specify a value between 1 and 86400 seconds.
For the retries , specify a value between 0 and 1024.
To interoperate with Cisco network devices, use the cisco option.
In the WebUI
To configure keepalives (Heartbeats) via the WebUI:
1. On the switch, navigate to the Configuration > Network > IP > GRE Tunnels page.
2. Locate the tunnel ID for which you are enabling keepalives, then click Edit . The Edit GRE Tunnel screen appears.
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 123
Figure 27 Configuring Heartbeats (Keepalives)
3. To enable tunnel keepalives and display the Heartbeat Interval and Heartbeat Retries fields, click Enable
Heartbeats .
a. Specify a value for Heartbeat Interval.
The default value is 10 seconds.
b. Specify a value for Heartbeat Retries .
The default value is 3 retries.
4. Click Apply .
In the CLI
To configure the keepalive heartbeats, use the following commands:
(host)(config) #interface tunnel id tunnel keepalive [<interval> <retries>] [cisco]
Configuring GRE Tunnel Groups
This section contains the following information: n n n n n
Configuring a Layer-2 or Layer-3 Tunnel Group Using the CLI
Configuring a Layer-2 or Layer-3 Tunnel Group Using the WebUI
About GRE Tunnel Groups
The switch supports redundancy of Generic Routing Encapsulation (GRE) tunnels for both Layer-2 and Layer-3
GRE tunnels. This feature enables automatic redirection of the user traffic to a standby tunnel when the primary tunnel goes down.
A tunnel group is identified by a name or number. You can add multiple tunnels to a tunnel group.
Tunnel Group Order
The order of the tunnels defined in the tunnel-group configuration specifies their standby precedence. The first member of the tunnel-group is the primary tunnel .
Tunnel Failover
A GRE tunnel group combines two tunnels created in the switch, where one tunnel is active and the other tunnel is the standby. Traffic forwarding can occur on the active tunnel, and the standby tunnel can become active once the active tunnel is down.
When the first tunnel fails, the second tunnel carries the traffic. The third tunnel in the tunnel-group takes over if the second tunnel also fails.
In the meantime, if the first tunnel comes up, it becomes the most eligible standby tunnel.
124 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
Preemption
You can also enable or disable preemption as part of the tunnel-group configuration. Preemption is enabled by default. (For CLI examples, see
Enabling Preemption on page 125 .)
The preemptive-failover option automatically redirects the traffic whenever it detects an active tunnel with a higher precedence in the tunnel group.
When preemption is disabled, the traffic gets redirected to a higher precedence tunnel only when the tunnel carrying the traffic fails.
Enabling a Tunnel Group
To enable this tunnel-group functionality, you must complete the following tasks:
1. Configure the member tunnel.
2. Enable tunnel keepalives on the tunnel interface.
3. Configure the tunnel group and set the group type to Layer-2 or Layer-3.
4. Add the member tunnels to the group.
Points to Remember
n n n n
When a tunnel is added to the tunnel group, the tunnel is used for data traffic only if it is the active tunnel in the group.
Standby tunnels do not carry any data traffic. However, all tunnels in the group continue to send and receive keepalive packets.
Only one type of tunnel can be placed into a tunnel group—either Layer-2 or Layer-3. That is, you can't have a tunnel group consisting of both Layer-2 and Layer-3 tunnels.
The default value of tunnel group type is Layer-3.
Regarding Layer-2 Tunnel Groups
When creating a Layer-2 tunnel group, keep in mind the following: n n n n
All tunnels in a Layer-2 tunnel group must be tunneling the same VLAN.
A Layer-2 tunnel can only be part of one tunnel group.
An Alcatel-Lucent Layer-2 tunnel-group is not interoperable with other vendors.
You must set up Layer-2 tunnel groups between Alcatel-Lucent devices only.
Configuring a Layer-2 or Layer-3 Tunnel Group Using the CLI
To configure a Layer-2 or Layer-3 tunnel group using the CLI:
(Controller-1) (config) #tunnel-group <tunnel_group_name>
(Controller-1) (config-tunnel-group)#mode {l2|l3}
(Controller-1)(config-tunnel-group)#tunnel <tunnel-id>
Example Configuration
The following is a sample configuration:
(Controller-1) (config) #tunnel-group branch_1
(Controller-1) (config-tunnel-group)#mode l2
Enabling Preemption
Execute the following command to enable preemption:
(Controller-1)(config-tunnel-group)#preemptive-failover
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 125
Viewing Operational Status
To view the operational status of all the tunnel groups and their members, issue the following command:
(Controller-1) #show tunnel-group
The following is the sample output of the show tunnel-group command:
(Controller-1) #show tunnel-group
Tunnel-Group Table Entries
--------------------------
Tunnel Group Mode Tunnel Group Id Preemptive Failover Active Tunnel Id Tunnel Members
---------------------------------------------------------------------------branch_1 L2 16385 enabled 1 10 11
Viewing Active and Member Tunnels
To view the active member tunnel and all the member tunnels of the respective tunnel-group, issue the following command:
(Controller-1) #show datapath tunnel-group
Following is the sample output of the show datapath tunnel-group command:
(host) #show datapath tunnel-group
Datapath Tunnel-Group Table Entries
-----------------------------------
Tunnel-Group Active Tunnel Members
------------------------------------------
16385 10 10 11
Viewing the Standby Member Tunnels
To view the standby member tunnels of the tunnel-group, issue the following command:
(host) #show datapath tunnel
The following is sample output of the show datapath tunnel command:
(host) #show datapath tunnel
+----+------+-----------------------------------------------------+
|SUM/| | | |
|CPU | Addr | Description Value |
+----+------+-----------------------------------------------------+
| | |
| G | [00] | Current Entries
| G | [02] | High Water Mark
| G | [03] | Maximum Entries
|
10 |
10 |
32768 |
| G | [04] | Total Entries
| G | [06] | Max link length
31 |
1 |
+----+------+-----------------------------------------------------+
Datapath Tunnel Table Entries
-----------------------------
Flags: E - Ether encap, I - Wi-Fi encap, R - Wired tunnel, F - IP fragment OK
W - WEP, K - TKIP, A - AESCCM, G - AESGCM, M - no mcast src filtering
S - Single encrypt, U - Untagged, X - Tunneled node, 1(cert-id) - 802.1X Term-PEAP
2(cert-id) - 802.1X Term-TLS, T - Trusted, L - No looping, d - Drop Bcast/Unknown Mcast,
D - Decrypt tunnel, a - Reduce ARP packets in the air, e - EAPOL only
C - Prohibit new calls, P - Permanent, m - Convert multicast n - Convert RAs to unicast(VLAN Pooling/L3 Mobility enabled), s - Split tunnel
V - enforce user vlan(open clients only), x - Striping IP
H - Standby (HA-Lite), c - IP Compression, g - PAN GlobalProtect Tunnel
126 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
# Source Destination Prt Type MTU VLAN Acls
------------------------------------- ----------------------
10
11
192.0.2.1
192.0.2.1
198.51.100.1
203.0.113.1
47
47
1
1
1100
1100
0
0
0
0
0
0
0
0
0
0
BSSID Decaps Encaps Heartbeats Flags EncapKBytes DecapKBytes
--------------------------------- -------------------------- ------------
00:00:00:00:00:00
00:00:00:00:00:00
0
0
5
0
0 TEFPR
0 LEFPR H
In this example, the member tunnel 11 is a standby tunnel, which is denoted by the H flag.
Configuring a Layer-2 or Layer-3 Tunnel Group Using the WebUI
To configure a Layer-2 or Layer-3 tunnel group using the WebUI:
1. Navigate to the Configuration > Network > IP > GRE Tunnels page.
2. In the Tunnel Group pane, click Add .
3. Specify a name for the tunnel-group in the Tunnel Group Name text box.
4. Under Mode , select the tunnel group type.
5. In the Tunnel Group Member text box, specify the tunnel IDs, separating the IDs with commas.
6. To enable preemption, select the Enable Preemptive-Failover Mode check box. This option is enabled by default.
To disable pre-emption, clear the check box.
7. Click Apply .
Jumbo Frame Support
Jumbo frames are the data frames that are larger than 1500 bytes and includes the Layer 2 header and Frame
Check Sequence (FCS). Jumbo frames functionality can be configured on OAW-40xx Series and OAW-4x50
Series switches to support up to 9216 bytes of payload.
In centralized deployments, frames that are more than 1500 bytes in size are generated from AP to the switch during encryption and enabling AMSDU. Therefore, whenever the AP associates to the switch, jumbo frames are used to get the highest network performance. If this functionality is not supported, the data frames gets fragmented, which reduces the overall throughput of the network and makes the network slow.
AOS-W supports jumbo frames between 11ac APs and both OAW-40xx Series and OAW-4x50 Series switchesonly.
You can enable the jumbo frame support in the following scenarios: n n n n
Tunnel node: In a tunneled node deployment, the wired clients connected on the tunneled nodes can send and receive the jumbo frames.
L2/L3 GRE tunnels: When you establish a GRE tunnel between two switches, the clients on one switch can send and receive jumbo frames from the clients on the other switch on enabling jumbo frames.
Between wired clients: In a network where clients connect to the switch with jumbo frames enabled ports can send and receive the jumbo frames.
Wi-Fi tunnel: A Wi-Fi tunnel can support an AMSDU jumbo frame for an AP (The maximum MTU supported is up to 9216 bytes).
Limitations for Jumbo Frame Support
This release of AOS-W does not support the jumbo frames for the following scenarios: n
IPsec, IPIP, and xSec.
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 127
n
IPv6 fragmentation/reassembly.
Configuring Jumbo Frame Support
You can use the WebUI or CLI to configure the jumbo frame support.
In the WebUI
To enable jumbo frame support globally:
1. Navigate to the Configuration > ADVANCED SERVICES > Stateful Firewall > Global Setting page.
2. Select the Jumbo frames processing checkbox to enable the jumbo frames support.
3. Enter the value of the MTU in the Jumbo MTU [1789-9216] bytes textbox.
4. Click Apply .
To enable jumbo frame support on a port:
1. Navigate to Configuration > NETWORK > Ports page.
2. Select the Enable Jumbo MTU checkbox to enable the jumbo frames support.
3. Click Apply .
To enable jumbo frame support on a port channel:
1. Navigate to the Configuration > NETWORK > Ports > Port-Channel page.
2. Select the Enable Jumbo MTU checkbox to enable the jumbo frames support.
3. Click Apply .
In the CLI
To enable the jumbo frame support globally and to configure the MTU value:
(host)(config)#firewall jumbo mtu <val>
You can configure the MTU value between 1,789-9,216. The default MTU value is 9,216.
To disable the jumbo frame support:
(host)(config)#no firewall enable-jumbo-frames
In this case, the MTU value is considered as 9,216 (default).
To enable jumbo frame support on a port channel:
(host)(config)#interface port-channel <id> jumbo
To disable jumbo frame support on a port channel:
(host)(config)#interface port-channel <id> no jumbo
To enable jumbo frame support on a port:
(host)(config) #interface gigabitethernet <slot>/<module>/<port> jumbo
To disable jumbo frame support on a port:
(host)(config) #interface gigabitethernet <slot>/<module>/<port> no jumbo
Viewing the Jumbo Frame Support Status
Execute the following command to view the global status of the jumbo frame support:
(host)#show firewall
Execute the following command to view the jumbo frame status on a port:
(host)#show interface gigabitethernet <slot>/<module>/<port>
Execute the following command to view the jumbo frame status on a port channel:
128 | Network Configuration Parameters AOS-W 6.5.3.x | User Guide
(host)#show interface port-channel <id>
AOS-W 6.5.3.x
| User Guide Network Configuration Parameters | 129
Chapter 5
IPv6 Support
This chapter describes AOS-W support for IPv6 features: n n n n n n n n n n n n n
Understanding IPv6 Notation on page 130
Understanding IPv6 Topology on page 130
Enabling IPv6 Support for Switch and APs on page 131
Filtering an IPv6 Extension Header (EH) on page 139
Configuring a Captive Portal over IPv6 on page 139
Working with IPv6 Router Advertisements (RAs) on page 140
Understanding AOS-W Supported Network Configuration for IPv6 Clients on page 148
Managing IPv6 User Addresses on page 154
Understanding IPv6 Exceptions and Best Practices on page 155
Understanding IPv6 Notation
The IPv6 protocol is the next generation of large-scale IP networks, it supports addresses that are 128 bits long. This allows 2
128 possible addresses (versus 2
32 possible IPv4 addresses).
Typically, the IP address assigned on an IPv6 host consists of a 64-bit subnet identifier and a 64-bit interface identifier. IPv6 addresses are represented as eight colon-separated fields of up to four hexadecimal digits each.
The following are examples of IPv6 addresses:
2001:0000:0eab:DEAD:0000:00A0:ABCD:004E
The use of the
“::” symbol is a special syntax that you can use to compress one or more group of zeros or to compress leading or trailing zeros in an address. The
“::” can appear only once in an address.
For example, the address,
2001:0000:0dea:C1AB:0000:00D0:ABCD:004E can also be represented as:
2001:0:eab:DEAD:0:A0:ABCD:4E – leading zeros can be omitted
2001:0:0eab:dead:0:a0:abcd:4e – not case sensitive
2001:0:0eab:dead::a0:abcd:4e - valid
2001::eab:dead::a0:abcd:4e - Invalid
IPv6 uses a "/" notation which describes the no: of bits in netmask, similar to IPv4.
2001:eab::1/128 – Single Host
2001:eab::/64 – Network
Understanding IPv6 Topology
IPv6 APs connect to the IPv6 switch over an IPv6 L3 network. The IPv6 switch can terminate both IPv4 and
IPv6 APs. IPv4 and IPv6 clients can terminate to either IPv4 or IPv6 APs. AOS-W supports Router
Advertisements (RA). You do not need an external IPv6 router in the subnet to generate RA for IPv6 APs and clients that depend on stateless autoconfiguration to obtain IPv6 address. The external IPv6 router is the
AOS-W 6.5.3.x
| User Guide IPv6 Support | 130
default gateway in most deployments. However, the switch can be the default gateway by using static routes.
The master-local communication always occurs in IPv4.
The following image illustrates how IPv6 clients, APs, and switches communicate with each other in an IPv6 network:
Figure 28 IPv6 Topology n n n n
The IPv6 switch ( MC2 ) terminates both V4 AP (IPv4 AP) and V6 AP (IPv6 AP).
Client 1 (IPv4 client) terminates to V6 AP and Client 2 (IPv6 client) terminates to V4 AP .
Router is an external IPv6 router in the subnet that acts as the default gateway in this illustration.
MC1 (master) and MC2 (local) communicates in IPv4.
Enabling IPv6
You must enable the IPv6 option on the switch before using any of the IPv6 functions. You can use the ipv6 enable command to enable the IPv6 packet/firewall processing on the switch. The IPv6 option is disabled by default.
You can also use the WebUI to enable the IPv6 option:
1. Navigate to the Configuration > Advanced Services > Stateful Firewall page.
2. Select the Global Settings tab.
3. Select the IPv6 Enable check box to enable the IPv6 option.
4. Click Apply .
Enabling IPv6 Support for Switch and APs
This release of AOS-W provides IPv6 support for switches and access points. You can now configure the master switch with an IPv6 address to manage the switches and APs. Both IPv4 and IPv6 APs can terminate on the
131 | IPv6 Support AOS-W 6.5.3.x | User Guide
IPv6 switch. You can provision an IPv6 AP in the network only if the switch interface is configured with an IPv6 address. An IPv6 AP can serve both IPv4 and IPv6 clients.
You must manually configure an IPv6 address on the switch interface to enable IPv6 support.
You can perform the following IPv6 operations on the switch: n n n n n n n n
Configuring IPv6 Addresses on page 133
Configuring IPv6 Static Neighbors on page 134
Configuring IPv6 Default Gateway and Static IPv6 Routes on page 135
Managing Switch IP Addresses on page 135
Configuring Multicast Listener Discovery on page 136
Debugging an IPv6 Switch on page 138
Provisioning an IPv6 AP on page 138
Monitoring Bandwidth Usage on page 139
n n n n n
You can also view the IPv6 statistics on the switch using the following commands: n n n n n n show datapath ip-reassembly ipv6
— View the IPv6 contents of the IP Reassembly statistics table.
show datapath route ipv6
— View datapath IPv6 routing table.
show datapath route-cache ipv6
— View datapath IPv6 route cache.
show datapath tunnel ipv6
— View the tcp tunnel table filtered on IPv6 entries.
show datapath user ipv6
— View datapath IPv6 user statistics such as current entries, pending deletes, high water mark, maximum entries, total entries, allocation failures, invalid users, and maximum link length.
show datapath session ipv6
— View datapath IPv6 session entries and statistics such as current entries, pending deletes, high water mark, maximum entries, total entries, allocation failures, invalid users, and maximum link length.
Additionally, you can view the IPv6 AP information on the switch using the following show commands: show ap database show ap active show user show ap details ip6-addr show ap debug
The following table lists IPv6 features:
Table 35: IPv6 APs Support Matrix
Features
Forward Mode - Tunnel
Forward Mode - Decrypt Tunnel
Forward Mode - Bridge
Forward Mode - Split Tunnel
AP Type - CAP
Supported on IPv6 APs?
Yes
No
No
No
Yes
AOS-W 6.5.3.x
| User Guide IPv6 Support | 132
Features
AP Type - RAP
AP Type - Mesh Node
IPSEC
CPSec
Wired-AP/Secure-Jack
Fragmentation/Reassembly
MTU Discovery
Provisioning through Static IPv6
Addresses
Provisioning through IPv6 FQDN Master
Name
Provisioning from WebUI
AP boot by Flash
AP boot by TFTP
WMM QoS
AP Debug and Syslog
ARM & AM
WIDS
CLI support for users & datapath
Supported on IPv6 APs?
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
No
No
Yes
Yes
Yes (Limited)
Yes
Configuring IPv6 Addresses
You can configure IPv6 addresses for the management interface, VLAN interface, and the loopback interface of the switch. The switch can have up to three IPv6 addresses for each VLAN interface. The IPv6 address configured on the loopback interface or the first VLAN interface of the switch becomes the default IPv6 address of the switch.
If only one IPv6 address is configured on the switch, it becomes the default IPv6 address of the switch. With this release of AOS-W, you can delete this IPv6 address.
You can configure IPv6 interface address using the WebUI or CLI. As per Internet Assigned Numbers Authority
(IANA), Alcatel-Lucent switches support the following ranges of IPv6 addresses: n n n
Global unicast—2000::/3
Unique local unicast—fc00::/7
Link local unicast—fe80::/10
133 | IPv6 Support AOS-W 6.5.3.x | User Guide
In the WebUI
To Configure Link Local Address
1. Navigate to the Configuration > Network > IP page and select the IP Interfaces tab.
2. Edit a VLAN # and select IP version as IPv6.
3. Enter the link local address in the Link Local Address field.
4. Click Apply .
To Configure Global Unicast Address
1. Navigate to the Configuration > Network > IP page and select the IP Interfaces tab.
2. Edit a VLAN # and select IP version as IPv6.
3. Enter the global unicast address and the prefix-length in the IP Address/Prefix-length field.
4. (Optional) Select the EUI64 Format check box, if applicable.
5. Click Add to add the address to the global address list.
6. Click Apply .
To Configure Loopback Interface Address
1. Navigate to the Configuration > Network > Switch page and select the System Settings tab.
2. Under Loopback Interface enter the loopback address in the IPv6 Address field.
3. Click Apply .
You cannot configure the management interface address using the WebUI.
In the CLI
To configure the link local address:
(host)(config)#interface vlan <vlan#>
(host)(config-subif)#ipv6 address <ipv6-address> link-local
To configure the global unicast address:
(host)(config)#interface vlan <vlan#>
(host)(config-subif)#ipv6 address <ipv6-prefix>/<prefix-length>
To configure the global unicast address (EUI 64 format):
(host)(config)#interface vlan <vlan#>
(host)(config-subif)#ipv6 address <ipv6-prefix/prefix-length> eui-64
To configure the management interface address:
(host)(config)#interface mgmt
(host)(config-subif)#ipv6 address <ipv6-prefix/prefix-length>
To configure the loopback interface address:
(host)(config)#interface loopback
(host)(config-subif)#ipv6 address <ipv6-prefix>
Configuring IPv6 Static Neighbors
You can configure a static neighbor on a VLAN interface either using the WebUI or the CLI.
In the WebUI
1. Navigate to the Configuration > Network > IP page and select the IPv6 Neighbors tab.
2. Click Add and enter the following details of the IPv6 neighbor:
AOS-W 6.5.3.x
| User Guide IPv6 Support | 134
n n n
IPV6 Address
Link-layer Addr
VLAN Interface
3. Click Done to apply the configuration.
In the CLI
To configure a static neighbor on a VLAN interface:
(host)(config)#ipv6 neighbor <ipv6addr> vlan <vlan#> <mac>
Configuring IPv6 Default Gateway and Static IPv6 Routes
You can configure IPv6 default gateway and static IPv6 routes using the WebUI or CLI.
In the WebUI
To Configure IPv6 Default Gateway
1. Navigate to the Configuration > Network > IP page and select the IP Routes tab.
2. Under the Default Gateway section, click Add .
3. Select IPv6 as IP Version , and enter the IPv6 address in the IP Address field.
4. Click Add to add the address to the IPv6 default gateway table.
5. Click Apply .
To Configure Static IPv6 Routes
1. Under the IP Routes section, click Add and select IPv6 as IP Version .
2. Enter the destination IP address and the forwarding settings in the respective fields.
3. Click Done to add the static route to the IPv6 routes table.
4. Click Apply .
In the CLI
To configure the IPv6 default gateway:
(host)(config)#ipv6 default-gateway <ipv6-address> <cost>
To configure static IPv6 routes:
(host)(config)#ipv6 route <ipv6-prefix/prefix-length> <ipv6-next-hop> <cost>
<ipv6-next-hop> = X:X:X:X::X
Managing Switch IP Addresses
You can change the default switch IP address by assigning a different VLAN interface address or the loop back interface address. You can also turn on Syslog messaging for IPv6 (similar to IPv4 logging) using the logging
<ipv6 address> command. For more information on logging, see
Configuring Logging on page 864 .You can
use the WebUI or CLI to change the default switch IP address.
In the WebUI
1. Navigate to the Configuration > Network > Switch page and select the System Settings tab.
2. Under the Switch IP Details section, select the VLAN Id or the loopback interface Id in the IPv6 Address drop down.
3. Click Apply.
135 | IPv6 Support AOS-W 6.5.3.x | User Guide
In the CLI
To configure an IPv6 address to the switch:
(host)(config)#switch-ipv6 loopback
(host)(config)#switch-ipv6 vlan <vlanId>
To enable logging over IPv6:
(host)(config)#logging <ipv6 address>
Configuring Multicast Listener Discovery
You can enable the IPv6 multicast snooping on the switch by using the WebUI or CLI and configure Multicast
Listener Discovery (MLD) parameters such as query interval, query response interval, robustness variable, and ssm-range.
The Source Specific Multicast (SSM) supports delivery of multicast packets that originate only from a specific source address requested by the receiver. You can forward multicast streams to the clients if the source and group match the client subscribed source group pairs (S,G).
The switch supports the following IPv6 multicast source filtering modes: n n
Include - In Include mode, the reception of packets sent to a specified multicast address is enabled only from the source addresses listed in the source list. The default IPv6 SSM address range is FF3X::4000:1 –
FF3X::FFFF:FFFF, and the hosts subscribing to SSM groups can only be in the Include mode.
Exclude - In Exclude mode, the reception of packets sent to a specific multicast address is enabled from all source addresses. If there is a client in the Exclude mode, the subscription is treated as an MLDv1 join.
For more information on MLD feature, see RFC 3810 and RFC 4604 ,
Starting with AOS-W 6.4.2.3, MLD snooping does not add IPv6 Solicited-Node multicast address or groups to the multicast table. A Solicited-Node multicast address is an IPv6 multicast address valid within the local-link
(example, an Ethernet segment or a Frame Relay cloud). Every IPv6 host has at least one such address per interface. Solicited-Node multicast addresses are used in Neighbor Discovery Protocol for obtaining the layer 2 link-layer addresses of other nodes.
In the WebUI
To enable IPv6 MLD Snooping
1. Navigate to the Configuration > Network > IP page and select the IP Interfaces tab.
2. Click the Edit button listed under Actions to edit the required VLAN interface.
3. Select IPv6 from the IP version drop-down list.
4. Check the Enable MLD Snooping check box under MLD section to enable IPv6 MLD snooping.
5. Click Apply.
To Modify IPv6 MLD Parameters
1. Navigate to the Configuration > Network > IP page and select the Multicast tab.
2. Under the MLD section, enter the required values in the following fields: n n
Robustness Variable: default value is 2
Query Interval (second): default value is 125 seconds n
Query Response Interval (in 1/10 second): default value is 100 (1/10 seconds).
3. Click Apply.
To configure the SSM Range:
1. Navigate to Configuration>Network>IP page and select the Multicast tab.
AOS-W 6.5.3.x
| User Guide IPv6 Support | 136
2. In the MLD section, use the SSM Range Start-IP and SSM Range End-IP fields to configure the
SSM Range.
3. Click Apply to save your changes.
In the CLI
To enable IPv6 MLD snooping:
(host)(config) #interface vlan 1
(host)(config-subif)#ipv6 mld snooping
To view if IPv6 MLD snooping is enabled:
(host)(config-subif)#show ipv6 mld interface
To view the MLD Group information:
(host)(config) #show ipv6 mld group
To modify IPv6 MLD parameters:
(host)(config) #ipv6 mld
(host)(config-mld) # query-interval <time in seconds (1-65535)>|query-response-interval <time in 1/10th of seconds (1-65535)|robustness-variable <value (2-10)>
To view MLD configuration:
(host)(config-subif)#show ipv6 mld config
When you enter the SSM Range ensure that the upstream router has the same range, else the multicast stream would be dropped.
Dynamic Multicast Optimization
When multiple clients are associated to an AP and when one client is subscribed for a multicast stream, all the clients associated to the AP receive the stream, as the packets are directed to the multicast MAC address. To restrict the multicast stream to only the subscribed clients, DMO sends the stream to the unicast MAC address of the subscribed clients. DMO is currently supported for both IPv4 and IPv6.
In the WebUI
You can configure the IPv6 DMO feature using the WebUI or CLI.
Using the WEBUI
To enable this feature using the WebUI:
1. Navigate to Configuration>Wireless>AP Configuration page.
2. Select the AP Group tab, click the AP Group you want to edit.
3. Expand the Wireless LAN menu, then expand the Virtual AP menu.
4. Select the Virtual AP profile for which you want to configure the Dynamic Multicast Optimization.
5. In the Basic tab under Broadcast/Multicast section configure the following parameters to enable multicasting: a. Select the Dynamic Multicast Optimization (DMO) checkbox, b. Use the Dynamic Multicast Optimization (DMO) Threshold field to set the maximum number of high-throughput stations in a multicast group.
6. Click Apply to save your changes.
In the CLI
To verify the DMO configuration, execute the following command:
137 | IPv6 Support AOS-W 6.5.3.x | User Guide
(host) #show wlan virtual-ap
Limitations
The following are the MLDv2 limitations: n n n n
Switch cannot route multicast packets.
For mobility clients mld proxy should be used.
VLAN pool scenario stream is forwarded to clients in both the VLANs even if the client from one of the
VLANs is subscribed.
Dynamic Multicast Optimization is applicable for wired clients in switches.
Debugging an IPv6 Switch
AOS-W provides the following debug commands for IPv6: n n n n n n show ipv6 global
— displays if IPv6 is enabled globally or not show ipv6 interface
— displays the configured IPv6 address, and any duplicate addresses show ipv6 route/show datapath route ipv6
— displays the IPv6 routing information show ipv6 ra status
— displays the Router Advertisement status show Datapath session ipv6
— displays the IPv6 sessions created, and the sessions that are allowed show datapath frame
— displays the IPv6 specific counters
You can also use the debug options such as ping and tracepath for IPv6 hosts. You can either use the WebUI or the CLI to use the ping and tracepath options.
In the WebUI
1. To ping an IPv6 host, navigate to the Diagnostics > Network > Ping page, enter an IPv6 address, and click
Ping .
2. To trace the path of an IPv6 host, navigate to the Diagnostics > Network > Tracepath page, enter an
IPv6 address, and click Trace .
In the CLI
To ping an IPv6 host:
(host)#ping ipv6 <global-ipv6-address>
(host)#ping ipv6 interface vlan <vlan-id> <linklocal-address>
To trace the path of an IPv6 host:
(host)#tracepath <global-ipv6-address>
Provisioning an IPv6 AP
You can provision an IPv6 AP on an IPv6 switch. You can either configure a static IP address or obtain a dynamic IPv6 address via stateless-autoconfig. The switch can act as the default gateway for the IPv6 clients, if static IPv6 routes are set on the switch.
Starting with AOS-W 6.3, a wired client can connect to the Ethernet interface of an IPv6 enabled AP.
You can provision an IPv6 AP using the WebUI or CLI.
In the WebUI
1. Navigate to the Configuration > AP Installation> Provision page and select the Provisioning tab.
AOS-W 6.5.3.x
| User Guide IPv6 Support | 138
2. Select an AP and click Provision .
3. Under the Master Discovery section, enter the host switch IP address and the IPv6 address of the master switch.
4. To provision a static IP, select the Use the following IP address check box under the IP Settings section, and enter the following details: n n n
IPv6 Address/Prefix-lengths
Gateway IPv6 Address
DNS IPv6 Address
Ensure that CPSEC is disabled before rebooting the AP.
5. Click Apply and Reboot to bring the IPv6 AP up.
In the CLI
To provision a static IPv6 address:
(host)(config)# provision-ap
Enhancements to IPv6 Support on AP
This release of AOS-W provides the following IPv6 enhancements on the AP: n n n
DNS based ipv6 switch discovery
FTP support for image upgrade in an IPv6 network
DHCPv6 client support
Monitoring Bandwidth Usage
Starting from AOS-W 6.5, customers can monitor bandwidth usage by clients/hosts with IPv6 addresses, over radius protocol. The Framed-IPv6-Address attribute is used in accounting start, stop, and interim packets. A host can have multiple IPv6 addresses and all of them are tracked to check the usage, for billing purpose.
Filtering an IPv6 Extension Header (EH)
AOS-W firewall is enhanced to process the IPv6 Extension Header (EH) to enable IPv6 packet filtering. You can now filter the incoming IPv6 packets based on the EH type. You can edit the packet filter options in the default
EH, using the CLI. The default EH alias permits all EH types.
Execute the following commands to permit or deny the IPv6 packets matching an EH type:
(host)(config) #netexthdr default
(host)(config-exthdr) #eh <eh-type> permit | deny
To view the EH types denied:
(host) (config-exthdr) #show netexthdr default
Configuring a Captive Portal over IPv6
IPv6 is now enabled on the captive portal for user authentication on the Alcatel-Lucent switch. For user authentication, use the internal captive portal that is initiated from the switch. A new parameter captive has been added to the IPv6 captive portal session ACL:
(host) (config) #ipv6 user alias controller 6 svc-https captive
139 | IPv6 Support AOS-W 6.5.3.x | User Guide
This release does not support external captive portal for IPv6. The captive portal authentication, customization of pages, and other attributes are same as IPv4.
You can configure captive portal over IPv6 (similar to IPv4) using the WebUI or CLI. For more information on configuration, see
Configuring Captive Portal in the Base Operating System on page 307 .
Working with IPv6 Router Advertisements (RAs)
AOS-W enables the switches to send router advertisements (RA) in an IPv6 network. Each host auto generates a link local address when you enable ipv6 on the host. The link local address allows the host to communicate between the nodes attached to the same link.
The IPv6 stateless autoconfiguration mechanism allows the host to generate its own addresses using a combination of locally available information and information advertised by the routers. The host sends a router solicitation multicast request for its configuration parameters in the IPv6 network. The source address of the router solicitation request can be an IP address assigned to the sending interface, or an unspecified address if no address is assigned to the sending interface.
The routers in the network respond with an RA. The RAs can also be sent at periodic intervals. The RA contains the network part of the Layer 3 IPv6 address (IPv6 Prefix). The host uses the IPv6 prefix provided by the RA; it generates the universally unique host part of the address (interface identifier), and combines the two to derive the complete address. To establish continuous connectivity to the default router, the host starts the neighbor reachability state machine for the router.
AOS-W uses Radvd, an open source Linux IPv6 Router Advertisement daemon maintained by Litech Systems Design.
You can perform the following tasks on the switch to enable, configure, and view the IPv6 RA status on a VLAN interface: n n n
Configure IPv6 RA on a VLAN
Configure Optional Parameters for RA l l l l
Configure neighbor discovery reachable time
Configure neighbor discovery retransmit time
Configure RA DNS
Configure RA hop-limit l l l l
Configure RA interval
Configure RA lifetime
Configure RA managed configuration flag
Configure RA MTU l l
Configure RA other configuration flag
Configure RA Preference l
Configure RA prefix
View IPv6 RA Status
Configuring an IPv6 RA on a VLAN
You must configure the IPv6 RA functionality on a VLAN for it to send solicited/unsolicited router advertisements on the IPv6 network. You must configure the following for the IPv6 RA to be operational on a
VLAN:
AOS-W 6.5.3.x
| User Guide IPv6 Support | 140
n n n
IPv6 global unicast address enable IPv6 RA
IPv6 RA prefix l l
The advertised IPv6 prefix length must be 64 bits for the stateless address autoconfiguration to be operational.
You can configure up to three IPv6 prefixes per VLAN interface.
l l
Each IPv6 prefix must have an on-link interface address configured on the VLAN.
Ensure you configure the upstream routers to route the packets back to Alcatel-Lucent switch.
You can use the WebUI or CLI to configure the IPv6 RA on a VLAN.
Using WebUI
1. Navigate to the Configuration > Network > IP page and select the IP Interfaces tab.
2. Edit a VLAN # and select IP version as IPv6 .
3. To configure an IPv6 global unicast address, follow the steps below: a. Under Details, enter the IPv6 address and the prefix-length in the IP Address/Prefix-length field.
b. (Optional) Select the EUI64 Format check box, if applicable.
c. Click Add to add the address to the global address list.
4. To enable an IPv6 RA on a VLAN, select the Enable Router Advertisements (RA) check box under
Neighbor Discovery .
5. To configure an IPv6 RA prefix for a VLAN, follow the steps below: a. Under Neighbor Discovery , enter an IPv6 prefix in the IPv6 RA Prefix field.
b. Click Add to configure an IPv6 prefix for the VLAN.
You can add up to three IPv6 prefixes per VLAN interface.
6. Click Apply .
Using CLI
Execute the following commands to configure router advertisements on a VLAN:
(host)(config) #interface vlan <vlanid>
(host)(config-subif)#ipv6 address <prefix>/<prefix-length>
(host)(config-subif)#ipv6 nd ra enable
(host)(config-subif)#ipv6 nd ra prefix X:X:X:X::X/64
Configuring Optional Parameters for RAs
In addition to enabling the RA functionality, you can configure the following IPv6 neighbor discovery and RA options on a VLAN: n n n
Neighbor discovery reachable time – the time, in milliseconds, that a node assumes a neighbor is reachable after receiving a reachability confirmation.
Neighbor discovery retransmit time – the time, in milliseconds, between retransmitted Neighbor Solicitation messages.
RA DNS – the IPv6 recursive DNS Server for the VLAN.
l l
On Linux systems, clients must run the open rdnssd daemon to support the DNS server option.
Windows 7 does not support the DNS server option.
n
RA hop-limit – the IPv6 RA hop-limit value. It is the default value to be placed in the Hop Count field of the
IP header for outgoing (unicast) IP packets.
141 | IPv6 Support AOS-W 6.5.3.x | User Guide
n n n n n n
RA interval – the maximum and minimum time interval between sending unsolicited multicast router advertisements from the interface, in seconds.
RA lifetime – the lifetime associated with the default router in seconds. A value of zero indicates that the router is not a default router and will not appear on the default router list. The router lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options.
RA managed configuration flag (Enable DHCP for address) – a flag that indicates that the hosts can use the
DHCP server for address autoconfiguration besides using RAs.
RA maximum transmission unit (MTU) – the maximum transmission unit that all the nodes on a link use.
RA other configuration flag (Enable DHCP for other information – a flag that indicates that the hosts can use the administered (stateful) protocol for autoconfiguration of other (non-address) information.
RA preference – the preference associated with the default router.
You can use the WebUI or CLI to configure these options.
It is recommended that you retain the default value of the RA interval to achieve better performance.
If you enable RAs on more than 100 VLAN interfaces, some of the interfaces may not send out the RAs at regular intervals.
In the WebUI
1. Navigate to the Configuration > Network > IP page.
2. Select the IP Interfaces tab.
3. Edit the VLAN on which you want to configure the neighbor discovery or RA options.
4. Select IP Version as IPv6 .
5. Under Neighbor Discovery , configure the following neighbor discovery and RA options for the VLAN based on your requirements: a. Enter a value in the Reachable Time field. The allowed range is 0-3,600,000 msec. The default value is zero.
b. Enter a value in the Retransmit Time field. The allowed range is 0-3,600,000 msec.he default value is zero.
c. Enter a DNS server name in the IPv6 Recursive DNS Server field.
d. Enter a hop-limit value in the RA hop-limit field. The allowed range is 1-255. The default value is 64.
e. Enter the maximum interval value in the RA Interval(sec) field. Allowed range is 4-1800 seconds.
Default value is 600 seconds.
f. Enter a value in the RA Minimum Interval(sec) field. Allowed range is 3-0.75 times the maximum RA interval value in seconds. The default minimum value is 0.33 times the maximum RA interval value g. Enter a value in the RA Lifetime field. A value of zero indicates that the router is not a default router.
Apart from a zero value, the allowed range for the lifetime value is the RA interval time to 9,000 seconds.
The default and minimum value is three times the RA interval time.
h. Select the DHCP for address check box to enable the hosts to use the DHCP server for address autoconfiguration apart from any addresses auto configured using the RA.
i.
Enter a value in the RA MTU Option option. The allowed range is 1,280-maximum MTU allowed for the link.
j.
Select the DHCP for Other Address check box to enable the hosts to use the DHCP server for autoconfiguration of other (non-address) information.
AOS-W 6.5.3.x
| User Guide IPv6 Support | 142
k. Select the router preference as High , Medium , or Low .
6. Click Apply.
In the CLI
Execute the following CLI commands to configure the neighbor discovery and RA options for a VLAN interface:
To configure neighbor discovery reachable time:
(host)(config) #interface vlan <vlan-id>
(host)(config-subif)#ipv6 nd reachable-time <value>
To configure neighbor discovery retransmit time:
(host)(config-subif)#ipv6 nd retransmit-time <value>
To configure IPv6 recursive DNS server:
(host)(config-subif)#ipv6 nd ra dns X:X:X:X::X
To configure RA hop-limit:
(host)(config-subif)#ipv6 nd ra hop-limit <value>
To configure RA interval:
(host) (config-subif)#ipv6 nd ra interval <value> <min-value>
To configure RA lifetime:
(host)(config-subif)#ipv6 nd ra life-time <value>
To enable hosts to use DHCP server for stateful address autoconfiguration:
(host)(config-subif)#ipv6 nd ra managed-config-flag
To configure maximum transmission unit for RA:
(host)(config-subif)#ipv6 nd ra mtu <value>
To enable hosts to use DHCP server for other non-address stateful autoconfiguration:
(host)(config-subif)#ipv6 nd ra other-config-flag
To specify a router preference:
(host)(config-subif)#ipv6 nd ra preference [High | Low | Medium]
To view the IPv6 RA status on the VLAN interfaces:
(host) #show ipv6 ra status
IPv6 Router Advertisement Proxy
An IPv6 network deployment typically has one or more upstream routers to delegate IPv6 prefixes through
Router Advertisements (RA) to clients. When a client connects to the network, it would begin with sending
Router Solicitations or DHCP IPv6 requests. In case of Stateless Address Auto-configuration (SLAAC) using RAs where clients sends Router Solicitations (RS), upstream routers can either respond with unicast (L2/L3) RA or with multicast RA. Whenever a new client joins the network, a unicast or a multicast RA is sent to from the router to the client. If it is a multicast packet then existing clients also receive the RA, which results in increasing the traffic. Starting from AOS-W 6.5.1.0, this issue is addressed by enabling IPv6 proxy RA to snoop incoming unsolicited Router Advertisement and Router Solicitations packets.
You can enable IPv6 RA proxy using the CLI and WebUI.
In the WebUI
1. Navigate to the Configuration > Advanced Services > Stateful Firewall page and select the Global
Setting tab.
2. Select IPV6 Proxy Router Advertisement Enable check box.
143 | IPv6 Support AOS-W 6.5.3.x | User Guide
3. Click Apply .
In the CLI
Execute the following command to configure an interval for proxy Router Advertisement:
(host)(config) #ipv6 proxy-ra interval
Execute the following command to enable the proxy Router Advertisement:
(host)(config) #ipv6 proxy-ra
Execute the following command to view the status of the IPv6 proxy Router Advertisement:
(host) #show ipv6 ra proxy
IPv6 RA Proxy status: enabled
IPv6 RA Proxy interval: 600
RADIUS Over IPv6
AOS-W provides support for RADIUS authentication server over IPv6. You can configure an IPv6 host or specify an FQDN that can resolve to an IPv6 address for RADIUS authentication. The RADIUS server is in IPv4 mode by default. You must enable the RADIUS server in IPv6 mode to resolve the specified FQDN to IPv6 address.
You can only configure the global IPv6 address as the host for the Radius server in IPv6 mode.
You can configure the IPv6 host for the RADIUS server using the WebUI or CLI.
In the CLI
You must enable the enable-ipv6 parameter to configure the RADIUS server in IPv6 mode.
(host)(config) #aaa authentication-server radius IPv6
(host)(RADIUS Server "IPv6") #enable-ipv6
Configure an IPv6 address as the host for RADIUS server using the following command:
(host)(RADIUS Server "IPv6") #host <ipv6-address>
The <host> parameter can also be a fully qualified domain name that can resolve to an IPv6 address.
To resolve FQDN, you must configure the DNS server name using the ip name-server <ip4addr> command.
You can configure an IPv6 address for the NAS-IP parameter using the following CLI command:
(host) (RADIUS Server "Ipv6") #nas-ip6 <IPv6 address>
You can configure an IPv6 address for the Source Interface parameter using the following CLI command:
(host) (RADIUS Server "Ipv6") # source-interface vlan <vland-id> ip6addr <ip6addr>
Use the following CLI command to configure an IPv6 address for the global NAS IP which the switch uses to communicate with all the RADIUS servers:
(host) (config) #ipv6 radius nas-ip6 <IPv6 address>
You can also configure an IPv6 global source-interface for all the RADIUS server requests using the following commands:
(host)(config) #ipv6 radius source-interface loopback
(host)(config) #ipv6 radius source-interface vlan <vlan-id> <ip6addr>
AOS-W 6.5.3.x
| User Guide IPv6 Support | 144
In the WebUI
To configure an IPv6 host for a RADIUS server:
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select RADIUS Server to display the RADIUS server List.
3. Select the required RADIUS server from the list to go to the Radius server page.
4. To enable the RADIUS server in IPv6 mode select the Enable IPv6 check box.
5. To configure an IPv6 host for the selected RADIUS server specify an IPv6 address or an FQDN in the Host field.
6. Click Apply .
To configure an IPv6 address for the NAS-IP:
1. Select the Advanced tab.
2. Specify an IPv6 address in the NAS IPv6 field.
3. Click Apply .
To configure an IPv6 global source-interface:
1. Select the Advanced tab.
2. To configure the IPv6 loopback interface as the source interface, select loopback from the Source
Interface v6 drop-down list.
3. To configure a VLAN interface as the source interface, specify the VLAN interface and the IPv6 address in the Source Interface v6 field.
4. Click Apply .
Radius Accounting for IPv6 Clients
Starting from AOS-W 6.5, customers can monitor bandwidth usage by clients/hosts with IPv6 addresses over
Radius Accounting for IPv6 Clients (RADIUS) protocol. The Framed-IPv6-Address attribute is used in accounting start, stop, and interim packets. A host can have multiple IPv6 addresses and all of them are tracked to check the usage for billing purpose.
TACACS Over IPv6
AOS-W provides support for TACACS authentication server over IPv6. You can configure the global IPv6 address as the host for TACACS authentication using CLI or WebUI.
In the CLI
(host)(config) #aaa authentication-server tacacs IPv6
(host)(TACACS Server "IPv6") #host <ipv6-address>
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select TACACS Server to display the Server List.
3. Select the required server from the list to go to the TACACS server page.
4. To configure an IPv6 host for the selected server, specify an IPv6 address in the Host field.
5. Click Apply .
145 | IPv6 Support AOS-W 6.5.3.x | User Guide
DHCPv6 Server
The DHCPv6 server enables network administrators to configure stateful/stateless options and manage dynamic IPv6 users connecting to a network. You can also configure domain name server using DHCPv6.
You can configure IPv6 pools with various configurations such as lease duration, DNS server, vendor specific options, and user defined options using DHCPv6. You can also exclude IPv6 addresses from subnets. Switch
IPv6 addresses, VLAN interface IPv6 addresses, and DNS server addresses are excluded from use by default.
Similar to DHCPv4, a DHCPv6 server pool is associated with a VLAN only through the IPv6 address configured in that VLAN interface. A VLAN interface can have a maximum of three global unicast addresses, but only one
DHCPv6 pool.
DHCPv6 server supports stateless configuration of clients with options apart from the network addresses described in RFC 3736.
Points to Remember
n n n
Similar to IPv4, the default router configuration is not required for IPv6 pools as IPv6 compliant routers will send RAs. The RA source address will be the default-gateway for the clients.
AOS-W does not support DHCPv6 relay and Hospitality feature on DHCPv6.
IPv6 clients will not get a global IPv6 address if a previous DHCP binding exists.
DHCP Lease Limit
The following table provides the maximum number of DHCP leases (both v4 and v6) supported per switch platform:
There is a new enforcement to the existing DHCP limit during configuration.
Table 36: DHCP Lease Limits
Platform
OAW-4005
OAW-4010
OAW-4024
OAW-4030
OAW-4450
OAW-4550
OAW-4650
OAW-4750
DHCP Lease Limit
512
1024
1024
2048
4096
5120
10240
15360
Configuring DHCPv6 Server
You must enable the global DHCPv6 knob for the DHCPv6 functionality to be operational. You can enable and configure DHCPv6 server using the WebUI or CLI.
AOS-W 6.5.3.x
| User Guide IPv6 Support | 146
In the WebUI
1. Navigate to Configuration > Network > IP page and select the DHCP Server tab.
2. Select the IPv6 DHCP Server check box to enable DHCPv6 globally.
3. If there are addresses that should not be assigned in the subnetwork: a. Under Excluded Address Range , click Add to create a list of IPv6 excluded address.
b. Enter the excluded IPv6 address range in IPv6 Excluded Range and click Done . The specified address range gets added to the IPv6 Excluded Address list box. The starting IP address in the Exclude
Address Range should always contain a unique value, if the IP address is already present, then the existing IP address is replaced with a new one, and a warning is displayed.
c. Click Apply .
4. Under Pool Configuration , click Add to create a new DHCP server pool or click Edit to modify an existing
DHCP server pool.
To enable the DHCPv6 Server functionality on an interface, select the IP Interfaces tab, edit the VLAN interface, and select a DHCP pool from the drop-down list under the DHCP server section. Ensure that the IP version of the VLAN interface is IPv6.
5. Select IP Version as IPv6 to create a DHCPv6 pool.
6. Enter a name in Pool Name to configure an IPv6 pool name.
7. Enter an IPv6 address in DNS Servers to configure an IPv6 DNS server.
To configure multiple DNS servers, enter the IPv6 addresses separated by space.
8. Enter a value in Domain Name to configure the domain name.
9. Enter the number of days, hours, minutes, and seconds in Lease to configure the lease time. The default value is 12 hours.
10.Specify an IPv6 prefix in Network to configure an IPv6 network.
11.Enter the following details under Option to configure client specific DHCPv6 options.
a. Specify the option code in Option .
b. Select IP or text from the IP/Text drop-down list.
c. Enter a value in Value . If you selected IP in step b , then you must enter a valid IPv6 address in this field.
d. Click Add .
12.Click
Apply .
In the CLI
To enable the DHCPv6 service you can use the following command:
(host)(config) #service dhcpv6
To configure a domain name server, execute the following commands:
(host)(config) #ipv6 dhcp pool <pool-name>
(host)(config-dhcpv6)#dns-server <ipv6-address>
To configure a domain name, use the following command:
(host)(config-dhcpv6)#domain-name <domain>
To configure DHCPv6 lease time, use the following command:
(host)(config-dhcpv6)#lease <days> <hours> <minutes> <seconds>
The default value is 12 hours.
147 | IPv6 Support AOS-W 6.5.3.x | User Guide
To configure a DHCP network, use the following command:
(host)(config-dhcpv6)#network <network-prefix>
To configure a client specific option, use the following command:
(host)(config-dhcpv6)#option <code> [ip <ipv6-address> | text <string>]
To configure DHCP server preference, use the following command:
(host)(config-dhcpv6)#preference <value>
To enable DHCPv6 Server functionality on an interface, use the following command:
(host) (config) #interface vlan <vlan-id>
(host) (config-subif) #ipv6 dhcp server <pool-name>
The configured DHCPv6 pool subnet must match the interface prefix for DHCPv6 Server to be active.
To configure the IPv6 excluded address range for the DHCPv6 server, use the following command:
(host)(config)#ipv6 dhcp excluded-address <low-address> [<high-address>]
You can view the DHCPv6 server settings, statistics, and binding information using the CLI.
To view the DHCPv6 database, use the following command:
(host)#show ipv6 dhcp database
You can also view the DHCPv6 database for a specific pool, use the following command:
(host) (config) #show ipv6 dhcp database [pool <pool-name>]
(host) (config) #show ipv6 dhcp database pool DHCPv6
To view the DHCPv6 binding information, use the following command:
(host)# show ipv6 dhcp binding
To clear all the DHCPv6 bindings, use the following command:
(host)# clear ipv6 dhcp binding
To view the DHCPv6 server statistics, use the following command:
(host)(config) #show ip dhcp statistics
To view the DHCPv6 active pools, use the following command:
(host) #show ipv6 dhcp active-pools
Understanding AOS-W Supported Network Configuration for IPv6
Clients
AOS-W provides wired or wireless clients using IPv6 addresses with services such as firewall functionality, layer-
2 authentication, and, with the installation of the Policy Enforcement Firewall Next Generation (PEFNG), identity-based security. The Alcatel-Lucent switch does not provide routing or Network Address Translation to
IPv6 clients (see
Understanding IPv6 Exceptions and Best Practices on page 155 ).
Supported Network Configuration
Clients can be wired or wireless and use IPv4 and/or IPv6 addresses. An external IPv6 router is recommended for a complete routing experience (dynamic routing). You can use the WebUI or CLI to display IPv6 client information.
On the switch, you can configure both IPv4 and IPv6 client addresses on the same VLAN.
AOS-W 6.5.3.x
| User Guide IPv6 Support | 148
Understanding the Network Connection Sequence for Windows IPv6 Clients
This section describes the network connection sequence for Windows Vista/XP clients that use IPv6 addresses, and the actions performed by the AP and the switch.
1. The IPv6 client sends a Router Solicit message through the AP. The AP passes the Router Solicit message from the IPv6 client through the GRE tunnel to the switch.
2. The switch removes the 802.11 frame and creates an 802.3 frame for the Router Solicit message.
a. The switch authenticates the user, applies firewall policies, and bridges the 802.3 frame to the IPv6 router.
b. The switch creates entries in the user and session tables.
3. The IPv6 router responds with a Router Advertisement message.
4. The switch applies firewall policies, then creates an 802.11 frame for the Router Advertisement message.
The switch sends the Router Advertisement through the GRE tunnel to the AP.
5. The IPv6 client sends a Neighbor Solicitation message.
6. The IPv6 router responds with a Neighbor Advertisement message.
7. If the DHCP is required to provide IPv6 addresses, the DHCPv6 process is started.
8. The IPv6 client sends data.
9. The switch removes the 802.11 frame and creates an 802.3 frame for the data.
The switch authenticates the user, applies firewall policies and bridges the 802.3 frame to the IPv6 router.
The switch creates entries in the user and session tables.
A client can have an IPv4 address and an IPv6 address, but the switch does not relate the states of the IPv4 and the
IPv6 addresses on the same client. For example, if an IPv6 user session is active on a client, the switch will delete an
IPv4 user session on the same client if the idle timeout for the IPv4 session is reached.
Understanding AOS-W Authentication and Firewall Features that
Support IPv6
This section describes AOS-W features that support IPv6 clients.
Understanding Authentication
This release of AOS-W only supports 802.1X authentication for IPv6 clients. You cannot configure layer-3 authentications to authenticate IPv6 clients.
Table 37: IPv6 Client Authentication
Authentication Method
802.1X
Stateful 802.1X (with non-Alcatel-
Lucent APs)
Supported for IPv6 Clients?
Yes
Yes
Local database
Captive Portal
Yes
Yes
149 | IPv6 Support AOS-W 6.5.3.x | User Guide
Authentication Method
VPN xSec
MAC-based
Supported for IPv6 Clients?
No
No (not tested)
Yes
You configure 802.1X authentication for IPv6 clients in the same way as for IPv4 client configurations. For more information about configuring 802.1X authentication on the switch, see
.
This release does not support authentication of management users on IPv6 clients.
Working with Firewall Features
If you installed a Policy Enforcement Firewall Next Generation (PEFNG) license in the switch, you can configure firewall functions for IPv6 client traffic. While these firewall functions are identical to firewall functions for IPv4 clients, you need to explicitly configure them for IPv6 traffic. For more information about firewall policies, see
Understanding Global Firewall Parameters on page 393 .
Voice-related and NAT firewall functions are not supported for IPv6 traffic.
Table 38: IPv6 Firewall Parameters
Parameter
Monitor Ping Attack (per
30 seconds)
Monitor TCP SYN Attack rate (per 30 seconds)
Description
Number of ICMP pings per 30 second, which if exceeded, can indicate a denial of service attack. Valid range is 1-16384 pings per 30 seconds.
Recommended value is 120.
Default: No default
Number of TCP SYN messages per 30 second, which if exceeded, can indicate a denial of service attack. Valid range is 1-16384 pings per 30 seconds.
Recommended value is 960.
Default: No default
Monitor IP Session Attack
(per 30 seconds)
Deny Inter User Bridging
Deny All IP Fragments
Number of TCP or UDP connection requests per 30 second, which if exceeded, can indicate a denial of service attack. Valid range is 1-16384 requests per 30 seconds.
Recommended value is 960.
Default: No default
Prevents the forwarding of Layer-2 traffic between wired or wireless users. You can configure user role policies that prevent Layer-3 traffic between users or networks but this does not block Layer-2 traffic. This option can be used to prevent traffic, such as Appletalk or IPX, from being forwarded.
Default: Disabled
Drops all IP fragments.
NOTE: Do not enable this option unless instructed to do so by an Alcatel-Lucent representative.
Default: Disabled
AOS-W 6.5.3.x
| User Guide IPv6 Support | 150
Table 38: IPv6 Firewall Parameters
Parameter
Enforce TCP Handshake
Before Allowing Data
Description
Prevents data from passing between two clients until the three-way TCP handshake has been performed. This option should be disabled when you have mobile clients on the network, as enabling this option will cause mobility to fail. You can enable this option if there are no mobile clients on the network.
Default: Disabled
Prohibit IP Spoofing Enables detection of IP spoofing (where an intruder sends messages using the IP address of a trusted client). When you enable this option, IP and MAC addresses are checked for each ARP request/response. Traffic from a second MAC address using a specific IP address is denied, and the entry is not added to the user table.
Possible IP spoofing attacks are logged and an SNMP trap is sent.
Default: Disabled
Prohibit RST Replay Attack When enabled, closes a TCP connection in both directions if a TCP RST is received from either direction. You should not enable this option unless instructed to do so by an Alcatel-Lucent representative.
Default: Disabled
Session Mirror
Destination
Session Idle Timeout
Destination (IPv4 address or switch port) to which mirrored session packets are sent. You can configure IPv6 flows to be mirrored with the session ACL “mirror” option. This option is used only for troubleshooting or debugging.
Default: N/A
Set the time, in seconds, that a non-TCP session can be idle before it is removed from the session table. Specify a value in the range 16–259 seconds. You should not set this option unless instructed to do so by an Alcatel-Lucent representative.
Default: 30 seconds
Per-packet Logging
IPv6 Enable
Enables logging of every packet if logging is enabled for the corresponding session rule. Normally, one event is logged per session. If you enable this option, each packet in the session is logged. You should not enable this option unless instructed to do so by an Alcatel-Lucent representative, as doing so may create unnecessary overhead on the switch.
Default: Disabled (per-session logging is performed)
Enables IPv6 globally.
The following examples configure attack rates and the session timeout for IPv6 traffic.
To configure the firewall function via the WebUI:
1. Navigate to the Configuration > Advanced Services > Stateful Firewall > Global Setting page.
2. Under the IPv6 column, enter the following: n n
For Monitor Ping Attack , enter 15
For Monitor IP Session Attack , enter 25 n
For Session Idle Timeout , enter 60
3. Click Apply .
To configure firewall functions using the command line interface, issue the following commands in config mode: ipv6 firewall attack-rate ping 15 ipv6 firewall attack-rate session 25 ipv6 firewall session-idle-timeout 60
151 | IPv6 Support AOS-W 6.5.3.x | User Guide
Understanding Firewall Policies
A user role, which determines a client’s network privileges, is defined by one or more firewall policies. A firewall policy consists of rules that define the source, destination, and service type for specific traffic, and whether you want the switch to permit or deny traffic that matches the rule.
You can configure firewall policies for IPv4 traffic or IPv6 traffic, and apply IPv4 and IPv6 firewall policies to the same user role. For example, if you have employees that use both IPv4 and IPv6 clients, you can configure both IPv4 and IPv6 firewall policies and apply them both to the “employee” user role.
The procedure to configure an IPv6 firewall policy rule is similar to configuring a firewall policy rule for IPv4 traffic, but with some differences.
Table 18 describes the required and optional parameters for an IPv6 firewall policy rule.
Table 39: IPv6 Firewall Policy Rule Parameters
Field
Source
(required)
Description
Source of the traffic: n any : Acts as a wildcard and applies to any source address.
n n user : This refers to traffic from the wireless client.
host : This refers to traffic from a specific host. When this option is chosen, you must configure the IPv6 address of the host. For example,
2002:d81f:f9f0:1000:c7e:5d61:585c:3ab.
n network : This refers to a traffic that has a source IP from a subnet of IP addresses.
When you chose this option, you must configure the IPv6 address and network mask of the subnet. For example, 2002:ac10:fe:: ffff:ffff:ffff::.
n alias : This refers to using an alias for a host or network.
NOTE: This release does not support IPv6 aliases. You cannot configure an alias for an IPv6 host or network.
Destination
(required)
Service
(required)
Destination of the traffic, which you can configure in the same manner as Source.
Action
(required)
Log (optional)
NOTE: Voice over IP services are unavailable for IPv6 policies.
Type of traffic: n n n any : This option specifies that this rule applies to any type of traffic.
tcp : Using this option, you configure a range of TCP port(s) to match the rule to be applied.
udp : Using this option, you configure a range of UDP port(s) to match the rule to be applied.
n n service : Using this option, you use one of the pre-defined services (common protocols such as HTTPS, HTTP, and others) as the protocol to match the rule to be applied. You can also specify a network service that you configure by navigating to the
Configuration > Advanced Services > Stateful Firewall > Network Services page.
protocol : Using this option, you specify a different layer 4 protocol (other than
TCP/UDP) by configuring the IP protocol value.
The action that you want the switch to perform on a packet that matches the specified criteria.
n n permit: Permits traffic matching this rule.
drop: Drops packets matching this rule without any notification.
NOTE: The only actions for IPv6 policy rules are permit or deny; in this release, the switch cannot perform network address translation (NAT) or redirection on IPv6 packets. You can specify options such as logging, mirroring, or blacklisting (described below).
Logs a match to this rule. This is recommended when a rule indicates a security breach, such as a data packet on a policy that is meant only to be used for voice calls.
AOS-W 6.5.3.x
| User Guide IPv6 Support | 152
Table 39: IPv6 Firewall Policy Rule Parameters
Field
Mirror
(optional)
Description
Mirrors session packets to a datapath or remote destination specified in the IPv6 firewall function (see “Session Mirror Destination” in
). If the destination is an IP address, it must be an IPv4 IP address.
Queue
(optional)
Time Range
(optional)
Black List
(optional)
TOS (optional)
802.1p Priority
(optional)
The queue in which a packet matching this rule should be placed. Select High for higher priority data, such as voice, and Low for lower priority traffic.
Time range for which this rule is applicable. You configure time ranges in the
Configuration > Security > Access Control > Time Ranges page.
Automatically blacklists a client that is the source or destination of traffic matching this rule. This option is recommended for rules that indicate a security breach where the blacklisting option can be used to prevent access to clients that are attempting to breach the security.
Value of type of service (TOS) bits to be marked in the IP header of a packet matching this rule when it leaves the switch.
Value of 802.1p priority bits to be marked in the frame of a packet matching this rule when it leaves the switch.
The following example creates a policy "ipv6-web-only" that allows only web (HTTP and HTTPS) access for IPv6 clients and assigns the policy to the user role “web-guest."
The user role “web-guest” can include both IPv6 and IPv4 policies, although this example only shows configuration of an IPv6 policy.
Creating an IPv6 Firewall Policy
Following the procedure below to create an IPv6 firewall policy via the WebUI.
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Click Add to create a new policy.
3. Enter ipv6-web-only for the Policy Name.
4. To configure a firewall policy, select Session for Policy Type.
5. Click Add to add a rule that allows HTTP traffic.
a. Under IP Version column, select IPv6 .
b. Under Source , select network from the drop-down list.
c. For Host IP , enter 2002:d81f:f9f0:1000:: .
d. For Mask , enter 64 as the prefix-length.
e. Under Service , select service from the drop-down list.
f. Select svc-http from the scrolling list.
g. Click Add .
6. Click Add to add a rule that allows HTTPS traffic.
a. Under IP Version column, select IPv6.
b. Under Source, select network from the drop-down list.
c. For Host IP , enter 2002:d81f:f9f0:1000:: .
d. For Mask , enter 64 as the prefix-length.
e. Under Service , select service from the drop-down list.
153 | IPv6 Support AOS-W 6.5.3.x | User Guide
.
f. Select svc-https from the scrolling list.
g. Click Add .
Rules can be reordered using the up and down arrow buttons provided for each rule.
7. Click Apply . The policy is not created until the configuration is applied.
To create an IPv6 firewall policy using the command-line interface, issue the following commands in config mode: ip access-list session ipv6-web-only
ipv6 network 2002:d81f:f9f0:1000::/64 any svc-http permit
ipv6 network 2002:d81f:f9f0:1000::/64 any svc-https permit
Assigning an IPv6 Policy to a User Role
To assign an IPv6 policy using the WebUI:
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Click Add to create a new user role.
3. Enter web-guest for Role Name.
4. Under Firewall Policies, click Add . From Choose from Configured Policies, select the “ipv6-web-only” IPv6 session policy from the list.
5. Click Done to add the policy to the user role.
6. Click Apply .
To assign an IPv6 policy to a user role via the command-line interface, issue the following command in config mode: user-role web-guest
access-list session ipv6-web-only position 1
Understanding DHCPv6 Passthrough/Relay
The switch forwards DHCPv6 requests from IPv6 clients to the external IPv6 router. On the external IPv6 router, you must configure the switch’s IP address as the DHCP relay. You do not need to configure an IP helper address on the switch to forward DHCPv6 requests.
Managing IPv6 User Addresses
Viewing or Deleting User Entries
To view or delete IPv6 user entries via the WebUI:
1. Navigate to the Monitoring > Switch > Clients page.
2. Click the IPv6 tab to display IPv6 clients.
3. To delete an entry in the IPv6 client display, click the radio button to the left of the client and then click
Disconnect .
To view user entries for IPv6 clients using the command line interface, use the show user-table command in enable mode. To delete a user entry for an IPv6 client, access the CLI in config mode and use the aaa ipv6 user delete command. For example:
(host)(config) #aaa ipv6 user delete 2002:d81f:f9f0:1000:e409:9331:1d27:ef44
AOS-W 6.5.3.x
| User Guide IPv6 Support | 154
Understanding User Roles
An IPv6 user or a client can inherit the corresponding IPv4 roles. A user or client entry on the user table will contain the user or client’s IPv4 and IPv6 entries. After captive-portal authentication, a IPv4 client can acquire a different role. This role is also updated on the client’s IPv6 entry in the user table.
Viewing Datapath Statistics for IPv6 Sessions
To view datapath session statistics for individual IPv6 sessions, access the command-line interface in enable mode and issue the command show datapath session ipv6 . To display the user entries in the datapath, access the command-line interface in enable mode, and issue the command show datapath user ipv6
. For details on each of these commands and the output they display, refer to the AOS-W Command Line Reference
Guide .
Understanding IPv6 Exceptions and Best Practices
The IPv6 best practices are provided below: n n n n n n
Ensure that you enable IPv6 globally.
The uplink port must be trusted. This is the same behavior as IPv4.
Ensure that the validuser session ACL does not block IPv6 traffic.
There must not be any ACLs that drop ICMPv6 or DHCPv6 traffic. It is acceptable to drop DHCPv6 traffic if the deployment uses Stateless Address Auto Configuration (SLAAC) only.
If an external device provides RA: l
It is not recommended to advertise too many prefixes in RA.
l
The switch supports a maximum of four IPv6 user entries in the user table. If a client uses more than four IPv6 addresses at a time, the user table is refreshed with the latest four active entries without disrupting the traffic flow. However, this may have some performance impact.
Enable BCMC Optimization under interface VLAN to drop any random IPv6 multicast traffic. DHCPv6, ND,
NS, and RA traffic are not dropped when you enable this option.
It is recommended to enable BCMC Optimization only if mDNS traffic is not used in the network, as mDNS traffic gets dropped if this option is enabled.
n n
It is not recommended to enable preemption on the master redundancy model. If preemption is disabled and if there is a failover, the new primary switch remains the primary switch even when the original master is online again. The new primary switch does not revert to its original state unless forced by the administrator. Disabling preemption prevents the master from “flapping” between two switches and allows the administrator to investigate the cause of the outage.
While selecting a source address, the number of common bits between each source address in the list, is checked from the left most bit. This is followed by selection of the source address that has the maximum number of matching bits with the destination address. If more than one source addresses has the same number of matching bits with the destination address, the kernel selects that source address that is most recently configured on the system. It is essential that the administrator/user configures the network appropriately, if a particular VLAN interface needs to be selected as the source. For example, in case of
Dot1x authentication the administrator/user can configure the source interface appropriately so that it is selected for authentication process. For more information on IPv6 source address selection, see RFC 3848 .
AOS-W does not support the following functions for IPv6 clients: n n
The switch offers limited routing services to IPv6 clients, so it is recommended to use an external IPv6 router for a complete routing experience (dynamic routing).
VoIP ALG is not supported for IPv6 clients.
155 | IPv6 Support AOS-W 6.5.3.x | User Guide
n n n n n
Remote AP supports IPv6 clients in tunnel forwarding mode only. The Remote AP bridge and split-tunnel forwarding modes do not support IPv6 clients. Secure Thin Remote Access Point (STRAP) cannot support
IPv6 clients.
IPSec is not supported over IPv6.
IPv6 Auto configuration and IPv6 Neighbor Discovery mechanisms does not apply to IPv6 tunnels.
Tunnel Encapsulation Limit, Tunnel-group, and MTU discovery options on IPv6 tunnels are not supported.
IPSec is not supported in this release, so IPv6 GRE cannot be used for master-local setup.
AOS-W 6.5.3.x
| User Guide IPv6 Support | 156
Chapter 6
Link Aggregation Control Protocol
The AOS-W implementation of Link Aggregation Control Protocol (LACP) is based on the standards specified in
802.3ad. LACP provides standardized means for exchanging information with partner systems, to form a Link
Aggregation Group (LAG). LACP avoids port channel misconfiguration.
Two devices (actor and partner) exchange LACP Data Units (DUs) when forming a LAG. Once multiple ports in the system have the same actor system ID, actor key, partner system ID, and partner key, they belong to the same LAG.
The maximum number of supported port-channels is eight. With the introduction of LACP, this number remains the same. A port-channel group (LAG) is created either statically or dynamically through LACP. This chapter contains the following topics: n n n
Understanding LACP Best Practices and Exceptions on page 157
LACP Sample Configuration on page 160
For information on configuring LACP on OAW-AP220 Series and OAW-AP270 Series access points, see
Aggregation Support on OAW-AP220 Series, OAW-AP270 Series, and OAW-AP320 Series on page 588
Hashing is done using the source IP and destination IP of the received frame if the received frame is a IP packet. Hashing is done using the source MAC and destination MAC of the received frame if the received frame is a non-IP packet. This hashing algorithm is common for both IP Frames and non-IP Frames as described below:
The XOR operation performed on the source and destination addresses bitwise and the AND operation is performed on the result with the Hash Key size bitwise. Typically, the Hash Key size is 8.
n n n n n n n n n n
Understanding LACP Best Practices and Exceptions
LACP is disabled by default.
LACP depends on periodical Tx/Rx of LACP Data Units (LACPDUs). Any failure is noticed immediately and that port is removed from the LAG.
The maximum LAG supported per system is eight groups; each group can be created statically or through
LACP.
Each LAG can have up to eight member ports.
The LAG group identification (ID) range is 0–7 for both static (port-channel) and LACP groups.
When a port is added to a LACP LAG, it inherits the port-channel’s properties such as, VLAN membership, trunk status, and so on.
When a port is added to a LACP LAG, the port’s property (like speed) is compared to the existing port property. If there is a mismatch, the command is rejected.
The LACP commands cannot be configured on a port that is already a member of a static port-channel.
Similarly, if the group assigned in the command lacp group <number> already contains static port members, the command is rejected.
The port uses the group number as its actor admin key.
All ports use long timeout values (90 seconds) by default.
AOS-W 6.5.3.x
| User Guide Link Aggregation Control Protocol | 157
n
The output of the command show interface port-channel now indicates if the LAG is created by LACP
(dynamic) or static configuration. If the LAG is created through LACP, you cannot add or delete any ports under that port channel. All other commands are allowed.
Configuring LACP
Two LACP configured devices exchange LACPDUs to form a link aggregation group (LAG). A device is configurable as an active or passive participant. In active mode, the device initiates DUs irrespective of the partner state; passive mode devices respond only to the incoming DUs sent by the partner device. Hence, to form a LAG group between two devices, one device must be an active participant. For detailed information on the LACP commands, see the AOS-W 6.4.x Command-Line Interface Reference Guide .
In the CLI
LACPDUs exchange their corresponding system identifier/priority along with their port’s key/priority. This information determines the LAG of a given port. The LAG for a port is selected based on its keys. The port is placed in that LAG only when its system ID/key and partner's system ID/key matches the other ports in the
LAG (if the group has ports).
1. Enable LACP and configure the per-port specific LACP. The group number range is 0–7.
lacp group <group_number> mode {active | passive} n n
Active mode—the interface is in an active negotiating state. LACP runs on any link that is configured to be in the active state. The port in an active mode also automatically initiates negotiations with other ports by initiating LACP packets.
Passive mode—the interface is not in an active negotiating state. LACP runs on any link that is configured in a passive mode. The port in a passive mode responds to negotiations requests from other ports that are in an active mode. Ports in passive mode respond to LACP packets.
A port in a passive mode cannot set up a port channel (LAG group) with another port in a passive mode.
2. Set the timeout for the LACP session. The timeout value is the amount of time that a port-channel interface waits for a LACPDU from the remote system before terminating the LACP session. The default long timeout value is 90 seconds; short is 3 seconds.
lacp timeout {long | short}
3. Set the port priority.
lacp port-priority <priority_value>
The higher the priority value the lower the priority. The range is 1-65535 and the default is 255.
4. View your LACP configuration.
The port uses the group number +1 as the “actor admin key”. All the ports use the long timeout value (90 seconds) by default.
(host)#show lacp 0 neighbor
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting fast LACPDUs
A - Device is in active mode P - Device is in passive mode
Partner's information
---------------------
Port Flags Pri OperKey State Num Dev Id
----------- ----------- ---- ----------------
FE 1/1 SA 1 0x10 0x45 0x5 00:0b:86:51:1e:70
FE 1/2 SA 1 0x10 0x45 0x6 00:0b:86:51:1e:70
158 | Link Aggregation Control Protocol AOS-W 6.5.3.x | User Guide
When a port in a LAG is misconfigured (the partner device is different than the other ports), or the neighbor timesout or can not exchange LACPDUs with the partner, the port status is displayed as “DOWN” (see the following example):
(host)#show lacp 0 internal
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting fast LACPDUs
A - Device is in active mode P - Device is in passive mode
Port Flags Pri AdminKey OperKey State Num Status
----------- --------------- ----- ---- -------
FE 1/1 SA 1 0x1 0x1 0x45 0x2 DOWN
FE 1/2 SA 1 0x1 0x1 0x45 0x3 UP
In the WebUI
Access LACP from the Configuration >Network >Port tabs. Use the drop-down list to enter the LACP values.
n n n n
LACP Group— the link aggregation group (LAG) number; the range is 0 to 7.
Mode— active negotiation state or not in an active negotiation state indicated by the passive option.
Priority—the port priority value; the range is 1-65535 and the default is 255.
Timeout— time out value for the LACP session. The long default is 90 seconds; the short default is 3 seconds.
For information on configuring LACP on OAW-AP220 Series and OAW-AP270 Series access points, see
Aggregation Support on OAW-AP220 Series, OAW-AP270 Series, and OAW-AP320 Series on page 588
AOS-W 6.5.3.x
| User Guide Link Aggregation Control Protocol | 159
LACP Sample Configuration
The following sample configuration is for FastEthernet (FE) port/slot 1/0, 1/1, and 1/2: interface fastethernet 1/0 description "FE1/0" trusted vlan 1-4094 lacp group 0 mode active
!
interface fastethernet 1/1 description "FE1/1" trusted vlan 1-4094 lacp timeout short lacp group 0 mode active
!
interface fastethernet 1/2 description "FE1/2" trusted vlan 1-4094 lacp group 0 mode passive
!
160 | Link Aggregation Control Protocol AOS-W 6.5.3.x | User Guide
Chapter 7
OSPFv2
n n
OSPFv2 (Open Shortest Path First) is a dynamic Interior Gateway routing Protocol (IGP) based on IETF RFC
2328. The OSPF uses the shortest or fastest routing path. Alcatel-Lucent’s implementation of OSPFv2 allows
Alcatel-Lucent switches to deploy effectively in a Layer 3 topology. Alcatel-Lucent switches can act as default gateway for all clients and forward user packets to the upstream router. An Alcatel-Lucent switch can be used for Instant AP VPN termination from the branch office, and the OSPF on the switch can be used to redistribute branch routes into corporate OSPF domain. The information on this chapter is in the following sections: n n n
Understanding OSPF Deployment Best Practices and Exceptions on page 161
Understanding OSPFv2 by Example using a WLAN Scenario on page 162
Understanding OSPFv2 by Example using a Branch Scenario on page 163
Sample Topology and Configuration on page 166
n n n n n n n n
Understanding OSPF Deployment Best Practices and Exceptions
OSPF is a robust routing protocol addressing various link types and deployment scenarios. The Alcatel-Lucent implementation applies to two main use cases; WLAN Scenarios and Branch Scenario.
OSPF is disabled by default.
Alcatel-Lucent switches support only one OSPF instance.
Convergence takes between 5 and 15 seconds.
All area types are supported.
Multiple configured areas are supported.
An Alcatel-Lucent switch can act as an ABR (Area border router).
OSPF supports VLAN and GRE tunnel interfaces.
To run OSPF over IPSec tunnels, a Layer 3 GRE tunnel is configured between two routers with GRE destination addresses as the inner address of the IPsec tunnel. OSPF is enabled on the Layer 3 GRE tunnel interface, and all of the OSPF control packets undergo GRE encapsulation before entering the IPsec tunnels.
The default MTU value for a Layer 3 GRE tunnel in an Alcatel-Lucent switch is 1100. When running OSPF over a GRE tunnel between an Alcatel-Lucent switch and another vendor’s router, the MTU values must be the same on both sides of the GRE tunnel.
The following table provides information on the maximum OSPF routes supported for various platforms:
Table 40: Maximum OSPF Routes
Platform Branches Routes
OAW-4550 8K 8K
OAW-4650
OAW-4750
16K
32K
16K
32K
Below are some guidelines regarding deployment and topology for this release of OSPFv2.
AOS-W 6.5.3.x
| User Guide OSPFv2 | 161
n n n n n n
In the WLAN scenario, configure the Alcatel-Lucent switch and all upstream routers in totally stub area; in the Branch scenario, configure as stub area so that the Branch switch can receive corporate subnets.
In the WLAN scenario upstream router, only configure the interface connected to the switch in the same area as the switch. This will minimize the number of local subnet addresses advertised by the upstream router to the switch.
Use the upstream router as the designated router (DR) for the link/interface between the switch and the upstream router.
The default MTU value for a Layer 3 GRE tunnel in an Alcatel-Lucent switch is 1100. When running OSPF over a GRE tunnel between an Alcatel-Lucent switch and another vendor’s router, the MTU values must be the same on both sides of the GRE tunnel.
Do not enable OSPF on any uplink/WAN interfaces on the Branch Switch. Enable OSPF only on the Layer 3
GRE tunnel connecting the master switch.
Use only one physical port in the uplink VLAN interface that is connecting to the upstream router. This will prevent broadcasting the protocol PDUs to other ports and hence limit the number of adjacencies on the uplink interface to only one.
Understanding OSPFv2 by Example using a WLAN Scenario
In the WLAN scenario, the Alcatel-Lucent switch acts as a default gateway for all the clients, and talks to one or two upstream routers for redundancy. The switch advertises all the user subnet addresses as stub addresses to the routers via LSAs.
Totally stub areas see only default route and to the areas themselves.
WLAN Topology
The switch (
) is configured with VLAN 10 and VLAN 12 as user VLANs. These VLANs have clients on the subnets, and the switch is the default router for those clients. VLAN 4 and VLAN 5 both have OSPF enabled.
These interfaces are connected to upstream routers (Router 1 and Router 2). The OSPF interface cost on VLAN
4 is configured lower than VLAN 5. The IDs are: n n n
Alcatel-Lucent switch— 40.1.1.1
Router 1— 50.1.1.1
Router 2— 60.1.1.1
Figure 29 WLAN OSPF Topology
162 | OSPFv2 AOS-W 6.5.3.x | User Guide
Based on the cost of the uplink interface, the default route from one of the upstream routers is installed in the forwarding information base (FIB) by the routing information base/route table manager (RIB/RTM) module.
WLAN Routing Table
View the switch routing table using the show ip route command:
(host)#show ip route
Codes: C - connected, O - OSPF, R - RIP, S - static
M - mgmt, U - route usable, * - candidate default
Below is the routing table for Router 1:
(router1) #show ip route
O
O
C
10.1.1.0/24 [1/0] via 4.1.1.1
12.1.1.0/24 [1/0] via 4.1.1.1
4.1.1.0 is directly connected, VLAN4
Below is the routing table for Router 2:
(router2) #show ip route
O
O
C
10.1.1.0/24 [2/0] via 5.1.1.1
12.1.1.0/24 [2/0] via 5.1.1.1
5.1.1.0 is directly connected, VLAN5
Understanding OSPFv2 by Example using a Branch Scenario
The branch office scenario has a number of remote branch offices with switches talking to a central office via a concentrator/switch using site-to-site VPN tunnels or master-local IPsec tunnels. The central office switch is in turn talking to upstream routers (see ). In this scenario, the default route is normally pointed to the uplink router, in many cases the ISP. Configure the area as stub so that inter-area routes are also advertised enabling the branch office switch to reach the corporate subnets.
Branch Topology
All the OSPF control packets exchanged between the Branch and the central office switches undergo GRE encapsulation before entering the IPsec tunnels. The switches in the branch offices advertise all the user subnet addresses to the Central office switch as stub addresses in router LSA. The central office switch in turn forwards those router LSAs to the upstream routers.
AOS-W 6.5.3.x
| User Guide OSPFv2 | 163
Figure 30 Branch OSPF Topology
All the branch office switches, the Central office switch, and the upstream routers are part of a stub area.
Because the OSPF packets follow GRE encapsulation over IPsec tunnels, the Central office switch can be a switch or any vendor’s VPN concentrator. Regardless, the switch in the branch office will operate with other vendors seamlessly.
In , the branch office switch is configured using VLAN 14 and VLAN 15. Layer 3 GRE tunnel is configured with IP address 20.1.1.1/24 and OSPF is enabled on the tunnel interface.
In the Central office switch, OSPF is enabled on VLAN interfaces 4, 5, and the Layer 3 GRE tunnel interface
(configured with IP address 20.1.1.2/24). OSPF interface cost on VLAN 4 is configured lower than VLAN 5.
Branch Routing Table
View the branch office switch routing table using the show ip route command:
(host)#show ip route
Codes: C - connected, O - OSPF, R - RIP, S - static
M - mgmt, U - route usable, * - candidate default
The routing table for the central office switch is below:
(host)#show ip route
Gateway of last resort is 4.1.1.2 to network 0.0.0.0
C
C
O
C
O*
O
0.0.0.0/0 [1/0] via 4.1.1.2*
14.1.1.0/24 [1/0] via 30.1.1.1*
15.1.1.0/24 [1/0] via 30.1.1.1*
4.1.1.0 is directly connected, VLAN4
5.1.1.0 is directly connected, VLAN5
20.1.1.0 is directly connected, Tunnel 1
The routing table for Router 1 is below:
(router1) #show ip route
O
O
C
14.1.1.0/24 [1/0] via 4.1.1.1
15.1.1.0/24 [1/0] via 4.1.1.1
4.1.1.0 is directly connected, VLAN4
The routing table for Router 2 is below:
(router2) #show ip route
164 | OSPFv2 AOS-W 6.5.3.x | User Guide
O
O
C
14.1.1.0/24 [1/0] via 5.1.1.1
15.1.1.0/24 [1/0] via 5.1.1.1
5.1.1.0 is directly connected, VLAN5
Configuring OSPF
To configure general OSPF settings from the OSPF tab, perform the following steps:
1. Navigate to the Configuration >IP page (see
Figure 31 ). The Area and Excluded subnets are displayed in
table format. If not explicitly specified for OSPF, the router ID defaults to the switch IP.
Figure 31 General OSPF Configuration
2. Click Add to add an area (see
).
Figure 32 Add an OSPF Area
3. Configure the OSPF interface settings in the Configuration screen (
). If OSPF is enabled, the parameters contain the correct default values. You can edit the OSPF values only when you enable OSPF on the interface.
AOS-W 6.5.3.x
| User Guide OSPFv2 | 165
Figure 33 Edit OSPF VLAN Settings
OSPF monitoring is available from an IP Routing sub-section ( Switch > IP Routing > Routing ). Both Static and OSPF routes are available in table format.
OSPF Interfaces and Neighboring information is available from the OSPF tab. The Interface information includes transmit (TX) and receive (RX) statistics.
Exporting VPN Client Addresses to OSPF
You can configure VPN client addresses so that they can be exported to OSPF and be advertised as host routes
(/32). Exporting applies to any VPN client address regardless of how it is assigned.
In the WebUI
1. Navigate to the Configuration > Advanced Services > All Profiles > VPN Authentication > default page.
2. (Optional) Regardless of how an authentication server is contacted, the Export VPN IP address as a route option causes any VPN client address to be exported to OSPF using IPC. Note that the Framed-IP-
Address attribute is assigned the IP address as long as any server returns the attribute. The Framed-IP-
Address value always has a higher priority than the local address pool.
3. Click Apply .
In the CLI
(host) (config) #aaa authentication vpn default
(host) (VPN Authentication Profile "default") #
(host) (VPN Authentication Profile "default") # export-route
Use the show ip ospf database command to show LSA types that are generated.
Sample Topology and Configuration
The figure below displays a sample OSPF topology followed by sample configurations of the Remote Branch 1,
Remote Branch 2, and the Central Office Switch (Active and Backup).
166 | OSPFv2 AOS-W 6.5.3.x | User Guide
Figure 34
Figure 35 Sample OSPF Topology
Remote Branch 1
switch-ip vlan 30 vlan 16 vlan 30 vlan 31 vlan 32 interface gigabitethernet 1/0 description "GE1/0" trusted switchport access vlan 16
!
interface gigabitethernet 1/1 description "GE1/1" trusted switchport access vlan 30
!
interface gigabitethernet 1/2 description "GE1/2" trusted switchport access vlan 31
!
interface gigabitethernet 1/3 description "GE1/3" trusted switchport access vlan 32
!
interface vlan 16 ip address 192.168.16.251 255.255.255.0
AOS-W 6.5.3.x
| User Guide OSPFv2 | 167
!
interface vlan 30 ip address 192.168.30.1 255.255.255.0
!
interface vlan 31 ip address 192.168.31.1 255.255.255.0
!
interface vlan 32 ip address 192.168.32.1 255.255.255.0
!
uplink wired priority 202 uplink cellular priority 201 uplink wired vlan 16 interface tunnel 2003 description "Tunnel Interface" ip address 2.0.0.3 255.0.0.0
tunnel source 192.168.30.1
tunnel destination 192.168.68.217
trusted ip ospf area 10.10.10.10
!
ip default-gateway 192.168.16.254
ip route 192.168.0.0 255.255.0.0 null 0
!
router ospf router ospf router-id 192.168.30.1
router ospf area 10.10.10.10 stub router ospf redistribute vlan 30-32
Remote Branch 2
switch-ip vlan 50
!
vlan 20 vlan 50 vlan 51 vlan 52
!
interface gigabitethernet 1/0 description "GE1/0" trusted switchport access vlan 20
!
interface gigabitethernet 1/1 description "GE1/1" trusted switchport access vlan 50
!
interface gigabitethernet 1/2 description "GE1/2" trusted switchport access vlan 51
!
interface gigabitethernet 1/3 description "GE1/3" trusted switchport access vlan 52
!
interface vlan 20 ip address 192.168.20.1 255.255.255.0
!
interface vlan 50
168 | OSPFv2 AOS-W 6.5.3.x | User Guide
ip address 192.168.50.1 255.255.255.0
!
interface vlan 51 ip address 192.168.51.1 255.255.255.0
!
interface vlan 52 ip address 192.168.52.1 255.255.255.0
!
uplink wired priority 206 uplink cellular priority 205 uplink wired vlan 20 interface tunnel 2005 description "Tunnel Interface" ip address 2.0.0.5 255.0.0.0
tunnel source 192.168.50.1
tunnel destination 192.168.68.217
trusted ip ospf area 10.10.10.10
!
ip default-gateway 192.168.20.254
ip route 192.168.0.0 255.255.0.0 null 0
!
router ospf router ospf router-id 192.168.50.1
router ospf area 10.10.10.10 stub router ospf redistribute vlan 50-52
Central Office Switch—Active
localip 0.0.0.0 ipsec db947e8d1b383813a4070ab0799fa6246b80fc5cfcc3268f switch-ip vlan 225 vlan 68 vlan 100 vlan 225
!
interface gigabitethernet 1/0 description "GE1/0" trusted switchport access vlan 225
!
interface gigabitethernet 1/1 description "GE1/1" trusted switchport access vlan 100
!
interface gigabitethernet 1/2 description "GE1/2" trusted switchport access vlan 68
!
interface vlan 68 ip address 192.168.68.220 255.255.255.0
!
interface vlan 100 ip address 192.168.100.1 255.255.255.0
!
interface vlan 225 ip address 192.168.225.2 255.255.255.0
!
interface tunnel 2003 description "Tunnel Interface" ip address 2.1.0.3 255.0.0.0
AOS-W 6.5.3.x
| User Guide OSPFv2 | 169
tunnel source 192.168.225.2
tunnel destination 192.168.30.1
trusted ip ospf area 10.10.10.10
!
interface tunnel 2005 description "Tunnel Interface" ip address 2.1.0.5 255.0.0.0
tunnel source 192.168.225.2
tunnel destination 192.168.50.1
trusted ip ospf area 10.10.10.10
!
master-redundancy master-vrrp 2 peer-ip-address 192.168.68.221 ipsec password123
!
vrrp 1 priority 120 authentication password123 ip address 192.168.68.217
vlan 68 preempt tracking vlan 68 sub 40 tracking vlan 100 sub 40 tracking vlan 225 sub 40 no shutdown
!
vrrp 2 priority 120 ip address 192.168.225.9
vlan 225 preempt tracking vlan 68 sub 40 tracking vlan 100 sub 40 tracking vlan 225 sub 40 no shutdown
!
ip default-gateway 192.168.68.1
ip route 192.168.0.0 255.255.0.0 null 0 router ospf router ospf router-id 192.168.225.1
router ospf area 10.10.10.10 stub router ospf redistribute vlan 100,225
!
Central Office Switch—Backup
localip 0.0.0.0 ipsec db947e8d1b383813a4070ab0799fa6246b80fc5cfcc3268f switch-ip vlan 225
!
interface gigabitethernet 1/0 description "GE1/0" trusted switchport access vlan 225
!
interface gigabitethernet 1/1 description "GE1/1" trusted switchport access vlan 100
!
170 | OSPFv2 AOS-W 6.5.3.x | User Guide
interface gigabitethernet 1/2 description "GE1/2" trusted switchport access vlan 68
!
interface vlan 68 ip address 192.168.68.221 255.255.255.224
!
interface vlan 100 ip address 192.168.100.5 255.255.255.0
!
interface vlan 225 ip address 192.168.225.1 255.255.255.0
!
interface tunnel 2003 description "Tunnel Interface" ip address 2.1.0.3 255.0.0.0
tunnel source 192.168.225.1
tunnel destination 192.168.30.1
trusted ip ospf area 10.10.10.10
!
interface tunnel 2005 description "Tunnel Interface" ip address 2.1.0.5 255.0.0.0
tunnel source 192.168.225.1
tunnel destination 192.168.50.1
trusted ip ospf area 10.10.10.10
!
master-redundancy master-vrrp 2 peer-ip-address 192.168.68.220 ipsec password123
!
vrrp 1 priority 99 authentication password123 ip address 192.168.68.217
vlan 68 tracking vlan 68 sub 40 tracking vlan 100 sub 40 tracking vlan 225 sub 40 no shutdown
!
vrrp 2 priority 99 ip address 192.168.225.9
vlan 225 tracking vlan 68 sub 40 tracking vlan 100 sub 40 tracking vlan 225 sub 40 no shutdown
!
ip default-gateway 192.168.68.1
ip route 192.168.0.0 255.255.0.0 null 0
!
router ospf router ospf router-id 192.168.225.1
router ospf area 10.10.10.10 stub router ospf redistribute vlan 100,225
!
AOS-W 6.5.3.x
| User Guide OSPFv2 | 171
The following figure displays how the switch is configured for Instant AP VPN for different OSPF cases.
Figure 36
Topology
n n n n n n
Area-10 is NSSA (Not-So-Stubby Area)
Area-11 is Normal area.
RAPNG AP-1 is configured to have a UP switch as its primary switch and a DOWN as secondary switch.
RAPNG AP-2 is configured to have a DOWN as its primary switch and a UP as secondary switch.
RAPNG AP-1 is configured to have a 201.201.203.0/24 L3-distributed network.
RAPNG AP-2 is configured to have a 202.202.202.0/24 L3-distributed network.
Observation
n n n
UP Switch will send Type-5 LSA (External LSA) of VPN route 201.201.203.0/24 to it’s upstream router, Cisco-
3750.
DOWN Switch will send Type-7 LSA (NSSA) of VPN route 202.202.202.0/24 to it’s upstream router, Cisco-
2950.
UP Switch will send a Type-4 asbr-summary LSA.
Configuring UP Switch
interface vlan 21 ip address 21.21.21.2 255.255.255.0
ip ospf area 0.0.0.11
!
router ospf router ospf area 0.0.0.11
router ospf redistribute rapng-vpn
!
172 | OSPFv2 AOS-W 6.5.3.x | User Guide
The following commands displays the configuration and run time protocol details on UP Switch:
(host)#show ip route
O
C
S
V
S
S
S
S
C
C
C
C
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
S
O
S
O
O
O
O
Codes: C - connected, O - OSPF, R - RIP, S - static
M - mgmt, U - route usable, * - candidate default, V - RAPNG VPN
Gateway of last resort is Imported from DHCP to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from CELL to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from PPPOE to network 0.0.0.0 at cost 10
Gateway of last resort is 10.15.231.185 to network 0.0.0.0 at cost 1
S* 0.0.0.0/0 [1/0] via 10.15.231.185*
10.15.228.0/27 [333/0] via 21.21.21.1*
12.12.12.0/25 [0/0] via 21.21.21.1*
22.22.22.0/24 [3/0] via 21.21.21.1*
23.23.23.0/24 [2/0] via 21.21.21.1*
25.25.25.0/24 [333/0] via 21.21.21.1*
192.100.3.0/24 [1/0] via 192.100.2.1*
192.100.4.0/24 [1/0] via 192.100.2.1*
192.100.5.0/24 [1/0] via 192.100.2.1*
192.100.6.0/24 [1/0] via 192.100.2.1*
192.100.7.0/24 [1/0] via 192.100.2.1*
192.100.8.0/24 [1/0] via 192.100.2.1*
192.100.9.0/24 [1/0] via 192.100.2.1*
192.100.10.0/24 [1/0] via 192.100.2.1*
192.100.11.0/24 [1/0] via 192.100.2.1*
192.100.12.0/24 [1/0] via 192.100.2.1*
192.100.13.0/24 [1/0] via 192.100.2.1*
192.100.14.0/24 [1/0] via 192.100.2.1*
192.168.1.0/24 [1/0] via 192.100.2.1*
192.169.1.0/24 [1/0] via 192.100.2.1*
192.170.1.0/24 [1/0] via 192.100.2.1*
192.171.1.0/24 [1/0] via 192.100.2.1*
192.172.1.0/24 [1/0] via 192.100.2.1*
192.173.1.0/24 [1/0] via 192.100.2.1*
192.174.1.0/24 [1/0] via 192.100.2.1*
192.175.1.0/24 [1/0] via 192.100.2.1*
192.176.1.0/24 [1/0] via 192.100.2.1*
192.177.1.0/24 [1/0] via 192.100.2.1*
192.178.1.0/24 [1/0] via 192.100.2.1*
192.179.1.0/24 [1/0] via 192.100.2.1*
201.201.203.0/26 [10/0] ipsec map
202.202.202.0/29 [0/0] via 21.21.21.1*
192.100.2.0/24 is directly connected, VLAN2
10.15.231.184/29 is directly connected, VLAN1
172.16.0.0/24 is directly connected, VLAN3
21.21.21.0/24 is directly connected, VLAN21
5.5.0.2/32 is an ipsec map 10.15.149.30-5.5.0.2
(host) #show ip ospf database
OSPF Database Table
-------------------
Area ID
-------
LSA Type
--------
Link ID
-------
0.0.0.11
ROUTER
0.0.0.11
ROUTER
21.21.21.1
192.100.2.3
0.0.0.11
NETWORK 21.21.21.1
0.0.0.11
IPNET_SUMMARY 22.22.22.0
0.0.0.11
IPNET_SUMMARY 23.23.23.0
0.0.0.11
ASBR_SUMMARY 25.25.25.1
0.0.0.11
ASBR_SUMMARY
N/A AS_EXTERNAL
192.100.2.3
10.15.228.0
N/A
N/A
AS_EXTERNAL
AS_EXTERNAL
12.12.12.0
25.25.25.0
Adv Router
----------
21.21.21.1
192.100.2.3
21.21.21.1
21.21.21.1
21.21.21.1
21.21.21.1
192.100.2.3
25.25.25.1
25.25.25.1
25.25.25.1
Age
---
Seq#
----
Checksum
--------
178 0x80000017 0xca50
1406 0x80000007 0x2253
178
178
0x80000003 0xdf6d
0x80000003 0x7e38
178
178
0x80000003 0x5064
0x80000003 0xefbc
1412 0x80000002 0xa85d
1014 0x8000000e 0xea43
268 0x80000003 0x433a
1761 0x80000005 0x3d8d
AOS-W 6.5.3.x
| User Guide OSPFv2 | 173
N/A
N/A
N/A
AS_EXTERNAL
AS_EXTERNAL
AS_EXTERNAL
201.201.203.0
10.15.231.186
3600 0x80000001 0x6690
201.201.203.0
192.100.2.3
1104 0x80000002 0xe4a2
202.202.202.0
25.25.25.1
268 0x80000003 0x4385
(host) #show ip ospf neighbor
OSPF Neighbor Table
-------------------
Neighbor ID Pri State
-----------------
21.21.21.1
1
Address
-------
Interface
---------
FULL/DR 21.21.21.1
Vlan
Configuring DOWN Switch
interface vlan 22 ip address 22.22.22.2 255.255.255.0
ip ospf area 0.0.0.10
!
router ospf router ospf area 0.0.0.10 nssa router ospf redistribute rapng-vpn
!
The following commands displays the configuration and run time protocol details on DOWN Switch:
(host)#show ip route
C
C
V
C
C
C
V
O
O
O
Codes: C - connected, O - OSPF, R - RIP, S - static
M - mgmt, U - route usable, * - candidate default, V - RAPNG VPN
Gateway of last resort is Imported from DHCP to network 0.0.0.0 at cost 10
Gateway of last resort is Imported from CELL to network 0.0.0.0 at cost 10
S
O
Gateway of last resort is Imported from PPPOE to network 0.0.0.0 at cost 10
O 0.0.0.0/0 [1/0] via 22.22.22.1*
10.0.0.0/8 [1/0] via 10.15.231.177*
10.15.228.0/27 [333/0] via 22.22.22.1*
12.12.12.0/25 [10/0] ipsec map
21.21.21.0/24 [3/0] via 22.22.22.1*
23.23.23.0/24 [2/0] via 22.22.22.1*
25.25.25.0/24 [333/0] via 22.22.22.1*
202.202.202.0/29 [10/0] ipsec map
192.100.2.0/24 is directly connected, VLAN2
10.15.231.176/29 is directly connected, VLAN1
22.22.22.0/24 is directly connected, VLAN22
4.4.0.2/32 is an ipsec map 10.15.149.35-4.4.0.2
4.4.0.1/32 is an ipsec map 10.17.87.126-4.4.0.1
(host) #show ip ospf neighbor
OSPF Neighbor Table
-------------------
Neighbor ID Pri State
-----------------
25.25.25.1
1
Address
-------
Interface
---------
FULL/BDR 22.22.22.1
Vlan 22
(host) #show ip ospf database
OSPF Database Table
-------------------
Area ID
-------
LSA Type
--------
0.0.0.10
ROUTER
Link ID
-------
25.25.25.1
0.0.0.10
ROUTER
0.0.0.10
NETWORK
192.100.2.2
22.22.22.2
0.0.0.10
IPNET_SUMMARY 21.21.21.0
0.0.0.10
IPNET_SUMMARY 23.23.23.0
0.0.0.10
NSSA
0.0.0.10
NSSA
0.0.0.0
10.15.228.0
Adv Router
----------
25.25.25.1
Age Seq# Checksum
-------------
1736 0x80000021 0xb732
192.100.2.2
500
192.100.2.2
500
25.25.25.1
25.25.25.1
1990
1990
0x80000005
0x80000004
0x80000003
0x80000003
0x9ad9
0x8aeb
0xe7bf
0x950d
25.25.25.1
25.25.25.1
725 0x80000002 0xaab9
1228 0x80000010 0xca5f
174 | OSPFv2 AOS-W 6.5.3.x | User Guide
0.0.0.10
NSSA
0.0.0.10
NSSA
0.0.0.10
NSSA
N/A AS_EXTERNAL
N/A AS_EXTERNAL
12.12.12.0
25.25.25.0
192.100.2.2
352
25.25.25.1
1485
0x80000005
0x80000006
0xe8cb
0x1fa8
202.202.202.0
192.100.2.2
352
12.12.12.0
192.100.2.2
352
202.202.202.0
192.100.2.2
352
0x80000005
0x80000005
0x80000005
0xe817
0x28d8
0x2824
Viewing the Status of Instant AP VPN
RAPNG AP-1
(host)# show vpn status profile name:default
-------------------------------------------------current using tunnel :primary tunnel ipsec is preempt status ipsec is fast failover status ipsec hold on period
:disable
:disable
:600 ipsec tunnel monitor frequency (seconds/packet) :5 ipsec tunnel monitor timeout by lost packet cnt :2 ipsec ipsec primary tunnel crypto type primary tunnel peer address
:Cert
:10.15.231.186
ipsec ipsec ipsec ipsec primary tunnel peer tunnel ip primary tunnel ap tunnel ip primary tunnel current sm status primary tunnel tunnel status
:192.100.2.3
:5.5.0.2
:Up
:Up ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec primary tunnel tunnel retry times primary tunnel tunnel uptime backup tunnel crypto type backup tunnel peer address backup tunnel peer tunnel ip backup tunnel ap tunnel ip backup tunnel current sm status backup tunnel tunnel status
:2
:1 hour 24 minutes 50 seconds
:Cert
:10.15.231.178
:0.0.0.0
:0.0.0.0
:Init
:Down
:0
:0 ipsec ipsec backup tunnel tunnel retry times backup tunnel tunnel uptime
(host)# show datapath route
Route Table Entries
-------------------
Flags: L - Local, P - Permanent, T - Tunnel, I - IPsec, M - Mobile, A - ARP, D - Drop
IP Mask Gateway Cost VLAN Flags
-----------------------------------------------------
0.0.0.0
0.0.0.0
128.0.0.0
192.168.10.0
0.0.0.0
128.0.0.0
128.0.0.0
255.255.254.0
10.15.149.25
192.100.2.3
192.100.2.3
192.168.10.1
201.201.203.0
10.15.149.24
255.255.255.192
255.255.255.248
0.0.0.0
10.15.149.30
10.15.231.186
255.255.255.255
10.15.149.25
IPv6 Route Table Entries
0
0
0
0
0
0
0
0
0
0
3333
103
1
0
T
T
D
LP
L
------------------------
Flags: L - Local, P - Permanent, T - Tunnel, I - IPsec, M - Mobile, A - ARP, D - Drop
Prefix Gateway Cost VLAN Flags
----------------------------- --------------------- ---- ---- ------
2100::/64
::1/128
(host)# show clients
Client List
-----------
2100::5
::
0
0
1 L
0 D
Name IP Address
Signal
MAC Address
Speed (mbps)
-------------
------
-----------
------------
OS Network Access Point
-------------------
Channel Type Role
-------------
AOS-W 6.5.3.x
| User Guide OSPFv2 | 175
201.201.203.8
00:26:c6:52:6b:14
(good) 6(poor)
Info timestamp :80259
149.30
00:24:6c:c9:27:a3 48AN 149.30
43
RAPNG AP-3
(host)# show vpn status ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec ipsec profile name:default
-------------------------------------------------current using tunnel :primary tunnel ipsec is preempt status ipsec is fast failover status
:disable
:disable ipsec hold on period :600 ipsec tunnel monitor frequency (seconds/packet) :5 ipsec tunnel monitor timeout by lost packet cnt :2 ipsec primary tunnel crypto type :Cert ipsec ipsec primary tunnel peer address primary tunnel peer tunnel ip
:10.15.231.178
:192.100.2.2
ipsec ipsec ipsec ipsec primary tunnel ap tunnel ip primary tunnel current sm status primary tunnel tunnel status primary tunnel tunnel retry times
:4.4.0.2
:Up
:Up
:13 primary tunnel tunnel uptime backup tunnel crypto type backup tunnel peer address backup tunnel peer tunnel ip backup tunnel ap tunnel ip backup tunnel current sm status backup tunnel tunnel status backup tunnel tunnel retry times backup tunnel tunnel uptime
:1 hour 55 minutes 6 seconds
:Cert
:10.15.231.186
:0.0.0.0
:0.0.0.0
:Init
:Down
:0
:0
( host)# show datapath route
Route Table Entries
-------------------
Flags: L - Local, P - Permanent, T - Tunnel, I - IPsec, M - Mobile, A - ARP, D - Drop
IP Mask Gateway Cost VLAN Flags
-----------------------------------------------------
0.0.0.0
0.0.0.0
0.0.0.0
128.0.0.0
10.15.149.33
192.100.2.2
0
0
0
0 T
128.0.0.0
192.168.10.0
10.15.149.32
202.202.202.0
128.0.0.0
255.255.254.0
192.100.2.2
192.168.10.1
255.255.255.248
10.15.149.35
255.255.255.248
0.0.0.0
0
0
0
3333
T
D
0 1 L
0 203 LP
0 0 10.15.231.178
255.255.255.255
10.15.149.33
IPv6 Route Table Entries
------------------------
Flags: L - Local, P - Permanent, T - Tunnel, I - IPsec, M - Mobile, A - ARP, D - Drop
Prefix Gateway Cost VLAN Flags
----------------------------- --------------------- ---- ---- ------
2100::/64
::1/128
2100::5
::
0
0
1 L
0 D
( host)# show clients
Client List
-----------
Name IP Address
Signal
MAC Address
Speed (mbps)
-------------
------
-----------
------------
OS
--
Network
-------
Access Point
------------
Channel
-------
Type
----
Role
----
176 | OSPFv2 AOS-W 6.5.3.x | User Guide
202.202.202.6
08:ed:b9:e1:51:7b
(good) 48(poor)
Info timestamp :80748
149.35
00:24:6c:c0:41:f2 48AN 149.35
53
AOS-W 6.5.3.x
| User Guide OSPFv2 | 177
Chapter 8
Authentication Servers
The AOS-W software allows you to use an external authentication server or the switch internal user database to authenticate clients who need to access the wireless network.
This chapter describes the following topics: n n n n n n n n
Understanding Authentication Server Best Practices and Exceptions on page 178
Understanding Servers and Server Groups on page 178
Configuring Authentication Servers on page 179
Managing the Internal Database on page 196
Configuring Server Groups on page 199
Assigning Server Groups on page 205
Configuring Authentication Timers on page 210
Authentication Server Load Balancing on page 211
n n
Understanding Authentication Server Best Practices and
Exceptions
For an external authentication server to process requests from the Alcatel-Lucent switch, you must configure the server to recognize the switch. Refer to the vendor documentation for information on configuring the authentication server.
To configure Microsoft’s IAS and Active Directory see the following links: l l http://technet2.microsoft.com/windowsserver/en/technologies/ias.mspx
http://www.microsoft.com/en-us/server-cloud/windows-server/active-directory.aspx
n n n n
Understanding Servers and Server Groups
AOS-W supports the following external authentication servers:
RADIUS (Remote Authentication Dial-In User Service)
LDAP (Lightweight Directory Access Protocol)
TACACS+ (Terminal Access Switch Access Control System)
Windows (For stateful NTLM authentication)
Starting with AOS-W 6.4, a maximum of 128 LDAP, RADIUS, and TACACS servers, each can be configured on the switch.
Additionally, you can use the switch’s internal database to authenticate users. You create entries in the database for users, their passwords, and their default role.
You can create groups of servers for specific types of authentication. For example, you can specify one or more
RADIUS servers to be used for 802.1X authentication. The list of servers in a server group is an ordered list.
This means that the first server in the list is always used unless it is unavailable, in which case the next server in the list is used. You can configure servers of different types in one group. For example, you can include the internal database as a backup to a RADIUS server.
AOS-W 6.5.3.x
| User Guide Authentication Servers | 178
represents a server group named “Radii” that consists of two RADIUS servers, Radius-1 and Radius-2.
The server group is assigned to the server group for 802.1X authentication.
Figure 37 Server Group
Server names are unique. You can configure the same server in multiple server groups. You must configure the server before you can add it to a server group.
If you use the switch’s internal database for user authentication, use the predefined “Internal” server group.
You can also include conditions for server-derived user roles or VLANs in the server group configuration. The server derivation rules apply to all servers in the group.
Configuring Authentication Servers
This section describes how to configure RADIUS, LDAP, TACACS+ and Windows external authentication servers and the internal database on the switch.
This section includes the following information: n n n n n n n n
Configuring a RADIUS Server on page 179
RADIUS Service-Type Attribute on page 181
Enabling Radsec on RADIUS Servers on page 182
Configuring Username and Password for CPPM Authentication on page 192 on page 192
Configuring an LDAP Server on page 192
Configuring a TACACS+ Server on page 193
Configuring a Windows Server on page 196
Configuring a RADIUS Server
Follow the procedures below to configure a RADIUS server using the WebUI or CLI.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Radius Server to display the Radius Server List.
3. To configure a RADIUS server, enter the name for the server and click Add.
179 | Authentication Servers AOS-W 6.5.3.x | User Guide
4. Select the name to configure server parameters. Enter the parameters as described in
Mode check box to activate the authentication server.
5. Click Apply .
The configuration does not take effect until you perform this step.
Using the CLI
(host)(config) #aaa authentication-server radius <name> host <ipaddr> key <key> enable
Table 41: RADIUS Server Configuration Parameters
Parameter
Host
Description
IP address or fully qualified domain name (FQDN) of the authentication server.
The maximum supported FQDN length is 63 characters.
Default: N/A
Key
Auth Port
Acct Port
Radsec Port
CPPM credentials
Retransmits
Timeout
NAS ID
NAS IP
Enable IPv6
NAS IPv6
Shared secret between the switch and the authentication server. The maximum length is 128 characters.
Default: N/A
Authentication port of this server.
Default: 1812
Accounting port of this server.
Default: 1813
Radsec port number of this server.
Range: 1-65535
Default: 2083
Allows the switch to use configurable username and password instead of a support password.
Maximum number of retries sent to the server by the switch before the server is marked as down.
Default: 3
Maximum time, in seconds, that the switch waits before timing out the request and resending it.
Default: 5 seconds
Network Access Server (NAS) identifier to use in RADIUS packets.
The NAS IP address to be sent in RADIUS packets from that server.
NOTE: If you define a local NAS IP using the Configuration > Security >
Authentication > Servers page and also define a global NAS IP using the
Configuration > Security > Authentication > Advanced page, the global
NAS IP address takes precedence.
Enable or disable IPv6 for this server.
Default: Disabled
The NAS IPv6 address to be sent in RADIUS packets.
AOS-W 6.5.3.x
| User Guide Authentication Servers | 180
Table 41: RADIUS Server Configuration Parameters
Parameter
Source Interface
Description
Enter a VLAN number ID.
Allows you to use source IP addresses to differentiate RADIUS requests.
Associates a VLAN interface with the RADIUS server to allow the serverspecific source interface to override the global configuration.
n n
If you associate a Source Interface (by entering a VLAN number) with a configured server, then the source IP address of the packet is that interface’s IP address.
If you do not associate the Source Interface with a configured server (leave the field blank), the IP address of the global Source Interface is used.
Use MD5
Mode
Lowercase MAC addresses
MAC address delimiter
Use MD5 hash of cleartext password.
Default: Disabled
Enables or disables the server.
Default: Enabled
Send MAC address with lowercase in the authentication and accounting requests to this server.
Default: Disabled
Send MAC address with the following delimiters in the authentication and accounting requests of this server: n colon : Send MAC address as XX:XX:XX:XX:XX:XX n n dash : Send MAC address as XX-XX-XX-XX-XX-XX none : Send MAC address as XXXXXXXXXXXX n oui-nic : Send MAC address as XXXXXX-XXXXXX
Default: none
Service-type of FRAMED-
USER
Radsec
Send the service-type as FRAMED-USER instead of LOGIN-USER. For more information, see
RADIUS Service-Type Attribute on page 181
.
Default: Disabled
Enable or disable RADIUS over TLS for this server.
Default: Disabled
Radsec Trusted CA Name Enter the trusted CA name to be used to verify this server.
Radsec Server Cert Name Enter the name of the trusted Radsec server certificate.
Radsec Client Cert called-station-id
Enter the name of the Radsec client certificate that the switch should use for
Radsec requests.
Allows user to send different values for Called Station ID. Configure the following parameters for Called Station ID: n csid_type : Called station ID type.
Default: macaddr n n include_ssid : Enabling this option includes SSID in the Called Station ID along with csid_type .
Default: disabled csid_delimiter : Enabling this option allows to send this delimiter to separate csid_type and ssid in the Called Station ID.
Default: colon
(example: 00-1a-1e-00-1a-b8:dotx-ssid)
RADIUS Service-Type Attribute
The switch sends the following Service-Type attribute values for RADIUS authentication requests.
181 | Authentication Servers AOS-W 6.5.3.x | User Guide
Table 42: RADIUS Service-Type Attributes
RADIUS Attribute
Service-Type
Authentication Type
MAC
802.1X
Captive Portal
Attribute Value
Call-Check
Framed
Login
The service-type-framed-user configuration of the RADIUS server overwrites all the attribute values to Framed irrespective of the authentication type. Existing deployments that depend upon this attribute for their thirdparty RADIUS integrations should make changes to support these new service types.
Enabling Radsec on RADIUS Servers
Conventional RADIUS protocol offers limited security. This level of limited security is not sufficient for authentication that takes place across unsecured networks such as the Internet. To address this, the
RADIUS over TLS or Radsec enhancement is introduced to ensure RADIUS authentication and accounting data is transmitted safely and reliably across insecure networks. The default destination port for RADIUS over TLS is
TCP/2083. Separate ports are not used for authentication, accounting, and dynamic authorization changes.
In a TLS connection, both the switch (TLS client) and the Radsec server (TLS server) need to authenticate each other using certificates. For the switch to authenticate the Radsec server: n n
Certificate Authority (CA) certificate should be uploaded as a Trusted CA , if the Radsec server uses a certificate signed by a CA.
Self-signed certificate should be uploaded as a PublicCert if the Radsec server uses a self-signed certificate.
If neither of these certificates are configured, the switch will not try to establish any connection with the Radsec server, even if Radsec is enabled.
The switch also needs to send a TLS client certificate to the Radsec server by uploading a certificate on the switch as ServerCert and configuring Radsec to accept and use the switch's certificate. If a certificate is not configured, the switch will use the device certificate in its Trusted Platform Module (TPM). In this case, the
Alcatel-Lucent device CA that signed the switch's certificate, should be configured as a Trusted CA on the
Radsec server.
When Radsec support is enabled, the default RADIUS shared key is radsec and remains the same even if the user configures a different shared key.
In the Web UI
1. From Configuration tab, navigate to Security > Authentication > Servers page.
2. Click RADIUS Server .
3. Click the Radsec server from the list displayed.
4. Enter the Radsec-related parameters as described in
.
5. Click Apply .
In the CLI aaa authentication-server radius <rad_server_name> enable-radsec radsec-client-cert-name <name> radsec-port <radsec-port> radsec-trusted-cacert-name <radsec-trusted-ca>
AOS-W 6.5.3.x
| User Guide Authentication Servers | 182
radsec-trusted-servercert-name <name>
To upload certificates through the CLI, see
.
To configure a Radsec server as RFC 3576 server for dynamic authorization (CoA), see
RADIUS Server VSAs
Vendor-Specific Attributes (VSAs) are a method for communicating vendor-specific information between
Network Access Servers and RADIUS servers, allowing vendors to support their own extended attributes.
You can use Alcatel-Lucent VSAs to derive the user role and VLAN for RADIUS-authenticated clients on the wired or Wi-Fi network, or define RTTS VSAs for a Cellular WLAN switch (CWC). The VSAs must be present on your RADIUS server, which requires that you update the RADIUS dictionary file with the vendor name and/or the vendor-specific code , the vendor-assigned attribute number, and the attribute format (such as string or integer) for each VSA. For more information on VSA-derived user roles, see
Configuring a VSA-Derived Role on page 391
describes Alcatel-Lucent-specific RADIUS VSAs, and
describes RTTS VSAs supported in AOS-W.
For the current and complete list of all VSAs available in the version of AOS-W currently running on your switch, access the command-line interface and issue the command show aaa radius attributes .
Table 43: Alcatel-Lucent RADIUS VSAs
VSA Type Value Description
Vendor
Name
Vendor
ID
Aruba-User-
Role
Aruba-User-
Vlan
Aruba-Priv-
Admin-User
Aruba-
Admin-Role
String
String
1
Integer 2
Integer 2
4
5
This VSA returns the role to be assigned to the user post authentication. The user will be granted access based on the role attributes defined in the role.
This VSA returns the VLAN to be used by the client.
Range: 1–4094.
If this VSA is set in the RADIUS accept message, the user can bypass the enable prompt.
This VSA returns the management role to be assigned to the user post management authentication. This role can be seen using the command show mgmt-role in the command-line interface.
String that identifies the name of the ESSID.
Aruba
Aruba
Aruba
Aruba
Aruba
14823
14823
14823
14823
14823
Aruba-Essid-
Name
Aruba-
Location-Id
String
String
Aruba-Port-
Id
Aruba-
Template-
User
String
String
6
7
8
String that identifies the name of the AP location.
String that identifies the Port ID.
String that identifies the name of anAlcatel-Lucent user template.
Aruba
Aruba
Aruba
14823
14823
14823
183 | Authentication Servers AOS-W 6.5.3.x | User Guide
VSA Type
Aruba-
Named-
User-Vlan
Aruba-AP-
Group
Aruba-
Framed-
IPv6-
Address
Aruba-
Device-Type
Aruba-No-
DHCP-
Fingerprint
Aruba-
Mdps-
Device-Udid
String
String
String
String
String
12
Integer 14
15
Value
9
10
11
Description
Vendor
Name
This VSA returns a VLAN name for a user. This
VLAN name on a switch could be mapped to userdefined name or multiple VLAN IDs.
Aruba
String that identifies the name of anAlcatel-Lucent AP
Group.
Aruba
This attribute is used for RADIUS accounting for IPv6 users.
Aruba
String that identifies anAlcatel-Lucent device on the network.
Aruba
This VSA prevents the switch from deriving a role and
VLAN based on DHCP finger printing.
Aruba
Aruba-
Mdps-
Device-Imei
Aruba-
Mdps-
Device-Iccid
Aruba-
Mdps-Max-
Devices
Aruba-
Mdps-
Device-
Name
String
String
String
String
16
17
18
19
UDID is unique device identifier which is used as input attribute by the Onboard application while performing the device authorization to the internal
RADIUS server within the ClearPass Policy Manager
(CPPM). The UDID checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
The Onboard application uses IMEI as an input attribute while performing the device authorization to the internal RADIUS server within the CPPM. IMEI checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
The Onboard application uses ICCID as an input attribute while performing the device authorization to the internal RADIUS server within the CPPM. ICCID checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
Used by Onboard as a way to define and enforce the maximum number of devices that can be provisioned by a given user.
Aruba
Aruba
Aruba
Aruba
The Onboard application uses device name as an input attribute while performing the device authorization to the internal RADIUS server within the CPPM. Device name checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
Aruba
Vendor
ID
14823
14823
14823
14823
14823
14823
14823
14823
14823
14823
AOS-W 6.5.3.x
| User Guide Authentication Servers | 184
VSA
Aruba-
Mdps-
Device-
Product
Aruba-
Mdps-
Device-
Version
Aruba-
Mdps-
Device-
Serial
Type
String
String
String
Aruba-
AirGroup-
User-Name
Aruba-
AirGroup-
Shared-User
String
String
Aruba-
AirGroup-
Shared-Role
Aruba-
AirGroup-
Device-Type
Aruba-Auth-
Survivability
String
Integer
String
24
25
26
27
28
Value
20
Description
Vendor
Name
The device product is used as input attribute by the
Onboard application while performing the device authorization to the internal RADIUS server within the CPPM. Device Product checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
Aruba
21
22
The device version is used as input attribute by the
Onboard application while performing the device authorization to the internal RADIUS server within the CPPM. Device Version checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
Aruba
The device serial number is used as input attribute by the Onboard application while performing the device authorization to the internal RADIUS server within the CPPM. Device Serial checks against role mappings or enforcement policies to determine if the device is authorized to be onboarded.
Aruba
A device owner or username associated with the device.
Aruba
This VSA contains a comma separated list of user names with whom the device is shared.
This VSA contains a comma separated list of user roles with whom the device is shared.
Aruba
Aruba
Aruba-AS-
User-Name
Aruba-AS-
Credential-
Hash
String
String
29
30
A value of 1 for this VSA indicates that the device authenticating on the network is a personal device and a value of 2 indicates that it is a shared device.
The Instant AP Auth survivability feature uses the
VSA to indicate that the CPPM server sends the
Aruba-AS-User-Name and Aruba-AS-Credential-
Hash values. This attribute is just used as a flag with no specific value required.
Aruba
Aruba
The Auth survivability feature uses the VSA for
Instant APs. The CPPM sends the actual user name to the Instant AP which can be used by the Instant AP to authenticate the user if the CPPM server is not reachable.
Aruba
The Auth survivability feature uses the VSA for
Instant APs. The CPPM sends the NT hash of the password to the Instant AP which can be used by the
Instant AP to authenticate the user if the CPPM server is not reachable.
Aruba
Vendor
ID
14823
14823
14823
14823
14823
14823
14823
14823
14823
14823
185 | Authentication Servers AOS-W 6.5.3.x | User Guide
VSA Type
Aruba-
WorkSpace-
App-Name
String
Aruba-
Mdps-
Provisioning-
Settings
String
Aruba-
Mdps-
Device-
Profile
Value Description
31
This VSA identifies an application supported by
Alcatel-Lucent WorkSpace.
32
String 33
Used as part of the ClearPass Onboard technology, this attribute allows the CPPM to signal back to the onboard process the context of the device provisioning settings that should be applied to the device based on applied role mappings.
Used as part of the ClearPass Onboard technology, this attribute allows CPPM to signal back to the onboard process the device profile that should be applied to the device based on applied role mappings.
Vendor
Name
Aruba
Vendor
ID
14823
Aruba
Aruba
14823
14823
The following table describes the RTTS VSAs supported by AOS-W. You can view counters for the number of times these attributes were sent and processed using the command show dot1x counters .
Table 44: RTTS RADIUS VSAs
VSA Type Value Description
Vendor
Name
Vendor
ID
RTTS-Estimated-Throughput integer 1
This Attribute can be used to transfer a UE throughput estimation value from a RADIUS authenticator to the cellular WLAN switch (via a RADIUS proxy).
Ericsson 10923
RTTS-Result
RTTS-Backoff-Time
RTTS-Reestimation-
Period
RTTS-Reest-
Below-
Throughput integer 2 integer 3 integer 4 integer 5
This Attribute can be used by the cellular WLAN switch to transfer the result of a traffic steering decision to the RADIUS authenticator.
This Attribute can be used by the cellular WLAN switch in the Access-Accept packet to indicate to the WLAN how long a rejected UE should be ignored before being considered again for entry into the WLAN.
This attribute is included by the cellular WLAN switch in the Access-Accept packet when RTTS-Result is True to indicate to the WLAN the required interval of time between RTTS Throughput estimates to be sent to the
CWC for the UE.
This Attribute is included by the cellular WLAN switch in the Access-Accept packet when RTTS-Result is True to indicate to the WLAN the level below which RTTS
Accounting-Request packets should be sent.
Ericsson 10923
Ericsson 10923
Ericsson 10923
Ericsson 10923
RTTS-Reest-
Keepalive-
Num integer 6
This attribute is included by the cellular WLAN switch when RTTS-Result is True in order to ensure that not too many reestimations are skipped by the WLAN due to the UE Wi-Fi estimated throughput being constantly higher than the RTTS-Reestimate-When-Below-Tput threshold.
Ericsson 10923
The following table describes the Hotspot 2.0 VSAs supported by AOS-W.
AOS-W 6.5.3.x
| User Guide Authentication Servers | 186
Table 45: Hotspot 2.0 RADIUS VSAs
VSA
Hotspot2-Subscription-Remediation-URL
String
Hotspot2-AP-Version
Type Value
1 integer 2
Hotspot2-STA-Version integer 2
Description
Vendor
Name
Subscription remediation is a process used by service providers to help clients resolve subscription errors and issues. If a mobile device is unable to authenticate to the network using existing credentials, the device can receive the
URL of a server that describes other available subscription options.
This attribute contains the following message fields: n Server Method : The provisioning supported by the subscription remediation server.
Supported values are n
0 : OMA-DM
1 : SOAP-XML SSP
Subscription Server URL : Subscription
Remediation Server URL that is sent to a client that is unable to authenticate using its existing credentials.
This attribute indicates the Hotspot release version supported by the AP. Supported values are 0 and 1.
0 = Release 1
1 = Release 2
This attribute indicates the Hotspot release version supported by the mobile device.
Supported values are 0 and 1.
0 = Release 1
1 = Release 2
Wi-Fi-
Alliance
Wi-Fi-
Alliance
Wi-Fi-
Alliance
Vendor
ID
40808
40808
40808
187 | Authentication Servers AOS-W 6.5.3.x | User Guide
VSA
Hotspot2-Deauthentication-
Request
Hotspot2-Session-Info-URL
Type
String
String
Value
4
Description
Vendor
Name
This attribute contains the following message fields: n
Code : Specify the reason the mobile device is being de-authenticated
0 = User’s subscription does not allow or no longer allows access at this BSS
1 = User’s subscription does not allow or no longer allows access at this ESS n n
Re-auth Delay : Define the delay time (in seconds) that a mobile device waits before attempting re-association to the same BSS,
ESS (as indicated in the Code variable). The supported range is 0- 65535. A value of 0 indicates the Re-auth Delay may be decided by the mobile device.
UI message field : The URL of a server that explains why the mobile device was not authorized. This URL must be defined as a
UTF-8 encoded string.
Wi-Fi-
Alliance
5
Configure this attribute to send a BSS Transition
Management Request frame before the mobile device’s session is terminated, warning the user their session is about to end. The URL provides a link to a webpage that provides the user with information on how to extend their session.
This attribute contains the following message fields: n n
Session Warning Time (SWT) : The Session
Warning Time (SWT) is the number of minutes before the end of a session that the AP warns the mobile device about the upcoming session end. If this value is set to 255 , the AP selects the session warning time value.
Session Information URL : This URL is sent to a mobile device before the end of the session.
The URL can link to a website that describes how users can extend their sessions.
Wi-Fi-
Alliance
Vendor
ID
40808
40808
Customizing the RADIUS Attributes
Starting from AOS-W 6.5.1, the users can now configure RADIUS modifier profile to customize the attributes that are included, excluded and modified in the RADIUS request before it is sent to the authentication server.
The RADIUS modifier profile can be configured and applied to either Access- Request or Accounting-Request or both on a RADIUS authentication or accounting server.
This profile can contain up to 64 RADIUS attributes with static values that are used either to add or update in the request and another 64 RADIUS attributes to be excluded from the Requests.
Two new parameters have been added in the RADIUS modifier profile : n n auth-modifier : When assigned, it references to a RADIUS modifier profile which is applied to all Access-
Requests sending to this RADIUS authentication server.
acct-modifier : When assigned, it references to a RADIUS modifier profile which is applied to all Accounting-
Requests sending to this RADIUS accounting server.
To create a RADIUS modifier profile to customize the attributes that are included, excluded and modified in the
RADIUS request before it is sent to the authentication or accounting server:
AOS-W 6.5.3.x
| User Guide Authentication Servers | 188
In the WebUI
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Click Wireless LAN .
3. Click Radius Modifier .
4. Under the Radius Modifier Profile , enter the name of the RADIUS modifier and click Add .
5. Click on the name of the Instance added.
6. In +Attr field, enter the Name and Static Value for the attribute you want to include and click Add . The name field should be available in the list of attributes when we execute the command, show aaa radiusattribute command.
7. In the -Attr field, enter the attribute you want to exclude and click Add .
8. Click Save as and enter the name of the Radius Modifier Profile .
9. Click Apply .
In the CLI
(host) (config) #aaa authentication-server radius radius1 acct-modifier acctport auth-modifier authport
…
…
(host) (config) #aaa radius modifier <profile_name> clone exclude include no
(host) #show aaa radius modifier <profile_name>
Dynamic Data Support
Starting from AOS-W 6.5.2.0, Alcatel-Lucent supports dynamic data for the included attributes in the RADIUS
Attribute modifier. Users can configure the dynamic value for each included attribute in the RADIUS modifier to be one or two data items. Following data items can be picked to form the dynamic value for each included attribute: n n n n
AP-Name : Name of the AP which the client currently associated to.
AP-MAC-Address : MAC-address of the AP which the client currently associated to.
AP-Group : Group-name of the AP which the client currently associated to.
ESSID : ESSID which the client currently associated to.
Field1 and Field2 have the same value but these can be used for different combination with the delimiter. This included attribute are of type ‘String’ and can contain up to 128 bytes.
In the WebUI
1. Navigate to Configuration > Advanced Services > All Profiles .
2. Click Wireless LAN .
3. Click Radius Modifier .
4. Under the Profile details, enter the name of the radius modifier profile and click Add.
5. Click on the name of the instance added.
6. In +Attr field, enter the name of the instance from the Name drop-down list and select the Data Type as
Dynamic .
189 | Authentication Servers AOS-W 6.5.3.x | User Guide
7. Select the First Dynamic Field from the drop-down list.
8. Select the Optional Second Dynamic Field from the drop-down list.
9. Select the Delimiter Between Fields from the drop-down list.
10.Click
Add to add the radius modifier.
11.. Click Save as and enter the name of the Radius Modifier profile.
12.. Click Apply .
In the CLI
To configure a RADIUS modifier profile with single-item dynamic data
(host)(config) #aaa radius modifier dynamic-mod
(host) (Radius Modifier Profile "dynamic-mod") #?
clone exclude include no
Copy data from another Radius Modifier Profile
Attribute to be excluded in RADIUS request
Attribute/Value to be included in RADIUS request
Delete Command
(host) (Radius Modifier Profile "dynamic-mod") #include ?
<name> RADIUS Attribute Name
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id ?
dynamic First dynamic field static Static Data
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic ?
ap-group1 Use AP group as first dynamic field ap-macaddr1 ap-name1 essid1
Use AP mac address as first dynamic field
Use AP name as first dynamic field
Use essid as first dynamic field
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic ap-name1
To configure a RADIUS modifier profile with two-item dynamic data
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic ?
ap-group1 Use AP group as first dynamic field ap-macaddr1 ap-name1 essid1
Use AP mac address as first dynamic field
Use AP name as first dynamic field
Use essid as first dynamic field
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic essid1 ?
with Optional second dynamic field
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic essid1 with
?
ap-group2 Use AP group as second dynamic field ap-macaddr2 ap-name2 essid2
Use AP mac address as second dynamic field
Use AP name as second dynamic field
Use essid as second dynamic field
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic essid1 with ap-macaddr2 ?
delimiter Delimiter between fields
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic essid1 with ap-macaddr2 delimiter ?
at colon
Use '@' as delimiter between fields
Use ':' as delimiter between fields dash dollar
Use '-' as delimiter between fields
Use '$' as delimiter between fields
AOS-W 6.5.3.x
| User Guide Authentication Servers | 190
hash none percent semicolon slash space
Use '#' as delimiter between fields
NULL
Use '%' as delimiter between fields
Use ';' as delimiter between fields
Use '/' as delimiter between fields
Use ' ' as delimiter between fields
(host) (Radius Modifier Profile "dynamic-mod") #include Aruba-Location-Id dynamic essid1 with ap-macaddr2 delimiter at ?
To show a RADIUS modifier profile with mixing of static- and dynamic- data
(host) (config) #show aaa radius modifier dynamic-mod
Radius Modifier Profile
-----------------------
Action
------
Attribute Name
--------------
Data Type Data Value
------------------
+Attr Aruba-Location-Id dynamic
+Attr BW-Area-Code static essid1 with ap-macaddr2 delimiter at
"212"
+Attr
+Attr
BW-City-Name
Aruba-AP-Group
-Attr Aruba-Device-Type static dynamic
"San Jose" ap-group1
RADIUS Server Authentication Codes
A configured RADIUS server returns the following standard response codes.
4
5
6
1
2
3
Table 46: RADIUS Authentication Response Codes
Code
0
Description
Authentication OK.
Authentication failed : user/password combination not correct.
Authentication request timed out : No response from server.
Internal authentication error.
Bad Response from RADIUS server : verify shared secret is correct.
No RADIUS authentication server is configured.
Challenge from server. (This does not necessarily indicate an error condition.)
RADIUS Server Fully Qualified Domain Names
If you define a RADIUS server using the FQDN of the server rather than its IP address, the switch periodically generates a DNS request and caches the IP address returned in the DNS response. To view the IP address that currently correlates to each RADIUS server FQDN, access the command-line interface in config mode and issue the following command:
(host) #show aaa fqdn-server-names
DNS Query Intervals
If you define a RADIUS server using the FQDN of the server rather than its IP address, the switch periodically generates a DNS request and caches the IP address returned in the DNS response. DNS requests are sent every
15 minutes by default.
191 | Authentication Servers AOS-W 6.5.3.x | User Guide
You can use either the WebUI or the CLI to configure how often the switch will generate a DNS request to cache the IP address for a RADIUS server identified via its fully qualified domain name (FQDN).
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Advanced page.
2. In the DNS Query Interval (min) field, enter a new DNS query interval, from 1-1440 minutes, inclusive.
3. Click Apply .
Using the CLI
(host)(config) #aaa dns-query-interval <minutes>
Configuring Username and Password for CPPM Authentication
The switch authenticating to CPPM is enhanced to use configurable username and password instead of support password. The support password is vulnerable to attacks as the server certificate presented by CPPM server is not validated.
In the WebUI:
1. Navigate to Configuration > Security> Authentication> Servers .
2. Under RADIUS Server , select the server name.
3. Enter the cppm_username and cppm_password in the CPPM credentials option.
4. Click Apply .
In the CLI:
(host)(config) #aaa authentication-server radius
Configuring an LDAP Server
describes the parameters you configure for an LDAP server.
Table 47: LDAP Server Configuration Parameters
Parameter
Host
Admin-DN
Admin Password
Allow Clear-Text
Authentication Port
Base-DN
Description
IP address of the LDAP server.
Default: N/A
Distinguished name for the admin user who has read/search privileges across all the entries in the LDAP database (the user does need write privileges, but will be able to search the database, and read attributes of other users in the database).
Password for the admin user.
Default: N/A
Allows clear-text (unencrypted) communication with the LDAP server.
Default: disabled
Port number used for authentication.
Default: 389
Distinguished Name of the node that contains the entire user database.
Default: N/A
AOS-W 6.5.3.x
| User Guide Authentication Servers | 192
Parameter
Filter
Description
A string searches for users in the LDAP database. The default filter string is:
(objectclass=* ).
Default: N/A
Key Attribute
Timeout
Mode
A string searches for a LDAP server. For Active Directory, the value is sAMAccountName.
Default: sAMAccountName
Timeout period of a LDAP request, in seconds.
Default: 20 seconds
Enables or disables the server.
Default: enabled
Preferred Connection
Type
Preferred type of connection between the switch and the LDAP server. The default order of connection type is:
1. ldap-s
2. start-tls
3. clear-text
The switch first tries to contact the LDAP server using the preferred connection type, and only attempts to use a lower-priority connection type if the first attempt is not successful.
NOTE: If you select clear-text as the preferred connection type, you must also enable the allow-cleartext option.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select LDAP Server to display the LDAP Server List.
3. To configure an LDAP server, enter the name for the server and click Add .
4. Select the name to configure server parameters. Enter parameters as described in
. Select the
Mode checkbox to activate the authentication server.
5. Click Apply .
The configuration does not take effect until you perform this step.
Using the CLI
(host)(config) #aaa authentication-server ldap < name>
Configuring a TACACS+ Server
defines the TACACS+ server parameters.
193 | Authentication Servers AOS-W 6.5.3.x | User Guide
Table 48: TACACS+ Server Configuration Parameters
Parameter
Host
Description
IP address of the server.
Default: N/A
Key
TCP Port
Retransmits
Timeout
Mode
Session
Authorization
Source Interface
Shared secret to authenticate communication between the TACACS+ client and server.
Default: N/A
TCP port used by server.
Default: 49
Maximum number of times a request is retried.
Default: 3
Timeout period for TACACS+ requests, in seconds.
Default: 20 seconds
Enables or disables the server.
Default: enabled
Enables or disables session authorization. Session authorization turns on the optional authorization session for admin users.
Default: disabled
Enter a VLAN number ID.
Allows you to use source IP addresses to differentiate TACACS requests.
Associates a VLAN interface with the TACACS server to allow the server-specific source interface to override the global configuration.
n n
If you associate a Source Interface (by entering a VLAN number) with a configured server, then the source IP address of the packet is that interface’s IP address.
If you do not associate the Source Interface with a configured server (leave the field blank), the IP address of the global Source Interface is used.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select TACACS Server to display the TACACS Server List.
3. To configure a TACACS+ server, enter the name for the server and click Add .
4. Select the name to configure server parameters. Enter parameters as described in
. Select the
Mode checkbox to activate the authentication server.
5. Click Apply .
The configuration does not take effect until you perform this step.
Using the CLI
The following command configures, enables a TACACS+ server and enables session authorization:
(host)(config) #aaa authentication-server tacacs <name>
Source Interface
AOS-W 6.5.2.0 introduces the Source Interface parameter. This parameter provides a customer the option of specifying the source IP for a TACACS server. The source IP specified in the TACACS server overrides the one in
AOS-W 6.5.3.x
| User Guide Authentication Servers | 194
global TACACS configuration. If neither the global or per-server source interface in the TACACS server is configured, then routable interface is chosen for TACACS server interface for communication. Both IPv4 and
IPv6 are supported while configuring source interface IP addresses.
If there is mismatch in the host IP and source interface IP. For example if the host is IPv6 and source interface is IPv4 or vice-versa in per-server configuration, then the connection doesn’t succeed.
Only VLAN address is allowed.
Changes to host address are allowed only if:
1. Source interface is not configured.
2. Source interface is of same type as the host IP address.
All other combinations require the use of the no command to clear out the host IP and/or source interface for that particular TACACS server.
Using the WebUI
Follow the steps below to configure per-server TACACS source interface:
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select TACACS Server to display the TACACS Server List.
3. Select a TACACS server to enter the source interface details.
4. Enter values for the vlanid/ipv6addr .
5. Click Apply > Save Configuration .
Follow the steps below to configure global TACACS setup:
1. Navigate to the Configuration > Security > Authentication > Advanced page.
2. In the TACACS Setup field select a value for the vlanid from the Source Address v4 drop- down list to configure source interface IPv4 address.
3. Enter values for the vlanid and IPv6 in the Source Address v6 field to configure source interface IPv6 address.
4. Click Apply > Save Configuration .
The configuration does not take effect until you perform this step.
Using the CLI
The following commands configure the global TACACS source interface on IPv4 and IPv6 respectively:
(host) (config) #ip tacacs source-interface vlan <vlan number>
(host) (config) ##ipv6 tacacs source-interface vlan <vlan id> <ip6addr>
The following commands configure per-server TACACS source interface on IPv4 and IPv6 respectively:
(host) (TACACS Server <name>) # source-interface vlan <vlan id>
(host) (TACACS Server <name>) # source-interface vlan <vlan id> ip6addr <ip6addr>
(host) (TACACS Server "<name>") #source-interface vlan
The following commands delete the global TACACS source interface on IPv4 and IPv6 respectively:
(host) (config)#no ip tacacs source-interface vlan <vlan id>
(host) (config)#no ipv6 tacacs source-interface vlan <vlan id> <ip6addr>
The following command deletes per-server TACACS source interface on IPv4:
(host) (TACACS Server <name>) #no source-interface vlan <vlanid>
195 | Authentication Servers AOS-W 6.5.3.x | User Guide
Configuring a Windows Server
defines parameters for a Windows server used for stateful NTLM authentication.
Table 49: Windows Server Configuration Parameters
Parameter
Host
Description
IP address of the server.
Default: N/A
Mode
Windows Domain
Enables or disables the server.
Default: enabled
Name of the Windows Domain assigned to the server.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Windows Server to display the Windows Server List.
3. To configure a Windows server, enter the name for the server and click Add .
4. Select the name of the server to configure its parameters. Enter the parameters as described in
5. Select the Mode checkbox to activate the authentication server.
6. Click Apply .
The configuration does not take effect until you perform this step.
Using the CLI
(host) (config)# aaa authentication-server windows <windows-server-name>
Managing the Internal Database
You can create entries in the switch’s internal database to authenticate clients. The internal database contains a list of clients, along with the password and default role for each client. When you configure the internal database as an authentication server, client information is checked in incoming authentication requests against the internal database.
Configuring the Internal Database
.
The master switch uses the internal database for authentication by default. You can choose to use the internal database in a local switch by entering the CLI command aaa authentication-server internal use-localswitch
. If you use the internal database in a local switch, you need to add clients on the local switch.
defines the required and optional parameters used in the internal database.
AOS-W 6.5.3.x
| User Guide Authentication Servers | 196
Table 50: Internal Database Configuration Parameters
Parameters
User Name
Password
Description
(Required) Enter a user name or select Generate to automatically generate a user name. An entered user name can be up to 64 characters in length.
(Required) Enter a password or select Generate to automatically generate a password string. An entered password must be a minimum of 6 characters and can be up to 128 characters in length.
Role
Enabled
Expiration
Static Inner IP
Address (for RAPs only)
Role for the client.
For this role to be assigned to a client, you need to configure a server derivation rule, as described in
Configuring Server-Derivation Rules on page 203
. (A user role assigned through a server-derivation rule takes precedence over the default role configured for an authentication method.)
(Optional) E-mail address of the client.
Select this check box to enable the user as soon as the user entry is created.
Select one of the following options: n Entry does not expire: No expiration on user entry.
n n
Set Expiry time (mins): Enter the number of minutes the user is authenticated before their user entry expires.
Set Expiry Date (mm/dd/yyyy) Expiry Time (hh:mm): To select a specific expiration date and time, enter the expiration date in mm/dd/yyyy format, and the expiration time in hh:mm format.
Assign a static inner IP address to a Remote AP. If this database entry is not for a remote AP, leave this field empty.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Add User in the Users section. The user configuration page displays.
4. Enter the information for the client, as described in the table above.
5. Click Enabled to activate this entry on creation.
6. Click Apply . The configuration does not take effect until you perform this step.
7. At the Servers page, click Apply .
The Internal DB Maintenance window also includes a Guest User Page feature that allows you to create user entries for guests only. For details on creating guest users, see
Guest Provisioning User Tasks on page 876
.
Using the CLI
Enter the following command in enable mode:
(host)(config) #local-userdb add {generate-username|username < name> }{ generate-password|password < password> }
Managing Internal Database Files
AOS-W allows you to import and export user information tables to and from the internal database. These files should not be edited once they are exported. AOS-W only supports the importing of database files that were
197 | Authentication Servers AOS-W 6.5.3.x | User Guide
created during the export process. Note that importing a file into the internal database overwrites and removes all existing entries.
Exporting Files in the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Export in the Internal DB Maintenance section. A popup window opens.
4. Enter the name of the file you want to export
5. Click OK .
Importing Files in the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Import in the Internal DB Maintenance section. A popup window opens.
4. Enter the name of the file you want to import.
5. Click OK .
Exporting and Importing Files in the CLI
Enter the following command in enable mode:
(host)(config) #local-userdb export <filename>
(host)(config) #local-userdb import <filename>
Working with Internal Database Utilities
The local internal database also includes utilities to clear all users from the database and restart the internal database to repair internal errors. Under normal circumstances, neither of these utilities are necessary.
Deleting All Users
Issue this command to remove users from the internal database after you have moved your user database from the switch’s internal server to an external server.
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Delete All Users in the Internal DB Maintenance section. A popup window opens and asks you to confirm that you want to remove all users.
4. Click OK .
Repairing the Internal Database
Use this utility under the supervision of Alcatel-Lucent technical support to recreate the internal database. This may clear internal database errors, but also removes all information from the database. Make sure you export your current user information before you start the repair procedure.
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Repair Database in the Internal DB Maintenance section. A popup window opens and asks you to confirm that you want to recreate the database.
4. Click OK .
AOS-W 6.5.3.x
| User Guide Authentication Servers | 198
Configuring Server Groups
You can create groups of servers for specific types of authentication – for example, you can specify one or more RADIUS servers to be used for 802.1X authentication. You can configure servers of different types in one group. For example, you can include the internal database as a backup to a RADIUS server.
Configuring Server Groups
Server names are unique. You can configure the same server in more than one server group. You must configure the server before you can include it in a server group.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Server Group to display the Server Group list.
3. Enter the name of the new server group and click Add .
4. Select the name to configure the server group.
5. Under Servers, click New to add a server to the group.
a. Select a server from the drop-down list and click Add Server .
b. Repeat the above step to add other servers to the group.
6. Click Apply .
Using the CLI
(host)(config) #aaa server-group <name> auth-server <name>
Configuring Server List Order and Fail-Through
The servers in a server group are part of an ordered list. The first server in the list is always used by default, unless it is unavailable, in which case the next server in the list is used. You can configure the order of servers in the server group through the WebUI using the up or down arrows (the top server is the first server in the list).
In the CLI, the position parameter specifies the relative order of servers in the list (the lowest value denotes the first server in the list).
As mentioned previously, the first available server in the list is used for authentication. If the server responds with an authentication failure, there is no further processing for the user or client for which the authentication request failed. You can also enable fail-through authentication for the server group so that if the first server in the list returns an authentication deny, the switch attempts authentication with the next server in the ordered list. The switch attempts to authenticate with each server in the list until there is a successful authentication or the list of servers in the group is exhausted. This feature is useful in environments where there are multiple, independent authentication servers; users may fail authentication on one server but can be authenticated on another server.
Before enabling fail-through authentication, note the following: n n n
This feature is not supported for 802.1X authentication with a server group that consists of external EAPcompliant RADIUS servers. You can, however, use fail-through authentication when the 802.1X
authentication is terminated on the switch (AAA FastConnect).
Enabling this feature for a large server group list may cause excess processing load on the switch. It is recommended that you use server selection based on domain matching whenever possible (see
Dynamic Server Selection on page 200
).
Certain servers, such as the RSA RADIUS server, lock out the switch if there are multiple authentication failures. Therefore, you should not enable fail-through authentication with these servers.
199 | Authentication Servers AOS-W 6.5.3.x | User Guide
In the following example, you create a server group "corp-serv" with two LDAP servers (ldap-1 and ldap-2), each containing a subset of the usernames and passwords used in the network. When you enable fail-through authentication, users that fail authentication with the first server on the list will be authenticated with the second server.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select LDAP Server to display the LDAP Server List.
3. Enter ldap-1 for the server name and click Add .
4. Enter ldap-2 for the server name and click Add .
5. Under the Servers tab, select ldap-1 to configure server parameters. Enter the IP address for the server.
Select the Mode check box to activate the authentication server. Click Apply .
6. Repeat
to configure ldap-2.
7. Display the Server Group list: Under the Servers tab, select Server Group .
8. Enter corp-serv as the new server group and click Add .
9. Select corp-serv, under the Server tab, to configure the server group.
10.Select
Fail Through .
11.Under Servers, click New to add a server to the group. Select ldap-1 from the drop-down list and click Add
Server .
12.Repeat
to add ldap-2 to the group.
13.Click
Apply .
Using the CLI
(host)(config) #aaa authentication-server ldap ldap-1 host 10.1.1.234
(host)(config) #aaa authentication-server ldap ldap-2 host 10.2.2.234
(host)(config) #aaa server-group corp-serv auth-server ldap-1 position 1 auth-server ldap-2 position 2 allow-fail-through n n
Configuring Dynamic Server Selection
The switch can dynamically select an authentication server from a server group based on the user information sent by the client in an authentication request. For example, an authentication request can include client or user information in one of the following formats: n n n
<domain>\<user> : for example, corpnet.com\darwin
<user>@<domain> : for example, [email protected]
host/<pc-name>.<domain> : for example, host/darwin-g.finance.corpnet.com (this format is used with
802.1X machine authentication in Windows environments)
When you configure a server in a server group, you have the option to associate the server with one or more match rules. A match rule for a server can be one of the following: n
The server is selected if the client/user information contains a specified string.
The server is selected if the client/user information begins with a specified string.
The server is selected if the client/user information exactly matches a specified string.
AOS-W 6.5.3.x
| User Guide Authentication Servers | 200
You can configure multiple match rules for the same server. The switch compares the client/user information with the match rules configured for each server, starting with the first server in the server group. If a match is found, the switch sends the authentication request to the server with the matching rule. If no match is found before the end of the server list is reached, an error is returned, and no authentication request for the client/user is sent.
depicts a network consisting of several subdomains in corpnet.com. The server radius-1 provides
802.1X machine authentication to PC clients in xyz.corpnet.com, sales.corpnet.com, and hq.corpnet.com. The server radius-2 provides authentication for users in abc.corpnet.com.
Figure 38 Domain-Based Server Selection Example
You configure the following rules for servers in the corp-serv server group: n n radius-1 is selected if the client information starts with “host.” radius-2 is selected if the client information contains “abc.corpnet.com.”
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Under the Servers tab, select Server Group to display the Server Group list.
3. Enter corp-serv for the new server group and click Add .
4. Under the Servers tab, select corp-serv to configure the server group.
5. Under Servers, click New to add the radius-1 server to the group. Select radius-1 from the drop-down list.
a. For Match Type, select Authstring .
b. For Operator, select starts-with .
c. For Match String, enter host/ .
d. Click Add Rule >> .
e. Scroll to the right and click Add Server .
6. Under Servers, click New to add the radius-2 server to the group. Select radius-2 from the drop-down list.
a. For Match Type, select Authstring.
b. For Operator, select contains .
c. For Match String, enter abc.corpnet.com.
d. Click Add Rule >> .
e. Scroll to the right and click Add Server .
201 | Authentication Servers AOS-W 6.5.3.x | User Guide
The last server you added to the server group (radius-2) automatically appears as the first server in the list. In this example, the order of servers is not important. If you need to reorder the server list, scroll to the right and click the up or down arrow for the appropriate server.
7. Click Apply .
Using the CLI
(host)(config) #aaa server-group corp-serv auth-server radius-1 match-authstring starts-with host/ position 1 auth-server radius-2 match-authstring contains abc.corpnet.com position 2
Configuring Match FQDN Option
You can also use the “match FQDN” option for a server match rule. With a match FQDN rule, the server is selected if the <domain> portion of the user information in the formats <domain>\<user> or
<user>@<domain> matches a specified string exactly . Note the following caveats when using a match FQDN rule: n n
This rule does not support client information in the host/<pc-name>.<domain> format, so it is not useful for 802.1X machine authentication.
The match FQDN option performs matches on only the <domain> portion of the user information sent in an authentication request. The match-authstring option (described previously) allows you to match all or a portion of the user information sent in an authentication request.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Under the Servers tab, select Server Group to display the Server Group list.
3. Enter corp-serv for the new server group and click Add .
4. Under the Servers tab, select corp-serv to configure the server group.
5. Under Servers, click New to add the radius-1 server to the group. Select radius-1 from the drop-down list.
a. For Match Type, select FQDN .
b. For Match String, enter corpnet.com
.
c. Click Add Rule >> .
d. Scroll to the right and click Add Server .
6. Click Apply .
Using the CLI
(host)(config) #aaa server-group corp-serv auth-server radius-1 match-fqdn corpnet.com
Trimming Domain Information from Requests
Before the switch forwards an authentication request to a specified server, it can truncate the domain-specific portion of the user information. This is useful when user entries on the authenticating server do not include domain information. You can specify this option with any server match rule. This option is only applicable when the user information is sent to the switch in the following formats: n n
<domain>\<user> : the <domain>\ portion is truncated
<user>@<domain> : the @<domain> portion is truncated
This option does not support client information sent in the format host/<pc-name>.<domain>
AOS-W 6.5.3.x
| User Guide Authentication Servers | 202
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Server Group to display the Server Group list.
3. Enter the name of the new server group and click Add .
4. Select the name to configure the server group.
5. Under Servers, click Edit for a configured server or click New to add a server to the group.
n n
If editing a configured server, select Trim FQDN, scroll right, and click Update Server .
If adding a new server, select a server from the drop-down list, then select Trim FQDN, scroll right, and click Add Server .
6. Click Apply .
Using the CLI
(host)(config) #aaa server-group corp-serv auth-server radius-2 match-authstring contains abc.corpnet.com trim-fqdn
Configuring Server-Derivation Rules
When you configure a server group, you can set the VLAN or role for clients based on attributes returned for the client by the server during authentication. The server derivation rules apply to all servers in the group. The user role or VLAN assigned through server derivation rules takes precedence over the default role and VLAN configured for the authentication method.
The authentication servers must be configured to return the attributes for the clients during authentication. For instructions on configuring the authentication attributes in a Windows environment using IAS, refer to the documentation at http://technet2.microsoft.com/windowsserver/en/technologies/ias.mspx
The server rules are applied based on the first match principle. The first rule that is applicable for the server and the attribute returned is applied to the client, and would be the only rule applied from the server rules. These rules are applied uniformly across all servers in the server group.
describes the server rule parameters you can configure.
203 | Authentication Servers AOS-W 6.5.3.x | User Guide
Table 51: Server Rule Configuration Parameters
Parameter
Role or VLAN
Description
The server derivation rules apply to either user role or VLAN assignment. With
Role assignment, a client can be assigned a specific role based on the attributes returned. In VLAN assignment, the client can be placed in a specific VLAN based on the attributes returned.
Attribute
Operation
Operand
Value position
This is the attribute returned by the authentication server that is examined for
Operation and Operand match.
This is the match method by which the string in Operand is matched with the attribute value returned by the authentication server.
n contains : The rule is applied if and only if the attribute value contains the string in parameter Operand.
n n n starts-with : The rule is applied if and only if the attribute value returned starts with the string in parameter Operand.
ends-with : The rule is applied if and only if the attribute value returned ends with the string in parameter Operand.
equals : The rule is applied if and only if the attribute value returned equals the string in parameter Operand.
n n not-equals : The rule is applied if and only if the attribute value returned is not equal to the string in parameter Operand.
value-of : This is a special condition. What this implies is that the role or
VLAN is set to the value of the attribute returned. For this to be successful, the role and the VLAN ID returned as the value of the attribute selected must be already configured on the switch when the rule is applied.
This is the string to which the value of the returned attribute is matched.
The user role or the VLAN name applied to the client when the rule is matched.
Position of the condition rule. Rules are applied based on the first match principle. One is the top.
Default: bottom
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Server Group to display the Server Group list.
3. Enter the name of the new server group and click Add .
4. Select the name to configure the server group.
5. Under Servers, click New to add a server to the group.
a. Select a server from the drop-down list and click Add .
b. Repeat the above step to add other servers to the group.
6. Under Server Rules, click New to add server derivation rules for assigning a user role or VLAN.
a. Enter the attribute.
b. Select the operation from the drop-down list.
c. Enter the operand.
d. To set the role, select set role from the Set drop-down list and enter the value to be assigned from the
Value drop-down list.
e. Or, to set the vlan, select set vlan from the Set drop-down list and select the VLAN name or ID from the
Value drop-down list and click the left-arrow.
AOS-W 6.5.3.x
| User Guide Authentication Servers | 204
f. Click Add .
g. Repeat the above steps to add other rules for the server group.
7. Click Apply .
Using the CLI
(host) (config) #aaa server-group <name>
(host) (Server Group name) #set {role|vlan} condition <attribute> contains|endswith|equals|not-equals|starts-with <operand> set-value <set-value-str> position <number>
Configuring a Role Derivation Rule for the Internal Database
When you add a user entry in the switch’s internal database, you can optionally specify a user role (see
Managing the Internal Database on page 196
). The role specified in the internal database entry to be assigned to the authenticated client, you must configure a server derivation rule as shown in the following sections:
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Server Group to display the Server Group list.
3. Select the internal server group.
4. Under Server Rules, click New to add a server derivation rule.
a. For Condition, enter Role .
b. Select value-of from the drop-down list.
c. Select Set Role from the drop-down list.
d. Click Add .
5. Click Apply .
Using the CLI
(host)(config) #aaa server-group internal set role condition Role value-of
Assigning Server Groups
You can create server groups for the following purposes: n n n user authentication management authentication accounting
You can configure all types of servers for user and management authentication (see
). Accounting is only supported with RADIUS and TACACS+ servers when RADIUS or TACACS+ is used for authentication.
Table 52: Server Types and Purposes
RADIUS
Yes User authentication
Management authentication
Accounting
Yes
Yes
TACACS+ LDAP
Yes Yes
Yes
Yes
Yes
No
Internal Database
Yes
Yes
No
205 | Authentication Servers AOS-W 6.5.3.x | User Guide
User Authentication
For information about assigning a server group for user authentication, refer to the Roles and Policies chapter of the AOS-W User Guide .
Management Authentication
Users who need to access the switch to monitor, manage, or configure the Alcatel-Lucent user-centric network can be authenticated with RADIUS, TACACS+, or LDAP servers or the internal database.
Only user record attributes are returned upon successful authentication. Therefore, to derive a management role other than the default mgmt auth role, set the server derivation rule based on the user attributes.
Using the WebUI
1. Navigate to the Configuration > Management > Administration page.
2. Under the Management Authentication Servers section, select the following: n n
Enable check box
Server Group
3. Click Apply .
Using the CLI
(host)(config) #aaa authentication mgmt server-group < group> enable
Accounting
You can configure accounting for RADIUS and TACACS+ server groups.
RADIUS or TACACS+ accounting is only supported when RADIUS or TACACS+ is used for authentication.
RADIUS Accounting
RADIUS accounting allows user activity and statistics to be reported from the switch to RADIUS servers:
1. The switch generates an Accounting Start packet when a user logs in. The code field of transmitted RADIUS packet is set to 4 (Accounting-Request). Note that sensitive information, such as user passwords, are not sent to the accounting server. The RADIUS server sends an acknowledgement of the packet.
2. The switch sends an Accounting Stop packet when a user logs off; the packet information includes various statistics such as elapsed time, input and output bytes, and packets. The RADIUS server sends an acknowledgment of the packet.
The following is the list of attributes that the switch can send to a RADIUS accounting server: n n n n
Acct-Status-Type: This attribute marks the beginning or end of accounting record for a user. Current values are Start, Stop, and Interim Update.
User-Name: Name of user.
Acct-Session-Id: A unique identifier to facilitate matching of accounting records for a user. It is derived from the user name, IP address, and MAC address. This is set in all accounting packets.
Acct-Authentic: This indicates how the user was authenticated. Current values are 1 (RADIUS), 2 (Local), and 3 (LDAP).
AOS-W 6.5.3.x
| User Guide Authentication Servers | 206
n n n n n n n n n
Acct-Session-Time: The elapsed time, in seconds, that the client was logged in to the switch. This is only sent in Accounting-Request records, where the Acct-Status-Type is Stop or Interim Update.
Acct-Terminate-Cause: Indicates how the session was terminated and is sent in Accounting-Request records where the Acct-Status-Type is Stop. Possible values are:
1: User logged off
4: Idle Timeout
5: Session Timeout. Maximum session length timer expired.
7: Admin Reboot: Administrator is ending service, for example prior to rebooting the switch.
NAS-Identifier: This is set in the RADIUS server configuration.
l
NAS-IP-Address: IP address of the master switch. You can configure a “global” NAS IP address:
In the WebUI, navigate to the Configuration > Security > Authentication > Advanced page.
l
In the CLI, use the, ip radius nas-ip command.
NAS-Port: Physical or virtual port (tunnel) number through which the user traffic is entering the switch.
NAS-Port-Type: Type of port used in the connection. This is set to one of the following: l
5: admin login l l
15: wired user type
19: wireless user
Framed-IP-Address: IP address of the user.
Calling-Station-ID: MAC address of the user.
Called-station-ID: MAC address of the switch.
The following attributes are sent in Accounting-Request packets when Acct-Status-Type value is Start: n n n n n n n n n n n
Acct-Status-Type
User-Name
NAS-IP-Address
NAS-Port
NAS-Port-Type
NAS-Identifier
Framed-IP-Address
Calling-Station-ID
Called-station-ID
Acct-Session-ID
Acct-Authentic
The following attributes are sent in Accounting-Request packets when Acct-Status-Type value is Stop: n n n n n n n n n
Acct-Status-Type
User-Name
NAS-IP-Address
NAS-Port
NAS-Port-Type
NAS-Identifier
Framed-IP-Address
Calling-Station-ID
Called-station-ID
207 | Authentication Servers AOS-W 6.5.3.x | User Guide
n n n n
Acct-Session-ID
Acct-Authentic
Terminate-Cause
Acct-Session-Time
The following statistical attributes are sent only in Interim-Update and Accounting Stop packets (they are not sent in Accounting Start packets): n n n n n n
Acct-Input-Octets
Acct-Output-Octets
Acct-Input-Packets
Acct-Output-Packets
Acct-Input-Gigawords
Acct-Output-Gigawords
Remote APs in split-tunnel mode now support RADIUS accounting. If you enable RADIUS accounting in a splittunnel Remote AP’s AAA profile, the switch sends a RADIUS accounting start record to the RADIUS server when a user associates with the remote AP, and sends a stop record when the user logs out or is deleted from the user database. If interim accounting is enabled, the switch sends updates at regular intervals. Each interim record includes cumulative user statistics, including received bytes and packets counters.
You can use either the WebUI or CLI to assign a server group for RADIUS accounting.
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > AAA Profiles page.
2. Select AAA Profile, then the AAA profile instance.
3. (Optional) In the Profile Details pane, select RADIUS Interim Accounting to allow the switch to send
Interim-Update messages with current user statistics to the server at regular intervals. This option is disabled by default, allowing the switch to send only start and stop messages RADIUS accounting server.
4. In the profile list, scroll down and select the Radius Accounting Server Group for the AAA profile. Select the server group from the drop-down list.
You can add additional servers to the group or configure server rules.
5. Click Apply .
Using the CLI
(host)(config) #aaa profile < profile> radius-accounting < group> radius-interim-accounting
Roaming RADIUS Accounting Service
Starting from AOS-W 6.5.2, the Roaming RADIUS Accounting Service creates an Accounting session for each wireless client. The records in the session contain the same set of RADIUS attributes as compared to the timerbased RADIUS Interim-Update Accounting record, except the statistics attributes. Whenever a wireless client roams to a different AP, the Roaming triggered RADIUS Interim-Update Accounting record is sent to the configured RADIUS Accounting server. This record is used to track the current location of the wireless client.
Currently this feature is supported only for wireless clients and not for wired, VPN/VIA, and L3-Mobility clients.
You can enable roaming RADIUS accounting services by using the WebUI and CLI:
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > AAA Profiles page.
2. Select AAA Profile , then select the AAA profile instance.
AOS-W 6.5.3.x
| User Guide Authentication Servers | 208
3. Select the RADIUS Roaming Accounting check box.
4. Click Apply .
5. Click Save Configuration .
Using the CLI
To enable roaming RADIUS accounting services, use the following CLI:
(host) (config) # aaa profile <profile_name> radius-accounting <group> radius-roam-accounting
To check if roaming-triggered RADIUS accounting is enabled, use the following CLI:
(host) #show aaa profile <profile_name>
RADIUS Accounting on Multiple Servers
AOS-W provides support for the switches to send RADIUS accounting to multiple RADIUS servers. The switch notifies all the RADIUS servers to track the status of authenticated users. Accounting messages are sent to all the servers configured in the server group in a sequential order.
You can enable multiple server account functionality by using the WebUI and CLI:
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > AAA Profiles page.
2. Select AAA Profile , then select the AAA profile instance.
3. Select the Multiple Server Accounting check box.
4. Click Apply .
5. Click Save Configuration .
Using the CLI
To enable RADIUS Accounting on Multiple Servers functionality, use the following CLI:
(host) (config) # aaa profile <profile_name> multiple-server-accounting
TACACS+ Accounting
TACACS+ accounting allows commands issued on the switch to be reported to TACACS+ servers. You can specify which types of commands are reported (action, configuration, or show commands), or report all commands.
You can configure TACACS+ accounting through the CLI:
(host)(config) #aaa tacacs-accounting server-group <group> command
{action|all|configuration|show} mode {enable|disable}
You can configure TACACS+ accounting through the WebUI:
1. Navigate to Configuration > SECURITY > Authentication .
2. In the Servers tab, click Tacacs Accounting Server .
3. In the Tacacs Accounting Server section: a. select an entry from the Server Group drop-down list.
b. select the appropriate Command check boxes to enable accounting for all commands of specified types.
c. select the Mode check box to enable or disable TACACS+ accounting.
4. Click Apply .
5. Click Save Configuration .
209 | Authentication Servers AOS-W 6.5.3.x | User Guide
Configuring Authentication Timers
describes the timers you can configure for all clients and servers. These timers can be left at their default values for most implementations.
Table 53: Authentication Timers
Timer
User Idle Timeout
Description
Maximum period after which a client is considered idle if there is no wireless traffic from the client. The timeout period is reset if there is wireless traffic. If there is no wireless traffic in the timeout period, the client is aged out. Once the timeout period has expired, the user is removed. If the keyword seconds is not specified, the value defaults to minutes at the command line.
Range: 1–255 minutes (30–15300 seconds)
Default: 5 minutes (300 seconds)
Authentication Server
Dead Time
Logon User Lifetime
User Interim stats frequency
Maximum period, in minutes, that the switch considers an unresponsive authentication server to be “out of service.”
This timer is only applicable if there are two or more authentication servers configured on the switch. If there is only one authentication server configured, the server is never considered out of service, and all requests are sent to the server.
If one or more backup servers are configured and a server is unresponsive, it is marked as out of service for the dead time; subsequent requests are sent to the next server on the priority list for the duration of the dead time. If the server is responsive after the dead time has elapsed, it can take over servicing requests from a lowerpriority server; if the server continues to be unresponsive, it is marked as down for the dead time.
Range: 0–50 minutes
Default: 10 minutes
Maximum time, in minutes, unauthenticated clients are allowed to remain logged on.
Range: 0–255 minutes
Default: 5 minutes
Sets the timeout value for user stats, reporting in minutes or seconds.
Range: 300–600 seconds, or 5–10 minutes
Default: 600 seconds
Setting an Authentication Timer
To set an authentication timer, complete one of the following procedures:
Using the WebUI
1. Navigate to the Configuration > Security > Authentication > Advanced page.
2. Configure the timers as described above.
3. Click Apply before moving on to another page or closing the browser window. If you do not perform this step, you will lose your configuration changes.
Using the CLI
The commands below configure timers you can apply to clients. If the optional seconds keyword is not specified for the idle-timeout and stats-timeout parameters, the value defaults to minutes.
(host)(config) #aaa timers dead-time <minutes>
AOS-W 6.5.3.x
| User Guide Authentication Servers | 210
idle-timeout <time> [seconds] logon-lifetime <0-255> stats-timeout <time> [seconds]
Authentication Server Load Balancing
Load balancing of authentication servers ensures that the authentication load is split across multiple authentication servers, thus avoiding any one particular authentication server from being overloaded.
Authentication Server Load Balancing functionality enables the Alcatel-Lucent Switch to perform load balancing of authentication requests destined for external authentication servers (Radius/LDAP etc). This prevents any one authentication server from having to handle the full load during heavy authentication periods, such as at the start of the business day.
Starting from AOS-W 6.5.1.0, the AOS-W switches perform load balancing of RADIUS accounting packets that are destined to external RADIUS Servers to ensure accounting load gets distributed. Server-load-balancing is enabled for RADIUS accounting packets as well.
Previously, the switch used the first authentication server in the server group list. The remaining servers in that group would be used in sequential order only when an authentication server was down. Thus, the switches performed fail-over instead of load balancing of authentication servers.
The load balancing algorithm computes the expected time taken to authenticate a new client for each authentication server and chooses that authentication server with the shorted expected authentication time.
The load balancing algorithm maintains re-authentication stickiness, meaning that at the time of reauthentication, the request is forwarded to the same server where it was originally authenticated.
Enabling Authentication Server Load Balancing Functionality
A new load–balancing enable parameter has been introduced in the aaa server-group test command to enable authentication server load balancing functionality.
aaa server-group <sg_name> load-balance auth-server s1 auth-server s2
You can use the following command to disable load balancing: aaa server-group<sg_name> no load-balance
If you configure an internal server in the server group, load balancing is not applicable to the internal server. The
Internal server will be used as a fall-back when all other servers in the group are down.
211 | Authentication Servers AOS-W 6.5.3.x | User Guide
Chapter 9
MAC-based Authentication
This chapter describes how to configure MAC-based authentication on the Alcatel-Lucent switch using the
WebUI.
Use MAC-based authentication to authenticate devices based on their physical media access control (MAC) address. Although this not the most secure and scalable method, MAC-based authentication implicitly provides an addition layer of security to authenticate devices. MAC-based authentication is often used to authenticate and allow network access through certain devices while denying access to the rest. For example, if clients are allowed access to the network through station A, then one method of authenticating station A is MAC-based.
Clients may be required to authenticate themselves using other methods depending on the network privileges required.
MAC-based authentication can also be used to authenticate Wi-Fi phones as an additional layer of security to prevent other devices from accessing the voice network using what is normally an insecure SSID.
This chapter describes the following topics: n n
Configuring MAC-Based Authentication on page 212
Configuring Clients on page 213
Configuring MAC-Based Authentication
Before configuring MAC-based authentication, you must configure the following options: n n
User role—The user role that will be assigned as the default role for the MAC-based authenticated clients.
(See
Roles and Policies on page 375
for information on firewall policies to configure roles.)
Configure the default user role for MAC-based authentication in the AAA profile. If derivation rules exist or if the client configuration in the internal database has a role assigned, these values take precedence over the default user role.
Authentication server group—The authentication server group that the switch uses to validate the clients.
The internal database can be used to configure the clients for MAC-based authentication. See
for information on configuring the clients on the local database. For information on configuring authentication servers and server groups, see
Authentication Servers on page 178 .
Configuring the MAC Authentication Profile
describes the parameters you can configure for MAC-based authentication.
AOS-W 6.5.3.x
| User Guide MAC-based Authentication | 212
Table 54: MAC Authentication Profile Configuration Parameters
Parameter
Delimiter
Description
Delimiter used in the MAC string: n colon specifies the format Xx:XX:XX:XX:XX:XX n n dash specifies the format XX-XX-XX-XX-XX-XX none specifies the format XXXXXXXXXXXX n oui-nic specifies the format XXXXXX:XXXXXX
Default: none
NOTE: This parameter is available for the aaa authentication-server radius command.
Case
Max Authentication failures
The case (upper or lower) used in the MAC string.
Default: lower
Number of times a station can fail to authenticate before it is blacklisted. A value of zero disables blacklisting.
Default: zero (0)
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. Select MAC Authentication Profile.
3. Enter a profile name and click Add .
4. Select the profile name to display configurable parameters.
5. Configure the parameters, as described in
.
6. Click Apply .
In the CLI
Execute the following command to configure a MAC authentication profile:
(host)(configure) #aaa authentication mac < profile> case {lower|upper} delimiter {colon|dash|none} max-authentication-failures <number>
Configuring Clients
You can create entries in the switch’s internal database to authenticate client MAC addresses. The internal database contains a list of clients along with the password and default role for each client. To configure entries in the internal database for MAC authentication, you enter the MAC address for both the username and password for each client.
You must enter the MAC address using the delimiter format configured in the MAC authentication profile. The default delimiter is none, which means that MAC addresses should be in the format xxxxxxxxxxxx. If you specify colons for the delimiter, you can enter MAC addresses in the format xx:xx:xx:xx:xx:xx.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Internal DB .
3. Click Add User in the Users section. The user configuration page displays.
213 | MAC-based Authentication AOS-W 6.5.3.x | User Guide
4. For User Name and Password , enter the MAC address for the client. Use the format specified by the
Delimiter parameter in the MAC Authentication profile. For example, if the MAC Authentication profile specifies the default delimiter (none), enter MAC addresses in the format xxxxxxxxxxxx
.
5. Click Enabled to activate this entry on creation.
6. Click Apply .
The configuration does not take effect until you perform this step.
In the CLI
Enter the following command in enable mode:
(host)(config) #local-userdb add username < macaddr> password < macaddr> ...
AOS-W 6.5.3.x
| User Guide MAC-based Authentication | 214
Chapter 10
Branch Switch Config for Cloud Services Switches
Many distributed enterprises with branch and remote offices and locations use cost-effective hybrid WAN connectivity solutions that include low-cost DSL, 4G and LTE technologies, rather than relying solely on traditional E1/T1 or T3/E3 dedicated circuits. OAW-40xx Series Cloud Services Switches are optimized for these types of locations, which are more likely to use cloud security architectures instead of dedicated security appliances, and where clients are likely to access applications in the cloud, rather than on local application servers.
Throughout this document the term branch switch will refer to a OAW-40xx Series Series Cloud Services switch that has been configured via a branch config group created using the AOS-W Smart Config WebUI.
AOS-W supports these distributed enterprises through the following features designed specifically for branch and remote offices: n n n n n n
Authentication survivability allows OAW-40xx Series switches to store user access credentials and key reply attributes whenever clients are authenticated with external RADIUS servers or LDAP authentication servers, providing authentication and authorization survivability when remote authentication servers are not accessible.
Integration with existing Palo Alto Networks Firewalls, like WildFire™ anti-virus and anti-malware detection services. In deployments with multiple Palo Alto Networks (PAN) firewalls, OAW-40xx Series switches can select the best PAN firewall based on priority and availability.
Policy-based routing on each uplink interface, which allows you specify the next hop to which packets are routed. AOS-W supports multiple next-hop lists, to ensure connectivity in the event that a device on the list becomes unreachable.
Uplink and VPN redundancy, and per-interface bandwidth contracts to limit traffic for individual applications (or categories of applications) either sent from or received by a selected interface.
Packet compression between Alcatel-Lucent devices (such as devices at the branch and main office), to maximize the amount of data that can be carried by the network.
A WAN health-check feature that uses ping-probes to measure WAN availability and latency on each uplink.
The following diagram depicts managed node where a branch switch in the branch office learns the address, routing information, and other provisioning information from the master switch.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 215
n n
This chapter describes the features and functions of a branch switch, and includes the following topics: n n n n
Branch Deployment Features on page 216
Zero-Touch Provisioning on page 230
Using Smart Config to create a Branch Config Group on page 233
PortFast and BPDU Guard on page 254
Preventing WAN Link Failure on Virtual APs on page 257
Branch WAN Dashboard on page 257
Branch Deployment Features
This section describes the following branch switch features. For details on the configuration parameters for each of these features, see
Using Smart Config to create a Branch Config Group on page 233
.
n n n n n n n
Layer-3 Redundancy for Branch Switch Masters on page 217
WAN Failure (Authentication) Survivability on page 218
WAN Optimization through IP Payload Compression on page 224
Interface Bandwidth Contracts on page 225
Branch Integration with a Palo Alto Networks (PAN) Portal on page 226
Branch Switch Routing Features on page 229
216 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
n
Cloud Management on page 230Cloud Management on page 230
Scalable Site-to-Site VPN Tunnels
AOS-W 6.4.4.0 and later supports site-to-site IPSEC tunnels based on a Fully Qualified Domain Name (FQDN).
When you identify the remote peer for a branch config group using an FQDN, that config group can be applied across multiple branch switches, as the configured FQDN can resolve to different IP addresses for each local branch, based on local DNS settings.
In AOS-W 6.4.4.0 and later releases, crypto maps for site-to-site VPNs support a VLAN ID as the identifier for the source network. When the VPN settings are pushed to branch switch, the IKE negotiation process uses the
IP address range for the VLAN. This feature allows you to push the same source network configuration to multiple branch switches, as each branch switch negotiates a different source source network IP for its VLAN based on the IP pool for that local branch.
Layer-3 Redundancy for Branch Switch Masters
AOS-W 6.4.4.0 introduces support for a redundant secondary master switch in branch switch deployments.
This prevents a scenario where a master switch acts as a single point of failure if the link to the master goes down, or a co-located Master-Standby VRRP switch pair fail due to a network failure or local natural disaster.
Configuring Layer-3 Redundancy
The IP address of a primary master and a secondary, backup master switch can be defined for a branch during the
Zero-touch provisioning process
, and is either defined in a DHCP server, or is manually entered into the branch switch during the initial startup dialog. The primary and secondary master switches must be manually kept in synchronization by ensuring all the configuration, certificates, and branch switch whitelist, AP whitelist and local user database are the same in both of them.
Database settings are not automatically synchronized from a primary master to a secondary master with Layer-3 redundancy. All database settings, certificates, whitelist settings and profile configurations must be kept in sync manually.
Viewing Switch Connectivity Status
The status of the branch's connection to a primary and secondary master switch appears in the
page of the branch switch WebUI. To display the current status of the branch switch's connectivity to the master and secondary master IP addresses, click the Layer3 Redundancy tab on the Status section of the dashboard.
Figure 39 Branch Switch Redundancy Status
Failover Behaviors
When a provisioned branch switch detects that its primary master is unreachable, it attempts to reconnect to the primary master for the time period defined by the
Master L3 Redundancy Switchover Timeout
in its branch
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 217
switch configuration. If the branch switch cannot reconnect to the primary master switch during this switchover timeout period, and the secondary switch is up and reachable, the branch switch reloads and associates to the secondary switch as the new master. The branch switch then synchronizes its branch and global configuration settings from the new master, and reloads again to apply those settings.
WAN Failure (Authentication) Survivability
This section contains the following information about the authentication survivability feature. This feature is supported on OAW-40xx Series switches.
n n n n n n n n
Supported Client and Authentication Types
Trigger Conditions for Critical Actions
Authentication for Captive Portal Clients
Authentication for 802.1X Clients
Authentication for MAC Address-Based Clients
Authentication for WISPr Clients
Authentication survivability allows switches to provide client authentication and authorization survivability when remote authentication servers are not accessible. It stores user access credentials, as well as key reply attributes, whenever clients are authenticated with external RADIUS servers or LDAP authentication servers.
When external authentication servers are not accessible, the switch uses its local Survival Server to continue providing authentication and authorization functions by using the user access credentials and key reply attributes that were stored earlier.
Authentication survivability is critical to WLANs managed by branch switches since most branch switches use geographically remote authentication servers to provide authentication and authorization services. When those authentication servers are not accessible, clients can't access the WLAN because the branch switch can't authenticate them.
This feature can be configured for branch switches using the Smart Config WebUI, or for master and local switches using the aaa auth-survivability commands in the command-line interface. For details on configuring this feature using the Smart Config WebUI, see
WAN Configuration on page 251 .
Supported Client and Authentication Types
The following combination of clients and authentication types are supported with the authentication survivability feature (see
):
Table 55: Clients and Supported Authentication Types
Clients
Captive Portal clients
802.1X clients
External Captive Portal clients using the XML-API
Authentication Methods
Password Authentication Protocol (PAP) n n
Termination disabled : Extensible Authentication Protocol-Transport
Layer Security (EAP-TLS) with an external RADIUS server
Termination enabled : EAP-TLS with Common Name (CN) lookup with an external authentication server
PAP
218 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Clients
MAC-based Authentication clients
VPN clients
VIA and other VPN clients
Wireless Internet Service Provider roaming (WISPr) clients
Authentication Methods
PAP n n
PAP with an external authentication server
CN lookup with an external authentication server
PAP method and CN lookup
PAP
In this initial release, the external authentication server can be either a RADIUS server or an LDAP server.
Supported Key Reply Attributes
The following key reply attributes are supported: n n n n n n n n n
ARUBA_NAMED_VLAN
ARUBA_NO_DHCP_FINGERPRINT
ARUBA_ROLE
ARUBA_VLAN
MS_TUNNEL_MEDIUM_TYPE
MS_TUNNEL_PRIVATE_GROUP_ID
MS_TUNNEL_TYPE
PW_SESSION_TIMEOUT
PW_USER_NAME
Support Restrictions
The authentication survivability feature has the following support restrictions: n n n n n
The Survival Server cache database is station-based (thus, the MAC address is the key), so authentication survivability is not supported for any station with a zero MAC address.
For a client using EAP-TLS, you must install the issuer certificate of the Survival Server certificate as a
TrustedCA certificate in the client station.
For an 802.1X client using EAP-TLS that does not terminate at the switch, the issuer certificate for the client certificate must be imported as a TrustedCA or an intermediateCA certificate at the switch—just as the same certificate must be installed at the terminating External RADIUS server.
The Survival Server does not support the Online Certificate Status Protocol (OCSP) nor the Certificate
Revocation List (CRL) for EAP-TLS.
Authentication survivability will not activate if Authentication Server Dead Time is configured as 0.
To configure Authentication Server Dead Time, on the switch, navigate to: Configuration > SECURITY >
Authentication > Advanced > Authentication Timers > Authentication ServerDeadTime (min) .
Administrative Functions
This section describes the scenarios that illustrate the functionality that the authentication survivability feature provides. For more information, see: n
WAN Failure (Authentication) Survivability on page 218
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 219
Enabling Authentication Survivability on a Local Branch Switch
You can configure each local branch switch to enable or disable Authentication Survivability; by default, this feature is disabled.
When authentication survivability is enabled, the enabled authentication survivability state is published, which instructs the Survival Server to start storing client access credential attributes and Key Reply attributes.
Configuring the Survival Server Certificate
A default server certificate is provided in the switch so that the local Survival Server can terminate EAP-TLS
802.1X requests.
Best practices is to import a customer server certificate into the switch and assign it to the local survival server.
Configuring the Lifetime of the Authentication Survivability Cache
All access credentials and Key Reply attributes that are saved in the local Survival Server remain in the system until they expire. The system-wide lifetime parameter auth-survivability cache lifetime has a range from 1 to 72 hours, and a default value of 24 hours. You must configure this parameter in each switch.
User Credential and Key Reply Attributes Are Saved Automatically
When a station is authenticated by an external authentication server, required access credential attributes and
Key Reply attributes are stored in the local Survival Server RADIUS database in an enabled authentication survivability AOS-Wswitch.
Expired User Credential and Key Reply Attributes Are Purged Automatically
At the switch, a timer task that runs every 10 minutes purges expired user credential attributes and Key Reply attributes that are stored in the Survival Server cache.
About the Survival Server
A local Survival Server runs on the switch to perform authentication functions, as well as EAP-termination using the RADIUS protocol.
The Survival Server consists of a turn-key FreeRADIUS server, plus MySQL database tables.
When authentication survivability is enabled, a FreeRADIUS server runs on the switch. The Survival Server is configured to accept RADIUS requests from the local host and retrieve the access credential and Key Reply attributes from the MySQL database. The Survival Server supports EAP-TLS, PAP, and Common Name (CN) lookup.
Trigger Conditions for Critical Actions
This section describes the trigger conditions for critical authentication survivability actions.
Storing User Access Credential and Key Reply Attributes to Survival Cache
Aruba OS stores the user access credential and Key Reply attributes under the following conditions:
1. Authentication survivability is enabled
2. The non-zero MAC-address client is authenticated using one of the following options: a. Authenticated with an External RADIUS server using PAP or EAP-TLS b. Authenticated with an External LDAP server using PAP c. Successful query on Common Name (CN) with an External RADIUS or LDAP server
220 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Picking Up the Survival Server for Authentication
The Survival Server performs an authentication or query request when authentication survivability is enabled, and one of the following is true:
1. All servers are out of service in the server group if fail-through is disabled
2. All in-service servers failed the authentication and at least one server is out of service when fail-through is enabled.
Access Credential Data Stored
In addition to the username, the following access credential data is stored: n n n
Password Authentication Protocol (PAP): authmgr receives the password provided by the client and then stores the encrypted SHA-1 hashed value of the password.
When employing 802.1X with disabled termination using EAP-TLS, the EAP indicator is stored.
The CN lookup EXIST indicator is stored.
Authentication for Captive Portal Clients
This section describes the authentication procedures for Captive Portal clients us, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.
This section describes the following authentication scenarios: n n
Captive Portal clients authentication using Password Authentication Protocol (PAP)
External Captive Portal clients authentication using the XML-API
Captive Portal Client Authentication Using PAP
describes what occurs for Captive Portal clients using PAP as the authentication method.
Table 56: Captive Portal Authentication Using PAP
When Authentication Servers Are
Available n n
If authentication succeeds, the associated access credential with an encrypted SHA-1 hash of the password and Key Reply attributes are stored in the Survival Server database.
If authentication fails, the associated access credential and Key Reply attributes associated with the PAP method (if they exist) are deleted from the Survival Server database.
When Authentication Servers Are Not Available
When no in-service server in the associated server group is available, the Survival Server is used to authenticate the Captive portal client using PAP.
The Survival Server uses the previously stored unexpired access credential to perform authentication and, upon successful authentication, returns the previously stored Key Reply attributes.
External Captive Portal Client Authentication Using the XML-API
describes the authentication procedures for External Captive Portal clients using the XML-API, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 221
Table 57: Captive Portal Authentication Using XML-API
When Authentication Servers Are Available
For authentication requests from an External Captive
Portal using the XML-API, PAP is used to authenticate these requests with an external authentication server.
n
If authentication succeeds, the associated access credential with an encrypted SHA-1 hash of the password and Key Reply attributes are stored in the
Survival Server database.
n If authentication fails, the associated access credential and Key Reply attributes associated with the PAP method (if they exist) are deleted from the
Survival Server database.
When Authentication Servers Are Not
Available
When no in-service server in the associated server group is available, the Survival Server is used to authenticate the Captive portal client using PAP.
The Survival Server uses the previously stored unexpired access credential to perform authentication and, upon successful authentication, returns the previously stored
Key Reply attributes.
Authentication for 802.1X Clients
This section describes the authentication procedures for 802.1X clients, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the
Survival Server takes over the handling of authentication requests.
For 802.1X clients, the authentication scenarios include two different 802.1X termination modes: n n
802.1X termination disabled at the Wireless LAN Switch
802.1X termination enabled at the Wireless LAN Switch
802.1X Termination Disabled at the Wireless LAN Switch
Table 58: 802.1X Authentication Using EAP-TLS
When Authentication Servers Are Available
For an 802.1X client that terminates at an external RADIUS server using EAP-TLS: n If authentication is accepted, the associated access credential with the EAP-TLS indicator, in addition to the
Key Reply attributes, are stored in the Survival Server database.
n If authentication is rejected, the associated access credential and Key Reply attributes associated with the
EAP-TLS method (if they exist) are deleted from the
Survival Server database.
When Authentication Servers Are Not
Available
When there is no available in-service server in the associated server group, the Survival Server terminates and authenticates 802.1X clients using
EAP-TLS.
The Survival Server uses the previously stored unexpired access credential to perform authentication and, upon successful authentication, returns the previously stored Key Reply attributes.
In this case, the client station must be configured to accept the server certificate assigned to the Survival
Server.
802.1X Termination Enabled at the Wireless LAN Switch
For an 802.1X client for which termination is enabled at the wireless LAN switchusing EAP-TLS with Common
Name (CN) lookup, a query request about the Common Name is sent to the external authentication server.
The external authentication server can be either a RADIUS server or an LDAP server.
222 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Table 59: 802.1X Client Authentication Using EAP_TLS with CN Lookup
When Authentication Servers Are Available n n
If the query succeeds, the associated access credential with a returned indicator of EXIST , plus the Key Reply attributes, are stored in the Survival Server database.
If the query fails, the associated access credential and
Key Reply attributes associated with the Query method
(if they exist) are deleted from the Survival Server database.
When Authentication Servers Are Not
Available
When there is no available in-service server in the associated server group, the Survival Server performs CN lookup for 802.1X clients for which termination is enabled at the switch using EAP-TLS.
The Survival Server returns previously stored Key
Reply attributes as long as the client with the EXIST indicator is in the Survival Server database.
Authentication for MAC Address-Based Clients
This section describes the authentication procedures for MAC address-based clients, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.
Table 60: MAC-Based Client Authentication Using PAP
When Authentication Servers Are Available n n
If authentication succeeds, the associated access credential, along with an encrypted SHA-1 hash of the password and Key Reply attributes, are stored in the
Survival Server database.
If authentication fails, the associated access credential and Key Reply attributes associated with the PAP method (if they exist) are deleted from the Survival
Server database.
When Authentication Servers Are Not
Available
When there is no available in-service server in the associated server group, the Survival Server authenticates the MAC-based authentication client using PAP.
The Survival Server returns previously stored Key
Reply attributes as long as the client with the EXIST indicator is in the Survival Server database.
Authentication for WISPr Clients
This section describes the authentication procedures for Wireless Internet Service Provider roaming (WISPr) clients, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.
The external authentication server can be either a RADIUS server or an LDAP server.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 223
Table 61: WISPr Authentication Using PAP
When Authentication Servers Are Available
For a WISPr client authenticated by an external server using
PAP: n n
If authentication succeeds, the associated access credential, along with an encrypted SHA-1 hash of the password and Key Reply attributes, are stored in the
Survival Server database.
If authentication fails, the associated access credential and Key Reply attributes (if they exist) associated with the PAP method are deleted from the Survival Server database.
When Authentication Servers Are Not
Available
When there is no available in-service server in the associated server group, the Survival Server authenticates the WISPr client using PAP.
Upon successful authentication, the Survival Server uses the previously stored unexpired credential to perform authentication, and returns the previously stored Key Reply attributes .
WAN Health Check
The health-check feature uses ping-probes to measure WAN availability and latency on selected uplinks. Based upon the results of this health-check information, the switch can continue to use its primary uplink, or failover to a backup link. Latency is calculated based on the round-trip time (RTT) of ping responses. The results of this health check appear in the WAN section of the
For details on configuring this feature using the Smart Config WebUI, see
.
WAN Optimization through IP Payload Compression
Data compression reduces the size of data frames that are transmitted over a network link, thereby reducing the time required to transmit the frame across the network. IP payload compression is one of the key features of the WAN bandwidth optimization solution, which is comprised of the following elements: n n n
IP Payload Compression
Traffic Management and QoS
Caching
Since the branch switch can send traffic to destinations other than the corporate headquarters on the same link, the preferred method is to enable payload compression on the IPsec tunnel between the branch switch and the master switch.
IP payload should be enabled only between Alcatel-Lucent devices. When this hardware-based compression feature is enabled, the quality of unencrypted traffic (such as Skype4b or Voice traffic) is not compromised through increased latency or decreased throughput.
Starting from AOS-W 6.5.1, WAN optimization through IP payload compression is supported in OAW-4450 switches.
Distributed Layer 3 Branch Deployment Model
In the branch deployment model shown in
, the IPsec tunnels are terminated on the master switch.
IPsec tunnels are treated as master-local tunnels.
Figure 40 Branch Deployment Model with Master Switch in HQ
224 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Modes of Operation
There are three modes of operation for the deflation and inflation compression processes: n n n
Static Compression
For static compression, a predefined Huffman code is used that may not be ideal for the block in question, but it usually achieves acceptable compression. The advantage of static compression is its speed of execution.
Dynamic Compression
The advantage of dynamic compression is a higher compression ratio. However, dynamic compression is slower than static compression, as it requires two passes to complete the process.
No Compression
You can use no compression for data such as an embedded image file that might already be in a compressed format. Such data does not compress well, and may even increase in size.
For details on configuring this feature using the Smart Config WebUI, see
WAN Configuration on page 251 .
Interface Bandwidth Contracts
OAW-40xx Series switches have the ability to classify and identify applications on the network. If a OAW-40xx
Series switch is configured as a branch office switch, you can create bandwidth contracts to limit traffic for individual applications (or categories of applications) either sent from or received by a selected interface. There are two basic models for using this feature.
n
Limiting lower-priority traffic : If there is a lower-priority application or application type that you want to limit, apply a bandwidth contract just to that application, and allow all other application traffic to pass without any limits.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 225
n
Protecting higher-priority traffic : If you want to guarantee bandwidth for a company-critical application or application group, you can add that application to an exception list, then apply a bandwidth contract to all remaining traffic.
You can apply bandwidth contracts using one or both of these models. Each interface supports up to 64 bandwidth contracts. An interface bandwidth contract is applied to downstream traffic before a user-role bandwidth contract is applied, and upstream traffic, the user-role bandwidth contract is applied before the interface bandwidth contract.
For all traffic using compression and encryption, bandwidth contracts are applied after that traffic is compressed and encrypted. If you apply more than one bandwidth contract to any specific category type, then the bandwidth contracts are applied in the following order.
1. A contract that explicitly excludes an application
2. A contract that explicitly excludes an application category
3. A contract that applies to a specific application
4. A contract that applies to a specific application category
5. A generic bandwidth contract, not specific to any application or application category
For details on configuring this feature using the Smart Config WebUI, see
WAN Configuration on page 251 .
App and App Category Visibility
WAN uplinks are typically of relatively low bandwidth. The actual upstream/downstream bandwidth that a
WAN uplink provides is usually different from what the service provider provides. Hence, ensure that the traffic transmitted by a Branch switch matches the actual rate provided by the service provider. This avoids congestion in the link from the Branch switch to the WAN. Congestion may cause traffic to be dropped and if the uplink has both high and low priority traffic, low priority traffic might not be dropped first. Hence, a Branch switch classifies traffic into multiple priorities and shapes the egress traffic to match the actual upstream bandwidth.
If there is any unused bandwidth in the downstream direction, a Branch switch allows the users to use the unused bandwidth although this bandwidth exceeds the allocation of the user. A Branch switch ensure this by using an ingress scheduler with minimum-bandwidth guarantees.
Minimum bandwidth guarantees are provided on per traffic class basis. Additional classification is done on the traffic flows and these are assigned newer traffic classes. Use hardware assist or software scheduler to schedule these new traffic classes to achieve minimum-bandwidth guarantees. Maximum bandwidth is enforced with bandwidth contracts.
Allocate higher bandwidth to critical applications and schedule them with higher priority.
Due to the wide range of bandwidth possibilities, percentages are used to provision bandwidth for the interface bandwidth contracts. Use the templates to configure multiple different bandwidth links across all
Branch switches. For example, 50 % for 500 Mbps for a 1 Gbps link or 50 mbps for a 100 mbps uplink.
On the WAN dashboard, for the AppRF window, currently the statistics/flows are detailed to view the AppRF stats on a per-uplink basis.
Branch Integration with a Palo Alto Networks (PAN) Portal
Branch switch deployments can leverage their networks' existing PaloAlto infrastructure to access more advanced security services, including antivirus services, malware detection and seamless integration with the
Palo Alto Networks WildFire
TM cloud-based threat detection.
226 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Enable Palo Alto firewall integration on a master switch to securely redirect internet inbound traffic from branch switches using the branch config group into the PAN firewall. Although this configuration setting can be used on standalone or local switches, this feature can only be used on switches in these types of deployments when used in conjunction with the switch uplink VLAN manager feature.
The uplink VLAN manager is enabled by default on branch switch uplinks. Master or local (non-branch) switches using the PAN portal feature must enable the uplink VLAN manager using the uplink command in the switch command-line interface.
Figure 41 Branch Switch and PAN Firewall Integration
Integration Workflow
The following steps describes the work flow to integrate a branch switch with a Palo Alto Networks (PAN) Large-
Scale VPN (LSVPN) firewall.
1. Palo Alto Portal certificates are installed on the master switch, and the master switch is configured with the
Palo Alto portal IP address or FQDN, Palo Alto certificate, and the username and password for device authentication using the Configuration> Branch > Smart Config > WAN section of the master switch
WebUI.
2. The OAW-40xx Series branch switch is provisioned via the basic setup dialog.
3. The Palo Alto portal may be configured with the device number (a text string comprised of the device serial number followed by its MAC address) of the branch switch(es) at each remote office site. This allows the branch switch to bypass the username and password challenge to authenticate to the portal.
4. The branch switch initiates a secure connection to the Palo Alto portal. Once the branch switch is authenticated, the Palo Alto portal sends the branch switch a list of PAN gateways and priority levels. Once the branch switch is authenticated, that device appears in the PAN satellite list, as shown in the figure below.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 227
Figure 42 Palo Alto Networks Active Satellites List
.
5. The branch switch uses the Palo Alto Networks gateway list and credentials from the portal to contact all
PAN gateways. Each PAN gateway sends the branch switch information that allows the branch switch to automatically create a secure IPsec tunnel and exchange branch subnet routes with each PAN gateway.
6. The branch switch maintains a priority list of IPsec tunnels to each PAN gateway to enable failover in the event a PAN gateway becomes unreachable.
7. Policy-based routing access control lists (ACLs) on the branch switch selectively routes traffic to the PAN gateways.
8. Traffic redirected from the branch switch is inspected via the Palo Alto Networks firewall.
Configuration Prerequisites
The Palo Alto Networks LSVPN framework can integrate with a branch switch by establishing an IPsec tunnels between the firewall and the switch. Integrating a Palo Alto Networks firewall with a OAW-40xx Series switch requires that all user traffic is routed, so it can be managed by a policy-based routing access control list.
The following certificate requirements must be fulfilled before the branch switch can integrate with the Palo
Alto Networks Large-Scale VPN (LSVPN) framework: n n n the LSVPN framework must be installed and active on your network. For more information on configuring
Palo Alto Networks products, refer to the Palo Alto Networks Technical Documentation portal .
The CA certificate used by the Palo Alto portal must be installed on the master switch, so that it can be pushed down to the branch switches.
On the PAN gateway devices, you must enable the accept published routes option, and the devices must install the server certificates derived from the management portal root CA.
In deployments with multiple PAN firewalls, you must configure the PAN management portal with a list of gateways and the priorities for each PAN gateway. Even if the PAN management portal uses serial number registration with preregistered serial numbers or MAC addresses, best practice is to configure LDAP, Radius,
Kerberos or Local Database authentication as well. This allows a switch to authenticate to the portal even if the portal does not recognize the switch's MAC address.
For details on configuring this feature using the Smart Config WebUI, see
WAN Configuration on page 251 .
228 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Branch Switch Routing Features
The following sections describe some of the features that can be configured using the Smart Config WebUI. For details on configuring these feature using the Smart Config WebUI, see
Routing Configuration on page 242 .
Uplink Routing Using Nexthop Lists
A next-hop IP is the IP address of a adjacent router or device with Layer-2 connectivity to the switch. If the switch uses policy-based routing to forward packets to a next hop device and that device becomes unreachable, the packets matching the policy will not reach their destination.
The nexthop list provides redundancy for the next-hop devices by forwarding the traffic to a backup next hop device in case of failures. If the active next-hop device on the list becomes unreachable, traffic matching a policy-based routing ACL is forwarded using the highest-priority active next-hop device on the list.
If preemptive failover is enabled and a higher priority next hop becomes reachable again, packets are again forwarded to the higher priority next-hop device.
For more information on creating a routing policy that references a nexthop list, see
Configuring Firewall Policies on page 375
.
A maximum of four next-hop device entries can be added to a nexthop list. Each next-hop device can be assigned a priority, which decides the order of selection of the next hop. If a higher priority next-hop device goes down, the next higher priority active next-hop device is chosen for forwarding.
If all the next-hop devices are configured with same priority, the order is determined based on the order in which they are configured. If all the next-hops devices are down, traffic is passed regular destination-based forwarding.
In a typical deployment scenario with multiple uplinks, the default route only uses one of the uplink next-hop devices for forwarding packets. If a next hop device becomes unreachable, the packets will not reach their destination.
If your deployment uses policy-based routing based on a nexthop list, any of the uplink next hop devices could be used for forwarding traffic. This requires a valid ARP entry (route-cache) in the system for all the policybased routing next-hop devices. Each switch supports up to 32 nexthop lists.
In a branch office deployment, the site uplinks can obtain their IP addresses and default gateway using DHCP.
In such deployments, the nexthop list configuration can use the VLAN IDs of uplink VLANs. If the VLAN gets an
IP address using DHCP, and the default gateway is determined by the VLAN interface, the gateway IP is used as the next-hop IP address.
Branch deployments may also require policy-based redirection of traffic to different VPN tunnels. The nexthop list allows you to select an IPsec map to redirect traffic through IPsec tunnels.
Policy-Based Routing
Policy-based routing is an optional feature that allows packets to be routed based on access control lists (ACLs) configured by the administrator. By default, when a switch receives a packet for routing, it looks up the destination IP in the routing table and forwards the packet to the next-hop router. If policy-based routing is configured, the nexthop device can be chosen based on a defined access control list.
In a typical deployment scenario with multiple uplinks, the default route only uses one of the uplink next-hop devices for forwarding packets. If a next-hop device becomes unreachable, the packets will not reach their destination. If your deployment uses policy-based routing based on a nexthop list, any of the uplink next-hop devices can be used for forwarding traffic. This requires a valid ARP entry (Route-cache) in the system for all the policy-based routing next hop devices.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 229
Inbound Interface Access Lists
In a branch switch environment, where an IPsec map defines the connections between the local branch switches and a master switch, the global routing ACL master-boc-traffic is applied to all IPsec maps between the master and the branch switches. If any branch switch requires a different ACL, access the command-line interface of that branch switch and issue the command routing-policy-map branch <mac-addr> accesslist <acl> to associate a different ACL to the L3 GRE tunnel between that one branch switch and its master.
This local setting will override the global settings defined in the master-boc-traffic ACL. For more information on configuring routing ACLs, see
Creating a Firewall Policy on page 376 .
To immediately associate a branch switch to the secondary master without waiting for the switchover timeout period to elapse, navigate to the Network>Switch>System settings page of the branch switch WebUI, and click the Switchover link.
If a branch switch detects that the link to the primary master switch is active but the branch cannot properly connect to the primary master due to a configuration error, the branch switch will wait for 10 minutes, then reboot and attempt to reconnect to the primary master. After 10 failed reboot and reconnect attempts, the branch switch will return to a factory default state and restart the provisioning process.
Cloud Management
AOS-W enables the OAW-40xx Series switches to be managed by Aruba Central at a future date.
All communication between the switches and Central will be secured. The switches can establish connection with Central even if the switches are behind NAT servers.
If the topology includes master and local switches, a single master switch can communicate with Central. In a master-local cluster topology, a local switch can communicate with both the master switch and Central. The master switch will be the source for configuration data of the local switches. Central manages the local configuration on the local switch.
Zero-Touch Provisioning
Traditionally, the deployment of switches was a multiple step process where the master switch information and local configurations were first pre-provisioned. After the local switch connected to the network, it established a secure tunnel to the master and downloaded the global configuration.
Zero touch provisioning makes the deployment of local switches plug-n-play. The local switch now learns the required information from the network and provisions itself automatically. A OAW-40xx Series branch switch is a zero-touch provision (ZTP) switch that automatically gets its local and global configuration and license limits from a central switch.
A switch does not need to be configured as a branch switch to be provisioned using ZTP.
ZTP offers the following advantages over a standard local switch: n n n simple deployment reduced operational cost limits to provisioning errors
The main elements of ZTP are: n n auto discovery of the primary master (and optionally, backup master) switch.
configuration download from the master switch
230 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Provisioning a switch includes completing the following: n n n setting the role setting the country code configuring the local configuration
The local configuration is the configuration that is specific to a switch. That is, not the global configuration shared by a network of switches. This includes, but is not limited to, IP addresses and VLANs.
Once the switch is provisioned, it is ready to obtain its global configuration either by: n n
The administrator entering the global configuration directly from the WebUI or CLI of a master switch
The switch retrieving the global configuration from a master switch
Previously the steps of setting the role, setting the country code, and configuring the local configuration could only be performed manually by an administrator. With ZTP, these steps can be automatically completed.
The local configuration that a branch switch retrieves through ZTP is called as branch config group.
A switch that is deployed using ZTP is called as branch switch.
Only the OAW-40xx Series cloud services switches may be deployed as branch switches.
Before you Begin
Before you deploy a OAW-40xx Series branch switch, use the smart config feature on the master switch to a create branch config group. The master switch can push a branch config group configuration to a branch switch when the branch becomes active on the network. The smart config feature is enabled by default. For more information on branch config group settings, refer to
Using Smart Config to create a Branch Config
The parameters of role, country code, and IP address of the master switch are collectively known as the provisioning parameters.
Provisioning Modes for Branch Deployments
The administrator has the choice of several provisioning modes that alter how the branch switch is supplied with its own IP address, role, country code, and branch config group.
During the various provisioning modes, the branch switch is supplied with the IP address of the primary master switch, or, for deployments requiring Layer-3 redundancy, the IP addresses of the primary and backup master switches. Once the branch switch learns the IP address of the primary master switch, the branch switch contacts the master switch and retrieves its branch config group.
Provisioning a switch means defining the following values for that device: n n n the role of the switch (master or branch) the country code local configuration settings
AOS-W supports the following provisioning modes for branch switches: n auto: In this mode, branch switch: l obtains its IP address from DHCP l l obtains its role, country code, and the IP addresses of the primary switch and any defined secondary switch from DHCP Options retrieves its branch config group from the primary master switch
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 231
n n mini-setup: In this mode, the branch switch: l l l has its role set to branch when mini-setup is initiated obtains its IP address from DHCP is configured through the console with its country code and the IP address of the primary master switch and (optionally) the secondary master switch IP.
l retrieves its branch config group from the primary master switch full-setup: In this mode, the branch switch: l l is configured with its role set to branch through the console is configured to obtain its IP address through manual configuration of a static IP, DHCP, or PPPoE l l is configured through the console with its country code and the IP address of the primary master switch and (optionally) the secondary master switch IP retrieves its branch config group from the primary master switch
Automatically Provisioning a Branch Switch
When a factory-default branch switch boots, it starts the auto-provisioning process.
First it will obtain its IP address through DHCP by sending a DHCP discover on the default uplink port. The default uplink port is configured as an access port in VLAN 4094.
To interrupt the auto provisioning process, enter the string mini-setup or full-setup at the initial setup dialog prompt shown below.
Auto-provisioning is in progress. Choose one of the following options to override or debug...
'enable-debug' : Enable auto-provisioning debug logs
'disable-debug': Disable auto-provisioning debug logs
'mini-setup' : Stop auto-provisioning and start mini setup dialog for smart-branch role
'full-setup' : Stop auto-provisioning and start full setup dialog for any role
Enter Option (partial string is acceptable):_
DHCP Options
When the branch switch sends the DHCP discover message to obtain its IP address, it adds a DHCP option 60 b
Vendor Class Identifier to that DHCP discover message, where DHCP Option 60 is set to “ArubaMC”.
If the DHCP Offer does have DHCP Option 60 = ArubaMC, the branch switch will accept the DHCP lease and send a DHCP request. It will also look for DHCP Option 43 – Vendor Specific Information in the DHCP Lease. If
DHCP Option 43 is present in the Offer, the branch switch will parse it to learn the provisioning parameters.
The role is not explicitly specified in DHCP Option 43. However, the switch will set its Role to branch if the other provisioning parameters are present in DHCP Option 43.
If the DHCP Offer does not have DHCP Option 60 = ArubaMC, the branch switch will still accept the DHCP lease and send a DHCP request. However, once it is bound to the IP address, it will initiate the next mode of autoprovisioning and query for a provisioning rule.
DHCP Server Provisioning
The branch switch adds ArubaMC as a DHCP option-60 vendor class identifier in its DHCP discovery messages, so the DHCP offer from the server must include ArubaMC as a DHCP option-60 vendor class identifier. The switch gets the master information and country code from the DHCP server, which is configured with the master information corresponding to that identifier. The server may also send vendor-specific information (VSI
- option 43) in its response to the switch.
Before you deploy a branch switch using ZTP, configure the DHCP server with the following information: n
The option-60 vendor class identifier ArubaMC
232 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
n
Option-43 Vendor Specific Information (VSI) with the primary master IP address, the country code, and optionally, a secondary master IP (for deployments requiring Layer-3 redundancy). This VSI must be in one of the following formats, where the IP address of a master switch is in dotted-decimal notation (a.b.c.d) format or a fully qualified domain name format (master.example.com), and the country code contains a valid ISO 3166 country codes, such as US , AU , or IN l l l
<Master-IP-address>
<Master-ip-address>,<Country-code>
<Primary-master-IP-address>, <Country-Code>,<Secondary-master-IP-address>
Using Smart Config to create a Branch Config Group
Before you begin to configure a branch config group for individual branch switches, you must select a master switch to serve as the master for a group of branch switches on a network. A switch can act either as a master or a branch switch, but not both.
Any change to an active branch switch’s DHCP pool configuration causes the branch switch to reboot.
Only OAW-4x50 Series switches can server as a master switch for a group of branch switches on a network.
Create and configure a branch config group on a master switch by navigating to the Configuration >
BRANCH > Smart Config section of the master switch WebUI. The Smart Config page contains eight tabs for configuring the branch config group settings.
The BRANCH > Smart Config section of the master switch WebUI is available on the OAW-4x50 Series switches only.
The configuration parameter on each of these tabs are described in the following pages: n n n n n n n n
Config Group Management Settings on page 233
System Configuration on page 237
Networking Configuration on page 240
Routing Configuration on page 242
Branch Config Group Summary on page 254
Whitelist Configuration on page 254
Config Group Management Settings
Use this tab to create a new branch config group, select the model of branch switch to which this config group will be applied, and choose either the Static or Dynamic IP address management option for your deployment.
Address Pools
Each branch switch must have a pool of addresses it can dynamically assign to APs or users on each of its
VLANs, and a separate IP address that branch switch uses to create a GRE tunnel to the master switch. Branch switch VLAN pools and the tunnel pool are defined on the master switch. Branch switch address pools are
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 233
pushed out to each branch switch when it comes up on the network. If a branch switch is removed from the master, the IP addresses allocated to that branch switch can be reused and reassigned to a new branch switch.
A master switch must have a separate VLAN pool defined for each VLAN used by its branch switch. A VLAN pool allocates a static, continuous block of multiple IP addresses to each branch switch. The branch switch acts as a
DNS proxy server and dynamically assign IP addresses from its allocated pool to each AP or client on the VLAN.
The tunnel pool on a branch switch defines a range of IP addresses that the branch switch uses to create a GRE tunnel within the IPsec tunnel back to the master switch. Unlike VLAN pools, which allocates multiple addresses to each branch switch VLAN, the tunnel DHCP pool assigns a single tunnel IP address to each branch switch.
Static vs Dynamic IP Management
If you choose the dynamic IP management option, you must define one or more IP address pools with a range of sharable addresses. The master switch then divides each IP address pool into unique subnets that can support the required number of clients per branch, and assigns one of these subnet to each branch switch.
If a branch deployment has existing IP addressing that needs to be preserved (for example, the printers at a branch office have static IP addresses), then the branch config group should use static IP addressing. When you create a branch config group that uses static IP addressing, you must export the AOS-W static IP addressing template from the master switch, define the IP settings for the devices that need a static IP address within that template, then import the template file back into a branch config group.
Starting from AOS-W 6.5, the ZTP feature is enhanced to support 16 VLANs per branch switch as against just four in the earlier versions of AOS-W. Except this VLAN enhancement, all the other configurations for the ZTP feature remain the same as in previous AOS-W versions.
The Bulk Edit template (in Excel sheet) on the branch switch allows you to specify the static IP assignment for individual branch switch devices. The static IP configuration is maintained in this Bulk Edit CSV file, with each line in the file representing the settings for a specific branch switch device. To support this enhancement, the
Bulk Edit Excel sheet (.CSV format) is now expanded to allow for addition of up to 16 VLANs for each branch switch.
The DHCP pools for the VLANs will have settings for the following parameters: pool name, domain name, domain name server, VLAN ID, IP address, mask, and the IP address exclude list.
To create a new branch config group:
1. Navigate to Configuration > Branch > Smart Config and select the Management tab.
2. Click the New button under the branch config group list. You are prompted to enter a name for the new branch config group profile.
3. Click OK .
4. Next, click the Model drop-down list and select the model type of your branch switches. Each profile can support a single switch model .
5. Click the IP Address Management drop-down list and select the Static or Dynamic option.
6. If you select Dynamic , each branch office switch will get an IP address using DHCP.
7. If you select Static , the WebUI gives you the option to select export and download the static IP address template export-RemoteNode.csv
, or select import and upload a completed static IP address .csv file.
8. Click Apply to save your settings.
The export-RemoteNode.csv
template defines the following settings for each branch switch in the branch config group. Complete the template by adding information for up to 16 IP address pools for each branch switch.
234 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Table 62: Branch Config Group Template Setting
Parameter Description
MAC Address MAC address of the switch.
Description
Time Zone
DST
Pool
Domain
DNS
Vlan
Vlan IP
Mask
Exclude List
IP Helper
A brief description of the switch
A text string indicating the switch's time zone.
NOTE: This string must contain three or more characters of a supported time zone in any of the formats described in
HongKong or UTC+08 or CCT .
Specify ON or OFF to indicate if the switch's time zone is currently using daylight savings time.
Name of an IP address pool. The template supports up to four different address pools, so different address pools can be used for APs, employees, or guest users.
Name of the branch switch domain.
IP address of the DNS server.
ID of the branch switch VLAN.
IP address of the branch switch
Netmask of the branch switch network.
A comma-separated list of IP addresses or IP address ranges that should not be assigned to clients associated to that branch switch. For example, 15.15.15.11-
15.15.15.20,15.15.15.25,15.15.15.31-15.15.15.40.
DHCP server relay agent IP address.
The new branch config group appears in the Branch Config Group List table. This table displays the branch config group name, validated/not validated status, and reboot status for each branch config group.
n n
Status : A status of Validated indicates that the branch config group has a complete configuration that can be applied to branch switches. (For example, a branch config group might have a status of Not Validated if the branch config group does not have a IP address defined for the switch or a switch VLAN interface.)
Reboot Required : This field indicates that the branch config group includes a configuration change that requires a reboot on the branch switches using that config group.
The table below describes the time zone formats supported by the export-RemoteNode.csv
template. Each line in the table describes three or more time zone formats for a single location, though only one is required for the template. For example, specify Edinburgh or UTC+00 or UTC or BST .
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 235
Table 63: Supported Branch Config Group Time Zone Formats
UTC- Time Zones UTC+ Time Zones n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n
"International-Date-Line-West", "UTC-12",
"American-Samoa", "UTC-11", "SST"
"Hawaii", "UTC-10", "HST"
"Alaska", "UTC-09", "AKST"
"Baja-California", "UTC-08", "PST"
"Pacific-Time", "UTC-08", "PST"
"Arizona", "UTC-07", "MST"
"Chihuahua", "UTC-07", "MST"
"La-Paz", "UTC-07", "MST"
"Mazatlan", "UTC-07", "MST"
"Mountain-Time", "UTC-07", "MST"
"Central-America", "UTC-06"
"Central-Time", "UTC-06", "CST""CDT"
"Guadalajara", "UTC-06", "CST", "CDT"
"Mexico-City", "UTC-06", "CST", "CDT"
"Monterrey", "UTC-06", "CST", "CDT"
"Saskatchewan", "UTC-06", "CST"
"Bogota", "UTC-05", "EST"
"Lima", "UTC-05", "EST"
"Quito", "UTC-05", "EST"
"Eastern-Time", "UTC-05", "EST" "EDT"
"Indiana(East)", "UTC-05", "EST" "EDT"
"Caracas", "UTC-04:30", "VET"
"Asuncion", "UTC-04", "AST" "PYST"
"Atlantic-Time(Canada)", "UTC-04", "AST" "ADT"
"Cuiaba", "UTC-04", "AST","AMST"
"Georgetown", "UTC-04", "AST"
"Manaus", "UTC-04", "AST"
"San-Juan", "UTC-04", "AST"
"Santiago", "UTC-04", "AST", "SAND"
"Newfoundland", "UTC-03:30", "NST", "NDT"
"Brasilia", "UTC-03", "BST" "BRAD"
"Buenos-Aires", "UTC-03", "BST", "ARST"
"Cayenne", "UTC-03", "BST"
"Fortaleza", "UTC-03", "BST"
"Greenland", "UTC-03", "BST", "GRED"
"Montevideo", "UTC-03", "BST," "UYST"
"Salvador", "UTC-03", "BST", "BRST"
"Mid-Atlantic", "UTC-02", "FNT"
"Azores", "UTC-01", "AZOST", "AZOST"
"Cape-Verde-Is", "UTC-01", "CVT"
"Casablanca", "UTC+00", "UTC",
"Coordinated-Universal-Time", "UTC+00", "UTC",
"Dublin", "UTC+00", "UTC", "IST"
"Edinburgh", "UTC+00", "UTC", "BST"
"Lisbon", "UTC+00", "UTC", "WEST"
"London", "UTC+00", "UTC", "BST"
"Monrovia", "UTC+00", "UTC",
"Reykjavik", "UTC+00", "UTC",
"Amsterdam", "UTC+01", "CET", "CEST"
"Berlin", "UTC+01", "CET", "CEST"
"Bern", "UTC+01", "CET", "CEST"
"Rome", "UTC+01", "CET", "CEST"
"Stockholm", "UTC+01", "CET", "CEST"
"Vienna", "UTC+01", "CET", "CEST"
"Belgrade", "UTC+01", "CET", "CEST"
"Bratislava", "UTC+01", "CET", "CEST"
"Budapest", "UTC+01", "CET", "CEST"
"Ljubljana", "UTC+01", "CET", "CEST"
"Prague", "UTC+01", "CET", "CEST" n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n
"Casablanca", "UTC+00", "UTC",
"Coordinated-Universal-Time", "UTC+00", "UTC",
"Dublin", "UTC+00", "UTC", "IST"
"Edinburgh", "UTC+00", "UTC", "BST"
"Lisbon", "UTC+00", "UTC", "WEST"
"London", "UTC+00", "UTC", "BST"
"Monrovia", "UTC+00", "UTC",
"Reykjavik", "UTC+00", "UTC",
"Amsterdam", "UTC+01", "CET", "CEST"
"Berlin", "UTC+01", "CET", "CEST"
"Bern", "UTC+01", "CET", "CEST"
"Rome", "UTC+01", "CET", "CEST"
"Stockholm", "UTC+01", "CET", "CEST"
"Vienna", "UTC+01", "CET", "CEST"
"Belgrade", "UTC+01", "CET", "CEST"
"Bratislava", "UTC+01", "CET", "CEST"
"Budapest", "UTC+01", "CET", "CEST"
"Ljubljana", "UTC+01", "CET", "CEST"
"Prague", "UTC+01", "CET", "CEST"
"Brussels", "UTC+01", "CET", "CEST"
"Copenhagen", "UTC+01", "CET", "CEST"
"Madrid", "UTC+01", "CET", "CEST"
"Paris", "UTC+01", "CET", "CEST"
"Sarajevo", "UTC+01", "CET", "CEST"
"Skopje", "UTC+01", "CET", "CEST"
"Warsaw", "UTC+01", "CET", "CEST"
"Zagreb", "UTC+01", "CET", "CEST"
"West-Central-Africa", "UTC+01", "CET"
"Windhoek", "UTC+01", "CET", "WAST"
"Amman", "UTC+02", "EET", "EEST"
"Athens", "UTC+02", "EET," "EEST"
"Bucharest", "UTC+02", "EET," "EEST"
"Beirut", "UTC+02", "EET", "EEST"
"Cairo", "UTC+02", "EET"
"Damascus", "UTC+02", "EET", "EEST"
"East-Europe", "UTC+02", "EET", "EEST"
"Harare", "UTC+02", "EET"
"Pretoria", "UTC+02", "EET"
"Helsinki", "UTC+02", "EET" "EEST"
"Istanbul", "UTC+02", "EET" "EEST"
"Kyiv", "UTC+02", "EET" "EEST"
"Riga", "UTC+02", "EET" "EEST"
"Sofia", "UTC+02", "EET" "EEST"
"Tallinn", "UTC+02", "EET" "EEST"
"Vilnius", "UTC+02", "EET" "EEST"
"Jerusalem", "UTC+02", "EET" "IST"
"Baghdad", "UTC+03", "MSK"
"Minsk", "UTC+03", "MSK"
"Kuwait", "UTC+03", "MSK"
"Riyadh", "UTC+03", "MSK"
"Nairobi", "UTC+03", "MSK"
"Tehran", "UTC+03:30", "IRST"
"Abu-Dhabi", "UTC+04", "GST"
"Muscat", "UTC+04", "GST"
"Baku", "UTC+04", "GST" "AZST"
"Moscow", "UTC+04", "GST"
"St.Petersburg", "UTC+04", "GST"
"Volgograd", "UTC+04", "GST"
"Port-Louis", "UTC+04", "GST"
"Tbilisi", "UTC+04", "GST"
236 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Table 63: Supported Branch Config Group Time Zone Formats
UTC- Time Zones UTC+ Time Zones n n n n n n n n n n n n n n n n n n
"Brussels", "UTC+01", "CET", "CEST"
"Copenhagen", "UTC+01", "CET", "CEST"
"Madrid", "UTC+01", "CET", "CEST"
"Paris", "UTC+01", "CET", "CEST"
"Sarajevo", "UTC+01", "CET", "CEST"
"Skopje", "UTC+01", "CET", "CEST"
"Warsaw", "UTC+01", "CET", "CEST"
"Zagreb", "UTC+01", "CET", "CEST"
"West-Central-Africa", "UTC+01", "CET"
"Windhoek", "UTC+01", "CET" "WAST"
"Amman", "UTC+02", "EET" "EEST"
"Athens", "UTC+02", "EET" "EEST"
"Bucharest", "UTC+02", "EET" "EEST"
"Beirut", "UTC+02", "EET" "EEST"
"Cairo", "UTC+02", "EET"
"Damascus", "UTC+02", "EET" "EEST"
"East-Europe", "UTC+02", "EET" "EEST"
"Harare", "UTC+02", "EET" n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n
"Yerevan", "UTC+04", "GST"
"Kabul", "UTC+04:30", "AFT"
"Islamabad" ,"UTC+05", "PKT"
"Karachi" ,"UTC+05", "PKT"
"Tashkent" ,"UTC+05", "PKT"
"Chennai" ,"UTC+05:30", "IST"
"Kolkata" ,"UTC+05:30", "IST"
"Mumbai" ,"UTC+05:30", "IST"
"New-Delhi" ,"UTC+05:30", "IST"
"Sri-Jayawardenepura", "UTC+05:30", "IST"
"Kathmandu", "UTC+05:45", "NPT"
"Astana", "UTC+06", "BTT"
"Dhaka", "UTC+06", "BTT"
"Ekaterinburg", "UTC+06", "BTT"
"Yangon", "UTC+06:30", "MMT"
"Bangkok", "UTC+07", "THA"
"Hanoi", "UTC+07", "THA"
"Jakarta", "UTC+07", "THA"
"Novosibirsk", "UTC+07", "THA"
"Beijing" ,"UTC+08", "CCT"
"Chongqing" ,"UTC+08", "CCT"
"Hong Kong" ,"UTC+08", "CCT"
"Krasnoyarsk" ,"UTC+08", "CCT"
"Kuala-Lumpur", "UTC+08", "CCT"
"Perth", "UTC+08", "CCT"
"Singapore", "UTC+08", "CCT"
"Taipei", "UTC+08", "CCT"
"Urumqi" ,"UTC+08", "CCT"
"Ulaanbaatar", "UTC+08", "CCT"
"Irkutsk", "UTC+09", "JST"
"Osaka", "UTC+09", "JST"
"Sapporo", "UTC+09", "JST"
"Tokyo", "UTC+09", "JST"
"Seoul", "UTC+09", "JST"
"Adelaide", "UTC+09:30", "ACST" "CST"
"Darwin", "UTC+09:30", "ACST"
"Brisbane", "UTC+10", "AEST"
"Canberra","UTC+10", "AEST"
"Melbourne","UTC+10", "AEST"
"Sydney","UTC+10", "AEST"
"Guam", "UTC+10", "AEST"
"Port-Moresby", "UTC+10",
"Hobart" ,"UTC+10", "AEST"
"Yakutsk", "UTC+10", "AEST"
"Solomon-Is.", "UTC+11", "NST"
"New-Caledonia", "UTC+11", "NST"
"Vladivostok", "UTC+11", "NST"
"Auckland", "UTC+12", "NZT"
"Wellington", "UTC+12", "NZT"
"Fiji", "UTC+12", "NZT"
"Magadan", "UTC+12"
"Nukualofa", "UTC+13"
"Samoa", "UTC+13"
System Configuration
Configure general system settings for the branch switches in a branch config group by navigating to
Configuration > Branch > Smart Config and selecting the System tab. The settings on the System tab are described in the table below.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 237
Figure 43 Branch Config Group System Settings
Parameter Description
General
System Contact
Admin User
An alphanumeric string that specifies the name of the system contact for the switch
The name of a system admin user
Admin Password The password for the system admin user
Servers
OmniVista
Server
Syslog Server
(Optional) IP address of the OmniVista server, if the branch office switch is managed or monitored by OmniVista.
(Optional) IP address of an external syslog server. You will define syslog facility levels in subsequent configuration fields on this page.
IP address of the domain server.
Domain Name
Server
Domain name (Optional) Default domain name to be used by the branch switches. The branch switches use the default domain name to complete hostnames that do not contain domain names.
(Optional) Certificate to be used for captive-portal authentication.
Captive Portal
Server
Certificate
Time Zone
RADIUS interface source
VLAN
Time zone for the branch office switch. Click the DST checkbox if the selected timezone is currently using daylight-savings time.
This field identifies the interface for outgoing RADIUS packets. The IP address of the specified interface is included in the IP header of RADIUS packets.
Advanced Settings
Master L3
Redundancy
Switchover
Timeout
If the branch switch is configured with a primary and a secondary master switch, this switchover period defines the number of minutes that a branch switch will wait before switching its master switch from an unreachable primary switch to the backup switch.
n n
Range: 15 - 60 minutes
Default: 15 minutes
NOTE: This timeout period does not apply if a user manually switches a branch switch from a primary to a secondary master switch by clicking the Switchover link on the Network > Switch
> System settings page of the branch switch WebUI.
firewall-visibility (Optional) Enable or disable the firewall visibility feature. For more information, see
AppRF (Optional) Enable or disable the AppRF feature. For more information, see
.
URL Filtering
Mark
Management
Frames
(Optional) Enable Web Content Classification. For more information, see
.
(Optional) Enable or disable the marking of IPsec mangement frames. This option is disabled by default.
238 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Parameter
Jumbo
Management
Frames
Description
(Optional) Enable or disable jumbo Ethernet frames on branch office switch ports. If you enable this feature, you must define the Maximum Transmission Unit (MTU) for these frames. The supported range is 1789 to 9612 bytes.
Skype4B Listen
Port
(Optional) AOS-W provides value-added services such as prioritization of Lync/Skype for
Business sessions, call quality metrics, and visibility by implementing Lync/Skype for Business
Application Layer Gateway (ALG). Use this parameter to define the Lync/Skype for Business listening port. For more information, see
Configuring the Lync/Skype for Business Listening Port on page 948
.
AirGroup (Optional) Enable or disable the AirGroup feature on the branch office switch. For more information on AirGroup, see
.
AirGroup MDNS (Optional) Enable or disable support for multicast Domain Name System (mDNS) service records. For more information, see
Zero Configuration Networking on page 994 .
AirGroup DLNA (Optional) Enable or disable support for DLNA (Digital Living Network Alliance); a network standard that is derived from UPnP (Universal Plug and Play) in addition to the mDNS protocol.
For more information, see
Zero Configuration Networking on page 994
.
Syslog Facility Levels
Network
Security
System
User
Wireless
(Optional) Click the syslog facility levels drop-down lists to change the severity level at which the different types of syslog messages are logged. By default, all message types are logged at the warnings level.
Revocation CheckPoints
CA Cert (Optional) The branch switch can act as an OCSP client and issue OCSP queries to remote OCSP responders located on the intranet or Internet. If you have uploaded an OCSP responder certificate to the master switch, click Edit to modify the certificates used to sign OCSP for the revocation check point. For more information on configuring a switch as an OCSP client, see
Configuring the Switch as an OCSP Client on page 299 .
SNMP
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 239
Parameter
Community
Strings for
SNMPv1 and
SNMPv2
Trap Receiver
Description
Enter community string to authenticate SNMPv1 and SNMPv2 requests. For more information on SNMP settings, see
.
SNMPv3 Users
Enter host information about a SNMP trap receiver that can receive and interpret the traps sent by the switch. Click New , enter the following types of trap information, then click Add .
n
IP address: Trap receiver IP address n n
SNMP version: SNMPv1,SNMPv 2c, or SNMPv3.
Security Name: SNMP security name string n n n
Engine ID: Engine ID of SNMP server in hexadecimal format. (SNMPv3 only)
UDP Port: UDP port on which the trap receiver listens for traps. The default is the UDP port number 162.
Type: Specify whether the switch can send inform messages to the trap receiver to acknowledge traps. (SNMPv2c or SNMPv3 only) n Retry: If the switch is configured to send inform messages, this field specifies the number of times the switch will retry sending inform messages to the trap receiver before giving up.
n Timeout: Estimated round trip time to the trap receiver, in seconds.
For more information on SNMP settings, see
.
Information about SNMPv3 users. Click New to open a message box that allows you to enter the following information types, then click Add .
n n
User: A string representing the name of the SNMP user.
Authentication Protocol: Select either MD5 or SHA authentication n n
Authentication Password: Authentication key for use with the SHA authentication protocol.
Privacy Protocol: Select either AES or DES encryption.
n Privacy Password: Privacy key for encrypted messages.
For more information on SNMP settings, see
.
Networking Configuration
Configure user and uplink VLANs for the branch switches in a branch config group, map named VLANs to one ore more VLAN IDs, define branch config group port settings and tunnels, and enable or disable the Spanning
Tree Protocol (STP) by navigating to Configuration>Branch>Smart Config and selecting the Networking tab.
Use the configuration settings on the Networking tab to configure the PortFast and BPDU Guard features for a branch config group. For complete details on these features, see
PortFast and BPDU Guard on page 254 .
The settings on the Networking tab are described in the table below.
Figure 44 Branch Switch Networking Settings.
Parameter Description
User VLANs
VLAN ID
Description
Identifier for the VLAN.
Text string describing the VLAN.
240 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Parameter
NAT Inside
Nat Outside
Description
Click this checkbox to enable source NAT for this VLAN. When applied, NAT is applied to both outbound and non-public, inter-VLAN traffic, with the desired IP address of the VLAN interface as the source address.
Starting in AOS-W 6.4.4.0, click this checkbox to enable destination NAT for this VLAN. With this option, NAT is applied only to outbound traffic with the IP address of the VLAN interface as the source address. Non-public, inter-VLAN traffic which is routed locally remains unaffected.
BCMC Optimization Click this checkbox to effectively prevent flooding of BCMC traffic on all VLAN member ports.
This option ensures controlled flooding of BCMC traffic without compromising the client connectivity.
Operstate Click this checkbox to select the operational state for the VLAN ( Up or Down ).
IP Address Select one of the following parameters from the drop-down list to allow a VLAN to get an
IP address using DHCP: n n dhcp-client - The VLAN to select the IP address from the DHCP server, if this option is selected.
dhcp-pool - A static IP address is assigned to the vlan based on the configured dhcp pools in the Routing tab, if this option is selected.
Named VLAN Mapping
Name Name assigned to an individual VLAN or group of VLANs (a VLAN pool).
VLAN Specify one or more VLAN IDs to associate the VLAN ID(s) to the VLAN name. For more information on configuring named VLANs, see
Configuring VLANs on page 105 .
Uplink VLANs
VLAN ID
Priority
Description
Operstate
IP Address
Ports
Specify the VLAN ID of the wired uplink network connection used by the branch switch.
Specify the priority of the VLAN by selecting a value from 101-255.
(Optional) text string used to describe the VLAN
Identify the VLAN operational state as UP or DOWN.
Specify whether the VLAN will receive its IP address using DHCP or PPPoE.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 241
Parameter
Port Settings: n n n n n n n n n n n
Port Enable
Enable
Description
Trusted
Speed/Duplex
Mode
Native VLAN
Trunk/Access
VLAN
PortFast
BPDU Guard
Tunnels
Description
Click Edit to edit the settings for an individual interface port, or to apply an access control list
(ACL) to inbound traffic, outbound traffic, or session traffic on a selected VLAN.
NOTE: For complete details on the PortFast and BPDU Guard features, see
. For more information on configuring the port settings for branch switches in a branch config group, see
and
Roles and Policies on page 375
.
Tunnel settings: n n n n n n n
Tunnel ID
Source IP
Destination IP
Mode
Keepalive
MTU
Trusted
AOS-W supports generic routing encapsulation (GRE) tunnels between the branch switch and
APs. To define tunnel settings for the branch switches using this branch config group, click
New , select your tunnel settings, then click nel configuration parameters, see
Spanning Tree Configuration
Add . For more information on individual GRE tun-
Configuring GRE Tunnels on page 115 .
Spanning Tree
Enabled
Spanning Tree Protocol (STP) can ensure a single active path between any two network nodes, thus avoiding bridge loops. Select this checkbox to enable spanning tree if you are employing STP in your network.
Routing Configuration
Use this tab to configure static routes and DHCP pools, policy-based routing, and uplink routing using nexthop lists.
Configuring Routing for a Branch Config Group
To configure the different routing settings for a branch config group, select the Routing sub-tab to configure the switch IP and NAS-IP VLANs, static routes and DHCP pools, then optionally click the PBR sub tab to configure policy-based routing (PBR) settings such as nexthop lists and PBR rules and targets.
Switch IP
A valid branch config group requires a VLAN to be assigned to the switch IP address. To assign an VLAN to a switch IP:
1. Navigate to Configuration>Branch>Smart Config>Routing and select the Routing sub-tab.
2. Click the Controller-IP drop-down list and select a VLAN ID from the list of uplink VLANs configured on the
Branch>Smart Config>Networking tab.
3. Click Apply .
242 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
NAS IP
AOS-W 6.5.x allows you configure a branch switch NAS IP with a VLAN. This setting is optional; if the NAS IP
VLAN is not configured for branch switches, the switch IP defined in the RADIUS server configuration address is used as the NAS IP.
To assign an VLAN to a NAS IP:
1. Navigate to Configuration>Branch>Smart Config>Routing and select the Routing sub-tab.
2. Click the Override NAS-IP drop-down list and select a VLAN ID from the list of uplink VLANs configured on the Branch>Smart Config>Networking tab.
3. Click Apply .
Static Routes
A static route allows the branch switch to connect to an upstream router or switch instead of the default gateway. To define a static route for your branch config group:
1. Select the Routing sub-tab.
2. Click New to open a pop-up window that allows you to configure the following static route settings:
Table 64: Branch Switch Static Route Settings
Parameter Description
Destination IP Destination IP addresses in dotted decimal format.
Destination Mask
NextHop
IPsec
Destination netmask, in dotted decimal format.
The IP address of the forwarding router in dotted decimal format.
To use a static IPsec route, map click the IPsec drop-down list and select a static
IPsec route map, or click New and enter the name of a new IPsec route map.
DHCP Pools
Client devices within a branch office will obtain their IP addresses from a DHCP pool.
1. Select the Routing sub-tab.
2. Click New to open a pop-up window that allows you to configure the following DHCP pool settings:
Table 65: Branch Switch DHCP Pool Settings
Parameter Description
VLAN VLAN ID. Click the VLAN drop-down list and select a VLAN ID from the list of uplink
VLANs configured on the Branch>Smart Config>Networking tab.
Pool Name
Domain Name
DNS Server
Name that identifies this VLAN pool.
Domain name of the DNS server.
IP address of the DNS server.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 243
Parameter
IP Address Range
Lease
Option
Description
IP addresses at the start and end of the branch switch’s address range, in dotteddecimal format and the netmask per branch. The WebUI converts the netmask per branch to hosts count.
Example: If the netmask per branch is /27, WebUI calculates the hosts count as 32.
Similarly, if netmask per branch is /24, the WebUI calculates the hosts count as 256.
Lease time for addresses in the DHCP pool. If unconfigured, the default value is 12 hours.
Use this field assign the client to a VLAN based upon the DHCP signature ID.
Next-Hop Device lists
If the switch uses policy-based routing to forward packets to a next hop device, a next-hop list ensures that if the primary next-hop device becomes unreachable, the packets matching the policy can still reach their destination. For more information on nexthop devices, see
Routing Configuration on page 242 .
To define a next-hop list:
1. Navigate to Configuration>Branch>Smart Config>Routing and select the PBR sub-tab.
2. Click the Add button below the Nexthop Configuration table to open a pop-up window that allows you to configure the following next-hop settings:
Table 66: Branch Switch Next-Hop Settings
Parameter Description
Nexthop-list name Name for the new nexthop list.
Nexthop IP / DHCP
Preemptive-Failover
IP address of the nexthop device or the VLAN ID of the VLAN used by the nexthop device. If the VLAN gets an IP address using DHCP, and the default gateway is determined by the VLAN interface, the gateway IP is used as the nexthop IP address.
When you click Add to define a NextHop IP or DHCP value, a pop-up list appears and field requires you to select either the IP or DHCP option.
n n
IP: In the Nexthop Value and Priority fields, enter the IP address and priority of the nexthop device
DHCP: In the Nexthop Value and Priority fields select the VLAN and priority of the nexthop device.
If preemptive failover is disabled and the highest-priority device on the nexthop list is disabled, the new primary nexthop device remains the primary even when the original device comes back online.
PBR Rules
A policy-based routing (PBR) rule is an ACL that can forward traffic as normal, or route traffic over a VPN tunnel specified by an IPsec map, routed to a nexthop router on a nexthop list, or redirected over an L3 GRE tunnel or tunnel group.
244 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
If you modify an existing ACL by adding a new rule with the same position as an existing rule, the previously existing rule will be overwritten. The Smart Config section of the AOS-W WebUI does not prevent you from creating duplicate rules in different positions, though this is not allowed when creating ACLs using the
Configuration>Security>Firewall Policies section of the AOS-W WebUI, or when using the ip access-list commands in the AOS-W command-line interface.
To associate a policy based routing rule with the branch config group,
1. Navigate to Configuration>Branch>Smart Config>Routing , and select the PBR subtab .
2. Click the Route ACL name drop-down list. Select an existing route ACL, or click New to define a new ACL.
3. If you selected New in the previous step, enter a name for the new ACL, then click Add . Next, you must define the rules for the new ACL.
4. Click the Add button below the PBR rules list, and define the following values:
Table 67: Policy Based Routing ACL Rule Parameters
Field Description
IP version
Source
(required)
Destination
(required)
Specifies whether the policy applies to IPv4 or IPv6 traffic.
Source of the traffic, which can be one of the following: n any: Acts as a wildcard and applies to any source address.
n user: This refers to traffic from the wireless client.
n n n host: This refers to traffic from a specific host. When this option is chosen, you must configure the IP address of the host.
network: This refers to a traffic that has a source IP from a subnet of IP addresses. When this option is chosen, you must configure the IP address and network mask of the subnet.
alias: This refers to using an alias for a host or network. You configure the alias by navigating to the Configuration > Advanced Services > Stateful Firewall > Destination page.
Destination of the traffic, which can be configured in the same manner as Source.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 245
Field
Service
(required)
Action
(required)
Position
Description
Type of traffic, which can be one of the following: n any: This option specifies that this rule applies to any type of traffic.
n n n application: For session and route policies on a OAW-40xx Series switch, you can create a rule that applies to a specific application type. Click the Application drop-down list and select an application type.
application category: For session and route policies on a OAW-40xx Series switch, you can create a rule that applies to a specific application category. Click the Application Category drop-down list and select a category type.
protocol: Using this option, you specify a different layer 4 protocol (other than TCP/UDP) by configuring the IP protocol value.
n n n service: Using this option, you use one of the pre-defined services (common protocols such as
HTTPS, HTTP, and others) as the protocol to match for the rule to be applied. You can also specify a network service that you have manually configured. For details, see
.
tcp: A range of TCP port(s) that must be used by the traffic in order for the rule to be applied.
udp: A range of UDP port(s) hat must be used by the traffic in order for the rule to be applied.
The action that you want the switch to perform on a packet that matches the specified criteria. This can be one of the following: n
Forward Regularly: Packets are forwarded to their next destination without any changes.
n n n n
Forward to ipsec-map: Packets are forwarded through an IPsec tunnel defined by the specified
IPsec map. You must specify the position of the forwarding or routing rule. (1 is first, default is last)
Forward to next-hop-list: packets are forwarded to the highest priority active device on the selected next hop list. You must also specify the position of the forwarding or routing rule (1 is first, default is last). For more information on next-hop lists, see
Forward to tunnel: Packets are forwarded through the tunnel with the specified tunnel ID. You must also specify the position of the forwarding or routing rule (1 is first, default is last). For more information on GRE tunnels, see
Configuring GRE Tunnels on page 115
.
Forward to tunnel group: Packets are forwarded through the active tunnel in a GRE tunnel group. You must also specify the position of the forwarding or routing rule (1 is first, default is last). For more information on tunnel groups, see
Configuring GRE Tunnel Groups on page 124 .
(Optional) Define a position for the rule in the ACL. Rules processed according to their position numbers, and new Rules are added at the end of an ACL by default. A position of 1 puts the rule at the top of the list.
Targets for PBR Rules
A Policy Based Routing (PBR) rule does not become active until it is applied to a VLAN interface or user role. To define a target for a PBR rule:
1. Select the PBR sub-tab.
2. Click the Add button below the Target table.
3. Click the PBR Rule Name drop-down list and select the rule to be applied to the target.
4. Select the target type: VLAN or User Role .
n n
If you selected the VLAN type, click the Target drop-down list and select a VLAN ID to apply the rule to the VLAN interface's inbound traffic.
If you selected the User Role type, click the Target drop-down list and select a user role. The rule will be applied to traffic from clients with the selected user role.
5. Click Done .
6. Click Apply .
246 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
VPN Configuration
Configure IPsec crypto maps and DTP settings for the branch switches in a branch config group by navigating to Configuration>Branch>Smart Config and selecting the VPN tab. The settings on the VPN tab are described in the table below.
Table 68: Branch Config Group VPN Settings
Parameter Description Description
IPSec maps
Name
Name of the IPsec map.
Disable IPsec map
Click this checkbox to temporarily disable a configured IPsec map without deleting it from the branch config group.
Priority
Source Network Type
Priority level for the IPsec map, from 1-9998. An IPsec map with a smaller priority number will take precedence over a map with a greater priority number.
Select one of the supported source network identifier types: n n n
IP Address : Identify the source network (the local network connected to the branch switch) using an IP address.
VLAN : Use a VLAN ID as the source network. When the configuration is pushed to the branch, the IP address range assigned for that VLAN in that branch is used during IKE negotiation.
Any : Use any as the source network.
Source Network
Source Network VLAN
If you selected the IP Address source network type, enter the IP address the source network in the Source Network field
If you selected VLAN as the source network type, click the VLAN drop-down list and select the VLAN ID of the source network VLAN.
Source Subnet Mask
Destination Network
Subnet mask for the source network (the local network connected to the branch switch).
Select one of the supported destination network identifier types: n n
IP Address : Identify the destination network (the remote network to which the local branch network communicates).
Any : Use any as the destination network.
Destination Subnet Mask
Peer Gateway Type
Subnet mask for the source network (the remote network to which the local branch network communicates).
Select one of the supported peer gateway types: n IP Address : Select this option to identify the remote end point of the VPN tunnel using an IP address.
n
FQDN : This option allows you to use same FQDN across different branches. The FQDN resolves to different IP addresses for each branch, based on its local DNS setting.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 247
Parameter Description Description
Peer Gateway Define the peer gateway.
If you selected IP Address for the Peer Gateway Type option, enter the appropriate IP address: n n
If you are configuring an IPsec map for a dynamically addressed remote peer, give the peer gateway a default value of 0.0.0.0
.
If you are configuring an IPsec map for a statically addressed remote peer, enter the IP address of the interface used by the remote peer to connect to the L3 network .
f you selected FQDN for the Peer Gateway Type option, enter the fully qualified domain name for the remote peer.
Peer Certificate Subject
Name
If you use IKEv2 to establish a site-to-site VPN for a statically addressed remote peer, identify the peer device by entering its certificate subject name in the Peer Certificate Subject Name field.
NOTE: This field is not enabled until you select the Certificate option for authentication at the bottom of the VPN tab. To identify a peer certificate's subject name, issue the show crypto-local pki servercert <certname> subject command in the master switch command-line interface.
Security Association
Lifetime (seconds)
Security Association
Lifetime (Kilobites)
Configures the lifetime for the security association (SA), in seconds.
Specifies the amount of traffic (in kilobytes) that can pass between IPSec peers in the local and remote networks before the security association expires.
Version
Click the drop-down list and select None (to create an IPsec map that doesn't use IKE), IKEv1 or IKEv2 .
IKE policies
Factory Certificate
Authentication
VLAN
Select a predefined IKE policy, or a policy manually defined on the Configuration > Advanced > VPN Services > IPsec page of the master switch
WebUI. For more information on creating IKE policies, see
Select this option to use factory-installed TPM (Trusted Platform Module) certificates for VPN authentication.
Select the VLAN containing the interface of the local branch switch that connects to the Layer-3 network. This setting determines the source IP address used to initiate IKE. If you select None , the default is the VLAN of the switch’s
IP address (either the VLAN where the loopback IP is configured, or VLAN 1 if no loopback IP is configured).
248 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Parameter Description Description
PFS If you enable Perfect Forward Secrecy (PFS) mode, new session keys are not derived from previously used session keys. Therefore, if a key is compromised, that compromised key does not affect any previous session keys. PFS mode is disabled by default. To enable this feature, click the PFS drop-down list and select one of the following Perfect Forward Secrecy modes: n group1 : 768-bit Diffie–Hellman prime modulus group.
n n group2 : 1024-bit Diffie–Hellman prime modulus group.
group 14 : 2048-bit Diffie–Hellman prime modulus group.
n n group19 : 256-bit random Diffie–Hellman ECP modulus group.
group20 : 384-bit random Diffie–Hellman ECP modulus group.
Pre-Connect
Trusted Tunnel
Enforce NATT
Select Pre-Connect to establish the VPN connection, even if there is no traffic being sent from the local network. If you do not select this, the VPN connection is established only when traffic is sent from the local network to the remote network.
Select Trusted Tunnel if traffic between the networks is trusted. If you do not select this, traffic between the networks is untrusted.
Select the Enforce NATT checkbox to enforce IKE and IPSEC NAT Traversal
(NAT-T) on UDP port 4500. This option is disabled by default.
Transform Sets
A transform set defines a specific encryption and authentication type used by the dynamic peer. Click the Transform Set drop-down list to select a predefined transform set or a transform set that was manually defined using the Configuration>Advanced Services > VPN Services > Advanced page of the master switch WebUI, then click the arrow button by the drop-down list to add that transform set to the IPsec map.
Dynamically Addressed
Peer
Pre-shared Key
Select either the Pre-shared Key or Certificate options to define security options for a dynamically address peer.
For pre-shared key authentication, select Pre-Shared Key , then enter a shared secret in the IKE Shared Secret and Verify IKE Shared Secret fields. This authentication type is generally required in IPsec maps for a VPN with dynamically addressed peers, but can also be used for a static site-tosite VPN.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 249
Parameter Description Description
Certificate
For certificate authentication, select Certificate , then click the Server Certificate and CA certificate drop-down lists to select certificates previously imported into the switch.
See
for more information on managing certificates.
DPD Parameters
Enable DPD
The DPD Parameters checkbox on the VPN tab enables or disables Dead
Peer Detection. When enabled, DPD uses IPsec traffic patterns to minimize the number of IKE messages required to determine the liveliness of an IKE peer. After a dead peer is detected, the branch switch tears down the IPsec session. Once the network path or other failure condition has been corrected, a new IPsec session is automatically re-established.
Table 69: Default IKE Policy Setting
Policy Name
Policy
Number
IKE
Version
Encryption
Algorithm
Default protection suite
10001
Default RAP
Certificate protection suite
10002
Default RAP
PSK protection suite
10003
Default RAP
IKEv2 RSA protection suite
1004
10005 Default Cluster
PSK protection suite
Default IKEv2
RSA protection suite
Default IKEv2
PSK protection suite
1006
10007
IKEv1
IKEv1
IKEv2
IKEv1
IKEv2
IKEv2
3DES-168
AES -256
AES -256
AES -256
AES -256
AES - 128
AES - 128
Hash
Algorithm
SHA 160
Authentica
-tion
Method
Pre-Shared
Key
SHA 160 RSA
Signature
PRF
Method
N/A
Diffie-
Hellman
Group
2 (1024 bit)
N/A 2 (1024 bit)
SHA 160
SSHA160
SHA160
SHA 96
SHA 96
Pre-Shared
Key
RSA
Signature
Pre-Shared
Key
RSA
Signature
Pre-shared key
N/A hmacsha1
Pre-
Shared
Key hmacsha1 hmacsha1
2 (1024 bit)
2 (1024 bit)
2 (1024 bit)
2 (1024 bit)
2 (1024 bit)
250 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Policy Name
Policy
Number
Default Suite-B
128bit ECDSA protection suite
10008
Default Suite-B
256 bit ECDSA protection suite
10009
Default RAP
IKEv2 RSA protection suite
10012
IKE
Version
Encryption
Algorithm
IKEv2
IKEv2
IKEv2
AES - 128
AES -256
AES -256
Hash
Algorithm
SHA 256-
128
Authentica
-tion
Method
ECDSA-256
Signature
PRF
Method
Diffie-
Hellman
Group hmacsha2-256
Random
ECP
Group
(256 bit)
SHA 384-
192
SSHA160
ECDSA-384
Signature
RSA
Signature hmacsha2-384
Random
ECP
Group
(384 bit) hmacsha1
14 2048bit group
WAN Configuration
Use the WAN tab to define settings for the features described below. For additional information on each of these features, refer also to the following sections of this document: n n n n n n
WAN Failure (Authentication) Survivability on page 218
Branch Switch Routing Features on page 229
WAN Optimization through IP Payload Compression on page 224
Interface Bandwidth Contracts on page 225
Branch Integration with a Palo Alto Networks (PAN) Portal on page 226
To configure WAN survivability, Health Check, Policy-Based Routing, WAN Optimization, Bandwidth
Management and PAN portal settings for the branch switches in a branch config group ,navigate to
Configuration>Branch>Smart Config and select the WAN tab. The settings on the WAN tab are described in the table below.
Table 70: Branch Config Group WAN Setting
Parameter Description
WAN Failure Survivability
Enable Auth-Survivability
Authentication Server
Certificate
This parameter controls whether to use the Survival Server when no other authentication servers in the server group are in-service.
This parameter also controls whether to store the user access credential in the
Survival Server when it is authenticated by an external RADIUS or LDAP server in the server group. Authentication Survivability is enabled or disabled at each switch. This parameter is disabled by default.
NOTE: Authentication Survivability will not activate if Authentication Server Dead
Time is configured as 0. For more information on configuring Authentication
Server Dead Time, see
Configuring Authentication Timers on page 210
.
This parameter allows you to view the name of the server certificate used by the local Survival Server. The local Survival Server is provided with a default server certificate from AOS-W . The customer server certificate must be imported into the switch first, and then you can assign the server certificate to the local Survival
Server.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 251
Table 70: Branch Config Group WAN Setting
Parameter Description
Local Cache Lifetime (hrs) This parameter specifies the lifetime in hours for the cached access credential in the local Survival Server. When the specified cache-lifetime expires, the cached access credential is deleted from the switch.
Configured authentication servers are put into the out-of-service (OOS) state when authentication requests time out. The wireless switch picks the next server from the server group when the previous server times out or fails.
When there are no more servers available from the server group, the local
Survival Server processes the authentication request. When the client is authenticated with the local Survival Server, the previously stored Key Reply attributes are included in the RADIUS response.
The Cache Lifetime range is from 1 to 168 hours. The default is 24 hours.
CA Certificate Assigned for
Auth Survivability
Select the certificate to be used for client authentication.
WAN Health Check
Health-Check
WAN
Probe Mode
Probe Interval (sec)
Packet Burst Per Probe
Probe Retries
IP/FQDN of remote host
Jitter Measurement
PBR
Probe Mode
Probe Interval (sec)
Select the health-check option to use ping-probes to measure WAN availability and latency on selected uplinks. Based upon the results of this health-check information, the switch can continue to use its primary uplink, or failover to a backup link.
Select the WAN tab to define ping probe settings for the health-check feature
Click the Probe Mode drop-down list and select ping or udp to enable ip probes of the selected type.
The Probe Interval field specifies the probe interval, in seconds. The WAN health-check feature sends the number of probes defined by the Packet Burst per Probe parameter during each probe interval. To change the default interval of 10 seconds, enter a new value into this field.
The Pocket Burst per Probe field specifies the number of probes to be sent during the probe interval. To change the default value of 5 probes, enter a new value into this field.
The number of times the switch will attempt to resend a probe.
IP address or Fully Qualified Domain Name (FQDN) of the remote host to which the ping probes are sent.
Jitter is a variation in the delay of received packets, which can be worsened by network congestion, improper queueing and configuration errors. The WAN health-check feature measures jitter on the connection to the remote host by sending and measuring packets at fixed intervals.
Select the PBR tab to define ping probe settings for policy-based routing.
Click the Probe Mode drop-down list and select ping to enable ip probes.
The Probe Interval field specifies the probe interval, in seconds. The WAN health-check feature sends the number of probes defined by the Packet Burst per Probe parameter during each probe interval. To change the default interval of 10 seconds, enter a new value into this field.
252 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Table 70: Branch Config Group WAN Setting
Parameter Description
Packet Burst Per Probe
The Pocket Burst per Probe field specifies the number of probes to be sent during the probe interval. To change the default value of 5 probes, enter a new value into this field.
Probe Retries
The number of times the switch will attempt to resend a probe.
WAN Optimization
Compression The Compression/Decompression Engine feature is enabled by default. However, the packets are compressed only if the IP Payload Compression Protocol (IPComp) is successfully negotiated via the Internet Key Exchange (IKE) protocol.
BW Management
Uplink
Service Type
Bandwidth Contract
Application
Category
Bandwidth Direction
Select an interface uplink to which you will apply the bandwidth contract.
n n n
Select one of the available service types for this bandwidth contract: n None: The contract applies to all upstream or downstream traffic on the interface.
Application: The contract applies to a specific application.
Category: The contract applies to all applications within a category type.
Exclude: If a bandwidth contract is applied to an entire interface or category of applications, you can create a bandwidth contract that excludes a single application or application category from that contract.
If you chose the None, Application or Category option in the Service Type field, select the name of the bandwidth contract to be applied to the interface.
If you chose the Application option in the Service Type field, select the application to which the bandwidth policy will be applied.
If you chose the Category option in the Service Type field, select the application category to which the bandwidth contract is applied.
Apply the bandwidth contract to upstream or downstream traffic.
PAN Portal
Portal IP
Trusted Certificate
User Name
Password
The IP address or fully qualified domain name (FQDN) of the portal.
Specify the name of the self-signed or external certification authority (CA) certificate to establish an SSL connection to the portal.
Username to authenticate to the Palo Alto Networks portal.
Password to authenticate to the Palo Alto Networks portal.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 253
Branch Config Group Summary
The Summary tab on the Configuration>Branch>Smart Config page displays a summary of the branch config group configuration created using the Smart Config WebUI, and a summary of the settings on a specific branch switch.
To view a summary of the branch config group settings:
1. Navigate to Configuration>Branch>Smart Config>Summary .
2. Select the Profile Summary subtab.
3. Click the Profile drop-down list and select the branch config group whose configuration settings you want to review.
To view a summary of the settings specific to an individual branch switch:
1. Navigate to Configuration>Branch>Smart Config>Summary .
2. Select the BOC Summary subtab.
3. Click the Profile drop-down list and select the MAC address of the branch switch whose configuration settings you want to review.
Whitelist Configuration
The branch switch whitelist database links the MAC address of the branch switch to the branch config group.
Once you have assigned a branch config group to a branch switch, you cannot edit the config group assigned to the branch switch in the whitelist entry. To assign a different configuration to an unprovisioned branch switch, you must delete the whitelist entry and create a new branch switch whitelist entry with the correct branch config group.
When you remove an entry for an active branch switch from the whitelist on the master switch, that branch switch no longer receives configuration or license updates from the master switch, but continues to operate as previously configured. As the license server is the master switch, any operation related to the licensing does not work after it is detached. If you remove an individual branch switch entry from the whitelist before that branch switch is connected to the network, that branch switch is not automatically provisioned as a branch switch, and remains inactive on the network until manually provisioned.
Add branch switches to the master switch whitelist by navigating to Configuration>Branch>Smart Config and selecting the Whitelist tab. The settings on the Whitelist tab are described in the table below.
Table 71: Branch Config Group Whitelist Settings
Parameter Description
MAC address
MAC address of the branch switch
Hostname Hostname of the master switch
Remote
Group
The name of the branch config group whose settings are applied to the branch switch.
PortFast and BPDU Guard
The following section describes some of the Layer-2 Spanning Tree Protocol (STP) features for the branch switch solution. Currently, PortFast and Bridge Protocol Data Unit (BPDU) Guard features are supported,
254 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
which work along with existing L2 STP feature. These two features enhance network reliability, manageability, and security for the existing L2 STP feature.
Some devices and local stacks running on systems/workstations are capable of generating potential STP
BPDUs that cause Denial of Service (DOS) attacks. PortFast and BPDU Guard features provide stability and security for network topologies to prevent such attacks.
PortFast
The PortFast feature is introduced to avoid network connectivity issues. These issues are caused by delays in
STP enabled ports moving from blocking-state to forwarding-state after transitioning from the listening and learning states. STP enabled ports that are connected to devices such as a single switch, workstation, or a server can access the network only after passing all these STP states. Some applications need to connect to the network immediately, else they will timeout.
Enabling the PortFast feature causes a switch or a trunk port to enter the STP forwarding-state immediately or upon a linkup event, thus bypassing the listening and learning states. The PortFast feature is enabled at a port level, and this port can either be a physical or a logical port. When PortFast feature is enabled on a switch or a trunk port, the port immediately transitions to the STP forwarding state.
Though PortFast is enabled the port still participates in STP. If the port happens to be part of topology that could form a loop, the port eventually transitions into STP blocking mode. PortFast is usually configured on an edge port, which means the port should not receive any STP BPDUs. If the port receives any STP BPDU, it moves back to normal/regular mode and will participate in the listening and learning states.
In most deployments, edge ports are access ports. However, in this scenario there are no restrictions in enabling the PortFast feature. The mode of the port changes from PortFast to non-PortFast when the port receives a STP BPDU. To re-enable this feature on a port, run the shut command followed by a no-shut command at the interface/port level.
Configuring PortFast on a non-edge port can cause instability to the STP topology.
BPDU Guard
BPDU Guard feature protects the port from receiving STP BPDUs, however the port can transmit STP BPDUs.
When a STP BPDU is received on a BPDU Guard enabled port, the port is shutdown and the state of the port changes to ErrDis (Error-Disable) state. The port remains in the ErrDis state until the port status is manually changed by using the configuration command shut followed by a no-shut applied on the interface. In most deployments, BPDU Guard feature is configured over the PortFast enabled STP ports, but in this implementation the BPDU Guard feature can be enabled on any of the STP ports, with or without PortFast feature being enabled on these ports.
It is recommended not to enable the BPDU Guard feature on a trunk port that forms the STP topology.
Scenarios Supported on PortFast and BPDU Guard
PortFast and BPDU Guard features are applied at the port/interface level. These features can also be applied in the following scenarios: n n n
RSTP and PVST modes
Access and Trunk ports
Physical and Logical ports
The PortFast and BPDU Guard features can be applied either independently or together.
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 255
In the global RSTP mode there is only one RSTP instance running in the entire switch. If the port that is enabled with PortFast and BPDU Guard receives any STP BPDU it will effect all the ports, as the global RSTP runs on a port basis.
In the PVST mode there can be multiple instances of RSTP running as they are based on per VLAN. Though it is based on per VLAN, it will still behave in the same way as it does in the global RSTP mode. For example, if there are five VLANs and each VLAN has a separate RSTP instance running, then any STP BPDU received on any of these five ports effects all ports.
If an STP BPDU is received from any one of the five RSTP instances running, the port that is enabled with BPDU
Guard shuts down and goes to ErrDis state. In other words both PortFast and BPDU Guard features are applied on a port basis for both global RSTP and PVST modes, even though the PVST runs on a per VLAN basis.
Enabling PortFast and BPDU Guard on a Port
The following section guides you to enable the PortFast and BPDU Guard features on a port.
In the Web UI
Follow the steps below to enable PortFast and BPDU Guard features on a port using the WebUI:
1. Navigate to Configuration>Branch>Smart Config and select the Networking tab.
2. In the Ports table, click the port number for which you want to enable PortFast and BPDU Guard.
3. Click Edit .
4. Select the PortFast and BPDU Guard checkbox.
5. Click Update .
To disable PortFast and BPDU Guard uncheck the PortFast and BPDU Guard checkboxes.
It is recommended to enable PortFast only on access port types. However, PortFast can be enabled on the trunk ports by selecting the Trunk checkbox in the WebUI.
In the CLI
Execute the following commands at the command prompt to enable PortFast and BPDU Guard:
(host) (config) #interface gigabitinternet 0/0/4
(host) (config-if)#spanning-tree portfast
(host) (config-if)#spanning-tree bpduguard
To disable PortFast
(host) (config-if) #no spanning-tree portfast
(host) (config-if) #no spanning-tree bpduguard
Execute the following command to enable PortFast on trunk ports:
(host) (config) #interface gigabitethernet 0/0/4
(host) (config-if)#spanning-tree portfast trunk
Execute the following show command to display the status of the STP ports in Global RSTP mode.
(host) (config-if) #show spanning-tree interface gigabitethernet 0/0/4
Execute the following show command to display the status of the STP ports in Instance RSTP (PVST) mode.
(host) #show spanning-tree interface gigabitethernet 0/0/4
Execute the following command to display the status of BPDU Guard enabled port that is in ErrDis state. This command is applicable for ports that are in both the Global RSTP and Instance RSTP (PVST) modes.
(host) (config-if) #show spanning-tree interface gigabitethernet 0/0/4
256 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Preventing WAN Link Failure on Virtual APs
In the branch switch deployments, the local switches are connected across the WAN link from the master switch to the RADIUS server. A WAN link outage will result in service outage as new users cannot be authenticated to 802.1X Virtual APs. This feature provides limited connectivity to branch switches even when the WAN link is down. To provide connectivity when the WAN link is down, open and PSK SSID Virtual APs
(VAPs) are available at all times and the user can connect to these VAPs instead of the main 802.1X Virtual AP.
Currently, this feature is targeted for Campus APs in branch office deployments.
When all the WAN links are down, an AP management module in the switch updates the link state using the notification it receives from the health check manager. Depending on the link state, the new set of Virtual APs are made available to the users, ensuring minimum service depending on the deployment. The VAPs for WAN link failure feature can be configured using the branch switch WebUI or command-line interface.
In the WebUI
1. Access the WebUI of a OAW-40xx Series switch configured as a branch switch, and navigate to
Configuration> AP Configuration> AP Group Page .
2. Select an AP Group .
3. Navigate to Wireless LAN > Virtual AP .
4. Select an existing virtual AP or add a new virtual AP.
5. Once you select the virtual AP, click Advanced tab.
6. Modify the WAN Operation Mode drop-down menu value to Primary , Always , or Backup . For WAN link failure, this mode should be set to backup .
The three modes are as follows: l l l always —The virtual AP is permanently enabled. This is the default mode.
backup —The virtual AP is enabled when the WAN link is down. If the WAN link is up, the virtual AP is disabled automatically.
primary —The virtual AP is enabled when the WAN link is up. If the WAN link is down, the virtual AP is disabled automatically.
In the CLI
(host)(Virtual AP profile "default") #wan-operation backup
For example:
(host) (config) #wlan virtual-ap default
(host)(Virtual AP profile "default")#?
wan-operation Virtual-AP WAN operation wmm-traffic-managemen.. WMM Traffic Management Profile
(host)(Virtual AP profile "default")#wan-operation ?
always Enable virtual-AP regardless of WAN link state.
backup primary
Enable virtual-AP when WAN link is down.
Enable virtual-AP only when WAN link is present.
(host)(Virtual AP profile "default") #wan-operation backup
Branch WAN Dashboard
The WAN (Wide Area Network) dashboard, in the Dashboard section of the WebUI, is the landing page for the
Branch switch. The WAN dashboard provides the WAN summary details for VLANs.
Following figure shows a snapshot of the WAN summary dashboard:
AOS-W 6.5.3.x
| User Guide Branch Switch Config for Cloud Services Switches | 257
The WAN Summary page contains the following tables: n n n n n n
Status : This section of the WAN Dashboard includes tabs that displays information for the status of monitored links, and for deployments using Layer-3 redundancy the status of the branch connectivity to the primary and secondary master switches.
l
Status : This section displays the link status and WAN status for VLANs monitored using the uplink manager utility. For each VLAN, the green represents an up status and red represents a down status for the link and WAN. The
is enabled by default on branch switches. If it is disabled, the WAN status link will appear orange, indicating that this feature is in an error state.
l
Layer3 Redundancy: This section displays the status of the branch switch's connection to the primary master and secondary master switches defined during the branch switch's provisioning process.
Throughput : Displays the In and Out traffic for VLANs. The Throughput table has four tabs for different uplinks. First tab shows throughput of VLANs having high priority followed by other VLAN data based on its priority. Clicking on each tab loads In and Out traffic throughput data for that particular VLAN.
Latency : Displays Latency data for available VLANs. Each line represents one VLAN.
Alerts : Lists the last five alerts with time stamp and description.
Usage : Displays traffic based on Application Category or Application.
Compression : Displays compression that occurred on all VLANs together.
258 | Branch Switch Config for Cloud Services Switches AOS-W 6.5.3.x | User Guide
Chapter 11
802.1X Authentication
802.1X is an Institute of Electrical and Electronics Engineers (IEEE) standard that provides an authentication framework for WLANs. 802.1X uses the Extensible Authentication Protocol (EAP) to exchange messages during the authentication process. The authentication protocols that operate inside the 802.1X framework that are suitable for wireless networks include EAP-Transport Layer Security (EAP-TLS), Protected EAP (PEAP), and EAP-
Tunneled TLS (EAP-TTLS). These protocols allow the network to authenticate the client while also allowing the client to authenticate the network.
This chapter describes the following topics: n n n n
Understanding 802.1X Authentication on page 259
Configuring 802.1X Authentication on page 262
Sample Configurations on page 271
Performing Advanced Configuration Options for 802.1X on page 287
Other types of authentication not discussed in this section can be found in the following sections of this guide: n n n n
Captive portal authentication:
Configuring Captive Portal Authentication Profiles on page 319
VPN authentication:
Planning a VPN Configuration on page 346
MAC authentication:
Configuring MAC-Based Authentication on page 212
Stateful 802.1X, stateful NTLM, and WISPr authentication:
Stateful and WISPr Authentication on page 291
Understanding 802.1X Authentication
802.1X authentication consists of three components: n n n
The supplicant , or client, is the device attempting to gain access to the network. You can configure the
Alcatel-Lucent user-centric network to support 802.1X authentication for wired users a wireless users.
The authenticator is the gatekeeper to the network and permits or denies access to the supplicants.
The Alcatel-Lucent switch acts as the authenticator, relaying information between the authentication server and supplicant. The EAP type must be consistent between the authentication server and supplicant, and is transparent to the switch.
The authentication server provides a database of information required for authentication, and informs the authenticator to deny or permit access to the supplicant.
The 802.1X authentication server is typically an EAP-compliant Remote Access Dial-In User Service (RADIUS) server which can authenticate either users (through passwords or certificates) or the client computer.
An example of an 802.1X authentication server is the Internet Authentication Service (IAS) in Windows (see http://technet.microsoft.com/en-us/library/cc759077(WS.10).aspx
).
In Alcatel-Lucent user-centric networks, you can terminate the 802.1X authentication on the switch. The switch passes user authentication to its internal database or to a “backend” non-802.1X server. This feature, also called AAA FastConnect , is useful for deployments where an 802.1X EAP-compliant RADIUS server is not available or required for authentication.
Supported EAP Types
Following is the list of supported EAP types:
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 259
n n n n n n n n n n n n
PEAP—Protected EAP (PEAP) is an 802.1X authentication method that uses server-side public key certificates to authenticate clients with the server. The PEAP authentication creates an encrypted SSL / TLS tunnel between the client and the authentication server. The exchange of information is encrypted and stored in the tunnel to ensure that the user credentials are kept secure.
EAP-GTC—The EAP-GTC (Generic Token Card) type uses clear text method to exchange authentication controls between the client and the server. Since the authentication mechanism uses the one-time tokens
(generated by the card), this method of credential exchange is considered safe. In addition, EAP-GTC is used in PEAP or TTLS tunnels in wireless environments. The EAP-GTC is described in RFC 2284.
EAP-AKA—The EAP-AKA (Authentication and Key Agreement) authentication mechanism is typically used in mobile networks that include Universal Mobile Telecommunication Systems (UMTS) and CDMA 2000. This method uses the information stored in the Subscriber Identity Module (SIM) for authentication. The EAP-
AKA is described in RFC 4187.
EAP-FAST—The EAP-FAST (Flexible Authentication via Secure Tunneling) is an alternative authentication method to PEAP. This method uses the Protected Access Credential (PAC) for verifying clients on the network. The EAP-FAST is described in RFC 4851.
EAP-MD5—The EAP-MD5 method verifies MD5 hash of a user password for authentication. This method is commonly used in a trusted network. The EAP-MD5 is described in RFC 2284.
EAP-POTP—The EAP type 32 is supported. Complete details are described in RFC 4793.
EAP-SIM—The EAP-SIM (Subscriber Identity Module) uses Global System for Mobile Communication (GSM)
Subscriber Identity Module (SIM) for authentication and session key distribution. This authentication mechanism includes network authentication, user anonymity support, result indication, and fast reauthentication procedure. Complete details about this authentication mechanism is described in RFC 4186.
EAP-TLS—The EAP-TLS (Transport Layer Security) uses Public key Infrastructure (PKI) to set up authentication with a RADIUS server or any authentication server. This method requires the use of a clientside certificate for communicating with the authentication server. The EAP-TLS is described in RFC 5216.
EAP-TLV—The EAP-TLV (type-length-value) method allows you to add additional information in an EAP message. Often this method is used to provide more information about an EAP message such as status information or authorization data. This method is always used after a typical EAP authentication process.
EAP-TTLS—The EAP-TTLS (Tunneled Transport Layer Security) method uses server-side certificates to set up authentication between clients and servers. The actual authentication is, however, performed using passwords. Complete details about EAP-TTLS is described in RFC 5281.
LEAP—Lightweight Extensible Authentication Protocol (LEAP) uses dynamic WEP keys and mutual authentication between the client and the RADIUS server.
ZLXEAP—ZoneLabs EAP is an EAP method that has been allocated EAP Type 44 by IANA. For more information, visit http://tools.ietf.org/html/draft-bersani-eap-synthesis-sharedkeymethods-00#page-30 .
Configuring Authentication with a RADIUS Server
See
for an overview of the parameters that you need to configure on authentication components when the authentication server is an 802.1X EAP-compliant RADIUS server.
Figure 45 802.1X Authentication with RADIUS Server
The supplicant and the authentication server must be configured to use the same EAP type. The switch does not need to know the EAP type used between the supplicant and authentication server.
260 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
For the switch to communicate with the authentication server, you must configure the IP address, authentication port, and accounting port of the server on the switch. The authentication server must be configured with the IP address of the RADIUS client, which is the switch in this case. Both the switch and the authentication server must be configured to use the same shared secret.
Additional information on EAP types supported in a Windows environment, Microsoft supplicants, and authentication servers, is available at http://technet.microsoft.com/en-us/library/cc782851
(WS.10).aspx
.
The client communicates with the switch through a GRE tunnel to form an association with an AP and to get authenticated in the network. Therefore, the network authentication and encryption configured for an ESSID must be the same on both the client and the switch.
Configuring Authentication Terminated on Switch
User authentication is performed either via the switch’s internal database or a non-802.1X server. See
Authentication Profile Basic WebUI Parameters on page 263
for an overview of the parameters that you need to configure on 802.1X authentication components when 802.1X authentication is terminated on the switch
(AAA FastConnect).
Figure 46 802.1X Authentication with Termination on Switch
In this scenario, the supplicant is configured for EAP-Transport Layer Security (TLS) or EAP-Protected EAP
(PEAP).
n n
EAP-TLS is used with smart card user authentication. A smart card holds a digital certificate which, with the user-entered personal identification number (PIN), allows the user to be authenticated on the network. EAP-
TLS relies on digital certificates to verify the identities of both the client and the server.
EAP-TLS requires that you import server and certification authority (CA) certificates onto the switch (see
the switch (the client certificate must be signed by a known CA) before the username is checked on the authentication server.
EAP-PEAP uses TLS to create an encrypted tunnel. Within the tunnel, one of the following “inner EAP” methods is used: l l
EAP-Generic Token Card (GTC): Described in RFC 2284, this EAP method permits the transfer of unencrypted usernames and passwords from client to server. The main uses for EAP-GTC are one-time token cards such as SecureID and the use of an LDAP or RADIUS server as the user authentication server. You can also enable caching of user credentials on the switch as a backup to an external authentication server.
EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2): Described in RFC
2759, this EAP method is widely supported by Microsoft clients. A RADIUS server must be used as the backend authentication server.
If you use the switch’s internal database for user authentication, you need to add the names and passwords of the users to be authenticated. If you use an LDAP server for user authentication, you need to configure both the LDAP server and the user IDs and passwords on the switch. If you use a RADIUS server for user authentication, you need to configure the RADIUS server on the switch.
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 261
Configuring 802.1X Authentication
On the switch, use the following steps to configure a wireless network that uses 802.1X authentication:
1. Configure the VLANs to which the authenticated users will be assigned. See
.
2. Configure policies and roles. You can specify a default role for users who are successfully authenticated using 802.1X. You can also configure server derivation rules to assign a user role based on attributes returned by the authentication server; server-derived user roles take precedence over default roles. For more information about policies and roles, see
Roles and Policies on page 375 .
The Policy Enforcement Firewall Virtual Private Network (PEFV) module provides identity-based security for wired and wireless users and must be installed on the switch. The stateful firewall allows user classification based on user identity, device type, location, and time of day to provide differentiated access for different classes of users. For information about obtaining and installing licenses, see
.
3. Configure the authentication server(s) and server group. The server can be an 802.1X RADIUS server or, if you use AAA FastConnect, a non-802.1X server or the switch’s internal database. If you use EAP-GTC within a PEAP tunnel, configure an LDAP or RADIUS server as the authentication server (see
Authentication Servers on page 178
). If you use EAP-TLS, import server and CA certificates on the switch (see
Certificates with AAA FastConnect on page 267 ).
4. Configure the AAA profile: l
Select the 802.1X default user role.
l
Select the server group you previously configured for the 802.1X authentication server group.
5. Configure the 802.1X authentication profile. See
6. Configure the virtual AP profile for an AP group or for a specific AP: l
Select the AAA profile you previously configured.
l
In the SSID profile, configure the WLAN for 802.1X authentication.
For details on how to complete the above steps, see
Sample Configurations on page 271
.
In the WebUI
This section describes how to create and configure a new instance of an 802.1X authentication profile in the
WebUI or the CLI.
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. In the Profiles list, select 802.1X Authentication Profile .
3. Enter a name for the profile, then click Add.
4. Click Apply .
5. In the Profiles list, select the 802.1X authentication profile you just created.
6. Change the settings described in
as desired, then click Apply .
The 802.1X authentication profile configuration settings are divided into two tabs— Basic and Advanced .
The Basic tab displays only those configuration settings that often need to be adjusted to suit a specific network. The Advanced tab shows all configuration settings, including settings that do not need frequent adjustment or should be kept at their default values. If you change a setting on one tab, then click and display the other tab without saving your configuration, that setting will revert to its previous value.
262 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
Table 72: 802.1X Authentication Profile Basic WebUI Parameters
Parameter Description
Basic 802.1X Authentication Settings
Max authentication failures
Number of times a user can try to log in with wrong credentials after which the user is blacklisted as a security threat. Set to 0 to disable blacklisting, otherwise enter a non-zero integer to blacklist the user after the specified number of failures.
Range: 0-5 failures.
Default: 0 failure.
NOTE: This option may require a license.
Enforce Machine
Authentication
Select the Enforce Machine Authentication option to require machine authentication. This option is also available on the Basic settings tab.
NOTE: This option may require a license.
Default role assigned to the user after completing only machine authentication.
The default role for this setting is the “guest” role.
Machine
Authentication: Default
Machine Role
Machine
Authentication: Default
User Role
Default role assigned to the user after 802.1X authentication. The default role for this setting is the “guest” role.
Reauthentication
Termination
Termination EAP-Type
Select the Reauthentication checkbox to force the client to do a 802.1X
reauthentication after the expiration of the default timer for reauthentication.
(The default value of the timer is 24 hours.) If the user fails to reauthenticate with valid credentials, the state of the user is cleared. If derivation rules are used to classify 802.1X-authenticated users, then the reauthentication timer per role overrides this setting.
This option is disabled by default.
Select the Termination checkbox to allow 802.1X authentication to terminate on the switch. This option is disabled by default.
If you enable termination, click either EAP-PEAP or EAP-TLS to select an Extensible
Authentication Protocol (EAP) method.
Termination Inner EAP-
Type
If you use EAP-PEAP as the EAP method, specify one of the following inner EAP types: n n eap-gtc : Described in RFC 2284, this EAP method permits the transfer of unencrypted usernames and passwords from client to server. The main uses for EAP-GTC are one-time token cards such as SecureID and the use of LDAP or RADIUS as the user authentication server. You can also enable caching of user credentials on the switch as a backup to an external authentication server.
eap-mschapv2 : Described in RFC 2759, this EAP method is widely supported by Microsoft clients.
Configure Suite-B 128 bit or more security level authentication enforcement.
Enforce Suite-B 128 bit or more security level
Authentication
Enforce Suite-B 128 bit or more security level
Authentication
Configure Suite-B 192 bit security level authentication enforcement.
Advanced 802.1X Authentication Settings
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 263
Table 72: 802.1X Authentication Profile Basic WebUI Parameters
Parameter
Machine Authentication
Cache Timeout
Blacklist on Machine
Authentication Failure
Interval between
Identity Requests
Description
The timeout, in hours, for machine authentication. The allowed range of values is
1-1000 hours, and the default value is 24 hours.
Select the Blacklist on Machine Authentication Failure checkbox to blacklist a client if machine authentication fails. This setting is disabled by default.
Quiet Period after
Failed Authentication
Reauthentication
Interval
Use Server provided
Reauthentication
Interval
Multicast Key Rotation
Time Interval
Interval, in seconds, between identity request retries.
Range: 1-65535 seconds.
Default: 30 seconds.
The enforced quiet period interval, in seconds, following failed authentication.
Range: 1-65535 seconds.
Default: 30 seconds.
Interval, in seconds, between reauthentication attempts.
Range: 60-864000 seconds.
Default: 86400 seconds (1 day).
Select this option to override any user-defined reauthentication interval and use the reauthentication period defined by the authentication server.
Unicast Key Rotation
Time Interval
Authentication Server
Retry Interval
Authentication Server
Retry Count
Framed MTU
Number of times ID-
Requests are retried
Maximum Number of
Reauthentication
Attempts
Interval, in seconds, between multicast key rotation.
Range: 60-864000 seconds.
Default: 1800 seconds.
Interval, in seconds, between unicast key rotation.
Range: 60-864000 seconds. Default: 900 seconds.
Server group retry interval, in seconds.
Range: 5-65535 seconds.
Default: 30 seconds.
Maximum number of authentication requests that are sent to server group.
Range: 0-3 requests.
Default: 2 requests.
Sets the framed Maximum Transmission Unit (MTU) attribute sent to the authentication server.
Range: 500-1500 bytes.
Default: 1100 bytes.
Maximum number of times ID requests are sent to the client.
Range: 1-10 retries.
Default: 3 retries.
Number of times a user can try to log in with wrong credentials after which the user is blacklisted as a security threat. Set to 0 to disable blacklisting, otherwise enter a value from 0-5 to blacklist the user after the specified number of failures.
NOTE: If changed from its default value, this option may require a license.
264 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
Table 72: 802.1X Authentication Profile Basic WebUI Parameters
Parameter
Maximum number of times Held State can be bypassed
Description
Number of consecutive authentication failures which, when reached, causes the switch to not respond to authentication requests from a client while the switch is in a held state after the authentication failure. Before this number is reached, the switch responds to authentication requests from the client even while the switch is in its held state.
(This parameter is applicable when 802.1X authentication is terminated on the switch, also known as AAA FastConnect.) The allowed range of values for this parameter is 0-3 failures, and the default value is 0.
Dynamic WEP Key
Message Retry Count
Dynamic WEP Key Size
Interval between
WPA/WPA2 Key
Messages
Delay between EAP-
Success and WPA2
Unicast Key Exchange
Set the Number of times WPA/WPA2 Key Messages are retried.
Range: 1-5 retries.
Default: 3 retries.
The default dynamic WEP key size is 128 bits, If desired, you can change this parameter to 40 bits.
Interval, in milliseconds, between each WPA key exchanges.
Range: 1000-5000 ms.
Default: 1000 ms.
Interval, in milliseconds, between EAP-Success and unicast key exchanges.
Range: 0-2000 ms.
Default: 0 ms (no delay).
Delay between
WPA/WPA2 Unicast Key and Group Key
Exchange
Time interval after which the PMKSA will be deleted
WPA/WPA2 Key
Message Retry Count
Interval, in milliseconds, between unicast and multicast key exchange. Time interval in milliseconds.
Range: 0-2000.
Default: 0 (no delay).
The time interval after which the PMKSA (Pairwise Master Key Security
Association) cache is deleted. Time interval in Hours.
Range: 1-2000.
Default: 8.
Number of times WPA/WPA2 key messages are retried.
Range: 1-5 retries.
Default: 3 retries.
Multicast Key Rotation
Unicast Key Rotation
Opportunistic Key
Caching
Select this checkbox to enable multicast key rotation. This feature is disabled by default.
Select this checkbox to enable unicast key rotation. This feature is disabled by default.
By default, the 802.1X authentication profile enables a cached pairwise master key (PMK) which is derived through a client and an associated AP. This key is used when the client roams to a new AP. This allows clients faster roaming without a full 802.1X authentication. Uncheck this option to disable this feature.
NOTE: Make sure that the wireless client (the 802.1X supplicant) supports this feature. If the client does not support this feature, the client will attempt to renegotiate the key whenever it roams to a new AP. As a result, the key cached on the switch can be out of sync with the client's key.
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 265
Table 72: 802.1X Authentication Profile Basic WebUI Parameters
Parameter
Validate PMKID
Description
This parameter instructs the switch to check the pairwise master key (PMK) ID sent by the client. When you enable this option, the client must send a PMKID in the associate or reassociate frame to indicate that it supports OKC or PMK caching; otherwise, full 802.1X authentication takes place.
NOTE: This feature is optional, since most clients that support OKC and PMK caching do not send the PMKID in their association request.
Use Session Key
Use Static Key xSec MTU
Token Caching
Token Caching Period
CA-Certificate
Server-Certificate
TLS Guest Access
TLS Guest Role
Ignore EAPOL-START after authentication
Handle EAPOL-Logoff
Ignore EAP ID during negotiation
Select the Use Session Key option to use the RADIUS session key as the unicast
WEP key. This option is disabled by default.
Select the Use Static Key option to use a static key as the unicast/multicast WEP key. This option is disabled by default.
Set the maximum transmission unit (MTU) for frames using the xSec protocol.
Range: 1024-1500 bytes.
Default: 1300 bytes.
If you select EAP-GTC as the inner EAP method, you can select the Token Caching checkbox to enable the switch to cache the username and password of each authenticated user. The switch continues to reauthenticate users with the remote authentication server. However, if the authentication server is unavailable, the switch will inspect its cached credentials to reauthenticate users.
This option is disabled by default.
If you select EAP-GTC as the inner EAP method, you can specify the timeout period, in hours, for the cached information. The default value is 24 hours.
Click the CA-Certificate drop-down list and select a certificate for client authentication. The CA certificate needs to be loaded in the switch before it will appear on this list.
Click the Server-Certificate drop-down list and select a server certificate the switch will use to authenticate itself to the client.
Select TLS Guest Access to enable guest access for EAP-TLS users with valid certificates. This option is disabled by default.
Click the TLS Guest Role drop-down list and select the default user role for EAP-
TLS guest users. This option may require a license.
Select Ignore EAPOL-START after authentication to ignore EAPOL-START messages after authentication. This option is disabled by default.
Select Handle EAPOL-Logoff to enable handling of EAPOL-LOGOFF messages.
This option is disabled by default.
Select Ignore EAP ID during negotiation to ignore EAP IDs during negotiation.
This option is disabled by default.
266 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
Table 72: 802.1X Authentication Profile Basic WebUI Parameters
Parameter
WPA-Fast-Handover
Disable rekey and reauthentication for clients on call
Description
Select this option to enable WPA-fast-handover on phones that support this feature. WAP fast-handover is disabled by default.
This feature disables rekey and reauthentication for VoWLAN clients. It is disabled by default, meaning that rekey and reauthentication is enabled.
NOTE: This option may require a license This option may require a license.
Check certificate common name against
AAA server
If you use client certificates for user authentication, enable this option to verify that the certificate's common name exists in the server. This parameter is enabled by default in the default-cap and default-rap VPN profiles, and disabled by default on all other VPN profiles.
In the CLI
The following command configures settings for an 802.1X authentication profiles. Individual parameters are described in the previous table.
(host)(config) #aaa authentication dot1x {<profile>|countermeasures}
Configuring and Using Certificates with AAA FastConnect
The switch supports 802.1X authentication using digital certificates for AAA FastConnect.
n n
Server Certificate—A server certificate installed in the switch verifies the authenticity of the switch for
802.1X authentication. Alcatel-Lucent switches ship with a demonstration digital certificate. Until you install a customer-specific server certificate in the switch, this demonstration certificate is used by default for all secure HTTP connections (such as the WebUI and captive portal) and AAA FastConnect. This certificate is included primarily for the purposes of feature demonstration and convenience, and is not intended for long-term use in production networks. Users in a production environment are urged to obtain and install a certificate issued for their site or domain by a well-known certificate authority (CA). You can generate a
Certificate Signing Request (CSR) on the switch to submit to a CA. For information on how to generate a CSR and how to import the CA-signed certificate into the switch, see
Managing Certificates on page 854 .
Client Certificates—Client certificates are verified on the switch (the client certificate must be signed by a known CA) before the username is checked on the authentication server. To use client certificate authentication for AAA FastConnect, you need to import the following certificates into the switch (see
Importing Certificates on page 857 ):
l l
Switch’s server certificate
CA certificate for the CA that signed the client certificates
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. In the Profiles list, select 802.1X Authentication Profile .
3. Select the default 802.1X authentication profile from the drop-down list to display configuration parameters.
4. In the Basic tab, select Termination .
5. Select the Advanced Tab.
6. In the Server-Certificate field, select the server certificate imported into the switch.
7. In the CA-Certificate field, select the CA certificate imported into the switch.
8. Click Save As . Enter a name for the 802.1X authentication profile.
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 267
9. Click Apply .
In the CLI
(host)(config) #aaa authentication dot1x <profile>
termination enable
server-cert <certificate>
ca-cert <certificate>
Configuring User and Machine Authentication
When a Windows device boots, it logs onto the network domain using a machine account. Within the domain, the device is authenticated before computer group policies and software settings can be executed; this process is known as machine authentication . Machine authentication ensures that only authorized devices are allowed on the network.
You can configure 802.1X for both user and machine authentication (select the Enforce Machine
Authentication option described in
Table 72 ). This tightens the authentication process further, since both the
device and user need to be authenticated.
Working with Role Assignment with Machine Authentication Enabled
When you enable machine authentication, there are two additional roles you can define in the 802.1X
authentication profile: n n
Machine authentication default machine role
Machine authentication default user role
While you can select the same role for both options, you should define the roles as per the polices that need to be enforced. Also, these roles can be different from the 802.1X authentication default role configured in the
AAA profile.
With machine authentication enabled, the assigned role depends upon the success or failure of the machine and user authentications. In certain cases, the role that is ultimately assigned to a client can also depend upon attributes returned by the authentication server or server derivation rules configured on the switch.
describes role assignment based on the results of the machine and user authentications.
Table 73: Role Assignment for User and Machine Authentication
Machine
Auth
Status
Failed
User
Auth
Status
Failed
Description
Failed
Passed
Passed
Failed
Role Assigned
Both machine authentication and user authentication failed. L2 authentication failed.
No role assigned. No access to the network allowed.
Machine authentication failed (for example, the machine information is not present on the server) and user authentication succeeded. Serverderived roles do not apply.
Machine authentication succeeded and user authentication has not been initiated. Server-derived roles do not apply.
Machine authentication default user role configured in the 802.1X
authentication profile.
Machine authentication default machine role configured in the 802.1X
authentication profile.
268 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
Machine
Auth
Status
Passed
User
Auth
Status
Passed
Description Role Assigned
Both machine and user are successfully authenticated. If there are server-derived roles, the role assigned via the derivation take precedence.
This is the only case where serverderived roles are applied.
A role derived from the authentication server takes precedence. Otherwise, the 802.1X authentication default role configured in the AAA profile is assigned.
For example, if the following roles are configured: n n n
802.1X authentication default role (in AAA profile): dot1x_user
Machine authentication default machine role (in 802.1X authentication profile): dot1x_mc
Machine authentication default user role (in 802.1X authentication profile): guest
Role assignment is as follows: n n
If both machine and user authentication succeed, the role is dot1x_user. If there is a server-derived role, the server-derived role takes precedence.
If only machine authentication succeeds, the role is dot1x_mc.
n n
If only user authentication succeeds, the role is guest.
On failure of both machine and user authentication, the user does not have access to the network.
With machine authentication enabled, the VLAN to which a client is assigned (and from which the client obtains its IP address) depends upon the success or failure of the machine and user authentications. The VLAN that is ultimately assigned to a client can also depend upon attributes returned by the authentication server or server derivation rules configured on the switch (see
Understanding VLAN Assignments on page 98 ). If machine
authentication is successful, the client is assigned the VLAN configured in the virtual AP profile. However, the client can be assigned a derived VLAN upon successful user authentication.
You can optionally assign a VLAN as part of a user role configuration. Do not use VLAN derivation if you configure user roles with VLAN assignments.
describes VLAN assignment based on the results of the machine and user authentications when VLAN derivation is used.
Table 74: VLAN Assignment for User and Machine Authentication
Machine Auth
Status
Failed
User
Auth
Status
Failed
Description
Failed
Passed
Passed
Failed
Both machine authentication and user authentication failed. L2 authentication failed.
Machine authentication failed (for example, the machine information is not present on the server) and user authentication succeeded.
Machine authentication succeeded and user authentication has not been initiated.
VLAN Assigned
No VLAN.
VLAN configured in the virtual AP profile.
VLAN configured in the virtual AP profile.
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 269
Machine Auth
Status
Passed
User
Auth
Status
Passed
Description
Both machine and user are successfully authenticated.
VLAN Assigned
Derived VLAN.
Otherwise, VLAN configured in the virtual
AP profile.
The administrator can now associate a VLAN ID to a client data based on the authentication credentials in a bridge mode.
Enabling 802.1X Supplicant Support on an AP
AOS-W provides 802.1X supplicant support on the Access Point (AP). The AP can be used as a 802.1X
supplicant where access to the wired Ethernet network is restricted to those devices that can authenticate using 802.1X. You can provision an AP to act as an 802.1X supplicant and authenticate to the infrastructure using the PEAP protocol.
Both Campus APs (CAPs) and Remote APs (RAPs) can be provisioned to use 802.1X authentication.
Prerequisites
n n
An AP has to be configured with the credentials for 802.1X authentication. These credentials are stored securely in the AP flash.
The AP must complete the 802.1X authentication before it sends or receives IP traffic such as DHCP.
If the AP cannot complete 802.1X authentication (explicit failure or reply timeout) within 1 minute, the AP will proceed to initiate the IP traffic and attempt to contact the switch. The infrastructure can be configured to allow this. If the AP contacts the switch it will be marked as unprovisioned so that the administrator can take corrective action.
Provisioning an AP as an 802.1X Supplicant
This section describes how an AP can be provisioned as an 802.1X supplicant using CLI or the WebUI.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Installation > Provisioning window. The list of discovered APs are displayed on this page.
2. Select the AP you want to provision.
3. Click Provision . The provisioning window opens.
4. Select the 802.1X Parameters using PEAP checkbox and enter the following credentials: a. User Name: Enter the username of the AP in the User Name field.
b. Password: Enter the password of the AP in the Password field.
5. Enter the password again in the Confirm Password field and reconfirm it.
6. Click Apply and Reboot (at the bottom of the page).
In the CLI
(host) (config)# provision-ap
(host) (AP provisioning) # apdot1x-username <username>
(host) (AP provisioning) # apdot1x-passwd <password>
270 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
(host) (AP provisioning) # reprovision ap-name <apname>
To view the 802.1X authentication details on the switch:
(host) # show ap active
Sample Configurations
The following examples show basic configurations on the switch for: n n
Configuring Authentication with an 802.1X RADIUS Server on page 271
Configuring Authentication with the Switch’s Internal Database on page 281
In the following examples: n n
Wireless clients associate to the ESSID WLAN-01 .
The following roles allow different networks access capabilities: l student l l l faculty guest system administrators
The examples show how to configure using the WebUI and CLI commands.
Configuring Authentication with an 802.1X RADIUS Server
n n n
An EAP-compliant RADIUS server provides the 802.1X authentication. The RADIUS server administrator must configure the server to support this authentication. The administrator must also configure the server to all communications with the Alcatel-Lucent switch.
The authentication type is WPA. From the 802.1X authentication exchange, the client and the switch derive dynamic keys to encrypt data transmitted on the wireless network.
802.1X authentication based on PEAP with MS-CHAPv2 provides both computer and user authentication. If a user attempts to log in without the computer being authenticated first, the user is placed into a more limited “guest” user role.
Windows domain credentials are used for computer authentication, and the user’s Windows login and password are used for user authentication. A single user sign-on facilitates both authentication to the wireless network and access to the Windows server resources.
802.1X Configuration for IAS and Windows Clients on page 1109
describes how to configure the Microsoft Internet
Authentication Server and Windows XP wireless client to operate with the switch configuration shown in this section.
Configuring Roles and Policies
You can create the following policies and user roles for: n n n n n
Student
Faculty
Guest
Sysadmin
Computer
Creating the Student Role and Policy
The student policy prevents students from using telnet, POP3, FTP, SMTP, SNMP, or SSH to the wired portion of the network. The student policy is mapped to the student user role.
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 271
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Policies page. Select Add to add the student policy.
2. For Policy Name, enter student .
3. For Policy Type, select IPv4 Session .
4. Under Rules, select Add to add rules for the policy.
a. Under Source, select user .
b. Under Destination, select alias .
The following step defines an alias representing all internal network addresses. Once defined, you can use the alias for other rules and policies.
c. Under the alias selection, click New . For Destination Name, enter Internal Network. Click Add to add a rule. For Rule Type, select network . For IP Address, enter 10.0.0.0. For Network Mask/Range, enter
255.0.0.0. Click Add to add the network range. Repeat these steps to add the network range 172.16.0.0
- 255.255.0.0. Click Done . The alias Internal Network appears in the Destination menu. This step defines an alias representing all internal network addresses. Once defined, you can use the alias for other rules and policies.
d. Under Destination, select Internal Network.
e. Under Service, select service . In the Service scrolling list, select svc-telnet .
f. Under Action, select drop .
g. Click Add .
5. Under Rules, click Add .
a. Under Source, select user .
b. Under Destination, select alias and then select Internal Network .
c. Under Service, select service . In the Service scrolling list, select svc-pop3 .
d. Under Action, select drop .
e. Click Add .
6. Repeat steps 4A-E to create rules for the following services: svc-ftp, svc-smtp, svc-snmp, and svc-ssh.
7. Click Apply .
8. Click the User Roles tab. Click Add to create the student role.
9. For Role Name, enter student .
10.Under Firewall Policies, click Add . In Choose from Configured Policies, select the student policy you previously created. Click Done .
11.Click
Apply .
In the CLI
(host)(config) #ip access-list session student
user alias “Internal Network” svc-telnet deny
user alias “Internal Network” svc-pop3 deny
user alias “Internal Network” svc-ftp deny
user alias “Internal Network” svc-smtp deny
user alias “Internal Network” svc-snmp deny
user alias “Internal Network” svc-ssh deny
(host)(config) #user-role student
session-acl student
session-acl allowall
272 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
Creating the Faculty Role and Policy
The faculty policy is similar to the student policy, however faculty members are allowed to use POP3 and
SMTP for VPN remote access from home. (Students are not permitted to use VPN remote access.) The faculty policy is mapped to the faculty user role.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Policies page. Click Add to add the faculty policy.
2. For Policy Name, enter faculty .
3. For Policy Type, select IPv4 Session .
4. Under Rules, click Add to add rules for the policy.
a. Under Source, select user .
b. Under Destination, select alias , then select Internal Network .
c. Under Service, select service . In the Service scrolling list, select svc-telnet .
d. Under Action, select drop .
e. Click Add .
f. Repeat steps A-E to create rules for the following services: svc-ftp, svc-snmp, and svc-ssh.
5. Click Apply .
6. Select the User Roles tab. Click Add to create the faculty role.
7. For Role Name, enter faculty .
8. Under Firewall Policies , click Add . In Choose from Configured Policies, select the faculty policy you previously created. Click Done .
In the CLI
(host)(config) #ip access-list session faculty
user alias “Internal Network” svc-telnet deny
user alias “Internal Network” svc-ftp deny
user alias “Internal Network” svc-snmp deny
user alias “Internal Network” svc-ssh deny
(host)(config) #user-role faculty
session-acl faculty
session-acl allowall
Creating the Guest Role and Policy
The guest policy permits only access to the internet (via HTTP or HTTPS) and only during daytime working hours. The guest policy is mapped to the guest user role.
In the WebUI
1. Navigate to the Configuration > Security > Access Control > Time Ranges page to define the time range working-hours. Click Add.
a. For Name, enter working-hours .
b. For Type, select Periodic .
c. Click Add .
d. For Start Day, click Weekday .
e. For Start Time, enter 07:30 .
f. For End Time, enter 17:00 .
g. Click Done .
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 273
h. Click Apply .
2. Click the Policies tab. Click Add to add the guest policy.
3. For e Policy Name , enter guest .
4. For Policy Type , select IPv4 Session .
5. Under Rules, click Add to add rules for the policy.
To create rules to permit access to DHCP and DNS servers during working hours: a. Under Source , select user .
b. Under Destination , select host . In Host IP, enter 10.1.1.25
.
c. Under Service , select service . In the Service scrolling list, select svc-dhcp .
d. Under Action , select permit .
e. Under Time Range , select working-hours .
f. Click Add .
g. Repeat steps A-F to create a rule for svc-dns .
To create a rule to deny access to the internal network: a. Under Source, select user .
b. Under Destination, select alias . Select Internal Network .
c. Under Service, select any .
d. Under Action, select drop .
e. Click Add .
To create rules to permit HTTP and HTTPS access during working hours: a. Under Source, select user .
b. Under Destination, select any .
c. Under Service, select service. In the Services scrolling list, select svc-http .
d. Under Action, select permit .
e. Under Time Range, select working-hours .
f. Click Add .
g. Repeat steps A-F for the svc-https service.
To create a rule that denies the user access to all destinations and all services: a. Under Source, select user .
b. Under Destination, select any .
c. Under Service, select any .
d. Under Action, select drop .
e. Click Add .
6. Click Apply .
7. Click the User Roles tab. Click Add to create the guest role.
8. For Role Name, enter guest.
9. Under Firewall Policies , click Add.
In Choose from Configured Policies, select the guest policy you previously created. Click Done .
In the CLI time-range working-hours periodic
weekday 07:30 to 17:00
(host)(config) #ip access-list session guest
user host 10.1.1.25 svc-dhcp permit time-range working-hours
274 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
user host 10.1.1.25 svc-dns permit time-range working-hours
user alias “Internal Network” any deny
user any svc-http permit time-range working-hours
user any svc-https permit time-range working-hours
user any any deny
(host)(config) #user-role guest
session-acl guest
Creating Roles and Policies for Sysadmin and Computer
The allowall policy, a predefined policy, allows unrestricted access to the network. The allowall policy is mapped to both the sysadmin user role and the computer user role.
In the WebUI
1. Navigate to Configuration > Security > Access Control > User Roles page. Click Add to create the sysadmin role.
2. For Role Name, enter sysadmin .
3. Under Firewall Policies, click Add . In Choose from Configured Policies, select the predefined allowall policy.
Click Done .
4. Click Apply .
In the CLI
(host)(config) #user-role sysadmin
session-acl allowall
Creating a computer role
In the WebUI
1. Navigate to Configuration > Security > Access Control > User Roles page. Click Add to create the computer role.
2. For Role Name, enter computer .
3. Under Firewall Policies, click Add . In Choose from Configured Policies, select the predefined allowall policy.
Click Done .
4. Click Apply.
In the CLI
Use the following command to create a computer role:
(host)(config) #user-role computer
session-acl allowall
Creating an Alias for the Internal Network
In the CLI
(host)(config) #netdestination “Internal Network”
network 10.0.0.0 255.0.0.0
network 172.16.0.0 255.255.0.0
Configuring the RADIUS Authentication Server
Configure the RADIUS server IAS1, with IP address 10.1.1.21 and shared key. The RADIUS server is configured to sent an attribute called Class to the switch; the value of this attribute is set to either “student,” “faculty,” or
“sysadmin” to identify the user’s group. The switch uses the literal value of this attribute to determine the role name.
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 275
On the switch, you add the configured server (IAS1) into a server group. For the server group, you configure the server rule that allows the Class attribute returned by the server to set the user role.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. In the Servers list, select Radius Server . In the RADIUS Server Instance list, enter IAS1 and click Add .
a. Select IAS1 to display configuration parameters for the RADIUS server.
b. For IP Address, enter 10.1.1.21.
c. For Key, enter |*a^t%183923!.
(You must enter the key string twice.) d. Click Apply .
3. In the Servers list, select Server Group. In the Server Group Instance list, enter IAS and click Add.
a. Select the server group IAS to display configuration parameters for the server group.
b. Under Servers, click New .
c. From the Server Name drop-down list, select IAS1. Click Add Server .
4. Under Server Rules, click New .
a. For Condition, enter Class.
b. For Attribute, select value-of from the drop-down list.
c. For Operand, select set role .
d. Click Add .
5. Click Apply.
In the CLI
(host)(config) #aaa authentication-server radius IAS1 host 10.1.1.21
key |*a^t%183923!
(host)(config) #aaa server-group IAS auth-server IAS1 set role condition Class value-of
Configuring 802.1X Authentication
An AAA profile specifies the 802.1X authentication profile and 802.1X server group to be used for authenticating clients for a WLAN. The AAA profile also specifies the default user roles for 802.1X and MAC authentication.
In the 802.1X authentication profile, configure enforcement of machine authentication before user authentication. If a user attempts to log in before machine authentication completes, the user is placed in the limited guest role.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. Select 802.1X Authentication Profile .
a. At the bottom of the Instance list, enter dot1x , then click Add .
b. Select the profile name you just added.
c. Select Enforce Machine Authentication .
d. For the Machine Authentication: Default Machine Role, select computer .
e. For the Machine Authentication: Default User Role, select guest .
f. Click Apply .
276 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
3. Select the AAA Profiles tab.
a. In the AAA Profiles Summary, click Add to add a new profile.
b. Enter aaa_dot1x , then click Add .
a. Select the profile name you just added.
b. For MAC Auth Default Role, select computer .
c. For 802.1X Authentication Default Role, select faculty .
d. Click Apply .
4. In the Profiles list (under the aaa_dot1x profile), select 802.1X Authentication Profile .
a. From the drop-down list, select the dot1x 802.1X authentication profile you configured previously.
b. Click Apply .
5. In the Profiles list (under the aaa_dot1x profile), select 802.1X Authentication Server Group .
a. From the drop-down list, select the IAS server group you created previously.
b. Click Apply .
In the CLI
(host)(config) #aaa authentication dot1x dot1x machine-authentication enable machine-authentication machine-default-role computer machine-authentication user-default-role guest
(host)(config) #aaa profile aaa_dot1x d>ot1x-default-role faculty mac-default-role computer authentication-dot1x dot1x d>ot1x-server-group IAS
Configuring VLANs
In this example, wireless clients are assigned to either VLAN 60 or 61 while guest users are assigned to VLAN
63. VLANs 60 and 61 split users into smaller IP subnetworks, improving performance by decreasing broadcast traffic. The VLANs are internal to the Alcatel-Lucent switch only and do not extend into other parts of the wired network. The clients’ default gateway is the Alcatel-Lucent switch, which routes traffic out to the 10.1.1.0
subnetwork.
You configure the VLANs, assign IP addresses to each VLAN, and establish the “helper address” to which client
DHCP requests are forwarded.
In the WebUI
1. Navigate to the Configuration > Network > VLANs page. Click Add to add VLAN 60.
a. For VLAN ID , enter 60 .
b. Click Apply.
c. Repeat steps A and B to add VLANs 61 and 63.
2. To configure IP parameters for the VLANs, navigate to the Configuration > Network > IP > IPInterfaces page.
a. Click Edit for VLAN 60.
b. For IP Address, enter 10.1.60.1
.
c. For Net Mask, enter 255.255.255.0
.
d. Under DHCP Helper Address, click Add.
Enter 10.1.1.25
and click Add .
e. Click Apply .
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 277
3. In the IP Interfaces page, click Edit for VLAN 61.
a. For IP Address, enter 10.1.61.1
.
b. For Net Mask, enter 255.255.255.0
.
c. Under DHCP Helper Address, click Add . Enter 10.1.1.25
and click Add.
d. Click Apply .
4. In the IP Interfaces page, click Edit for VLAN 63.
a. For IP Address, enter 10.1.63.1
.
b. For Net Mask, enter 255.255.255.0.
c. Under DHCP Helper Address, click Add . Enter 10.1.1.25
and click Add .
d. Click Apply .
5. Select the IP Routes tab.
a. For Default Gateway, enter 10.1.1.254
.
b. Click Apply .
In the CLI
(host)(config) #vlan 60
(host)(config) #interface vlan 60 ip address 10.1.60.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #vlan 61
(host)(config) #interface vlan 61 ip address 10.1.61.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #vlan 63
(host)(config) #interface vlan 63 ip address 10.1.63.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #ip default-gateway 10.1.1.254
Configuring the WLANs
In this example, default AP parameters for the entire network are: the default ESSID is WLAN-01 and the encryption mode is TKIP. A second ESSID called “guest” has the encryption mode set to static WEP with a configured WEP key.
In this example, the non-guest clients that associate to an AP are mapped into one of two different user VLANs.
The initial AP to which the client associates determines the VLAN: clients that associate to APs in the first floor of the building are mapped to VLAN 60, and clients that associate to APs in the second floor of the building are mapped to VLAN 61. Therefore, the APs in the network are segregated into two AP groups, named first-floor and second-floor. (See
Creating an AP group on page 525
for information about creating AP groups.) The guest clients are mapped into VLAN 63.
Configuring the Guest WLAN
You create and configure the virtual AP profile, guest and apply the profile to each AP group. The “guest” virtual
AP profile contains the SSID profile “guest” which configures static WEP with a WEP key.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. In the AP Group list, click Edit for first-floor.
278 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
3. Under Profiles, select Wireless LAN and then Virtual AP .
4. To create the guest virtual AP: a. Select NEW from the Add a profile drop-down list. Enter guest , and click Add.
b. In the Profile Details entry for the guest virtual AP profile, select NEW from the SSID profile drop-down list. A pop-up window allows you to configure the SSID profile.
c. For the name for the SSID profile enter guest .
d. For the Network Name for the SSID, enter guest .
e. For Network Authentication , select None .
f. For Encryption , select WEP .
g. Enter the WEP Key.
h. Click Apply to apply the SSID profile to the Virtual AP.
i.
Under Profile Details , click Apply .
5. Click on the guest virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN , select 63 .
c. Click Apply .
6. Navigate to the Configuration > Wireless > AP Configuration page.
7. In the AP Group list, click Edit for the second-floor.
8. In the Profiles list, select Wireless LAN and then Virtual AP .
9. Select guest from the Add a profile drop-down list. Click Add .
10.Click
Apply .
In the CLI
(host)(config) #wlan ssid-profile guest essid guest wepkey1 aaaaaaaaaa opmode static-wep
(host)(config) #wlan virtual-ap guest vlan 63 ssid-profile guest
(host)(config) #ap-group first-floor virtual-ap guest
(host)(config) #ap-group second-floor virtual-ap guest
Configuring the Non-Guest WLANs
You create and configure the SSID profile “WLAN-01” with the ESSID “WLAN-01” and WPA TKIP encryption. You need to create and configure two virtual AP profiles: one with VLAN 60 for the first-floor AP group and the other with VLAN 61 for the second-floor AP group. Each virtual AP profile references the SSID profile “WLAN-
01” and the previously-configured AAA profile aaa_dot1x.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. In the AP Group list, click Edit for the first-floor.
3. In the Profiles list, select Wireless LAN and then Virtual AP .
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 279
4. To configure the WLAN-01_first-floor virtual AP: a. Select NEW from the Add a profile drop-down list. Enter WLAN-01_first-floor , and click Add .
b. In the Profile Details entry for the WLAN-01_first-floor virtual AP profile, select the aaa_dot1x AAA profile you previously configured. A pop-up window displays the configured AAA profile parameters.
Click Apply .
c. From the SSID profile drop-down list, select NEW. A pop-up window allows you to configure the SSID profile.
d. Enter WLAN-01 for the name of the SSID profile.
e. For Network Name , enter WLAN-01 .
f. For Network Authentication , select WPA.
g. Click Apply .
h. At the bottom of the Profile Details page, click Apply .
5. Click on the WLAN-01_first-floor virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN , select 60.
c. Click Apply .
6. Navigate to the Configuration > Wireless > AP Configuration page.
7. In the AP Group list, click Edit for the second-floor.
8. In the Profiles list, select Wireless LAN and then Virtual AP .
9. To configure the WLAN-01_second-floor virtual AP: a. Select NEW from the Add a profile drop-down list. Enter WLAN-second-floor , and click Add .
b. In the Profile Details entry for the virtual AP profile, select aaa_dot1x from the AAA profile drop-down list. A pop-up window displays the configured AAA profile parameters. Click Apply .
c. From the SSID profile drop-down list, select WLAN-01 . A pop-up window displays the configured SSID profile parameters. Click Apply .
d. At the bottom of the Profile Details page, click Apply.
10.Click on the new virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN , select 61.
c. Click Apply .
In the CLI
(host)(config) #wlan ssid-profile WLAN-01 essid WLAN-01 opmode wpa-tkip
(host)(config) #wlan virtual-ap WLAN-01_first-floor vlan 60 aaa-profile aaa_dot1x ssid-profile WLAN-01
(host)(config) #wlan virtual-ap WLAN-01_second-floor vlan 61 aaa-profile aaa_dot1x ssid-profile WLAN-01
(host)(config) #ap-group first-floor
280 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
virtual-ap WLAN-01_first-floor ap-group second-floor virtual-ap WLAN-01_second-floor
Configuring Authentication with the Switch’s Internal Database
In the following example: n n
The switch’s internal database provides user authentication.
The authentication type is WPA. From the 802.1X authentication exchange, the client and the switch derive dynamic keys to encrypt data transmitted on the wireless network.
Configuring the Internal Database
Configure the internal database with the username, password, and role (student, faculty, or sysadmin) for each user. There is a default internal server group that includes the internal database. For the internal server group, configure a server derivation rule that assigns the role to the authenticated client.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. In the Servers list, select Internal DB .
3. Under Users, click Add User to add users.
4. For each user, enter a username and password.
5. Select a role for each user (if a role is not specified, the default role is guest).
6. Select the expiration time for the user account in the internal database.
7. Click Apply .
In the CLI
Use the privileged mode in the CLI to configure users in the switch’s internal database.
(host)(config) #local-userdb add username < user> password < password>
Configuring a Server Rule
In the WebUI
1. Navigate to the Configuration > Security > Authentication > Servers page.
2. Select Server Group to display the Server Group list.
3. Select the internal server group.
4. Under Server Rules , click New to add a server derivation rule.
a. For Condition , enter Role.
b. Select value-of from the drop-down list.
c. Select Set Role from the drop-down list.
d. Click Add .
5. Click Apply .
In the CLI
(host)(config) #aaa server-group internal set role condition Role value-of
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 281
Configuring 802.1X Authentication
An AAA profile specifies the 802.1X authentication profile and 802.1X server group to be used for authenticating clients for a WLAN. The AAA profile also specifies the default user role for 802.1X
authentication.
For this example, you enable both 802.1X authentication and termination on the switch.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page. In the profiles list, select 802.1X Authentication Profile .
a. In the Instance list, enter dot1x, then click Add .
b. Select the dot1x profile you just created.
c. Select Termination .
The defaults for EAP Method and Inner EAP Method are EAP-PEAP and EAP-MSCHAPv2, respectively.
d. Click Apply .
2. Select the AAA Profiles tab.
a. In the AAA Profiles Summary , click Add to add a new profile.
b. Enter aaa_dot1x , then click Add .
c. Select the aaa_dot1x profile you just created.
d. For 802.1X Authentication Default Role, select faculty .
e. Click Apply .
3. In the Profiles list (under the aaa_dot1x profile you just created), select 802.1X Authentication Profile .
a. Select the dot1x profile from the 802.1X Authentication Profile drop-down list.
b. Click Apply.
4. In the Profiles list (under the aaa_dot1x profile you just created), select 802.1X Authentication Server
Group .
a. Select the internal server group.
b. Click Apply .
In the CLI
(host)(config) #aaa authentication dot1x dot1x termination enable
(host)(config) #aaa profile aaa_dot1x d>ot1x-default-role student authentication-dot1x dot1x d>ot1x-server-group internal
Configuring VLANs
In this example, wireless clients are assigned to either VLAN 60 or 61 while guest users are assigned to VLAN
63. VLANs 60 and 61 split users into smaller IP subnetworks, improving performance by decreasing broadcast traffic. The VLANs are internal to the Alcatel-Lucent switch only and do not extend into other parts of the wired network. The clients’ default gateway is the Alcatel-Lucent switch, which routes traffic out to the 10.1.1.0
subnetwork.
282 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
You configure the VLANs, assign IP addresses to each VLAN, and establish the “helper address” to which client
DHCP requests are forwarded.
In the WebUI
1. Navigate to the Configuration > Network > VLAN page. Click Add to add VLAN 60.
a. For VLAN ID , enter 60 .
b. Click Apply .
c. Repeat steps A and B to add VLANs 61 and 63.
2. To configure IP parameters for the VLANs, navigate to the Configuration > Network > IP > IP Interfaces page.
a. Click Edit for VLAN 60.
b. For IP Address, enter 10.1.60.1
.
c. For Net Mask, enter 255.255.255.0
.
d. Under DHCP Helper Address, click Add.
Enter 10.1.1.25
and click Add .
e. Click Apply.
3. In the IP Interfaces page, click Edit for VLAN 61.
a. For IP Address, enter 10.1.61.1
.
b. For Net Mask, enter 255.255.255.0
.
c. Under DHCP Helper Address, click Add . Enter 10.1.1.25
and click Add .
d. Click Apply .
4. In the IP Interfaces page, click Edit for VLAN 63.
a. For IP Address, enter 10.1.63.1
.
b. For Net Mask, enter 255.255.255.0
.
c. Under DHCP Helper Address, click Add . Enter 10.1.1.25
and click Add .
d. Click Apply .
5. Select the IP Routes tab.
a. For Default Gateway, enter 10.1.1.254
.
b. Click Apply .
In the CLI
(host)(config) #vlan 60
(host)(config) #interface vlan 60 ip address 10.1.60.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #vlan 61
(host)(config) #interface vlan 61 ip address 10.1.61.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #vlan 63
(host)(config) #interface vlan 63 ip address 10.1.63.1 255.255.255.0
ip helper-address 10.1.1.25
(host)(config) #ip default-gateway 10.1.1.254
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 283
Configuring WLANs
In this example, default AP parameters for the entire network are as follows: the default ESSID is WLAN-01 and the encryption mode is TKIP. A second ESSID called guest has the encryption mode set to static WEP with a configured WEP key.
In this example, the non-guest clients that associate to an AP are mapped into one of two different user VLANs.
The initial AP to which the client associates determines the VLAN: clients that associate to APs in the first floor of the building are mapped to VLAN 60, and clients that associate to APs in the second floor of the building are mapped to VLAN 61. Therefore, the APs in the network are segregated into two AP groups, named first-floor and second-floor. (See
Creating an AP group on page 525
for information about creating AP groups.) The guest clients are mapped into VLAN 63.
Configuring the Guest WLAN
You create and configure the virtual AP profile, guest and apply the profile to each AP group. The guest virtual
AP profile contains the SSID profile, guest which configures static WEP with a WEP key.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. In the AP Group list, select first-floor .
3. In the Profiles list, select Wireless LAN and then Virtual AP .
4. To configure the guest virtual AP: a. Select NEW from the Add a profile drop-down list. Enter guest for the name of the virtual AP profile, and click Add .
b. In the Profile Details entry for the guest virtual AP profile, select NEW from the SSID profile drop-down list. A pop-up window allows you to configure the SSID profile.
c. Enter guest for the name of the SSID profile.
d. Enter guest for the Network Name.
e. For Network Authentication, select None .
f. For Encryption, select WEP .
g. Enter the WEP key.
h. Click Apply .
i.
Under Profile Details , click Apply.
5. Click on the guest virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN , select 63 .
c. Click Apply.
6. Navigate to the Configuration > Wireless > AP Configuration page.
7. In the AP Group list, select second-floor .
8. In the Profiles list, select Wireless LAN and then Virtual AP .
9. Select guest from the Add a profile drop-down list. Click Add .
10.Click
Apply .
In the CLI
(host)(config) #wlan ssid-profile guest essid guest wepkey1 aaaaaaaaaa
284 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
opmode static-wep
(host)(config) #wlan virtual-ap guest vlan 63 ssid-profile guest
(host)(config) #ap-group first-floor virtual-ap guest
(host)(config) #ap-group second-floor virtual-ap guest
Configuring the Non-Guest WLANs
You create and configure the SSID profile “WLAN-01” with the ESSID “WLAN-01” and WPA TKIP encryption. You need to create and configure two virtual AP profiles: one with VLAN 60 for the first-floor AP group and the other with VLAN 61 for the second-floor AP group. Each virtual AP profile references the SSID profile “WLAN-
01” and the previously-configured AAA profile “aaa_dot1x”.
In the WebUI
1. Navigate to the Configuration > Wireless > AP Configuration page.
2. In the AP Group list, select first-floor.
3. In the Profiles list, select Wireless LAN, then select Virtual AP.
4. To configure the WLAN-01_first-floor virtual AP: a. Select NEW from the Add a profile drop-down list. Enter WLAN-01_first-floor , and click Add .
b. In the Profile Details entry for the WLAN-01_first-floor virtual AP profile, select aaa_dot1x from the
AAA Profile drop-down list. A pop-up window displays the configured AAA parameters. Click Apply .
c. From the SSID profile drop-down list, select NEW . A pop-up window allows you to configure the SSID profile.
d. Enter WLAN-01 for the name of the SSID profile.
e. Enter WLAN-01 for the Network Name.
f. Select WPA for Network Authentication.
g. Click Apply .
h. At the bottom of the Profile Details page, click Apply .
5. Click on the WLAN-01_first-floor virtual AP profile name in the Profiles list or in Profile Details to display configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN, select 60.
c. Click Apply .
6. Navigate to the Configuration > Wireless > AP Configuration page.
7. In the AP Group list, select second-floor.
8. In the Profiles list, select Wireless LAN and then Virtual AP .
9. To create the WLAN-01_second-floor virtual AP: a. Select NEW from the Add a profile drop-down list. Enter WLAN-01_second-floor , and click Add .
b. In the Profile Details entry for the virtual AP profile, select aaa_dot1x from the AAA Profile dropdown list. A pop-up window displays the configured AAA profile parameters. Click Apply .
c. From the SSID profile drop-down list, select WLAN-01 . A pop-up window displays the configured SSID profile parameters. Click Apply .
d. At the bottom of the Profile Details page, click Apply .
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 285
10.Click on the WLAN-01_second-floor virtual AP profile name in the Profiles list or in Profile Details to display the configuration parameters.
a. Ensure that you select Virtual AP enable .
b. For VLAN , select 61.
c. Click Apply .
In the CLI
(host)(config) #wlan ssid-profile WLAN-01 essid WLAN-01 opmode wpa-tkip
(host)(config) #wlan virtual-ap WLAN-01_first-floor vlan 60 aaa-profile aaa_dot1x ssid-profile WLAN-01
(host)(config) #wlan virtual-ap WLAN-01_second-floor vlan 61 aaa-profile aaa_dot1x sid-profile WLAN-01
(host)(config) #ap-group first-floor virtual-ap WLAN-01_first-floor
(host)(config) #ap-group second-floor virtual-ap WLAN-01_second-floor
Configuring Mixed Authentication Modes
Use l2-auth-fail-through command to perform mixed authentication which includes both MAC and 802.1X
authentication. When MAC authentication fails, enable the l2-auth-fail-through command to perform
802.1X authentication.
By default the l2-auth-fail-through command is disabled.
Table 75: Mixed Authentication Modes
Authentication 1
MAC authentication
Success
Success
2
Success
Fail 802.1X
authentication
Association
Role Assignment dynamicwep
802.1X
No
Association
—
3
Success
— staticwep
MAC
4
Fail
Success dynamicwep
802.1X
5
Fail
Fail
6
Fail
—
No
Association
— staticwep logon
describes the different authentication possibilities
In the CLI
(host)(config) #aaa profile test l2-auth-fail-through
286 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
Performing Advanced Configuration Options for 802.1X
This section describes advanced configuration options for 802.1X authentication.
Configuring Reauthentication with Unicast Key Rotation
When enabled, unicast and multicast keys are updated after each reauthorization. It is a best practice to configure the time intervals for reauthentication, multicast key rotation, and unicast key rotation to be at least
15 minutes. Ensure that these intervals are mutually prime, and the factor of the unicast key rotation interval and the multicast key rotation interval is less than the reauthentication interval.
Unicast key rotation depends upon both the AP/switch and wireless client behavior. It is known that some wireless
NICs have issues with unicast key rotation.
The following is an example of the parameters you can configure for reauthentication with unicast and multicast key rotation: n n n n n n
Reauthentication: Enabled
Reauthentication Time Interval: 6011 Seconds
Multicast Key Rotation: Enabled
Multicast Key Rotation Time Interval: 1867 Seconds
Unicast Key Rotation: Enabled
Unicast Key Rotation Time Interval: 1021 Seconds
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. Select 802.1X Authentication Profile, then select the name of the profile you want to configure.
3. Select the Advanced tab. Enter the following values: l l
Reauthentication Interval: 6011
Multicast Key Rotation Time Interval: 1867 l l
Unicast Key Rotation Time Interval: 1021
Multicast Key Rotation: (select) l l
Unicast Key Rotation: (select)
Reauthentication: (select)
4. Click Apply .
In the CLI
(host)(config) #aaa authentication dot1x profile reauthentication timer reauth-period 6011 unicast-keyrotation timer ukey-rotation-period 1021 multicast-keyrotation timer mkey-rotation-period 1867
Application Single Sign-On Using L2 Authentication
This feature allows single sign-on (SSO) for different web-based applications using Layer 2 authentication information. Single sign-on for web-based application uses Security Assertion Markup Language (SAML), which happens between the web service provider and an identity provider (IDP) that the web server trusts. A request
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 287
made from the client to a web server is redirected to the IDP for authentication. If the user has already been authenticated using L2 credentials, the IDP server already knows the authentication details and returns a SAML response, redirecting the client browser to the web-based application. The user enters the web-based application without needing to enter the credentials again.
Enabling application SSO using L2 network information requires configuration on the switch and on the IDP server. The Alcatel-Lucent ClearPass Policy Manager (CPPM) is the only IDP supported. The switch has been optimized to work with CPPM to provide better functionality as an IDP.
Important Points to Remember
n n n n
CPPM is the only supported IDP.
SSO occurs after 802.1X authentication. Therefore, SSO after captive portal authentication is not supported. Roles for captive portal and SSO are mutually exclusive and, therefore, a user in the captive portal role cannot perform SSO and vice-versa.
SSO with VIA is not supported.
There is a limit on the number of concurrent sessions that can be serviced at a given instant. This limit is set at the webserver level using the web-server profile web-max-clients command. The default value is 320 for OAW-40xx Series and OAW-4x50 Series switches platforms and 25 for other switch platforms. The maximum number of concurrent SSO sessions that can be handled is dependent on the other web services being handled and the same time.
Enabling Application SSO
Enabling application SSO using L2 authentication information requires configuration on the switch and CPPM.
This feature is enabled by completing the following steps: n n
Switch: l l
Configuring an SSO-IDP Profile
Applying an SSO Profile to a User Role l
Selecting an IDP Certificate
CPPM (refer to the ClearPass Policy Manager for configuration of the following procedures): l l
Add the switch’s IP address as a network device
Add the user to the local user DB l l l l l l l
Create an enforcement profile to return the Aruba vendor-specific attribute (VSA) SSO token
Create an IDP attribute enforcement profile
Create an enforcement policy binding the Aruba VSA SSO token enforcement profile
Create an enforcement policy binding the IDP enforcement profile
Create a service, allowing the respective authentication types and authentication database, and bind the
Aruba VSA SSO token enforcement policy.
Create a service, allowing the respective authentication types and authentication database, and bind the
IDP enforcement policy.
Configure SSO for the CPPM.
Configuring SSO IDP-Profiles
Before SSO can be enabled, you must configure an SSO profile by completing the procedure detailed below.
In the WebUI
1. Navigate to Configuration > Advanced Services > All Profiles > Wireless LANs > SSO .
2. Enter the name of the SSO profile and click Add .
288 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
3. Click on the name of the IDP profile in the Instance list to edit the profile.
4. Click New .
5. Enter the name of the IDP URL in the URL Name text box.
6. Enter the IDP URL into the URL text box.
7. Click Add .
8. Repeat steps 4 through 7 for each IDP URL you are adding to the SSO profile.
9. Click Apply when all URLs have been added.
In the CLI sso idp-profile <idp profile name> idp <urlname> <url>
Applying an SSO Profile to a User Role
The newly created SSO profile must be applied to any applicable user rules that require SSO. Apply the SSO profile be completing the steps below.
In the WebUI
1. Navigate to Configuration > Security > Access Control .
2. Select the User Roles tab.
3. Select the User Role that the SSO profile will be linked to and click Edit .
4. Under Misc. Configuration , select an IDP profile from the idp profile name drop-down menu.
5. Click Apply .
In the CLI user-role <role name> sso <idp profile name>
Selecting an IDP Certificate
An SSL certificate is needed for SSL negotiation with browser. The certificate can be imported in PKCS12 format, so that it contains the certificate and private key, or the key pair can be generated and a certificate signing request (CSR) request sent to the enterprise CA server to generate a certificate which can then be uploaded to the switch.
For information about uploading or generating a certificate, see
.
After a certificate is uploaded or generated, the IDP certificate must be selected.
In the WebUI
1. Navigate to Configuration > Management > General .
2. Under IDP Server Certificate , select the IDP certificate from the Server Certificate drop-down menu.
3. Click Apply .
In the CLI
(host)(config) #web-server profile
(host)(Web Server Configuration) #idp-cert <name of the certificate>
AOS-W 6.5.3.x
| User Guide 802.1X Authentication | 289
Device Name as User Name for Non-802.1X Authentication
When a client is authenticated by non-802.1X method of authentication, the host name of the host device is used as the user name (instead of the MAC address) of the host device. When a host device tries to obtain an IP address by using DHCP, the host name of the host device in the option-12 field of DHCP request is used as the host name of the host device.
A CLI command allows the use of the host name or the MAC address of a host device as the user name of the host device. By default, the MAC address of the host device is used as the user name. If the CLI command is enabled, the host name of the host device is used as the user name.
Using Device Name as User Name
In the CLI
(host) (config) #aaa profile <profile>
(host) (AAA Profile “<profile >”) #username-from-dhcp-opt12
290 | 802.1X Authentication AOS-W 6.5.3.x | User Guide
Chapter 12
Stateful and WISPr Authentication
AOS-W supports stateful 802.1X authentication, stateful NTLM authentication, and authentication for Wireless
Internet Service Provider roaming (WISPr). Stateful authentication differs from 802.1X authentication in that the switch does not manage the authentication process directly, but instead monitors the authentication messages between a user and an external authentication server, then assigns a role to that user based upon the information in those authentication messages. WISPr authentication allows clients to roam between hotspots using different ISPs.
This chapter describes the following topics: n n n n n n n
Working With Stateful Authentication on page 291
Working With WISPr Authentication on page 292
Understanding Stateful Authentication Best Practices on page 292
Configuring Stateful 802.1X Authentication on page 292
Configuring Stateful NTLM Authentication on page 293
Configuring Stateful Kerberos Authentication on page 294
Configuring WISPr Authentication on page 295
Working With Stateful Authentication
AOS-W supports three different types of stateful authentication: n n n
Stateful 802.1X authentication : This feature allows the switch to learn the identity and role of a user connected to a third-party AP, and is useful for authenticating users to networks with APs from multiple vendors. When an 802.1X-capable access point sends an authentication request to a RADIUS server, the switch inspects this request and the associated response to learn the authentication state of the user. It then applies an identity-based user-role through the Policy Enforcement Firewall.
Stateful Kerberos authentication : Stateful Kerberos authentication configures a switch to monitor the
Kerberos authentication messages between a client and a Windows authentication server. If the client successfully authenticates via a Kerberos authentication server, the switch recognizes that the client has been authenticated and assigns that client a specified user role.
Stateful NTLM authentication : NT LAN Manager (NTLM) is a suite of Microsoft authentication and session security protocols. You can use stateful NTLM authentication to configure a switch to monitor the
NTLM authentication messages between a client and a Windows authentication server. If the client successfully authenticates via an NTLM authentication server, the switch recognizes that the client has been authenticated and assigns that client a specified user role.
The default Windows authentication method has changed from the older NTLM protocol to the newer
Kerberos protocol, starting with Windows 2000. Therefore, stateful NTLM authentication is most useful for networks with legacy, pre-Windows 2000 clients. Also note that unlike other types of authentication, all users authenticated via stateful NTLM authentication must be assigned to the user role specified in the
Stateful NTLM Authentication profile. Alcatel-Lucent’s stateful NTLM authentication does not support placing users in various roles based upon group membership or other role-derivation attributes.
AOS-W 6.5.3.x
| User Guide Stateful and WISPr Authentication | 291
Working With WISPr Authentication
WISPr authentication allows a “smart client” to authenticate to the network when roaming between Wireless
Internet Service Providers, even if the wireless hotspot uses an ISP, which the client may not have an account for.
If you are a hotspot operator using WISPr authentication, and a client that has an account with your ISP attempts to access the Internet at your hotspot, your ISP’s WISPr AAA server authenticates that client directly and allows the client to access the network. If, however, the client only has an account with a partner ISP, your
ISP’s WISPr AAA server forwards that client’s credentials to the partner ISP’s WISPr AAA server for authentication. Once the client has been authenticated on the partner ISP, it is authenticated on your hotspot’s own ISP, as per their service agreements. After your ISP sends an authentication message to the switch, the switch assigns the default WISPr user-role to that client.
AOS-W supports the following smart clients, which enable client authentication and roaming between hotspots by embedding iPass Generic Interface Specification (GIS) redirect , proxy , authentication , and logoff messages within HTML messages to the switch.
n n n n n iPass
Boingo
Trustive weRoam
AT&T
Understanding Stateful Authentication Best Practices
Before you can configure a stateful authentication feature, you must define a user-role you want to assign to the authenticated users and create a server group that includes a RADIUS authentication server for stateful
802.1X authentication or a Windows server for stateful NTLM authentication. For details on performing these tasks, refer to the following sections of this User Guide: n n n n
Roles and Policies on page 375
Configuring a RADIUS Server on page 179
Configuring a Windows Server on page 196
Configuring Server Groups on page 199
You can use the default stateful NTLM authentication and WISPr authentication profiles to manage the settings for these features, or you can create additional profiles as desired. Note that unlike most other types of authentication, stateful 802.lx authentication uses only a single Stateful 802.1X profile. This profile can be enabled or disabled, but you cannot configure more than one Stateful 802.1X profile.
Configuring Stateful 802.1X Authentication
When you configure 802.1X authentication for clients on non-Alcatel-Lucent APs, you must specify the group of RADIUS servers that performs the user authentication and select the role to assign to users who successfully complete authentication. When the user logs off or shuts down the client machine, AOS-W notes the deauthentication message from the RADIUS server and changes the user’s role from the specified authenticated role back to the login role. For details on defining a RADIUS server used for stateful 802.1X
authentication, see
Configuring a RADIUS Server on page 179
.
In the WebUI
To configure the Stateful 802.1X Authentication profile via the WebUI:
292 | Stateful and WISPr Authentication AOS-W 6.5.3.x | User Guide
1. Navigate to the Configuration > Security > Authentication > L2 Authentication page.
2. In the Profiles list, select Stateful 802.1X Authentication Profile .
3. Click the Default Role drop-down list, and select the role assigned to stateful 802.1X authenticated users.
4. Specify the timeout period for authentication requests, between 1 and 20 seconds. The default value is 10 seconds.
5. Select the Mode checkbox to enable stateful 802.1X authentication.
In the CLI
Use the commands below to configure stateful 802.1X authentication via the command-line interface. The first set of commands defines the RADIUS server used for 802.1X authentication, and the second set assigns that server to a server group. The third set associates the server group with the stateful 802.1X authentication profile, then sets the authentication role and timeout period.
(host)(config)# aaa authentication-server radius <server-name> acctport <port> authport <port> clone <server> enable host <ipaddr> key <psk> nas-identifier <string> nas-ip <ipaddr> retransmit <number> timeout <seconds> use-md5
!
(host)(config)# aaa server-group group <server-group> auth-server <server-name>
!
(host)(config)# aaa authentication stateful-dot1x server-group <server-group> default-role <role> enable timeout <seconds>
Configuring Stateful NTLM Authentication
The Stateful NTLM Authentication profile requires that you specify a server group, which includes the servers performing NTLM authentication, and the role to be assigned to users who are successfully authenticated. For details on defining a windows server used for NTLM authentication, see
Configuring a Windows Server on page
.
When the user logs off or shuts down the client machine, the user remains in the authenticated role until the user ages out, meaning there is no user traffic for the amount of time specified in the User Idle Timeout setting in the Configuration > Security > Authentication > Advanced page.
In the WebUI
To create and configure a new instance of a stateful NTLM authentication profile via the WebUI:
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page.
2. In the Profiles list, expand the Stateful NTLM Authentication Profile .
3. To define settings for an existing profile, click that profile name in the profiles list.
AOS-W 6.5.3.x
| User Guide Stateful and WISPr Authentication | 293
To create and define settings for a Stateful NTLM Authentication profile, select an existing profile, then click
Save As in the right window pane. Enter a name for the new profile in the entry field at the top of the right window pane.
4. Click the Default Role drop-down list, and select the role to be assigned to all users after they complete stateful NTLM authentication.
5. Specify the timeout period for authentication requests, between 1 and 20 seconds. The default value is 10 seconds.
6. Select the Mode checkbox to enable stateful NTLM authentication.
7. Click Apply .
8. In the Profiles list, select the Server Group entry below the Stateful NTLM Authentication profile.
9. Click the Server Group drop-down list and select the group of Windows servers you want to use for stateful NTLM authentication.
10.Click
Apply .
In the CLI
Use the commands below to configure stateful NTLM authentication via the command-line interface. The first set of commands defines the Windows server used for NTLM authentication, and the second set adds that server to a server group. The third set associates that server group with the stateful NTLM authentication profile, then defines the profile settings.
(host)(config)# aaa authentication-server windows <windows_server_name> host <ipaddr> enable
!
(host)(config)# aaa server-group group <server-group> auth-server <windows_server_name>
!
(host)(config)# aaa authentication stateful-ntlm default-role <role> enable server-group <server-group> timeout <seconds>
Configuring Stateful Kerberos Authentication
The Stateful Kerberos Authentication profile requires that you specify a server group, which includes the
Kerberos servers and the role assigned to authenticated users. For details on defining a windows server used for Kerberos authentication, see
Configuring a Windows Server on page 196 .
When the user logs off or shuts down the client machine, the user remains in the authenticated role until the user ages out, meaning there is no user traffic for the amount of time specified in the User Idle Timeout setting in the Configuration > Security > Authentication > Advanced page.
In the WebUI
To create and configure a new stateful Kerberos authentication profile via the WebUI:
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page.
2. In the Profiles list, expand the Stateful Kerberos Authentication Profile .
3. To define settings for an existing profile, click the profile name in the Profiles list.
294 | Stateful and WISPr Authentication AOS-W 6.5.3.x | User Guide
To create and define settings for a new Stateful Kerberos Authentication profile, select an existing profile, then click Save As in the right window pane. Enter a name for the new profile in the entry field at the top of the right window pane.
4. Click the Default Role drop-down list, and select the role to be assigned to all users after they complete stateful Kerberos authentication.
5. Specify the timeout period for authentication requests, from 1-20 seconds. The default value is 10 seconds.
6. Click Apply .
7. In the Profiles list, select the Server Group entry below the Stateful Kerberos Authentication profile.
8. Click the Server Group drop-down list and select the group of Windows servers you want to use for stateful Kerberos authentication.
9. Click Apply.
In the CLI
Use the commands below to configure stateful Kerberos authentication via the command-line interface. The first set of commands defines the server used for Kerberos authentication, and the second set adds that server to a server group, and the third set of commands associates that server group with the stateful NTLM authentication profile then defines the profile settings.
(host)(config)# aaa authentication-server windows <windows_server_name> host <ipaddr> enable
(host)(config)# aaa server-group group <server-group> auth-server <windows_server_name>
(host)(config)# aaa authentication stateful-kerberos default-role <role> enable server-group <server-group> timeout <seconds>
Configuring WISPr Authentication
The WISPr authentication profile includes parameters to define RADIUS attributes, default roles for authenticated WISPr users, the maximum number of authentication failures, and login wait times. The WISPr-
Location-ID, sent from the switch to the WISPr RADIUS server, is the concatenation of the ISO Country Code,
E.164 Country Code, E.164 Area Code, and SSID/Zone parameters configured in this profile.
The parameters used to define WISPr RADIUS attributes are specific to the RADIUS server your ISP uses for
WISPr authentication; contact your ISP to determine these values. You can find a list of ISO and ITU country and area codes at the ISO and ITU websites ( www.iso.org
) and http://www.itu.int
.)
In the WebUI
To create and configure a new WISPr authentication profile in the WebUI:
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page.
2. In the Profiles list, expand the WISPr Authentication Profile .
3. To define settings for an existing profile, click that profile name in the Profiles list.
To create and define settings for a new WISPr Authentication profile, select an existing profile, then click
Save As in the right window pane. Enter a name for the new profile in the entry field. at the top of the right window pane.
4. Define values for the parameters below.
AOS-W 6.5.3.x
| User Guide Stateful and WISPr Authentication | 295
Table 76: WISPr Authentication Profile Parameters
Parameter
Default Role
Description
Default role assigned to users that complete WISPr authentication.
Logon wait minimum wait
Logon wait maximum wait
If the switch’s CPU utilization has surpassed the Login wait CPU utilization threshold value , the Logon wait minimum wait parameter defines the minimum number of seconds a user has to wait to retry a login attempt. Range: 1–10 seconds. Default: 5 seconds.
If the switch’s CPU utilization has surpassed the Login wait
CPUutilization threshold value, the Logon wait maximum wait parameter defines the maximum number of seconds a user has to wait to retry a login attempt. Range: 1–10 seconds. Default: 10 seconds.
Percentage of CPU utilization at which the maximum and minimum login wait times are enforced. Range: 1–100%. Default: 60%.
The ISO Country Code section of the WISPr Location ID.
Logon wait CPU utilization threshold
WISPr Location-ID ISO Country
Code
WISPr Location-ID E.164 Country
Code
The E.164 Country Code section of the WISPr Location ID.
WISPr Location-ID E.164 Area Code The E.164 Area Code section of the WISPr Location ID.
WISPr Location-ID SSID/Zone
WISPr Operator Name
WISPr Location Name
The SSID/Zone section of the WISPr Location ID.
A name identifying the hotspot operator.
A name identifying the hotspot location. If no name is defined, the parameter uses the name of the associated AP.
5. Click Apply .
6. In the Profiles list, select the Server Group entry below the WISPr Authentication profile.
7. Click the Server Group drop-down list and select the group of RADIUS servers you want to use for WISPr authentication.
8. Click Apply .
A Boingo smart client uses a NAS identifier in the format <CarrierID>_<VenueID> for location identification. To support Boingo clients, you must also configure the NAS identifier parameter in the Radius server profile for the
WISPr server
In the CLI
Use the CLI commands below to configure WISPr authentication. The first set of commands defines the
RADIUS server used for WISPr authentication, and the second set adds that server to a server group. The third set of commands associates that server group with the WISPR authentication profile, then defines the profile settings.
(host)(config)# aaa authentication-server radius <rad_server_name> host 172.4.77.214
key qwERtyuIOp enable nas-identifier corp_venue1
!
296 | Stateful and WISPr Authentication AOS-W 6.5.3.x | User Guide
(host)(config)# aaa server-group group <server-group> auth-server <radius_server_name>
!
(host)(config)# aaa authentication wispr default-role <role> logon-wait {cpu-threshold|maximum-delay|minimum-delay} server-group <server-group> wispr-location-id-ac <wispr-location-id-ac> wispr-location-id-cc <wispr-location-id-cc> wispr-location-id-isocc <wispr-location-id-isocc> wispr-location-id-network <wispr-location-id-network> wispr-location-name-location <wispr-location-name-location> wispr-location-name-operator-name <wispr-location-name-location>
AOS-W 6.5.3.x
| User Guide Stateful and WISPr Authentication | 297
Chapter 13
Certificate Revocation
The Certificate Revocation feature enables the switch to perform real-time certificate revocation checks using the Online Certificate Status Protocol (OCSP), or traditional certificate validation using the Certificate
Revocation List (CRL) client.
Topics in this chapter include: n n n n n n
Understanding OCSP and CRL on page 298
Configuring the Switch as a CRL Client on page 301
Configuring the Switch as an OCSP Responder on page 302
Configuring the Switch as an OCSP Client on page 299
Certificate Revocation Checking for SSH Pubkey Authentication on page 303
OCSP Configuration for AOS-W VIA
Understanding OCSP and CRL
OCSP (RFC 2560) is a standard protocol that consists of an OCSP client and an OCSP responder. This protocol determines revocation status of a given digital public-key certificate without downloading the entire CRL.
CRL is the traditional method of checking certificate validity. A CRL provides a list of certificate serial numbers that have been revoked or are no longer valid. CRLs let the verifier check the revocation status of the presented certificate while verifying it. CRLs are limited to 512 entries.
Both the Delegated Trust Model and the Direct Trust Model are supported to verify digitally signed OCSP responses. Unlike the Direct Trust Model, the Delegated Trust Model does not require the OCSP responder certificates to be explicitly available on the switch.
Configuring a Switch as OCSP and CRL Clients
The switch can act as an OCSP client and issue OCSP queries to remote OCSP responders located on the intranet or Internet. Since many applications in AOS-W (such as IKE), use digital certificates, a protocol such as
OCSP needs to be implemented for revocation.
An entity that relies on the content of a certificate (a relying party) needs to check before accepting the certificate as valid. Once it is verified that the certificate has not been revoked, the OCSP client retrieves certificate revocation status from an OCSP responder. The responder may be the CA (Certificate Authority) that has issued the certificate in question, or it may be some other designated entity which provides the service on behalf of the CA. A revocation checkpoint is a logical profile that is tied to each CA certificate that the switch has
(trusted or intermediate). Also, the user can specify revocation preferences within each profile.
The OCSP request is not signed by the Alcatel-Lucent OCSP client at this time. However, the OCSP response is always signed by the responder.
Both OCSP and CRL configuration and administration is usually performed by the administrator who manages the web access policy for an organization.
In small networks where there are is no Internet connection or connection to an OCSP responder, CRL is preferable to than OCSP.
AOS-W 6.5.3.x
| User Guide Certificate Revocation | 298
Configuring an OCSP Switch as a Responder
The switch can be configured to act as an OCSP responder (server) and respond to OCSP queries from clients that want to obtain revocation status of certificates.
The OCSP responder on the switch is accessible over HTTP port 8084. You cannot configure this port. Although the OCSP responder accepts signed OCSP requests, it does not attempt to verify the signature before processing the request. Therefore, even unsigned OCSP requests are supported.
The switch as an OCSP responder provides revocation status information to Alcatel-Lucent applications that use CRLs. This is useful in small disconnected networks where clients cannot reach outside OCSP server to validate certificates. Typical scenarios include client to client or client to other server communication situations where the certificates of either party need to be validated.
Configuring the Switch as an OCSP Client
When OCSP is used as the revocation method, you need to configure the OCSP responder certificate and the
OCSP URL.
In the WebUI
1. Navigate to the Configuration > Management > Certificates > Upload page .
2. Enter a name in the Certificate Name field. This name identifies the certificate you are uploading.
3. Enter the certificate file name in the Certificate Filename field. Use the Browse button to enter the full pathname.
4. Select the certificate format from the Certificate Format drop-down menu.
5. Select OCSP Responder Cert from the Certificate Type drop-down menu.
A revocation check method (OCSP or CRL) can be chosen independently for every revocation checkpoint. In this example, we are only describing the OCSP check method.
Once this certificate is uploaded it is maintained in the certificate store for OCSP responder certificates.
These certificates are used for signature verification.
299 | Certificate Revocation AOS-W 6.5.3.x | User Guide
Figure 47 Upload a certificate
6. Click Upload . The certificate appears in the Certificate Lists pane.
7. For detailed information about an uploaded certificate, click View next to the certificate.
Figure 48 View certificate details
8. Select the Revocation Checkpoint tab.
AOS-W 6.5.3.x
| User Guide Certificate Revocation | 300
9. In the Revocation Checkpoint pane, click Edit next to the revocation checkpoint that you want to configure. The Revocation Checkpoint pane displays.
10.In the Revocation Check field, select ocsp from the Method 1 drop-down list as the primary check method.
11.In the OCSP URL field, enter the URL of the OCSP responder.
12.In the OCSP Responder Cert field, select the OCSP certificate you want to configure from the drop-down menu.
13.Click
Apply .
In the CLI
This example configures an OCSP client with the revocation check method as OCSP for revocation check point
CAroot.
The OCSP responder certificate is configured as RootCA-Ocsp_responder. The corresponding OCSP responder service is available at http://10.4.46.202/ocsp
. The check method is OCSP for revocation check point
CARoot.
(host) (config) #crypto-local pki rcp CARoot
(host) (RCP-CARoot) #ocsp-responder-cert RootCA-Ocsp_responder
(host) (RCP-CARoot) #ocsp-url http://10.4.46.202/ocsp
(host) (RCP-CARoot) #revocation-check ocsp
The show crypto-local pki OCSP ResponderCert
CLI command lists the contents of the OCSP Responder
Certificate store.
The show crypto-local pki revocation checkpoint rcp_name
CLI command shows the entire configuration for a given revocation checkpoint.
Configuring the Switch as a CRL Client
CRL is the traditional method of checking certificate validity. When you want to check certificate validity using a
CRL, import the CRL. You can import CRLs only through the WebUI.
In the WebUI
1. Navigate to the Configuration > Management > Certificates > Upload page .
2. Enter a name in the Certificate Name field. This name identifies the CRL certificate you are uploading.
3. Enter the certificate file name in the Certificate Filename field. Use Browse to enter the full pathname.
4. Select the certificate format from the Certificate Format drop-down menu.
5. Select CRL from the Certificate Type drop-down menu.
A revocation check method (OCSP or CRL) can be chosen independently for every revocation checkpoint. In this example, we are only describing the CRL check method.
Once this CRL is uploaded it is maintained in the store for CRLs. These CRLs are used for signature verification.
6. Click Upload . The CRL appears in the Certificate Lists pane. Select CRL from the Group drop-down list if you want to display only CRLs.
7. For detailed information about an uploaded CRL, click View next to the CRL.
8. Select the Revocation Checkpoint tab.
9. In the Revocation Checkpoint pane, click Edit next to the revocation checkpoint that you want to configure. The Revocation Checkpoint pane displays.
301 | Certificate Revocation AOS-W 6.5.3.x | User Guide
10.In the Revocation Check field, select crl from the Method 1 drop-down list.
11.In the CRL Location field, enter the CRL you want to use for this revocation checkpoint. The CRLs listed are files that have already been imported onto the switch.
12.Click
Apply .
In the CLI
This example configures an OCSP responder with the check method as CRL for revocation check point ROOTCassh-webui. The CRL location is crl1 and the revocation check method is crl.
(host) (config) #crypto-local pki rcp ROOTCa-ssh-webui
(host) (RCP-CARoot) #crl-location file crl1
(host) (RCP-CARoot) #revocation-check crl
Configuring the Switch as an OCSP Responder
When configured as an OCSP responder, the switch provides revocation status information to AOS-W applications that use CRLs.
In the WebUI
1. Navigate to the Configuration > Management > Certificates > Upload page .
2. Enter a name in the Certificate Name field. This name identifies the OCSP signer certificate you are uploading.
3. Enter the certificate file name in the Certificate Filename field. Use Browse to enter the full pathname.
4. Select the certificate format from the Certificate Format drop-down menu.
5. Select OCSP signer cert from the Certificate Type drop-down menu. Once this certificate is uploaded, it is maintained in the certificate store for OCSP signer certificates. These certificates are used for signature verification.
The OCSP signer cert signs OCSP responses for this revocation check point. The OCSP signer cert can be the same trusted CA as the check point, a designated OCSP signer certificate issued by the same CA as the check point or some other local trusted authority.
If you do not specify an OCSP signer cert, OCSP responses are signed using the global OCSP signer certificate. If that is not present, than an error message is sent out to clients.
The OCSP signer certificate takes precedence over the global OCSP signer certificate as it is check point specific.
6. Click Upload . The certificate appears in the Certificate Lists pane. Select OCSP signer cert from the Group drop-down list if you want to display only those certificates which are OCSP signer certificates.
7. For detailed information about an uploaded certificate, click View next to the certificate.
8. Select the Revocation Checkpoint tab.
9. Select Enable next to Enable OCSP Responder .
Enable OCSP Responder is a global knob that turns the OCSP responder service on or off on the switch. The default is disabled (off). Enabling this option automatically adds the OCSP responder port (TCP 8084) to the permit list in the CP firewall so this can be accessed from outside the switch.
10.Select the OCSP signer cert from the OCSP Certificates drop-down menu to be used to sign OCSP responses for this revocation check point.
11.In the Revocation Checkpoint pane, click Edit next to the revocation checkpoint that you want to configure. The Revocation Checkpoint pane displays.
AOS-W 6.5.3.x
| User Guide Certificate Revocation | 302
12.In the Revocation Check field, optionally select a check method from the Method 1 drop-down list.
Optionally, select a backup check method from the Method 2 drop-down list.
13.Select
Enable next to Enable OCSP Responder .
14.Select
OCSP signer cert from the OCSP Signer Cert drop-down menu.
15.In the CRL Location field, enter the CRL you want used for this revocation checkpoint. The CRLs listed are files that have already been imported onto the switch.
16.Click
Apply .
In the CLI
This example configures the switch as an OCSP responder. The OCSP responder service is enabled, the revocation check point is CAroot, the OCSP signer cert is “oscap_CA1,” and the CRL file location is “Sec1-WIN-
05PRGNGEKAO-CA-unrevoked.crl.”
(host) (config) #crypto-local pki service-ocsp-responder
(host) (config) #crypto-local pki rcp CAroot
(host) (CAroot) #ocsp-signer-cert oscsp_CA1
(host) (CAroot) #crl-location file Sec1-WIN-05PRGNGEKAO-CA-unrevoked.crl
(host) (CAroot) #enable-ocsp-responder
Certificate Revocation Checking for SSH Pubkey Authentication
This feature allows the ssh-pubkey management user to be optionally configured with a Revocation
Checkpoint (RCP). This meets the requirement for a two-factor authentication and integration of device management with PKI for SSH pubkey authentication. The AOS-W implementation of SSH using Pubkey authentication is designed for integration with smart cards or other technologies that use X.509 certificates.
The RCP checks the revocation status of the SSH user’s client certificate before permitting access. If the revocation check fails, the user is denied access using the ssh-pubkey authentication method. However, the user can still authenticate through a username and password if configured to do so.
For information about configuring a revocation checkpoint, see
.
Configuring the SSH Pubkey User with RCP
You can configure the SSH pubkey user with RCP to check the validity of the user’s x.509 certificate.
In the WebUI
1. Navigate to Configuration > Management > Administration .
2. Under Management Users , click Add . The Add User page displays.
3. Select Certificate Management , then SSH Public Key .
4. When adding an ssh-pubkey user, when revocation check is enabled, perform either of the following tasks : n n
To enable the RCP check, select a valid configured RCP from Revocation Checkpoint drop-down menu.
Select None if you do not want the RCP check enabled for the ssh pubkey user.
In the CLI
The CLI allows you to configure an optional RCP for an ssh-pubkey user. Users can still be configured without the RCP. In this example, the certificate name is
“client1-rg,”, the username is “test1,” the role name is “root,” and the rcp is “ca-rg:”
(host)(config) #mgmt-user ssh-pubkey client-cert client1-rg test1 root ?
rcp Revocation Checkpoint for ssh user's client certificate
(host)(config) #mgmt-user ssh-pubkey client-cert client1-rg test1 root rcp ca-rg
303 | Certificate Revocation AOS-W 6.5.3.x | User Guide
In this example, a user is configured without the RCP:
(host)(config) #mgmt-user ssh-pubkey client-cert client2-rg test2 root
Displaying Revocation Checkpoint for the SSH Pubkey User
The RCP checks the revocation status of the SSH user’s client certificate before permitting access. If the revocation check fails, the user is denied access using the ssh-pubkey authentication method. However, the user can still authenticate through a username and password if configured to do so. This feature allows the ssh-pubkey management user to be optionally configured with a Revocation Checkpoint (RCP). This meets the requirement for a two-factor authentication and integration of device management with PKI for SSH pubkey authentication. The AOS-W implementation of SSH using Pubkey authentication is designed for integration with smart cards or other technologies that use X.50.
Configuring the SSH Pubkey User with RCP
The column REVOCATION CHECKPOINT displays the configured RCP for the ssh-pubkey user. If no RCP is configured for the user, the word none is displayed.
In the WebUI
Navigate to Configuration > Management > Administration .
The column SSH Revocation Checkpoint displays the RCP configured (if any) for the ssh pubkey user.
In the CLI
(host)#show mgmt-user ssh-pubkey
Removing the SSH Pubkey User
In the WebUI
1. Navigate to Configuration > Management > Administration .
2. Click Delete next to the management user you want to delete.
In the CLI
(host) (config) #no mgmt-user ssh-pubkey client-cert <certname> <username>
OCSP Configuration for AOS-W VIA
In AOS-W 6.5, the OCSP configuration for AOS-W VIA is simplified with the following configuration parameters removed: n n n n ocsp-responder ike-url (OCSP responder's URL for IKE) ocsp-responder eap-url (OCSP responder's URL for EAP) ocsp-responder ike-cn (OCSP responder's CN for IKE) ocsp-responder eap-cn (OCSP responder's CN for EAP)
These parameters will be picked up directly from the certificate. The WebUI path and the CLI command to enable OCSP certificate verification are as follows.
In the WebUI
To enable the OCSP certificate verification in the WebUI, perform the following steps:
1. Navigate to Configuration > Advanced Services > All Profiles .
AOS-W 6.5.3.x
| User Guide Certificate Revocation | 304
2. In the Profiles section (left pane) of the All Profile Management page, click Other Profiles > AOS-W
VIA Connection > Default.
3. In the Profiles Details section (right pane), select the OCSP Cert verification enabled check box.
In the CLI
To enable the OCSP certificate verification, the ocsp-responder enable subcommand is introduced in the aaa authentication via connection-profile <name> command. It is disabled by default.
You can disable the OCSP certificate verification using the no ocsp-responder enable sub-command.
Example Configuration
(host) (config) #aaa authentication via connection-profile default
(host) (VIA Connection Profile "default") # ocsp-responder enable
Example Verification
The following show command helps view the status of OCSP configuration :
(host) (VIA Connection Profile "default") #show aaa authentication via connection-profile default
VIA Connection Profile "default"
--------------------------------
Parameter
---------
VIA Servers
Client Auto-Login
Value
-----
N/A
Enabled
N/A
.
.
VIA Authentication Profiles to provision
.
.
.
OCSP Cert verification enabled
.
User idle timeout
Disable
N/A
305 | Certificate Revocation AOS-W 6.5.3.x | User Guide
Chapter 14
Captive Portal Authentication
Captive portal is one of the methods of authentication supported by AOS-W. A captive portal presents a web page which requires user action before network access is granted. The required action can be simply viewing and agreeing to an acceptable use policy, or entering a user ID and password which must be validated against a database of authorized users.
You can also configure captive portal to allow clients to download the Alcatel-Lucent VPN dialer for Microsoft
VPN clients if the VPN is to be terminated on the switch. For more information about the VPN dialer, see
Private Networks on page 346 .
Topics in this chapter include: n n n n n n n n n n n
Understanding Captive Portal on page 306
Configuring Captive Portal in the Base Operating System on page 307
Using Captive Portal with a PEFNG License on page 309
Sample Authentication with Captive Portal on page 312
Configuring Guest VLANs on page 318
Configuring Captive Portal Authentication Profiles on page 319
Enabling Optional Captive Portal Configurations on page 324
Personalizing the Captive Portal Page on page 328
Creating and Installing an Internal Captive Portal on page 330
Creating Walled Garden Access on page 339
Enabling Captive Portal Enhancements
Understanding Captive Portal
You can configure captive portal for guest users, where no authentication is required, or for registered users who must be authenticated against an external server or the switch’s internal database.
While you can use captive portal to authenticate users, it does not provide for encryption of user data and should not be used in networks where data security is required. Captive portal is most often used for guest access, access to open systems (such as public hot spots), or as a way to connect to a VPN.
You can use captive portal for guest and registered users at the same time. The default captive portal web page provided with AOS-W displays login prompts for both registered users and guests. (You can customize the default captive portal page, as described in
Personalizing the Captive Portal Page on page 328 )
You can also load up to 16 different customized login pages into the switch. The login page displayed is based on the SSID to which the client associates.
Policy Enforcement Firewall Next Generation (PEFNG) License
You can use captive portal with or without the PEFNG license installed in the switch. The PEFNG license provides identity-based security to wired and wireless clients through user roles and firewall rules. You must purchase and install the PEFNG license on the switch to use identity-based security features.
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 306
There are differences in how captive portal functions work and how you configure captive portal, depending on whether the license is installed. Other parts of this chapter describe how to configure captive portal in the base operating system (without the PEFNG license) and with the license installed.
Switch Server Certificate
The Alcatel-Lucent switch is designed to provide secure services through the use of digital certificates. A server certificate installed in the switch verifies the authenticity of the switch for captive portal.
Alcatel-Lucent switches ship with a demonstration digital certificate. Until you install a customer-specific server certificate in the switch, this demonstration certificate is used by default for all secure HTTP connections such as captive portal. This certificate is included primarily for the purposes of feature demonstration and convenience and is not intended for long-term use in production networks. Users in a production environment are urged to obtain and install a certificate issued for their site or domain by a well-known certificate authority
(CA). You can generate a Certificate Signing Request (CSR) on the switch to submit to a CA. For information on how to generate a CSR and how to import the CA-signed certificate into the switch, see
Managing Certificates on page 854
in
Management Access on page 833 .
The switch can accept wild card server certificates (CN begins with an asterisk). If a wildcard certificate is uploaded (for example, CN=*.domain.com), the asterisk in CN is replaced with 'captiveportal-login' in order to derive the Captive Portal logon page URL (captiveportal-login.domain.com).
Once you have imported a server certificate into the switch, you can select the certificate to be used with captive portal as described in the following sections.
To select a certificate for captive portal using the WebUI:
1. Navigate to the Configuration > Management > General page.
2. Under Captive Portal Certificate, select the name of the imported certificate from the drop-down list.
3. Click Apply .
To select a certificate for captive portal using the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #web-server profile
(host)(Web Server Configuration) #captive-portal-cert <certificate>
To specify a different server certificate for captive portal with the CLI, use the no command to revert back to the default certificate before you specify the new certificate:
(host)(config) #web-server profile
(host)(Web Server Configuration) #captive-portal-cert ServerCert1
(host)(Web Server Configuration) #no captive-portal-cert
(host)(Web Server Configuration) #captive-portal-cert ServerCert2
Configuring Captive Portal in the Base Operating System
The base operating system (AOS-W without any licenses) allows full network access to all users who connect to an ESSID, both guest and registered users. In the base operating system, you cannot configure or customize user roles; this function is only available by installing the PEFNG license. Captive portal allows you to control or identify who has access to network resources.
When you create a captive portal profile in the base operating system, an implicit user role is automatically created with same name as the captive portal profile. This implicit user role allows only DNS and DHCP traffic between the client and network and directs all HTTP or HTTPS requests to the captive portal. You cannot directly modify the implicit user role or its rules. Upon authentication, captive portal clients are allowed full access to their assigned VLAN.
307 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
The WLAN Wizard within the AOS-W WebUI allows for basic captive portal configuration for WLANs associated with the “default” ap-group: Configuration > Wizards > WLAN Wizard . Follow the steps in the workflow pane within the wizard and refer to the help tab for assistance.
What follows are the tasks for configuring captive portal in the base AOS-W. The example server group and profile names appear inside quotation marks.
n n n n n
Create the Server Group name. In this example, the server group name is “cp-srv”.
If you are configuring captive portal for registered users, configure the server(s) and create the server group. For more information about configuring authentication servers and server groups, see
Authentication Servers on page 178
.
Create Captive Portal Authentication Profile. In this example, the profile name is “c-portal”.
Create and configure an instance of the captive portal authentication profile. Creating the captive portal profile automatically creates an implicit user role and ACL with the same name. Creating the profile “cportal” creates an implicit user role called “c-portal”. That user role allows only DNS and DHCP traffic between the client and network and directs all HTTP or HTTPS requests to the captive portal.
Create an AAA Profile. In this example, the profile name is “aaa_c-portal”.
Create and configure an instance of the AAA profile. For the initial role, enter the implicit user role that was created in
. The initial role in the profile “aaa_c-portal” must be set to “c-portal”.
Create SSID Profile. In this example, the profile name is “ssid_c-portal”.
Create and configure an instance of the virtual AP profile which you apply to an AP group or AP name.
Specify the AAA profile you created in
Create a Virtual AP Profile. In this example, the profile name is “vp_c-portal”.
Create and configure an instance of the SSID profile for the virtual AP.
The following sections present the procedure for configuring the captive portal authentication profile, the AAA profile, and the virtual AP profile using the WebUI or the command line (CLI). Configuring the VLAN and authentication servers and server groups are described elsewhere in this document.
In AOS-W 2.5.2 and later 2.5.x releases, captive portal users in the base operating system are placed into the predefined cpbase initial user role before authentication. The cpbase role is not supported in AOS-W 3.x. You need to create new captive portal profiles in the base operating system, as described in this section, which automatically generates the required policies and roles.
In the WebUI
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page. Select the
Captive Portal Authentication profile.
a. In the Captive Portal Authentication Profile Instance list, enter the name of the profile (for example, cportal ), then click Add.
b. Select the captive portal authentication profile you just created.
c. You can enable user login and/or guest login, and configure other captive portal profile parameters as described in
d. Click Apply .
2. To specify authentication servers, select Server Group under the captive portal authentication profile you just configured.
a. Select the server group (for example, cp-srv ) from the drop-down menu.
b. Click Apply.
3. Select the AAA Profiles tab.
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 308
a. In the AAA Profiles Summary, click Add to add a new profile. Enter the name of the profile (for example, aaa_c-portal ), then click Add .
b. Select the AAA profile you just created.
c. For Initial Role, select the captive portal authentication profile (for example, c-portal ) you created previously.
The Initial Role must be exactly the same as the name of the captive portal authentication profile you created.
d. Click Apply .
4. Navigate to the Configuration > Wireless > AP Configuration page. Select either the AP Group or AP
Specific tab. Click Edit for the applicable AP group name or AP name.
5. Under Profiles, select Wireless LAN, then select Virtual AP.
6. To create a new virtual AP profile, select NEW from the Add a profile drop-down menu. Enter the name for the virtual AP profile (for example, vp_c-portal ), then click Add .
a. In the Profile Details entry for the new virtual AP profile, select the AAA profile you previously created from the AAA Profile drop-down menu. A pop-up window displays the configured AAA profile parameters. Click Apply in the pop-up window.
b. From the SSID profile drop-down menu, select NEW. A pop-up window allows to you configure the SSID profile.
c. Enter the name for the SSID profile (for example, ssid_c-portal ).
d. Enter the Network Name for the SSID (for example, c-portal-ap ).
e. Click Apply in the pop-up window.
f. At the bottom of the Profile Details page, click Apply .
7. Click on the new virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select the VLAN to which users are assigned (for example, 20 ).
c. Click Apply .
In the CLI
To configure captive portal in the base operating system via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa authentication captive-portal c-portal server-group cp-srv
(host)(config) #aaa profile aaa_c-portal initial-role c-portal
(host)(config) #wlan ssid-profile ssid_c-portal essid c-portal-ap
(host)(config) #wlan virtual-ap vp_c-portal aaa-profile aaa_c-portal ssid-profile ssid_c-portal vlan 20
Using Captive Portal with a PEFNG License
The PEFNG license provides identity-based security for wired and wireless users. There are two user roles that are important for captive portal:
309 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
n n
Default user role, which you specify in the captive portal authentication profile, is the role granted to clients upon captive portal authentication. This can be the predefined guest system role.
Initial user role, which you specify in the AAA profile, directs clients who associate to the SSID to captive portal whenever the user initiates a Web browser connection. This can be the predefined logon system role.
The captive portal authentication profile specifies the captive portal login page and other configurable parameters. The initial user role configuration must include the applicable captive portal authentication profile instance.
MAC-based authentication, if enabled on the switch, takes precedence over captive portal authentication.
The following are the basic tasks for configuring captive portal using role-based access provided by the Policy
Enforcement Firewall software module. Note that you must install the PEFNG license before proceeding (see
).
n n
Configure the user role for a default user.
Create and configure user roles and policies for guest or registered captive portal users. (See
for more information about configuring policies and user roles.)
Create a server group.
If you are configuring captive portal for registered users, configure the server(s) and create the server group. (See
Authentication Servers on page 178
for more information about configuring authentication servers and server groups.)
If you are using the switch’s internal database for user authentication, use the predefined “Internal” server group.
You need to configure entries in the internal database, as described in
Authentication Servers on page 178 .
n n n n n
Create the captive portal authentication profile.
Create and configure an instance of the captive portal authentication profile. Specify the default user role for captive portal users.
Configure the initial user role.
Create and configure the initial user role for captive portal. You need to include the predefined captiveportal policy, which directs clients to the captive portal, in the initial user role configuration.
You also need to specify the captive portal authentication profile instance in the initial user role configuration. For example, if you are using the predefined logon system role for the initial role, you need to edit the role to specify the captive portal authentication profile instance.
Create the AAA Profile.
Create and configure an instance of the AAA profile. Specify the initial user role.
Create the SSID Profile “ssid_c-portal”.
Create and configure an instance of the virtual AP profile that you apply to an AP group or AP name. Specify the AAA profile you just created.
Create the Virtual AP Profile “vp_c-portal”.
Create and configure an instance of the SSID profile for the virtual AP.
The following sections present the WebUI and Command Line (CLI) procedures for configuring the captive portal authentication profile, initial user role, the AAA profile, and the virtual AP profile. Other chapters within this document detail the configuration of the user roles and policies, authentication servers, and server groups.
Configuring Captive Portal in the WebUI
To configure captive portal with PEFNG license via the WebUI:
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 310
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page.
2. Select Captive Portal Authentication Profile.
a. In the Captive Portal Authentication Profile Instance list, enter the name of the profile (for example, cportal ), then click Add .
b. Select the captive portal authentication profile you just created.
c. Select the default role (for example, employee ) for captive portal users.
d. Enable guest login and/or user login, as well as other parameters (refer to
).
e. Click Apply .
3. To specify the authentication servers, select Server Group under the captive portal authentication profile you just configured.
a. Select the server group (for example, cp-srv ) from the drop-down menu.
b. Click Apply.
4. Select the AAA Profiles tab.
a. In the AAA Profiles Summary, click Add to add a new profile. Enter the name of the profile (for example, aaa_c-portal ), then click Add .
b. Set the Initial role to a role that you will configure with the captive portal authentication profile.
c. Click Apply .
5. Navigate to the Configuration > Security > Access Control page to configure the initial user role to use captive portal authentication.
a. To edit the predefined logon role, select the System Roles tab, then click Edit for the logon role.
b. To configure a new role, first configure policy rules in the Policies tab, then select the User Roles tab to add a new user role and assign policies.
c. To specify the captive portal authentication profile, scroll down to the bottom of the page. Select the profile from the Captive Portal Profile drop-down menu, and click Change .
d. Click Apply .
6. Navigate to the Configuration > Wireless > AP Configuration page to configure the virtual AP profile.
7. Select either the AP Group or AP Specific tab. Click Edit for the applicable AP group name or AP name.
8. Under Profiles, select Wireless LAN, then select Virtual AP.
9. Select NEW from the Add a profile drop-down menu to create a new virtual AP profile. Enter the name for the virtual AP profile (for example, vp_c-portal ), then click Add.
a. In the Profile Details entry for the new virtual AP profile, select the AAA profile you previously configured. A pop-up window displays the configured AAA profile parameters. Click Apply in the pop-up window.
b. From the SSID profile drop-down menu, select NEW. A pop-up window allows you to configure the SSID profile.
c. Enter the name for the SSID profile (for example, ssid_c-portal ).
d. Enter the Network Name for the SSID (for example, c-portal-ap ).
e. Click Apply in the pop-up window.
f. At the bottom of the Profile Details page, click Apply.
10.Click on the new virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select the VLAN to which users are assigned (for example, 20 ).
c. Click Apply .
311 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
Configuring Captive Portal in the CLI
To configure captive portal with the PEFNG license via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa authentication captive-portal c-portal d>efault-role employee server-group cp-srv
(host)(config) #user-role logon captive-portal c-portal
(host)(config) #aaa profile aaa_c-portal initial-role logon
(host)(config) #wlan ssid-profile ssid_c-portal essid c-portal-ap vlan 20
(host)(config) #wlan virtual-ap vp_c-portal aaa-profile aaa_c-portal ssid-profile ssid_c-portal
Sample Authentication with Captive Portal
In the following example: n n n
Guest clients associate to the guestnet SSID which is an open wireless LAN. Guest clients are placed into
VLAN 900 and assigned IP addresses by the switch’s internal DHCP server. The user has no access to network resources beyond DHCP and DNS until they open a web browser and log in with a guest account using captive portal.
Guest users are given a login and password from guest accounts created in the switch’s internal database.
The temporary guest accounts are created and administered by the site receptionist.
Guest users must enter their assigned login and password into the captive portal login before they are given access to use web browsers (HTTP and HTTPS), POP3 email clients, and VPN clients (IPsec, PPTP, and L2TP) on the Internet and only during specified working hours. Guest users are prohibited from accessing internal networks and resources. All traffic to the Internet is source-NATed.
This example assumes a Policy Enforcement Firewall Next Generation (PEFNG) license is installed in the switch.
In this example, you create two user roles: n n guest-logon is a user role assigned to any client who associates to the guestnet SSID. Normally, any client that associates to an SSID will be placed into the logon system role. The guest-logon user role is more restrictive than the logon role.
auth-guest is a user role granted to clients who successfully authenticate via the captive portal.
Creating a Guest User Role
The guest-logon user role consists of the following ordered policies: n n n captiveportal is a predefined policy that allows captive portal authentication.
guest-logon-access is a policy that you create with the following rules: l
Allows DHCP exchanges between the user and the DHCP server during business hours while blocking other users from responding to DHCP requests.
l
Allows ICMP exchanges between the user and the switch during business hours.
block-internal-access is a policy that you create that denies user access to the internal networks.
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 312
The guest-logon user role configuration needs to include the name of the captive portal authentication profile instance. You can modify the user role configuration after you create the captive portal authentication profile instance.
Creating an Auth-guest User Role
The auth-guest user role consists of the following ordered policies: n n n n n cplogout is a predefined policy that allows captive portal logout.
guest-logon-access is a policy that you create with the following rules: l l
Allows DHCP exchanges between the user and the DHCP server during business hours while blocking other users from responding to DHCP requests.
Allows DNS exchanges between the user and the public DNS server during business hours. Traffic is source-NATed using the IP interface of the switch for the VLAN.
block-internal-access is a policy that you create that denies user access to the internal networks.
auth-guest-access is a policy that you create with the following rules: l
Allows DHCP exchanges between the user and the DHCP server during business hours while blocking other users from responding to DHCP requests.
l l
Allows DNS exchanges between the user and the public DNS server during business hours. Traffic is source-NATed using the IP interface of the switch for the VLAN.
Allows HTTP/S traffic from the user during business hours. Traffic is source-NATed using the I interface of the switch for the VLAN.
drop-and-log is a policy that you create that denies all traffic and logs the attempted network access.
Configuring Policies and Roles in the WebUI
Creating a Time Range
To create a time range via the WebUI:
1. Navigate to the Configuration > Security > Access Control > Time Ranges page to define the time range “working-hours”.
2. Click Add .
a. For Name, enter working-hours .
b. For Type, select Periodic .
c. Click Add .
d. For Start Day, click Weekday .
e. For Start Time, enter 07:30.
f. For End Time, enter 17:00 .
g. Click Done .
3. Click Apply .
To create the guest-logon-access policy via the WebUI:
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Select Add to add the guest-logon-access policy.
3. For Policy Name, enter guest-logon-access.
4. For Policy Type, select IPv4 Session .
5. Under Rules, select Add to add rules for the policy.
a. Under Source, select user .
313 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
b. Under Destination, select any .
c. Under Service, select udp . Enter 68.
d. Under Action, select drop .
e. Click Add .
6. Under Rules, click Add .
a. Under Source, select any .
b. Under Destination, select any .
c. Under Service, select service . Select svc-dhcp .
d. Under Action, select permit.
e. Under Time Range, select working-hours.
f. Click Add .
Creating Aliases
The following step defines an alias representing the public DNS server addresses. Once defined, you can use the alias for other rules and policies.
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Select Add to add the guest-logon-access policy.
3. For Policy Name, enter guest-logon-access.
4. For Policy Type, select IPv4 Session .
5. Under Rules, click Add .
a. Under Source, select user .
b. Under Destination, select alias .
c. Under the alias selection, click New .
l
For Destination Name, enter “Public DNS“.
l l
Click Add to add a rule. For Rule Type , select host .
For IP Addres s, enter 64.151.103.120.
l l l l
Click Add.
For Rule Type, select host.
For IP Address, enter 216.87.84.209.
Click Add .
Click Apply.
The alias “Public DNS” appears in the Destination menu d. Under Destination, select Public DNS.
e. Under Service, select svc-dns.
f. Under Action, select src-nat .
g. Under Time Range, select working-hours .
h. Click Add .
6. Click Apply .
Creating an Auth-Guest-Access Policy
To configure the auth-guest-access policy via the WebUI:
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Select Add to add the guest-logon-access policy.
3. For Policy Name, enter auth-guest-access .
4. For Policy Type, select IPv4 Session .
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 314
5. Under Rules, select Add to add rules for the policy.
a. Under Source, select user .
b. Under Destination, select any .
c. Under Service, select udp . Enter 68 .
d. Under Action, select drop .
e. Click Add .
6. Under Rules, click Add .
a. Under Source, select any .
b. Under Destination, select any .
c. Under Service, select service . Select svc-dhcp .
d. Under Action, select permit .
e. Under Time Range, select working-hours .
f. Click Add .
7. Under Rules, click Add .
a. Under Source, select user .
b. Under Destination, select alias . Select Public DNS from the drop-down menu.
c. Under Service, select service . Select svc-dns .
d. Under Action, select src-nat .
e. Under Time Range, select working-hours .
f. Click Add .
8. Under Rules, click Add .
a. Under Source, select user .
b. Under Destination, select any .
c. Under Service, select service . Select svc-http .
d. Under Action, select src-nat .
e. Under Time Range, select working-hours .
f. Click Add .
9. Under Rules, click Add .
a. Under Source, select user .
b. Under Destination, select any .
c. Under Service, select service . Select svc-https .
d. Under Action, select src-nat .
e. Under Time Range, select working-hours .
f. Click Add .
10.Click
Apply .
Creating an Block-Internal-Access Policy
To create the block-internal-access policy via the WebUI:
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Select Add to add the block-internal-access policy.
3. For Policy Name, enter block-internal-access.
4. For Policy Type, select IPv4 Session .
5. Under Rules, select Add to add rules for the policy.
315 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
a. Under Source, select user .
b. Under Destination, select alias .
The following step defines an alias representing all internal network addresses. Once defined, you can use the alias for other rules and policies.
c. Under the alias selection, click New . For Destination Name, enter “Internal Network”. Click Add to add a rule. For Rule Type, select network . For IP Address, enter 10.0.0.0. For Network Mask/Range, enter
255.0.0.0. Click Add to add the network range. Repeat these steps to add the network ranges
172.16.0.0 255.240.0.0 and 192.168.0.0 255.255.0.0. Click Apply . The alias “Internal Network” appears in the Destination menu d. Under Destination, select Internal Network.
e. Under Service, select any .
f. Under Action, select drop .
g. Click Add .
6. Click Apply .
Creating a Drop-and-Log Policy
To create the drop-and-log policy via the WebUI:
1. Navigate to the Configuration > Security > Access Control > Policies page.
2. Select Add to add the drop-and-log policy.
3. For Policy Name, enter drop-and-log .
4. For Policy Type, select IPv4 Session .
5. Under Rules, select Add to add rules for the policy.
a. Under Source, select user.
b. Under Destination, select any .
c. Under Service, select any.
d. Under Action, select drop .
e. Select Log .
f. Click Add .
6. Click Apply.
Creating a Guest Role
To create a guest role via the WebUI:
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Click Add .
3. For Role Name, enter guest-logon.
4. Under Firewall Policies, click Add .
5. For Choose from Configured Policies, select captiveportal from the drop-down menu.
6. Click Done.
7. Under Firewall Policies, click Add.
8. For Choose from Configured Policies, select guest-logon-access from the drop-down menu.
9. Click Done .
10.Under Firewall Policies, click Add .
11.For Choose from Configured Policies, select block-internal-access from the drop-down menu.
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 316
12.Click
Done .
13.Click
Apply .
Creating an Auth-Guest Role
To create the guest-logon role via the WebUI:
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Click Add.
3. For Role Name, enter auth-guest.
4. Under Firewall Policies, click Add .
5. For Choose from Configured Policies, select cplogout from the drop-down menu.
6. Click Done .
7. Under Firewall Policies, click Add .
8. For Choose from Configured Policies, select guest-logon-access from the drop-down menu.
9. Click Done .
10.Under Firewall Policies, click Add.
11.For Choose from Configured Policies, select block-internal-access from the drop-down menu.
12.Click
Done .
13.Under Firewall Policies, click Add.
14.For Choose from Configured Policies, select auth-guest-access from the drop-down menu.
15.Click
Done .
16.Under Firewall Policies, click Add .
17.For Choose from Configured Policies, select drop-and-log from the drop-down menu.
18.Click
Done .
19.Click
Apply .
Configuring Policies and Roles in the CLI
Defining a Time Range
To create a time range via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #time-range working-hours periodic weekday 07:30 to 17:00
Creating Aliases
To create aliases via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #netdestination “Internal Network” network 10.0.0.0 255.0.0.0
network 172.16.0.0 255.255.0.0
network 192.168.0.0 255.255.0.0
(host)(config) #netdestination “Public DNS” host 64.151.103.120
host 216.87.84.209
Creating a Guest-Logon-Access Policy
To create a guest-logon-access policy via the command-line interface, access the CLI in config mode and issue the following commands:
317 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
(host)(config) #ip access-list session guest-logon-access user any udp 68 deny any any svc-dhcp permit time-range working-hours user alias “Public DNS” svc-dns src-nat time-range working-hours
Creating an Auth-Guest-Access Policy
To create an auth-guest-access policy via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #ip access-list session auth-guest-access user any udp 68 deny any any svc-dhcp permit time-range working-hours user alias “Public DNS” svc-dns src-nat time-range working-hours user any svc-http src-nat time-range working-hours user any svc-https src-nat time-range working-hours
Creating a Block-Internal-Access Policy
To create a block-internal-access policy via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #ip access-list session block-internal-access user alias “Internal Network” any deny
Creating a Drop-and-Log Policy
To create a drop-and-log policy via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #ip access-list session drop-and-log user any any deny log
Creating a Guest-Logon Role
To create a guest-logon-role via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #user-role guest-logon session-acl captiveportal position 1 session-acl guest-logon-access position 2 session-acl block-internal-access position 3
Creating an Auth-Guest Role
To create an auth-guest role via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #user-role auth-guest session-acl cplogout position 1 session-acl guest-logon-access position 2 session-acl block-internal-access position 3 session-acl auth-guest-access position 4 session-acl drop-and-log position 5
Configuring Guest VLANs
Guests using the WLAN are assigned to VLAN 900 and are given IP addresses via DHCP from the switch.
In the WebUI
1. Navigate to the Configuration > Network > VLANs page.
a. Select the VLAN ID tab.
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 318
a. Click Add .
b. For VLAN ID, enter 900.
c. Click Apply .
2. Navigate to the Configuration > Network > IP > IP Interfaces page.
a. Click the IP Interfaces tab.
a. Click Edit for VLAN 900.
b. For IP Address, enter 192.168.200.20.
c. For Net Mask, enter 255.255.255.0.
d. Click Apply .
3. Click the DHCP Server tab.
a. Select Enable DHCP Server .
b. Click Add under Pool Configuration.
c. In the Pool Name field, enter guestpool .
d. In the Default Router field, enter 192.168.200.20.
e. In the DNS Server field, enter 64.151.103.120.
f. In the Lease field, enter 4 hours.
g. In the Network field, enter 192.168.200.0. In the Netmask field, enter 255.255.255.0.
h. Click Done.
4. Click Apply .
In the CLI
(host)(config) #vlan 900
(host)(config) #interface vlan 900
(host)(config) #ip address 192.168.200.20 255.255.255.0
(host)(config) #ip dhcp pool "guestpool"
(host)(config) #default-router 192.168.200.20
(host)(config) #dns-server 64.151.103.120
(host)(config) #lease 0 4 0
(host)(config) #network 192.168.200.0 255.255.255.0
Configuring Captive Portal Authentication Profiles
In this section, you create an instance of the captive portal authentication profile and the AAA profile. For the captive portal authentication profile, you specify the previously-created auth-guest user role as the default user role for authenticated captive portal clients and the authentication server group (“Internal”).
To configure captive portal authentication via the WebUI:
1. Navigate to the Configuration > Security > Authentication > L3 Authentication page. In the Profiles list, select Captive Portal Authentication Profile.
a. In the Captive Portal Authentication Profile Instance list, enter guestnet for the name of the profile, then click Add .
b. Select the captive portal authentication profile you just created.
c. For Default Role, select auth-guest .
d. Select User Login.
e. Deselect (uncheck) Guest Login.
f. Click Apply .
2. Select Server Group under the guestnet captive portal authentication profile you just created.
319 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
a. Select internal from the Server Group drop-down menu.
b. Click Apply .
To configure captive portal authentication via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa authentication captive-portal guestnet d>efault-role auth-guest user-logon no guest-logon server-group internal
Modifying the Initial User Role
The captive portal authentication profile specifies the captive portal login page and other configurable parameters. The initial user role configuration must include the applicable captive portal authentication profile instance. Therefore, you need to modify the guest-logon user role configuration to include the guestnet captive portal authentication profile.
To modify the guest-logon role via the WebUI:
1. Navigate to the Configuration > Security > Access Control > User Roles page.
2. Select Edit for the guest-logon role.
3. Scroll down to the bottom of the page.
4. Select the captive portal authentication profile you just created from the Captive Portal Profile drop-down menu, and click Change.
5. Click Apply .
To modify the guest-logon role via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #user-role guest-logon captive-portal guestnet
Configuring the AAA Profile
In this section, you configure the guestnet AAA profile, which specifies the previously-created guest-logon role as the initial role for clients who associate to the WLAN.
To configure the AAA profile via the WebUI:
1. Navigate to the Configuration > Security > Authentication > AAA Profiles page.
2. In the AAA Profiles Summary, click Add to add a new profile. Enter guestnet for the name of the profile, then click Add .
3. For Initial role, select guest-logon.
4. Click Apply.
To configure the AAA profile via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa profile guestnet initial-role guest-logon
Configuring the WLAN
In this section, you create the guestnet virtual AP profile for the WLAN. The guestnet virtual AP profile contains the SSID profile guestnet (which configures opensystem for the SSID) and the AAA profile guestnet .
To configure the guest WLAN via the WebUI:
1. Navigate to the Configuration > Wireless > AP Configuration page.
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 320
2. Select either AP Group or AP Specific tab. Click Edit for the AP group or AP name.
3. To configure the virtual AP profile, navigate to the Configuration > Wireless > AP Configuration page.
Select either the AP Group or AP Specific tab. Click Edit for the applicable AP group name or AP name.
4. Under Profiles, select Wireless LAN, then select Virtual AP.
5. To create a new virtual AP profile, select NEW from the Add a profile drop-down menu. Enter the name for the virtual AP profile (for example, guestnet ), and click Add .
a. In the Profile Details entry for the new virtual AP profile, select the AAA profile you previously configured. A pop-up window displays the configured AAA profile parameters. Click Apply in the pop-up window.
b. From the SSID profile drop-down menu, select NEW. A pop-up window allows you to configure the SSID profile.
c. Enter the name for the SSID profile (for example, guestnet ).
d. Enter the Network Name for the SSID (for example, guestnet ).
e. For Network Authentication, select None.
f. For Encryption, select Open.
g. Click Apply in the pop-up window.
h. At the bottom of the Profile Details page, click Apply.
6. Click on the new virtual AP name in the Profiles list or in Profile Details to display configuration parameters.
a. Make sure Virtual AP enable is selected.
b. For VLAN, select the ID of the VLAN in which captive portal users are placed (for example, VLAN 900) .
c. Click Apply.
To configure the guest WLAN via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #wlan ssid-profile guestnet essid guestnet opmode opensystem
(host)(config) #aaa profile guestnet initial-role guest-logon
(host)(config) #wlan virtual-ap guestnet vlan 900 aaa-profile guestnet ssid-profile guestnet
Managing User Accounts
Temporary user accounts are created in the internal database on the switch. You can create a user role which will allow a receptionist to create temporary user accounts. Guests can use the accounts to log into a captive portal login page to gain Internet access.
See
Creating Guest Accounts on page 875
for more information about configuring guest provisioning users and administering guest accounts.
Configuring Captive Portal Configuration Parameters
describes configuration parameters on the WebUI Captive Portal Authentication profile page.
In the CLI, you configure these options with the aaa authentication captive-portal commands.
321 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
Table 77: Captive Portal Authentication Profile Parameters
Parameter
Default Role
Description
Role assigned to the Captive Portal user upon login. When both user and guest logon are enabled, the default role applies to the user logon; users logging in using the guest interface are assigned the guest role.
Default: guest
Default Guest Role
Redirect Pause
Login Page
User Logon
Guest Login
Logout popout window
Use HTTP for authentication
Logon wait minimum wait
Logon wait maximum wait
Logon wait CPU utilization threshold
Max Authentication failures
Show FDQN
Role assigned to guest.
Default: guest
Time, in seconds, that the system remains in the initial welcome page before redirecting the user to the final web URL. If set to 0, the welcome page displays until the user clicks on the indicated link.
Default: 10 seconds
URL of the page that appears for the user logon. This can be set to any URL.
Default: /auth/index.html
Enables Captive Portal with authentication of user credentials.
Default: Enabled
Enables Captive Portal logon without authentication.
Default: Disabled
Enables a pop-up window with the Logout link for the user to logout after logon. If this is disabled, the user remains logged in until the user timeout period has elapsed or the station reloads.
Default: Enabled
Use HTTP protocol on redirection to the Captive Portal page. If you use this option, modify the captive portal policy to allow HTTP traffic.
Default: disabled (HTTPS is used)
Minimum time, in seconds, the user will have to wait for the logon page to pop up if the CPU load is high. This works in conjunction with the Logon wait CPU utilization threshold parameter.
Default: 5 seconds
Configure parameters for the logon wait interval
Default: 10 seconds
CPU utilization percentage above which the Logon wait interval is applied when presenting the user with the logon page.
Default: 60%
Maximum number of authentication failures before the user is blacklisted.
Default: 0
Allows the user to see and select the fully-qualified domain name (FQDN) on the login page. The FQDNs shown are specified when configuring individual servers for the server group used with captive portal authentication.
Default: Disabled
Authentication Protocol
Select the PAP, CHAP or MS-CHAPv2 authentication protocol.
NOTE: Do not use the CHAP = option unless instructed to do so by anAlcatel-Lucent representative.
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 322
Parameter
Logon Page
Welcome Page
Show Welcome
Page
Add switch IP address in redirection URL
Add User VLAN in the Redirection URL
Add a switch interface in the redirection URL
Allow only one active user session
White List
Description
URL of the page that appears before logon. This can be set to any URL.
Default: /auth/index.html
URL of the page that appears after logon and before redirection to the web URL. This can be set to any URL.
Default: /auth/welcome.html
Displays the configured welcome page before the user is redirected to their original
URL. If this option is disabled, users are redirected to the web URL immediately after they log in.
Default: Enabled
Sends the switch’s IP address in the redirection URL when external captive portal servers are used. An external captive portal server can determine the switch from which a request originated by parsing the ‘switchip’ variable in the URL.
Default: Disabled
Sends the user’s VLAN ID in the redirection URL when external captive portal servers are used.
Sends the switch’s interface IP address in the redirection URL when external captive portal servers are used. An external captive portal server can determine the switch from which a request originated by parsing the ‘switchip’ variable in the URL. This parameter requires the Public Access license.
Black List
Show Acceptable
Use Policy Page
Allows only one active user session at a time.
Default: Disabled
To add a netdestination to the captive portal whitelist, enter the destination host or subnet, then click Add.
The netdestination will be added to the whitelist. To remove a netdestination from the whitelist, select it in the whitelist field, then click Delete .
If you have not yet defined a netdestination, use the CLI command netdestination to define a destination host or subnet before you add it to the whitelist.
This parameter requires the Public Access license.
To add a netdestination to the captive portal blacklist, enter the destination host or subnet, then click Add . The netdestination will be added to the blacklist. To remove a netdestination from the blacklist, select it in the blacklist field, then click Delete .
If you have not yet defined a netdestination, use the CLI command netdestination to define a destination host or subnet before you add it to the blacklist.
Show the acceptable use policy page before the logon page.
Default: Disabled
323 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
Parameter
User idle timeout
Redirect URL
URL Hash Key
Description
The user idle timeout value for this profile. Specify the idle timeout value for the client in seconds. Valid range is 30-15300 in multiples of 30 seconds. Enabling this option overrides the global settings configured in the AAA timers. If this is disabled, the global settings are used.
URL to which an authenticated user will be directed. This parameter must be an absolute URL that begins with either http:// or https:// .
If a redirection URL is defined, enter a URL Hash Key to hash the redirect URL using the specified key.
This parameter enhances security for the Clearpass Guest login URL so that Clearpass can trust and ensure that the client MAC address in the redirect URL has not been tampered with by anyone. Default: Disabled.
Enabling Optional Captive Portal Configurations
The following are optional captive portal configurations: n n n n n
Uploading Captive Portal Pages by SSID Association on page 324
Changing the Protocol to HTTP on page 325
Configuring Redirection to a Proxy Server on page 326
Redirecting Clients on Different VLANs on page 327
Web Client Configuration with Proxy Script on page 327
Uploading Captive Portal Pages by SSID Association
You can upload custom login pages for captive portal into the switch through the WebUI (refer to
Installing an Internal Captive Portal on page 330
). The SSID to which the client associates determines the captive portal login page displayed.
You specify the captive portal login page in the captive portal authentication profile, along with other configurable parameters. The initial user role configuration must include the applicable captive portal authentication profile instance. (In the case of captive portal in the base operating system, the initial user role is automatically created when you create the captive portal authentication profile instance.) You then specify the initial user role for captive portal in the AAA profile for the WLAN.
When you have multiple captive portal login pages loaded in the switch, you must configure a unique initial user role and user role, and captive portal authentication profile, AAA profile, SSID profile, and virtual AP profile for each WLAN that will use captive portal. For example, if you want to have different captive portal login pages for the engineering, business and faculty departments, you need to create and configure according to
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 324
Table 78: Captive Portal login Pages
Entity Engineering
Captive portal login page
/auth/eng-login.html
Captive portal user role eng-user
Captive portal authentication profile
Initial user role
AAA profile
SSID profile
Virtual AP profile eng-cp
(Specify /auth/englogin.html and eng-user) eng-logon
(Specify the eng-cp profile) eng-aaa
(Specify the eng-logon user role) eng-ssid eng-vap
Business
/auth/bus-login.html
bus-user bus-cp
(Specify /auth/buslogin.html and bus-user) bus-logon
(Specify the bus-cp profile) bus-aaa
(Specify the bus-logon user role) bus-ssid bus-vap
Faculty
/auth/fac-login.html
fac-user fac-cp
(Specify /auth/buslogin.html and fac-user) fac-logon
(Specify the fac-logon profile) fac-aaa
(Specify the fac-logon user role) fac-ssid fac-vap
Changing the Protocol to HTTP
By default, the HTTPS protocol is used on redirection to the Captive Portal page. If you need to use HTTP instead, you need to do the following: n n
Modify the captive portal authentication profile to enable the HTTP protocol.
For captive portal with role-based access only —Modify the captiveportal policy to permit HTTP traffic instead of HTTPS traffic.
In the base operating system, the implicit ACL captive-portal-profile is automatically modified.
To change the protocol to HTTP via the WebUI:
1. Edit the captive portal authentication profile by navigating to the Configuration > Security >
Authentication > L3 Authentication page.
a. Enable (select) “Use HTTP for authentication”.
b. Click Apply.
2. (For captive portal with role-based access only) Edit the captiveportal policy by navigating to the
Configuration > Security > Access Control > Policies page.
a. Delete the rule for “user mswitch svc-https dst-nat”.
b. Add a new rule with the following values and move this rule to the top of the rules list: n source is user n n destination is the mswitch alias service is svc-http n action is dst-nat c. Click Apply.
To change the protocol to HTTP via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa authentication captive-portal profile protocol-http
325 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
(For captive portal with role-based access only)
(host)(config) #ip access-list session captiveportal no user alias mswitch svc-https dst-nat user alias mswitch svc-http dst-nat user any svc-http dst-nat 8080 user any svc-https dst-nat 8081
Configuring Redirection to a Proxy Server
You can configure captive portal to work with proxy Web servers. When proxy Web servers are used, browser proxy server settings for end users are configured for the proxy server’s IP address and TCP port. When the user opens a Web browser, the HTTP/S connection request must be redirected from the proxy server to the captive portal on the switch.
To configure captive portal to work with a proxy server: n n
(For captive portal with base operating system) Modify the captive portal authentication profile to specify the proxy server’s IP address and TCP port.
(For captive portal with role-based access) Modify the captiveportal policy to have traffic for the proxy server’s port destination NATed to port 8088 on the switch.
The base operating system automatically modifies the implicit ACL captive-portal-profile .
The following sections describe how use the WebUI and CLI to configure the captive portal with a proxy server.
When HTTPS traffic is redirected from a proxy server to the switch, the user’s browser will display a warning that the subject name on the certificate does not match the hostname to which the user is connecting.
To redirect proxy server traffic using the WebUI:
1. For captive portal with Alcatel-Lucent base operating system, edit the captive portal authentication profile by navigating to the Configuration > Security > Authentication > L3 Authentication page.
a. For Proxy Server, enter the IP address and port for the proxy server.
b. Click Apply .
2. For captive portal with role-based access, edit the captiveportal policy by navigating to the Configuration
> Security > Access Control > Policies page.
3. Add a new rule with the following values: a. Source is user b. Destination is any c. Service is TCP d. Port is the TCP port on the proxy server e. Action is dst-nat f. IP address is the IP address of the proxy port g. Port is the port on the proxy server
4. Click Add to add the rule. Use the up arrows to move this rule just below the rule that allows HTTP(S) traffic.
5. Click Apply .
To redirect proxy server traffic via the command-line interface, access the CLI in config mode and issue the following commands.
For captive portal with Alcatel-Lucent base operating system:
(host)(config) #aaa authentication captive-portal profile proxy host ipaddr port port
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 326
For captive portal with role-based access:
(host)(config) #ip access-list session captiveportal user alias mswitch svc-https permit user any tcp port dst-nat 8088 user any svc-http dst-nat 8080 user any svc-https dst-nat 8081
Redirecting Clients on Different VLANs
You can redirect wireless clients that are on different VLANs (from the switch’s IP address) to the captive portal on the switch. To do this:
1. Specify the redirect address for the captive portal.
2. For captive portal with the PEFNG license only, you need to modify the captiveportal policy that is assigned to the user. To do this: a. Create a network destination alias to the switch interface.
b. Modify the rule set to allow HTTPS to the new alias instead of the mswitch alias.
In the base operating system, the implicit ACL captive-portal-profile is automatically modified.
This example shows how to use the command-line interface to create a network destination called cp-redirect and use that in the captiveportal policy:
(host)(config) #ip cp-redirect-address ipaddr
For captive portal with PEFNG license:
(host)(config) #netdestination cp-redirect ipaddr
(host)(config) #ip access-list session captiveportal user alias cp-redirect svc-https permit user any svc-http dst-nat 8080 user any svc-https dst-nat 8081
Web Client Configuration with Proxy Script
If the web client proxy configuration is distributed through a proxy script (a
.pac
file), you need to configure the captiveportal policy to allow the client to download the file. Note that in order modify the captiveportal policy, you must have the PEFNG license installed in the switch.
To allow clients to download proxy script via the WebUI:
1. Edit the captiveportal policy by navigating to the Configuration > Security > Access Control >
Policies page.
2. Add a new rule with the following values: l
Source is user l l l l
Destination is host
Host IP is the IP address of the proxy server
Service is svc-https or svc-http
Action is permit
3. Click Add to add the rule. Use the up arrows to move this rule above the rules that perform destination
NAT.
4. Click Apply .
To allow clients to download proxy script via the command-line interface, access the CLI in config mode and issue the following commands:
327 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
(host)(config) #ip access-list session captiveportal user alias mswitch svc-https permit user any tcp port dst-nat 8088 user host ipaddr svc-https permit user any svc-http dst-nat 8080 user any svc-https dst-nat 8081
Personalizing the Captive Portal Page
The following can be personalized on the default captive portal page: n n n
Captive portal background
Page text
Acceptance Use Policy
The background image and text should be visible to users with a browser window on a 1024 by 768 pixel screen. The background should not clash if viewed on a much larger monitor. A good option is to have the background image at 800 by 600 pixels, and set the background color to be compatible. The maximum image size for the background can be around 960 by 720 pixels, as long as the image can be cropped at the bottom and right edges. Leave space on the left side for the login box.
You can create your own web pages and install them in the switch for use with captive portal. See “Internal
Captive Portal” on page 265
1. Navigate to the Configuration > Management > Captive Portal > Customize Login Page page.
You can choose one of three page designs. To select an existing design, click the first or the second page design present.
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 328
2. To customize the page background: a. Select the YOUR CUSTOM BACKGROUND page.
b. Under Additional options , enter the location of the JPEG image in the Upload your own custom background field.
c. Set the background color in the Custom page background color field. The color code must a hexadecimal value in the format #hhhhhh.
d. To view the page background changes, click Submit at the bottom on the page and then click the View
CaptivePortal link. The User Agreement Policy page appears and displays the Captive Portal page as it will be seen by users
3. To customize the captive portal background text: a. Enter the text that needs to be displayed in the Page Text (in HTML format) message box.
b. To view the background text changes, click Submit at the bottom on the page and then click the View
CaptivePortal link. The User Agreement Policy page appears.
c. Click Accept.
This displays the Captive Portal page as it will be seen by users.
4. To customize the text under the Acceptable Use Policy: a. Enter the policy information in the Policy Text text box. Use this only in the case of guest logon.
b. To view the use policy information changes, click Submit at the bottom on the page and then click the
View CaptivePortal link. The User Agreement Policy page appears. The text you entered appears in the Acceptable Use Policy text box.
c. Click Accept.
This displays the Captive Portal page as it will be seen by users
.
329 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
Creating and Installing an Internal Captive Portal
If you do not wish to customize the default captive portal page, you can use the following procedures to create and install a new internal captive portal page. This section describes the following topics: n n n n n n n n
Creating a New Internal Web Page on page 330
Installing a New Captive Portal Page on page 332
Displaying Authentication Error Messages on page 332
Reverting to the Default Captive Portal on page 333
Configuring Localization on page 333
Customizing the Welcome Page on page 336
Customizing the Pop-Up box on page 338
Customizing the Logged Out Box on page 339
Creating a New Internal Web Page
In addition to customizing the default captive portal page, you can also create your own internal web page. A custom web page must include an authentication form to authenticate a user. The authentication form can include any of the following variables listed in
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 330
Table 79: Web Page Authentication Variables
Variable user password
FQDN
Description
(Required)
(Required)
The fully-qualified domain name (this is dependent on the setting of the switch and is supported only in Global Catalog Servers software.
The form can use either the "get" or the "post" methods, but the "post" method is recommended. The form's action must absolutely or relatively reference https://<switch_IP>/auth/index.html/u .
You can construct an authentication form using the following HTML:
<FORM method="post" ACTION="/auth/index.html/u">
...
</FORM>
A recommended option for the <FORM> element is: autocomplete="off"
This option prevents Internet Explorer from caching the form inputs. The form variables are input using any form control method available such as INPUT, SELECT, TEXTAREA, and BUTTON. Example HTML code follows.
Username Example
Minimal:
<INPUT type="text" name="user">
Recommended Options: accesskey="u" Sets the keyboard shortcut to 'u'
SIZE="25 "Sets the size of the input box to 25
VALUE= ""Ensures no default value
Password Example
Minimal:
<INPUT type="password" name="password">
Recommended Options: accesskey="p" Sets the keyboard shortcut to 'p'
SIZE="25 "Sets the size of the input box to 25
VALUE= ""Ensures no default value
FQDN Example
Minimal:
<SELECT name=fqdn>
<OPTION value="fqdn1" SELECTED>
<OPTION value="fqdn2">
</SELECT>
Recommended Options:
None
Finally, an HTML also requires an input button:
<INPUT type="submit">
331 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
Basic HTML Example
<HTML>
<HEAD>
</HEAD>
<BODY>
<FORM method="post" autocomplete="off" ACTION="/auth/index.html/u">
Username:<BR>
<INPUT type="text" name="user" accesskey="u" SIZE="25" VALUE="">
<BR>
Password:<BR>
<INPUT type="password" name="password" accesskey="p" SIZE="25"
<BR>
VALUE="">
<INPUT type="submit">
</FORM>
</BODY>
</HTML>
You can find a more advanced example simply by using your browser’s "view-source" function while viewing the default captive portal page.
Installing a New Captive Portal Page
You can install the captive portal page by using the Maintenance function of the WebUI.
Log into the WebUI and navigate to Configuration > Management > Captive Portal > Upload Custom
Login Pages .
This page lets you upload your own files to the switch. There are different page types that you can choose: n n n
Captive Portal Login (top level): This type uploads the file into the switch and sets the captive portal page to reference the file that you are uploading. Use with caution on a production switch as this takes effect immediately.
Captive Portal Welcome Page: This type uploads the file that appears after logon and before redirection to the web URL. The display of the welcome page can be disabled or enabled in the captive portal profile.
Content: The content page type allows you to upload all miscellaneous files that you need to reference from your main captive portal login page. This can be used for images, scripts or any other file that you need to reference. These files are uploaded into the same directory as the top level captive portal page and thus all files can be referenced relatively.
Uploaded files can be referenced using: https://<switch_IP>/upload/custom/<CP-Profile-Name>/<file>
Displaying Authentication Error Messages
This section contains a script that performs the following tasks: n n
When the user is redirected to the main captive portal login when there is authentication failure, the redirect
URL includes a query parameter "errmsg" which java script can extract and display.
Store the originally requested URL in a cookie so that once the user has authenticated, they are automatically redirected to its original page. Note that for this feature to work, you need AOS-W release
2.4.2.0 or later. If you don't want this feature, delete the part of the script shown in red.
<script>
{ function createCookie(name,value,days)
{
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 332
if (days)
{ var date = new Date(); date.setTime(date.getTime()+(days*24*60*60*1000)); var expires = "; expires="+date.toGMTString();
} else var expires = ""; document.cookie = name+"="+value+expires+"; path=/";
} var q = window.location.search; var errmsg = null; if (q && q.length > 1) { q = q.substring(1).split(/[=&]/); for (var i = 0; i < q.length - 1; i += 2) { if (q[i] == "errmsg") { errmsg = unescape(q[i + 1]); break;
} if (q[i] == "host") { createCookie('url',unescape(q[i+1]),0)
}
}
} if (errmsg && errmsg.length > 0) { errmsg = "<div id='errorbox'>\n" + errmsg + "\n</div>\n"; document.write(errmsg);
}
}
</script>
Reverting to the Default Captive Portal
You can reassign the default captive portal site using the "Revert to factory default settings" check box in the
"Upload Custom Login Pages" section of the Maintenance tab in the WebUI.
Configuring Localization
The ability to customize the internal captive portal provides you with a very flexible interface to the Alcatel-
Lucent captive portal system. However, other than posting site-specific messages onto the captive portal website, the most common type of customization is likely to be language localization. This section describes a simple method for creating a native language captive portal implementation using the Alcatel-Lucent internal captive portal system.
1. Customize the configurable parts of the captive portal settings to your liking. To do this, navigate to the
Configuration > Management > Captive Portal > Customize Login Page in the WebUI:
For example, choose a page design, upload a custom logo and/or a custom background. Also include any page text and acceptable use policy that you would like to include. Put this in your target language or else you will need to translate this at a later time.
Ensure that Guest login is enabled or disabled as necessary by navigating to the Configuration > Security
> Authentication > L3 Authentication > Captive Portal Authentication Profile page to create or edit the captive portal profile. Select or deselect "Guest Login".
2. Click Submit and then click on View Captive Portal.
Check that your customization and text/html is correct, with the default interface still in English and the character set still autodetects to ISO-8859-1.
Repeat steps 1 and 2 until you are satisfied with your page.
333 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
3. Once you have a page you find acceptable, click on View Captive Portal one more time to display your login page. From your browser, choose "View->Source" or its equivalent. Your system will display the HTML source for the captive portal page. Save this source as a file on your local system.
4. Open the file that you saved in
, using a standard text editor, and make the following changes: a. Fix the character set. The default <HEAD>...</HEAD> section of the file will appear as:
<head>
<title>Portal Login</title>
<link href="default1/styles.css" rel="stylesheet" media="screen" type="text/css" />
<script language="javascript" type="text/javascript"> function showPolicy()
{win = window.open("/auth/acceptableusepolicy.html", "policy",
"height=550,width=550,scrollbars=1");}
</script>
</head>
In order to control the character set that the browser will use to show the text with, you will need to insert the following line inside the <HEAD>...</HEAD> element:
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS"/>
Replace the "Shift_JIS" part of the above line with the character set that is used by your system. In theory, any character encoding that has been registered with IANA can be used, but you must ensure that any text you enter uses this character set and that your target browsers support the required character set encoding.
b. The final <HEAD>...</HEAD> portion of the document should look similar to this:
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS"/>
<title>Portal Login</title>
<link href="default1/styles.css" rel="stylesheet" media="screen" type="text/css" />
<script language="javascript" type="text/javascript"> function showPolicy()
{win = window.open("/auth/acceptableusepolicy.html", "policy",
"height=550,width=550,scrollbars=1");}
</script>
</head> c. Fix references: If you have used the built-in preferences, you will need to update the reference for the logo image and the CSS style sheet.
To update the CSS reference, search the text for "<link href" and update the reference to include "/auth/" in front of the reference. The original link should look similar to the following:
<link href="default1/styles.css" rel="stylesheet" media="screen" type="text/css" />
This should be replaced with a link like the following:
<link href="/auth/default1/styles.css" rel="stylesheet" media="screen" type="text/css" />
The easiest way to update the image reference is to search for "src" using your text editor and updating the reference to include "/auth/" in front of the image file. The original link should look similar to the following:
<img src="default1/logo.gif"/>
This should be replaced with a link like this:
<img src="/auth/default1/logo.gif"/> d. Insert javascript to handle error cases:
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 334
When the switch detects an error situation, it will pass the user's page a variable called "errmsg" with a value of what the error is in English. Currently, only "Authentication Failed" is supported as a valid error message.
To localize the authentication failure message, replace the following text (it is just a few lines below the
<body> tag):
<div id="errorbox" style="display: none;">
</div> with the script below. You will need to translate the "Authentication Failed" error message into your local language and add it into the script below where it states: localized_msg="...":
<script>
{ var q = window.location.search; var errmsg = null; if (q && q.length > 1) { q = q.substring(1).split(/[=&]/); for (var i = 0; i < q.length - 1; i += 2) { if (q[i] == "errmsg") { errmsg = unescape(q[i + 1]); break;
}
}
} if (errmsg && errmsg.length > 0) { switch(errmsg) { case "Authentication Failed": localized_msg="Authentication Failed"; break; default: localised_msg=errmsg; break;
} errmsg = "<div id='errorbox'>\n" + localised_msg + "\n</div>\n";
}; document.write(errmsg);
}
</script> e. Translate the web page text. Once you have made the changes as above, you only need to translate the rest of the text that appears on the page. The exact text that appears will depend on the switch settings when you originally viewed the captive portal. You will need to translate all relevant text such as
"REGISTERED USER", "USERNAME", "PASSWORD", the value="" part of the INPUT type="submit" button and all other text. Ensure that the character set you use to translate into is the same as you have selected in part i) above.
Feel free to edit the HTML as you go if you are familiar with HTML.
5. After saving the changes made in step 4 above, upload the file to the switch using the
Configuration > Management > Captive Portal > Upload Custom Login Pages section of the WebUI.
Choose the captive portal profile from the drop-down menu. Browse your local computer for the file you saved. For Page Type, select “Captive Portal Login”. Ensure that the "Revert to factory default settings" box is NOT checked and click Apply . This will upload the file to the switch and set the captive portal profile to use this page as the redirection page.
In order to check that your site is operating correctly, go back to the "Customize Login Page" and click on
"View Captive Portal" to view the page you have uploaded. Check that your browser has automatically detected the character set and that your text is not garbled.
335 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
To make any adjustments to your page, edit your file locally and simply re-upload to the switch in order to view the page again.
6. Finally, it is possible to customize the welcome page on the switch, however for language localization it is recommended to use an "external welcome page" instead. This can be a web site on an external server, or it can be a static page that is uploaded to a switch.
You set the welcome page in the captive portal authentication profile. This is the page that the user will be redirected to after successful authentication.
If this is required to be a page on the switch, the user needs to create their own web page (using the charset meta attribute in step 4 above). Upload this page to the designated switch in the same manner as uploading the captive portal login page under " Configuration > Management > Captive Portal > Upload Custom
Login Pages.
For Page Type, select “Captive Portal Welcome Page”.
Any required client side script (CSS) and media files can also be uploaded using the “Content” Page Type, however file space is limited (use the CLI command show storage to see available space). Remember to leave ample room for system files.
The "Registered User" and "Guest User" sections of the login page are implemented as graphics files, referenced by the default CSS styles. In order to change these, you will need to create new graphic files, download the CSS file, edit the reference to the graphics files, change the style reference in your index file and then upload all files as "content" to the switch.
A sample of a translated page is displayed in
.
Figure 49 Sample Translated Page
Customizing the Welcome Page
Once a user is authenticated by the switch, a Welcome page is launched. The default welcome page depends on your configuration, but will look similar to
Figure 50 Default Welcome Page
You can customize this welcome page by building your own HTML page and uploading it to the switch. You upload it to the switch by navigating to Management > Captive Portal > Upload Login Pagesand select “Captive
Portal Welcome Page” from the Page Type drop-down menu. This file is stored in a directory called "/upload/" on the switch using the file's original name.
In order to actually use this file, you will need to configure the welcome page on the switch. To do this use the
CLI command: "aaa captive-portal welcome-page /upload/welc.html" where "welc.html" is the name of the file
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 336
that you uploaded, or you can change the Welcome page in the captive portal authentication profile in the
WebUI.
An example that will create the same page as displayed in
is shown below. The part in red will redirect the user to the web page you originally setup. For this to work, please follow the procedure described above in this document.
:
<html>
<head>
<script>
{ function readCookie(name)
{ var nameEQ = name + "="; var ca = document.cookie.split(';'); for(var i=0;i < ca.length;i++)
{ var c = ca[i]; while (c.charAt(0)==' ') c = c.substring(1,c.length); if (c.indexOf(nameEQ) == 0) return c.substring
(nameEQ.length,c.length);
} return null;
} var cookieval = readCookie('url'); if (cookieval.length>0) document.write("<meta http-equiv=\"refresh\" content=\"2;url=http://"+cookieval+"\""+">");
}
</script>
</head>
<body bgcolor=white text=000000>
<font face="Verdana, Arial, Helvetica, sans-serif" size=+1>
<b>User Authenticated </b>
<p>In 2 seconds you will be automatically redirected to your original web page</p>
<p> Press control-d to bookmark this page.</p>
<FORM ACTION="/auth/logout.html">
<INPUT type="submit" name="logout" value="Logout">
</FORM>
</font>
</body>
</html>
Customizing Authentication Reply-Message to Captive Portal Users
In AOS-W 6.4.x and earlier versions, captive portal authentication displayed pre-defined strings such
Authentication Successful and Authentication Failed to users in the log-in page. So, response sent by
RADIUS server through the Reply-Message was not forwarded by Authentication module to the Captive
Portal module.
AOS-W 6.5 introduces the support for customizing authentication Reply-Message to captive portal users in the log-in page for better user experience. The purpose behind the Reply-Message is to return appropriate information to the captive portal system.
For example, ClearPass can send a RADIUS-reject for various reasons, such as, authentication failed, bandwidth limit exceeded, max. session reached, max. devices used. In AOS-W 6.4.x, the user returns Authentication failed message for all the reasons. In AOS-W 6.5, ClearPass can now include the reason why it is rejecting in the
337 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
Reply-Message. So, ClearPass processes the Reply-Message on the web login form and informs the user that
The max. number of sessions has been reached is the reason for authentication failure.
So, another RADIUS attribute is added in the reply message to the Captive Portal module from
Authentication module with the following two restrictions: n n
There can be multiple Reply-Message attributes in a packet but only the first attribute is considered.
The length of the reply message is limited to 256 characters.
RADIUS server and Authentication servers are required to be configured accordingly to send the reply message against authentication success or failure scenarios
This feature is implemented in the following ways: n n
For internal captive portal case l l
In case of authentication success: Welcome page with the addition of custom defined Reply-Message is displayed.
In case of authentication failure: Log-in page is displayed again with the custom defined Reply-Message.
For external captive portal case: l
In case of authentication success: Redirected to the welcome page.
l
In case of authentication failure: Failure reason is mentioned on the initial screen
Customizing the Pop-Up box
In order to customize the Pop-Up box, you must first customize your Welcome page. Once you have customized your welcome page, then you can configure your custom page to use a pop-up box. The default
HTML for the pop-up box is:
<html>
<body bgcolor=white text=000000>
<font face="Verdana, Arial, Helvetica, sans-serif" size=+1>
<b>Logout</b></font>
<p>
<a href="/auth/logout.html"> Click to Logout </a>
</body>
</html>
If you wish your users to be able to logout using this pop-up box, then you must include a reference to
/auth/logout.html Once a user accesses this URL then the switch will log them out. It is easiest to simply edit the above HTML to suit your users and then upload the resulting file to the switch using the WebUI under
Configuration > Management > Captive Portal > Upload custom pages and choose "content” as the page type.
Once you have completed your HTML, then you must get the clients to create the pop-up box once they have logged into the switch. This is done by inserting the following code into your welcome page text and reuploading the welcome page text to your switch.
Common things to change: n n n n
URL: set the URL to be the name of the pop-up HTML file that you created and uploaded. This should be preceded by "/upload/".
Width: set w to be the required width of the pop-up box.
Height: set h to be the required height of the pop-up box.
Title: set the second parameter in the window.open command to be the title of the pop-up box. Be sure to include the quotes as shown:
<script language="JavaScript"> var url="/upload/popup.html"; var w=210;
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 338
var h=80; var x=window.screen.width - w - 20; var y=window.screen.height - h - 60; window.open(url, 'logout',
"toolbar=no,location=no,width="+w+",height="+h+",top="+y+",left="+x+",screenX="+x+",screenY
="+y);
</script>
Customizing the Logged Out Box
In order to customize the Logged Out box, you must first customize your Welcome page and also your Pop-Up box. To customize the message that occurs after you have logged out then you need to replace the URL that the pop-up box will access in order to log out with your own HTML file.
First you must write the HTML web page that will actually log out the user and will also display page that you wish. An example page is shown below. The key part that must be included is the <iframe>..</iframe> section.
This is the part of the HTML that actually does the user logging out. The logout is always performed by the client accessing the /auth/logout.html file on the switch and so it is hidden in the html page here in order to get the client to access this page and for the switch to update its authentication status. If a client does not support the iframe tag, then the text between the <iframe> and the </iframe> is used. This is simply a 0 pixel sized image file that references /auth/logout.html. Either method should allow the client to logout from the switch.
Everything else can be customized.
<html>
<body bgcolor=white text=000000>
<iframe src='/auth/logout.html' width=0 height=0 frameborder=0><img src=/auth/logout.html
width=0 height=0></iframe>
<P><font face="Verdana, Arial, Helvetica, sans-serif" size=+1>
You have now logged out.</font></P>
<form> <input type="button" onclick="window.close()" name="close" value="Close
Window"></form>
</body>
</html>
After writing your own HTML, then you need to ensure that your customized pop-up box will access your new logged out file. In the pop-up box example above, you simply replace the "/auth/logout.html" with your own file that you upload to the switch. For example, if your customized logout HTML is stored in a file called
"loggedout.html" then your "pop-up.html" file should reference it like this:
<html>
<body bgcolor=white text=000000>
<font face="Verdana, Arial, Helvetica, sans-serif" size=+1>
<b>Logout</b></font>
<p>
<a href="/upload/loggedout.html"> Click to Logout </a>
</body>
</html>
Creating Walled Garden Access
On the Internet, a walled garden typically controls a user’s access to web content and services. The walled garden directs the user’s navigation within particular areas to allow access to a selection of websites or prevent access to other websites.
339 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
The Walled Garden feature can be used with the PEFNG or PEFV licenses.
Walled garden access is needed when an external or internal captive portal is used. A common example could be a hotel environment where unauthenticated users are allowed to navigate to a designated login page (for example, a hotel website) and all its contents.
Users who do not sign up for Internet service can view “allowed” websites (typically hotel property websites).
The website names must be DNS-based (not IP address based) and support the option to define wildcards.
HTTP or HTTPS proxy does not work when walled garden is implemented as a user-role using domain name
ACL. For example, user alias example.com any permit .
When a user attempts to navigate to other websites not configured in the white list walled garden profile, the user is redirected back to the login page. In addition, the black listed walled garden profile is configured to explicitly block navigation to websites from unauthenticated users.
In the WebUI
1. Navigate to Advanced Services > Stateful Firewall > Destination.
2. Click Add to add a destination name.
3. Select the switch IP version, IPv4 or IPv6, from the IP Version drop-down menu.
4. In the Destination Name field, enter a name and click Add .
5. Select name from the Rule Type drop-down menu and add a hostname or wildcard with domain name to which an unauthenticated user is redirected.
6. Click Apply .
7. Navigate to Configuration > Security > Authentication > L3 Authentication.
8. Select Captive Portal Authentication Profile.
9. To allow users to access a domain, enter the destination name that contains the allowed domain names in the White List field. This stops unauthenticated users from viewing specific domains such as a hotel website.
A rule in the white list must explicitly permit a traffic session before it is forwarded to the switch. The last rule in the white list denies everything else.
10.To deny users access to a domain, enter the destination name that contains prohibited domain names in the Black List field. This prevents unauthenticated users from viewing specific websites.
11.Click
Apply .
In the CLI
This example configures a destination named Mywhite-list and adds the domain names, example.com and example.net to that destination. It then adds the destination name Mywhite-list (which contains the allowed domain names example.com and example.net) to the white list.
(host)(config)# netdestination "Mywhite-list"
(host)(config)#name example.com
(host)(config)#name example.net
(host) (config) #aaa authentication captive-portal default
(host)(Captive Portal Authentication Profile "default")#white-list Mywhite-list
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 340
Enabling Captive Portal Enhancements
AOS-W introduces the following enhancements in Captive Portal: n
Location information such as AP name and AP group name have been included in the Captive Portal redirect
URL. The following example shows a Captive Portal redirect URL that contains the AP name and the AP group name: https://securelogin.example.com/cgibin/login?cmd=login&mac=00:24:d7:ed:84:14&ip=10.15.104.13&essid=example-testtunnel&apname=ap135&apgroup=example&url=http%3A%2F%2Fwww%2Eespncricinfo%2Ecom%2F n n n n n n
A new option redirect-url is introduced in the Captive Portal Authentication profile which allows you to redirect the users to a specific URL after the authentication is complete.
Captive Portal Login URL length has been increased from 256 characters to 2048 characters.
Support for “?” (question mark) inside the Captive Portal login URL has been added.
A new field, description has been introduced in the netdestination and netdestination6 commands to provide a description about the netdestination up to 128 characters long.
Support for configuring Whitelist in Captive Portal has been introduced.
Support for bypassing Captive Portal landing page has been introduced.
The Captive Portal enhancements are available on Tunnel and Split-Tunnel forwarding modes.
Configuring the Redirect-URL
You can configure the Captive Portal redirect URL using the following commands:
(host) (config) # aaa authentication captive-portal REDIRECT
(host) (Captive Portal Authentication Profile "REDIRECT") #redirect-url <absolute-URL>
Example:
(host) (config) # aaa authentication captive-portal REDIRECT
(host) (Captive Portal Authentication Profile "REDIRECT") #redirect-url https://test-login.php
Configuring the Login URL
You can configure a Captive Portal login URL up to 2048 characters using the following commands:
(host) (config) # aaa authentication captive-portal LOGIN
(host) (Captive Portal Authentication Profile "LOGIN")#login-page
"http://10.17.36.100/login.php?isinit=1&mac=00:11:22:33:44:55&loginURL=https://captiveportallogin.test.aero/auth/index.html&originalURL=&statusURL=&error=&logginIn”
You can configure the login URL with “?” (question mark) character in it provided the URL containing the question mark is within the double quotes.
Defining Netdestination Descriptions
You can provide a description (up to 128 characters) for the netdestination using the CLI.
Use the following commands to provide description for an IPv4 netdestination:
(host) (config) #netdestination Local-Server
(host) (config-dest) #description “This is a local server for IPv4 client registration”
Use the following commands to provide description for an IPv6 netdestination:
(host) (config) #netdestination6 Local-Server6
(host) (config-dest) #description “This is a local server for IPv6 client registration”
The following command displays the details of the specified IPv4 netdestination:
341 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
(host) (config-dest) #show netdestination Local-Server
1
2
3
Local-Server Description: This is a local server for IPv4 client registration
-------------------------------------------------------------------------------
Position Type IP addr Mask-Len/Range
-----------------------------name 0.0.0.1
yahoomail name 0.0.0.2
mycorp name 0.0.0.3
cricinfo
The following command displays the details of the specified IPv6 netdestination:
(host) (config-dest) #show netdestination Local-Server6
2
3
Local-Server6 Description: This is a local server for IPv6 client registration
-------------------------------------------------------------------------------
Position Type IP addr Mask-Len/Range
------------------------------
1 name 0.0.0.1
yahoomail name 0.0.0.2
mycorp name 0.0.0.3
cricinfo
Configuring a Whitelist
You can now configure a Whitelist in Captive Portal using the CLI.
Configuring the Netdestination for a Whitelist:
Use the following commands to configure a netdestination alias for Whitelist:
(host) (config) #netdestination whitelist
(host) (config-dest) #description guest_whitelist
(host) (config-dest) #name mycorp
Associating a Whitelist to Captive Portal Profile
Use the following CLI commands to associate a whitelist to the Captive profile:
(host) (config) #aaa authentication captive-portal CP_Profile
(host) (Captive Portal Authentication Profile "CP_Profile”) #white-list whitelist
Applying a Captive Portal Profile to a User-Role
Use the following commands to apply the Captive Portal profile to a user-role:
(host) (config) # user-role guest_role
(host) (config-role) #session-acl logon-control
(host) (config-role) #session-acl captiveportal
(host) (config-role) #captive-portal CP_Profile
Verifying a Whitelist Configuration
Use the following commands to verify the whitelist alias:
(host) (config) #show netdestination whitelist whitelist Description: guest_whitelist
--------------------------------------
Position Type IP addr Mask-Len/Range
------------------------------
1 name 0.0.0.6
mycorp
Verifying a Captive Portal Profile Linked to a Whitelist
Use the following commands to verify the Captive Portal profile linked to the whitelist:
(host) (config) #show aaa authentication captive-portal CP_Profile
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 342
Captive Portal Authentication Profile "CP_Profile"
-----------------------------------------------------------------
Parameter
---------
Value
-----
Default Role
Default Guest Role
Server Group
Redirect Pause guest guest default
10 sec
User Login
Guest Login
Logout popup window
Use HTTP for authentication
Logon wait minimum wait
Logon wait maximum wait logon wait CPU utilization threshold
Max Authentication failures
Enabled
Disabled
Enabled
Disabled
5 sec
10 sec
60 %
0
Show FQDN
Use CHAP (non-standard)
Login page
Welcome page
Disabled
Disabled
/auth/index.html
/auth/welcome.html
Show Welcome Page
Add switch IP address in the redirection URL
Yes
Disabled
Adding user vlan in redirection URL Disabled
Add a controller interface in the redirection URL N/A
Allow only one active user session
White List
Black List
Show the acceptable use policy page
Redirect URL
Disabled whitelist
N/A
Disabled
N/A
Verifying Dynamic ACLs for a Whitelist
Use the following commands to verify the dynamically created ACLs for the whitelist:
(host) (config) #show rights guest_role
Derived Role = 'guest_role'
Up BW:No Limit Down BW:No Limit
L2TP Pool = default-l2tp-pool
PPTP Pool = default-pptp-pool
Periodic reauthentication: Disabled
ACL Number = 79/0
Max Sessions = 65535
Captive Portal profile = CP_Profile
1
2
3 access-list List
----------------
Position Name
-----------
CP_Profile_list_operations logon-control captiveportal
Location
--------
CP_Profile_list_operations
-----------------------------------------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P
Blacklist Mirror DisScan ClassifyMedia IPv4/6
------------------------------------------------------------
-------------------------------------
1 user whitelist svc-http permit
4
Low
2 user whitelist svc-https permit
4
Low
343 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
logon-control
-------------
Priority Source Destination Service Action TimeRange Log Expired Queue TOS 8021P
Blacklist Mirror DisScan ClassifyMedia IPv4/6
------------------------------------------------------------
------------------------------------
1 user any udp 68 deny
4
Low
2 any any Low
3 any any svc-icmp permit
4 svc-dns permit
4
Low
Low 4
5 any any any any svc-dhcp permit
4 svc-natt permit
4 captiveportal
-------------
Priority Source Destination Service Action
TOS 8021P Blacklist Mirror DisScan ClassifyMedia IPv4/6
TimeRange
Low
Log Expired Queue
------------------------------------------------------
-------------------------------------------
1 user controller svc-https dst-nat 8081
4
2 user any
3
4
5 user user user any any any svc-http dst-nat 8080
4 svc-https dst-nat 8081
4 svc-http-proxy1 dst-nat 8088
4 svc-http-proxy2 dst-nat 8088
4
6 user any svc-http-proxy3 dst-nat 8088
4
Expired Policies (due to time constraints) = 0
Low
Low
Low
Low
Low
Low
Verifying DNS Resolved IP Addresses for Whitelisted URLs
Use the following command to verify the DNS resolved IP addresses for the whitelisted URLs:
(host) #show firewall dns-names ap-name <AP-name>
Example:
(host) #show firewall dns-names ap-name ap135
2
3
0
1
Firewall DNS names
------------------
Index
-----
Name
---bugzilla cricinfo yahoo mycorp
Id
--
10
9
1
6
Num-IP
------
1
0
0
1
List
----
0.0.0.0
1.1.1.1
Bypassing Captive Portal Landing Page
An increasing number of user sessions in Captive Portal pre-authenticated role, repeatedly request the Captive
Portal login page from the switch. This impacts the number of browser-based user login requests handled per second by the switch. This eventually delays the loading of the Captive Portal page and logging into Captive
Portal. Most of the increased activities are from non-browser based applications running on smart phones and tablets.
AOS-W 6.5.3.x
| User Guide Captive Portal Authentication | 344
When this feature is disabled, the switch sends 200 OK status code message to the now-browser based apps so that the apps stop sending repeated requests to the switch. This reduces the load of the httpd process on the switch. This feature is enabled by default.
You can enable this feature from the switch CLI. On enabling this feature, non-browser apps continue to request Captive Portal login page from the switch. This increases the load of the httpd process of the switch.
(host) (config) #web-server profile
(host) (Web Server Configuration) #bypass-cp-landing-page
The landing page contains the meta-refresh tag to reload the page using real browser applications.
Netdestination for AAAA Records
The Captive Portal whitelist supports IPv6 addresses for netdestination. Add an IPv6 netdestination with the domain name that is to be whitelisted and specify this destination as whitelist in Captive Portal profile. This adds the required ACL policies to permit IPv6 traffic to the domain.
In the CLI
(host) (config) #netdestination6 <string> name <host_name>
345 | Captive Portal Authentication AOS-W 6.5.3.x | User Guide
Chapter 15
Virtual Private Networks
Wireless networks can use virtual private network (VPN) connections to further secure wireless data from attackers. The Alcatel-Lucent switch can be used as a VPN concentrator that terminates all VPN connections from both wired and wireless clients.
This chapter describes the following topics: n n n n n n n n n n
Planning a VPN Configuration on page 346
Working with VPN Authentication Profiles on page 350
Configuring a Basic VPN for L2TP/IPsec on page 352
Configuring a VPN for L2TP/IPsec with IKEv2 on page 356
Configuring a VPN for Smart Card Clients on page 361
Configuring a VPN for Clients with User Passwords on page 362
Configuring Remote Access VPNs for XAuth on page 363
Working with Remote Access VPNs for PPTP on page 364
Working with Site-to-Site VPNs on page 365
Working with VPN Dialer on page 373
n n
Planning a VPN Configuration
You can configure the switch for the following types of VPNs: n n
Remote access VPNs: These VPNs allow hosts such as telecommuters or traveling employees to connect to private networks (e.g. a corporate network) over the Internet. Each host must run VPN client software, which encapsulates and encrypts traffic, then sends it to a VPN gateway at the destination network. The switch supports the following remote access VPN protocols: l
Layer-2 Tunneling Protocol over IPsec (L2TP/IPsec) l l l l
Point-to-Point Tunneling Protocol (PPTP)
XAUTH IKE/IPsec
IKEv2 with Certificates
IKEv2 with EAP
Site-to-site VPNs: Site-to-site VPNs allow networks, like branch office networks, to connect to other networks like a corporate network. Unlike a remote access VPN, hosts in a site-to-site VPN do not run VPN client software. All traffic for the other network is sent and received through a VPN gateway, which encapsulates and encrypts the traffic.
Before enabling VPN authentication, you must configure the following:
The default user role for authenticated VPN clients. See
Roles and Policies on page 375
for information about configuring user roles .
The authentication server group used by the switch to validate clients. See
Authentication Servers on page
for configuration details.
A server-derived role, if present, takes precedence over the default user role.
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 346
You then specify the default user role and authentication server group in the VPN authentication default profile, as described in the sections below.
ESP Tunnel Mode is the only supported IPsec mode of operation. AOS-W does not support AH and Transport modes.
Selecting an IKE protocol
Switches running AOS-W version 6.1 and later support both IKEv1 and the newer IKEv2 protocol to establish
IPsec tunnels. Though both IKEv1 and IKEv2 support the same suite-B cryptographic algorithms, IKEv2 is a simpler, faster, and more reliable protocol than IKEv1.
If your IKE policy uses IKEv2, you should be aware of the following caveats when you configure your VPN: n n n
AOS-W does not support separate pre-shared keys for both directions of an exchange; both peers must use the same pre-shared key. AOS-W does not support mixed authentication with both pre-shared keys and certificates; each authentication exchange requires a single authentication type. For example, if a client authenticates with a pre-shared key, the switch must also authenticate with a pre-shared key.
AOS-W does not support IKEv2 Authentication Headers (AH) or IP Payload Compression Protocol (IPComp).
Starting from AOS-W 6.5, AOS-W supports the functionality where the non-Aruba devices can fragment the large IKE_AUTH packets using the standards described in the RFC 7383 – Internet Key Exchange Protocol
Version 2 (IKEv2) message fragmentation when the Aruba device acts as a responder and not as an initiator.
Understanding Suite-B Encryption Licensing
Alcatel-Lucent switches support Suite-B cryptographic algorithms when the Advanced Cryptography (ACR) license is installed.
describes the Suite-B algorithms supported by AOS-W IKE Policies and IPsec tunnels. For further details on configuring a VPN to use Suite-B algorithms, see
L2TP/IPsec with IKEv2 on page 356 .
Table 80: Suite-B Algorithms Supported by the ACR License
IKE Policies hash: SHA-256-128, SHA-384-192
Diffie-Hellman (DH) Groups: ECP-256, ECP-384
Suite-B for IPsec tunnels
Encryption: AES-128-GCM, AES-256-GCM
Perfect Forward Secrecy (PFS): ECP-256, ECP-
384
— Pseudo-Random Function (PRF): HMAC_SHA_256, HMAC_
SHA_384
Suite-B certificates: ECDSA-256, ECDSA-384 —
The AOS-W hardware supports IKE Suite-B AES-128-GCM and AES-256-GCM encryption. AOS-W software performs the IKE Suite-B Diffie-Hellman and Certificate-based signature operations, and hash, PFS, and PRF algorithm functions.
The following VPN clients support Suite-B algorithms when establishing an L2TP/IPsec VPN:
347 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
Table 81: Client Support for Suite-B
Client Operating
System n Windows client
NOTE: Windows client operating system includes
Windows XP and later versions.
Supported Suite-B
IKE Authentication n n
IKEv1 Clients using ECDSA
Certificates
IKEv1/IKEv2 Clients using ECDSA
Certificates with L2TP/PPP/EAP-TLS certificate user-authentication
Supported Suite-B IPsec
Encryption n n
AES-128-GCM
AES-256-GCM
The Suite-B algorithms described in
are also supported by Site-to-Site VPNs between Alcatel-Lucent switches, or between an Alcatel-Lucent switch and a server running Windows 2008 or StrongSwan 4.3.
Working with IKEv2 Clients
Not all clients support both the IKEv1 and IKEv2 protocols. Only the clients in
support IKEv2 with the following authentication types:
Table 82: VPN Clients Supporting IKEv2
Windows Client n n
Machine authentication with Certificates
User name password authentication using EAP-
MSCHAPv2 or PEAP-
MSCHAPv2 n
User smart-card authentication with EAP-
TLS / IKEv2
NOTE: Windows clients using
IKEv2 do not support preshared key authentication.
NOTE: Windows client operating system includes
Windows 7 and later versions.
StrongSwan 4.3 Client n n n
Machine authentication with Certificates
User name password authentication using EAP-
MSCHAPv2
Suite-B cryptographic algorithms
AOS-W VIA Client n n
Machine authentication with
Certificates
User name password authentication using EAP-MSCHAPv2 n EAP-TLS using Microsoft cert repository
NOTE: AOS-W VIA clients using IKEv2 do not support pre-shared key authentication.
Support for AOS-W VIA-Published Subnets
Starting from AOS-W 6.5, a new feature is introduced in switches to support IKEv2 configuration (CFG_SET) payload for AOS-W VIA clients. This is in conformation with section 3.15 of RFC 5996 applicable for routebased VPNs. This feature is disabled by default.
When this feature is enabled, switches can accept CFG_SET message with the INTERNAL_IP4_SUBNET attribute type. When a switch receives this message, which consists of an IP address and netmask, it adds an entry to the datapath route table that points to the AOS-W VIA’s inner IP address as the next-hop. The datapath routecache for the AOS-W VIA’s inner IP will point to the tunnel endpoint associated with the AOS-W VIA.
Enabling Support for AOS-W VIA-Published Subnets
In the WebUI
To enable this feature in the switch, perform the following steps in the WebUI:
1. Navigate to Configuration > Advanced Services > VPN Services > IPSEC .
2. Select the Allow AOS-W VIA to push subnets check box under L2TP and XAUTH Parameters .
3. Click Apply .
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 348
In the CLI
To enable this feature in the switch, execute the following command:
(host) (config) #crypto-local isakmp allow-via-subnet-routes
To disable the feature in the switch, execute the following command:
(host) (config)#no crypto-local isakmp allow-via-subnet-routes
Verifying Support for AOS-W VIA-Published Subnets
To verify if the switch is configured to accept subnet routes from AOS-W VIA clients, execute the following command:
(host) #show crypto-local isakmp allow-via-subnet-routes
Controller will accept subnet routes from via client
Limitations
The following limitations are applicable to the CFG_SET support feature for switches: n
This feature supports only IPv4 n
This feature is only applicable with IKEv2
For details about how to configure and run AOS-W VIA on Linux platform, refer to the AOS-W VIA 2.3.1 Linux
Edition Release Notes .
Understanding Supported VPN AAA Deployments
If you want to simultaneously deploy various combinations of a VPN client, RAP-psk, RAP-certs, and CAP on the same switch, see
.
Each row in this table specifies the allowed combinations of AAA servers for simultaneous deployment.
Configuration rules include the following: n n n n
RAP-certs can only use LocalDB-AP.
An RAP-psk and RAP-cert can only terminate on the same switch if the RAP VPN profile’s AAA server uses
Local-db.
If an RAP-psk is using an external AAA server, the RAP-cert cannot be terminated on the same switch.
Clients can use any type of AAA server, regardless of the RAP/CAP authentication configuration server.
Table 83: Supported VPN AAA Deployments
VPN Client
External AAA server 1
External AAA server 1
RAP psk
LocalDB
External AAA server 1
External AAA server 1
LocalDB
LocalDB
External AAA server 2
LocalDB
External AAA server 1
RAP certs
LocalDB-AP
Not supported
Not supported
LocalDB-AP
Not supported
CAP
CPSEC-whitelist
CPSEC-whitelist
CPSEC-whitelist
CPSEC-whitelist
CPSEC-whitelist
Working with Certificate Groups
The certificate group feature allows you to access multiple types of certificates on the same switch. To create a certificate group, use the following command:
349 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
(host) (config) #crypto-local isakmp certificate-group server-certificate server_certificate ca-certificate ca_certificate
You can view existing certificate groups using: show crypto-local isakmp certificate-group
Working with VPN Authentication Profiles
VPN Authentication profiles identify an authentication server, the server group to which the authentication server belongs, and a user-role for authenticated VPN clients. There are three predefined VPN authentication profiles: default , default-rap , and default-cap . These different profiles allow you to use different authentication servers, user-roles, and IP pools for VPN, remote AP, and campus AP clients.
You can configure the default and default-rap profiles, but not the default-cap profile.
Table 84: Predefined Authentication Profile settings
Parameter
Default Role for authenticated users
Description
The role that will be assigned to the authenticated users.
default default-vpnrole
Maximum allowed authentication failures
Check certificate common name against AAA server
The number of contiguous authentication failures before the station is blacklisted.
0 (feature is disabled) disabled default-rap default-cap default-vpnrole sys-ap-role
0
0 (feature is disabled)
0 (feature is disabled) enabled enabled
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 350
Parameter
Export VPN IP address as a route
User idle timeout
PAN firewalls Integration
Description
When enabled, this causes any VPN client address to be exported to
OSPF using IPC.
NOTE: Note that the
Framed-IP-Address attribute is assigned the
IP address as long as the any server returns the attribute. The Framed-IP-
Address value always has a higher priority than the local address pool.
default enabled
The user idle timeout value for this profile.
Specify the idle timeout value for the client in seconds. Valid range is
30-15300 in multiples of
30 seconds. Enabling this option overrides the global settings configured in the AAA timers. If this is disabled, the global settings are used.
Requires IP mapping at
Palo Alto Networks firewalls.
disabled disabled default-rap enabled
N/A disabled default-cap enabled
N/A disabled
To edit the default VPN authentication profile:
1. Navigate to the Configuration > Advanced Services > All Profiles > Wireless LAN > VPN
Authentication page.
2. In the Profiles list of the left window pane, select the default VPN Authentication Profile.
3. Click the Default Role drop-down list and select the default user role for authenticated VPN users. (For detailed information on creating and managing user roles and policies, see
Roles and Policies on page 375
.)
4. (Optional) If you use client certificates for user authentication, select the Check certificate common name against AAA server checkbox to verify that the certificate's common name exists in the server.
This parameter is enabled by default in the default-cap and default-rap VPN profiles, and disabled by default on all other VPN profiles.
5. (Optional) Set Max Authentication failures to an integer value. The default value is 0, which disables this feature.
6. (Optional) Regardless of how an authentication server is contacted, the Export VPN IP address as a route option causes any VPN client address to be exported to OSPF using IPC. Note that the Framed-IP-
Address attribute is assigned the IP address as long as any server returns the attribute. The Framed-IP-
Address value always has a higher priority than the local address pool.
7. (Optional) Enabling PAN Firewall Integration requires IP mapping at Palo Alto Networks firewalls. (For more information about PAN firewall integration, see
Palo Alto Networks Firewall Integration on page 689
.)
8. Click Apply .
9. In the Default profile menu in the left window pane, select Server Group .
10.From the Server Group drop-down list, select the server group to be used for VPN authentication.
11.Click
Apply .
351 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
To configure VPN authentication via the command-line interface, access the CLI in config mode and issue the following commands:
(host)(config) #aaa authentication vpn default cert-cn-lookup clone default-role < role> export-route max-authentication-failure < number> pan-integration radius-accounting < server_group_name > server-group < name> user-idle-timeout < seconds >
Configuring a Basic VPN for L2TP/IPsec
The combination of Layer-2 Tunneling Protocol and Internet Protocol Security (L2TP/IPsec) creates a highlysecure technology that enables VPN connections across public networks such as the Internet. L2TP/IPsec provides a logical transport mechanism on which to transmit PPP frames, tunneling, or encapsulation, so that the PPP frames can be sent across an IP network. L2TP/IPsec relies on the PPP connection process to perform user authentication and protocol configuration. With L2TP/IPsec, the user authentication process is encrypted using the Data Encryption Standard (DES) or Triple DES (3DES) algorithm.
L2TP/IPsec using IKEv1 requires two levels of authentication: n n
Computer-level authentication with a preshared key to create the IPsec security associations (SAs) to protect the L2TP-encapsulated data.
User-level authentication through a PPP-based authentication protocol using passwords, SecureID, digital certificates, or smart cards after successful creation of the SAs.
Note that only Windows 7 (and later versions), StrongSwan 4.3, and VIA clients support IKEv2. For additional information on the authentication types supported by these clients, see
Working with IKEv2 Clients on page 348 .
Configuring a Basic L2TP VPN in the WebUI
Use the following procedures in the WebUI to configure a remote access VPN for L2TP IPsec for clients using pre-shared keys, certificates, or EAP for authentication: n n n n n n n n
Defining Authentication Method and Server Addresses on page 357
Defining Address Pools on page 357
Enabling Source NAT on page 357
Selecting Certificates on page 358
Defining IKEv1 Shared Keys on page 354
Configuring IKE Policies on page 358
Setting the IPsec Dynamic Map on page 359
Finalizing WebUI changes on page 360
Defining Authentication Method and Server Addresses
1. Define the authentication method and server addresses.
2. Navigate to Configuration > Advanced Services > VPN Services and click the IPSEC tab.
3. To enable L2TP, select Enable L2TP (this is enabled by default).
4. Select the authentication method for IKEv1 clients. Currently supported methods include: l
Password Authentication Protocol (PAP)
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 352
l l l
Extensible Authentication Protocol (EAP)
Challenge Handshake Authentication Protocol (CHAP)
Microsoft Challenge Handshake Authentication Protocol (MSCHAP) l
Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2)
5. Configure the IP addresses of the primary and secondary Domain Name System (DNS) servers and the primary and secondary Windows Internet Naming Service (WINS) Server that are pushed to the VPN client.
Defining Address Pools
Next, define the pool from which the clients are assigned addresses:
1. In the Address Pools section of the IPSEC tab, click Add to open the Add Address Pool page.
2. Specify the pool name, start address, and end address.
3. Click Done .
RADIUS Framed-IP-Address for VPN Clients
IP addresses are usually assigned to VPN clients from configured local address pools. However, the Framed-IP-
Address attribute that is returned from a RADIUS server can be used to assign the IP address.
VPN clients use different mechanisms to establish VPN connections with the switch, such as IKEv1, IKEv2, EAP, or a user certificate. Regardless of how the RADIUS server is contacted for authentication, the Framed-IP-
Address attribute is assigned the IP address as long as the RADIUS server returns the attribute. The Framed-IP-
Address value always has a higher priority than the local address pool.
Enabling Source NAT
In the Source NAT section of the IPSEC tab, select Enable Source NAT if the IP addresses of clients must be translated to access the network. If source NAT is enabled, click the NAT pool drop-down list and select an existing NAT pool. To create a new NAT pool:
1. Navigate to Configuration > Network > IP > NAT Pools .
2. Click Add .
3. In the Pool Name field, enter a name for the new NAT pool, up to 63 alphanumeric characters.
4. In the Start IP address field, enter the dotted-decimal IP address that defines the beginning of the range of source NAT addresses in the pool.
5. In the End IP address field, enter the dotted-decimal IP address that defines the end of the range of source
NAT addresses in the pool.
6. In the Destination NAT IP Address field, enter the destination NAT IP address in dotted-decimal format.
If you do not enter an address into this field, the NAT pool will use the destination NAT IP 0.0.0.0
.
7. Click Done.
8. Navigate to Configuration > Advanced Services > VPN Services and click the IPSEC tab to return to the
IPsec window.
9. Click the NAT Pool drop-down list and select the NAT pool you just created.
Selecting Certificates
If you are configuring a VPN to support machine authentication using certificates, define the IKE Server certificates for VPN clients using IKE. Note that these certificates must be imported into the switch, as described in
Management Access on page 833 .
1. Select the server certificate for client machines using IKE by clicking the IKE Server Certificate drop-down list and selecting an available certificate name.
353 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
2. If you are configuring a VPN to support clients using certificates, you must also assign one or more trusted
CA certificates to VPN clients.
a. Under CA Certificate Assigned for VPN-clients, click Add .
b. Select a CA certificate from the drop-down list of CA certificates imported in the switch.
c. Click Done .
d. Repeat the above steps to add additional CA certificates.
Defining IKEv1 Shared Keys
If you are configuring a VPN to support IKEv1 and clients using pre-shared keys, you can configure a global IKE key or IKE key for each subnet. Make sure that this key matches the key on the client.
1. In the IKE Shared Secrets section of the IPsec tab, click Add to open the Add IKE Secret page .
2. Enter the subnet and subnet mask. To make the IKE key global, specify 0.0.0.0 for both values.
3. Enter the IKE Shared Secret and Verify IKE Shared Secret.
4. Click Done .
Configuring IKE Policies
AOS-W contains several predefined default IKE policies, as described in
. If you do not want to use any of these predefined policies, you can use the procedures below to edit an existing policy or create your own custom IKE policy instead.
The IKE policy selections, along with any preshared key, must be reflected in the VPN client configuration. When using a third-party VPN client, set the VPN configuration on clients to match the choices made above. In case the Alcatel-
Lucent dialer is used, these configurations must be made on the dialer prior to downloading the dialer onto the local client.
1. Scroll down to the IKE Policies section of the IPSEC tab, then click Edit to edit an existing policy or click Add to create a new policy.
2. Enter a number into the Priority field to set the priority for this policy. Enter a priority of 1 for the configuration to take priority over the Default setting.
3. Select the IKE version. Click the Version drop-down list and select V1 for IKEv1 or V2 for IKEv2.
4. Set the Encryption type. Click the Encryption drop-down list and select one of the following encryption types: n
DES n n n n
3DES
AES128
AES192
AES256
5. Set the HASH function. Click the Hash drop-down list and select one of the following hash types: n
MD5 n n
SHA
SHA1-96 n n
SHA2-256-128
SHA2-384-192
6. AOS-W VPNs support client authentication using pre-shared keys, RSA digital certificates, or Elliptic Curve
Digital Signature Algorithm (ECDSA) certificates. To set the authentication type for the IKE rule, click the
Authentication drop-down list and select one of the following:
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 354
n n n n n n
Pre-Share (for IKEv1 clients using pre-shared keys)
RSA (for clients using certificates)
ECDSA-256 (for clients using certificates) n
ECDSA-384 (for clients using certificates)
7. Diffie-Hellman is a key agreement algorithm that allows two parties to agree upon a shared secret, and is used within IKE to securely establish session keys. To set the Diffie–Hellman Group for the ISAKMP policy, click the Diffie–Hellman Group drop-down list and select one of the following groups: n n
Group 1: 768-bit Diffie–Hellman prime modulus group.
Group 2: 1024-bit Diffie–Hellman prime modulus group.
Group 14: 2048-bit Diffie–Hellman prime modulus group.
Group 19: 256-bit random Diffie–Hellman ECP modulus group.
Group 20: 384-bit random Diffie–Hellman ECP modulus group.
Configuring Diffie–Hellman Group 1 and Group 2 types are not permitted if the switch is operating in FIPS mode.
8. Set the Security Association Lifetime to define the lifetime of the security association in seconds. The default value is 7200 seconds. To change this value, uncheck the default checkbox and enter a value between 300 and 86400 seconds.
9. Click Done .
Setting the IPsec Dynamic Map
Dynamic maps enable IPsec SA negotiations from dynamically addressed IPsec peers. AOS-W has a predefined
IPsec dynamic map for IKEv1. If you do not want to use this predefined map, you can use the procedures below to edit an existing map or create your own custom IPsec dynamic map instead:
1. Scroll down to the IPsec Dynamic Map section of the IPSEC tab, then click Edit by a map name to edit the existing map or click Add to create a new map.
2. In the Name field, enter a name for the dynamic map.
3. In the Priority field, enter a priority number for the map. Negotiation requests for security associations try to match the highest-priority map first. If that map does not match, the negotiation request continues down the list to the next-highest priority map until a match is made.
4. Click the Version drop-down list and select V1 to create an IPsec map for remote peers using IKEv1.
5. (Optional) Configure Perfect Forward Secrecy (PFS) settings for the dynamic peer by assigning a Diffie-
Hellman prime modulus group. PFS provides an additional level of security by ensuring that the IPsec SA key was not derived from any other key, and therefore, cannot be compromised if another key is broken.
Click the Set PFS drop-down list and select one of the following groups: n
Group 1: 768-bit Diffie–Hellman prime modulus group.
n n
Group 2: 1024-bit Diffie–Hellman prime modulus group.
Group 14: 2048-bit Diffie–Hellman prime modulus group.
n n
Group 19: 256-bit random Diffie–Hellman ECP modulus group.
Group 20: 384-bit random Diffie–Hellman ECP modulus group.
6. Select the transform set for the map to define a specific encryption and authentication type used by the dynamic peer. Click the Transform Set drop-down list, and select the transform set for the dynamic peer.
To view current configuration settings for an IPsec transform-set, access the command-line interface and issue the command crypto ipsec transform-set tag <transform-set-name> .
355 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
7. Set the Life Time to define the lifetime of the security association for the dynamic peer in seconds or kilobytes. The default value is 7200 seconds. To change this value, uncheck the default checkbox and enter a value between 300 and 86400 seconds or 1000 and 1000000000 kilobytes.
8. Click Done .
Finalizing WebUI changes
When you have finished configuring your IPsec VPN settings, click Apply to apply the new settings before navigating to other pages.
Configuring a Basic L2TP VPN in the CLI
Use the following procedures to use the command-line interface to configure a remote access VPN for L2TP
IPsec:
1. Define the authentication method and server addresses:
(host)(config) #vpdn group l2tp enable client configuration {dns|wins} <ipaddr1> [<ipaddr2>]
2. Enable authentication methods for IKEv1 clients:
vpdn group l2tp ppp authentication {cache-securid|chap|eap|mschap|mschapv2|pap
3. Create address pools:
(host)(config) #ip local pool <pool> <start-ipaddr> <end-ipaddr>
4. Configure source NAT:
(host)(config) #ip access-list session srcnatuser any any src-nat pool <pool> position 1
5. If you are configuring a VPN to support machine authentication using certificates, define server certificates for VPN clients using IKEv1:
(host)(config) #crypto-local isakmp server-certificate <cert>
6. If you are configuring a VPN to support IKEv1 Clients using pre-shared keys, you can configure a global IKE key by entering 0.0.0.0
for both the address and netmask parameters in the command below, or configure an IKE key for an individual subnet by specifying the IP address and netmask for that subnet: crypto isakmp key < key> address < ipaddr|> netmask < mask>
7. Define IKE Policies:
(host)(config) #crypto isakmp policy <priority> encryption {3des|aes128|aes192|aes256|des} version v1|v2 authentication {pre-share|rsa-sig|ecdsa-256ecdsa-384} group {1|2|19|20} hash {md5|sha|sha1-96|sha2-256-128|sha2-384-192} lifetime <seconds>
Configuring a VPN for L2TP/IPsec with IKEv2
Only clients running Windows 7 (and later versions), StrongSwan 4.3, and Alcatel-Lucent VIA support IKEv2. For additional information on the authentication types supported by these clients, see “
Working with IKEv2 Clients on page 348 ."
Configuring an L2TP VPN with IKEv2 in the WebUI
Use the following procedures to in the WebUI to configure a remote access VPN for IKEv2 clients using certificates.
n n
Defining Authentication Method and Server Addresses on page 357
Defining Address Pools on page 357
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 356
n n n n n
Enabling Source NAT on page 357
Selecting Certificates on page 358
Configuring IKE Policies on page 358
Setting the IPsec Dynamic Map on page 359
Finalizing WebUI changes on page 360
Defining Authentication Method and Server Addresses
1. Define the authentication method and server addresses.
2. Navigate to Configuration > Advanced Services > VPN Services and click the IPSEC tab.
3. To enable L2TP, select Enable L2TP (this is enabled by default).
4. Select the authentication method for IKEv1 clients. The currently supported methods include: l l l l
Password Authentication Protocol (PAP)
Extensible Authentication Protocol (EAP)
Challenge Handshake Authentication Protocol (CHAP)
Microsoft Challenge Handshake Authentication Protocol (MSCHAP) l
Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2)
5. Configure the IP addresses of the primary and secondary Domain Name System (DNS) servers and primary and secondary Windows Internet Naming Service (WINS) Servers that are pushed to the VPN client.
Defining Address Pools
Next, define the pool from which the clients are assigned addresses.
1. In the Address Pools section of the IPSEC tab, click Add to open the Add Address Pool page.
2. Specify the pool name, the start address, and the end address.
3. Click Done .
Enabling Source NAT
In the Source NAT section of the IPSEC tab, select Enable Source NAT if the IP addresses of clients must be translated to access the network. If source NAT is enabled, click the NAT pool drop-down list and select an existing NAT pool. To create a new NAT pool:
1. Navigate to Configuration > Network > IP > NAT Pools .
2. Click Add .
3. In the Pool Name field, enter a name for the new NAT pool, up to 63 alphanumeric characters.
4. In the Start IP address field, enter the dotted-decimal IP address that defines the beginning of the range of source NAT addresses in the pool.
5. In the End IP address field, enter the dotted-decimal IP address that defines the end of the range of source
NAT addresses in the pool.
6. In the Destination NAT IP Address field, enter the destination NAT IP address in dotted-decimal format.
If you do not enter an address into this field, the NAT pool uses the destination NAT IP 0.0.0.0
.
7. Click Done to close the NAT pools tab.
8. Navigate to Configuration > Advanced Services > VPN Services and click the IPSEC tab to return to the
IPSEC window.
9. Click the NAT Pool drop-down list and select the NAT pool you just created.
357 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
Selecting Certificates
To configure the VPN to support machine authentication using certificates, define the IKE Server certificates for
VPN clients using IKEv2. Note that these certificate must be imported into the switch, as described in
.
1. Select the IKEv2 server certificate for client machines using IKEv2 by clicking the IKEv2 Server Certificate drop-down list and selecting an available certificate name.
2. If you are configuring a VPN to support IKEv2 clients using certificates, you must also assign one or more trusted CA certificates to VPN clients.
a. Under CA Certificate Assigned for VPN-clients, click Add .
b. Select a CA certificate from the drop-down list of CA certificates imported in the switch.
c. Click Done .
d. Repeat the above steps to add additional CA certificates.
Configuring IKE Policies
AOS-W contains several predefined default IKE policies, as described in
. If you do not want to use any of these predefined policies, you can use the procedures below to delete a factory-default policy, edit an existing policy, or create your own custom IKE policy instead.
The IKE policy selections must be reflected in the VPN client configuration. When using a third-party VPN client, set the VPN configuration on clients to match the choices made above. In case the Alcatel-Lucent dialer is used, these configurations must be made on the dialer prior to downloading the dialer onto the local client.
1. Scroll down to the IKE Policies section of the IPSEC tab, then click Edit to edit an existing policy or click Add to create a new policy.
You can also delete a predefined factory-default IKE policy by clicking Delete .
2. Enter a number into the Priority field to set the priority for this policy. Enter a priority of 1 for the configuration to take priority over the Default setting.
3. Select the IKE version. Click the Version drop-down list and select V2 for IKEv2.
4. Set the Encryption type. Click the Encryption drop-down list and select one of the following encryption types: n n
DES
3DES n n
AES128
AES192 n
AES256
5. Set the HASH function. Click the Hash drop-down list and select one of the following hash types: n n n n
MD5
SHA
SHA1-96
SHA2-256-128 n
SHA2-384-192
6. AOS-W VPNs support IKEv2 client authentication using RSA digital certificates or Elliptic Curve Digital
Signature Algorithm (ECDSA) certificates. To set the authentication type for the IKE rule, click the
Authentication drop-down list and select one of the following types: n n
RSA
ECDSA-256
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 358
n n
ECDSA-384
7. Diffie-Hellman is a key agreement algorithm that allows two parties to agree upon a shared secret, and is used within IKE to securely establish session keys. To set the Diffie–Hellman Group for the ISAKMP policy, click the Diffie–Hellman Group drop-down list and select one of the following groups:
Group 1: 768-bit Diffie–Hellman prime modulus group.
n n n
Group 2: 1024-bit Diffie–Hellman prime modulus group.
Group 19: 256-bit random Diffie–Hellman ECP modulus group.
Group 20: 384-bit random Diffie–Hellman ECP modulus group.
Configuring Diffie–Hellman Group 1 and Group 2 types are not permitted if the switch is operating in the FIPS mode.
8. Set the Pseudo-Random Function (PRF) value. This algorithm is an HMAC function to used to hash certain values during the key exchange: n n
PRF-HMAC-MD5
PRF-HMAC-SHA1 n n
PRF-HMAC-SHA256
PRF-HMAC-SHA384
9. Set the Security Association Lifetime to define the lifetime of the security association in seconds. The default value is 7200 seconds. To change this value, uncheck the default checkbox and enter a value between 300 and 86400 seconds.
10.Click
Done.
Setting the IPsec Dynamic Map
Dynamic maps enable IPsec SA negotiations from dynamically addressed IPsec peers. AOS-W has predefined
IPsec dynamic maps for IKEv2. If you do not want to use these predefined maps, you can use the procedures below to delete a factory-default map, edit an existing map, or create your own custom IPsec dynamic map instead:
In the WebUI
1. Scroll down to the IPsec Dynamic Map section of the IPSEC tab, then click Edit by a map name to edit an existing map, or click Add to create a new map.
You can also delete a predefined factory-default dynamic map by clicking Delete .
2. In the Name field, enter a name for the dynamic map.
3. In the Priority field, enter a priority number for the map. Negotiation requests for security associations try to match the highest-priority map first. If that map does not match, the negotiation request continues down the list to the next-highest priority map until a match is made.
4. Click the Version drop-down list, and select v2 to create a map for remote peers using IKEv2.
5. (Optional) Configure Perfect Forward Secrecy (PFS) settings for the dynamic peer by assigning a Diffie-
Hellman prime modulus group. PFS provides an additional level of security by ensuring that the IPsec SA key was not derived from any other key, and therefore can not be compromised if another key is broken.
Click the Set PFS drop-down list and select one of the following groups: n n n
Group 1: 768-bit Diffie–Hellman prime modulus group.
Group 2: 1024-bit Diffie–Hellman prime modulus group.
Group 14: 2048-bit Diffie–Hellman prime modulus group.
359 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
n
Group 19: 256-bit random Diffie–Hellman ECP modulus group.
n
Group 20: 384-bit random Diffie–Hellman ECP modulus group.
6. Select the transform set for the map to define a specific encryption and authentication type used by the dynamic peer. Click the Transform Set drop-down list, and select the transform set for the dynamic peer.
To view current configuration settings for an IPsec transform-set, access the command-line interface and issue the command crypto ipsec transform-set tag <transform-set-name>.
7. Set the Life Time to define the lifetime of the security association for the dynamic peer in seconds or kilobytes. The default value is 7200 seconds. To change this value, uncheck the default checkbox and enter a value between 300 and 86400 seconds or 1000 and 1000000000 kilobytes.
8. Click Done .
Finalizing WebUI changes
When you have finished configuring your IPsec VPN settings, click Apply to apply the new settings before navigating to other pages.
Configuring an L2TP VPN with IKEv2 in the CLI
Use the following procedures in the CLI to configure a remote access VPN for L2TP IPsec using IKEv2:
1. Define the server addresses:
(host)(config) #vpdn group l2tp enable client configuration {dns|wins} < ipaddr1> [< ipaddr2> ]
2. Enable authentication methods for IKEv2 clients:
(host)(config) #crypto isakmp eap-passthrough {eap-mschapv2|eap-peap|eap-tls}
3. Create address pools:
(host)(config) #ip local pool <pool> <start-ipaddr> <end-ipaddr>
4. Configure source NAT:
(host)(config) #ip access-list session srcnat user any any src-nat pool <pool> position 1
5. If you are configuring a VPN to support machine authentication using certificates, define server certificates for VPN clients using IKEv2:
(host)(config) #crypto-local isakmp server-certificate <cert>
The IKE pre-shared key value must be between 6-64 characters. To configure a pre-shared IKE key that contains nonalphanumeric characters, surround the key with quotation marks.
For example: crypto-local isakmp key "key with spaces" fqdn-any .
6. Define IKEv2 Policies:
(host)(config) #crypto isakmp policy <priority> encryption {3des|aes128|aes192|aes256|des} version v2 authentication {pre-share|rsa-sig|ecdsa-256ecdsa-384} group {1|2|19|20} hash {md5|sha|sha1-96|sha2-256-128|sha2-384-192} prf PRF-HMAC-MD5|PRF-HMAC-SHA1|PRF-HMAC-SHA256|PRF-HMAC-SHA384 lifetime <seconds>
7. Define IPsec Tunnel parameters:
(host)(config) #crypto ipsec mtu <max-mtu>
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 360
transform-set <transform-set-name> esp-3des|esp-aes128|esp-aes128-gcm|esp-aes192|espaes256|esp-aes256-gcm|esp-des esp-md5-hmac|esp-null-mac|esp-sha-hmac
Configuring a VPN for Smart Card Clients
This section describes how to configure a remote access VPN on the switch for Microsoft L2TP/IPsec clients with smart cards, which contain a digital certificate allowing user-level authentication without requiring the user to enter a username and password. As described earlier in this chapter, L2TP/IPsec requires two levels of authentication: IKE SA (machine) authentication and user-level authentication with an IKEv2 or PPP-based authentication protocol.
Microsoft clients running Windows 7 (and later versions) support both IKEv1 and IKEv2. Microsoft clients using
IKEv2 support machine authentication using RSA certificates (but not ECDSA certificates or pre-shared keys) and smart card user-level authentication with EAP-TLS over IKEv2.
Windows 7 (and later version) clients without smart cards also support user password authentication using EAP-
MSCHAPv2 or PEAP-MSCHAPv2.
Working with Smart Card clients using IKEv2
To configure a VPN for Windows 7 (and later version) clients using smart cards and IKEv2, follow the procedure described in
Configuring a VPN for L2TP/IPsec with IKEv2 on page 356 , and ensure that the following settings
are configured: n n n n
L2TP is enabled
User Authentication is set to EAP-TLS
IKE version is set to V2
The IKE policy is configured for ECDSA or RSA certificate authentication
Working with Smart Card Clients using IKEv1
Microsoft clients using IKEv1, including clients running Windows Vista or earlier versions of Windows, only support machine authentication using a pre-shared key. In this scenario, user-level authentication is performed through an external RADIUS server using PPP EAP-TLS, and client and server certificates are mutually authenticated during the EAP-TLS exchange. During the authentication, the switch encapsulates EAP-TLS messages from the client into RADIUS messages and forwards them to the server.
On the switch, you must configure the L2TP/IPsec VPN with EAP as the PPP authentication and IKE policy for preshared key authentication of the SA.
On the RADIUS server, you must configure a remote access policy to allow EAP authentication for smart card users and select a server certificate. The user entry in Microsoft Active Directory must be configured for smart cards.
To configure an L2TP/IPsec VPN for clients using smart cards and IKEv1, ensure that the following settings are configured:
1. On a RADIUS server, a remote access policy must be configured to allow EAP authentication for smart card users and to select a server certificate. The user entry in Microsoft Active Directory must be configured for smart cards. (For detailed information on creating and managing user roles and policies, see
n n
Ensure that the RADIUS server is part of the server group used for VPN authentication.
Configure other VPN settings as described in
Configuring a VPN for L2TP/IPsec with IKEv2 on page 356
, while selecting the following options:
361 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
l l l l
Select Enable L2TP
Select EAP for the Authentication Protocol.
Define an IKE Shared Secret to be used for machine authentication. (To make the IKE key global, specify
0.0.0.0 and 0.0.0.0 for both subnet and subnet mask.)
Configure the IKE policy for Pre-Share authentication.
Configuring a VPN for Clients with User Passwords
This section describes how to configure a remote access VPN on the switch for L2TP/IPsec clients with user passwords. As described earlier, L2TP/IPsec requires two levels of authentication: IKE SA authentication and user-level authentication with the PAP authentication protocol. IKE SA is authenticated with a preshared key, which you must configure as an IKE shared secret on the switch. User-level authentication is performed by the switch’s internal database.
On the switch, you must configure the following: n n n n n
AAA database entries for username and passwords
VPN authentication profile, which defines the internal server group and the default role assigned to authenticated clients
L2TP/IPsec VPN with PAP as the PPP authentication (IKEv1 only).
(For IKEv1 clients) An IKE policy for preshared key authentication of the SA.
(For IKEv2 clients) A server certificate to authenticate the switch to clients, and a CA certificate to authenticate VPN clients.
In the WebUI
Use the following procedure to configure L2TP/IPsec VPN for username/password clients through the WebUI:
1. Navigate to the Configuration > Security > Authentication > Servers page.
a. Select Internal DB to view entries for the internal database.
b. Click Add User .
c. Enter the username and password information for the client.
d. Click Enabled to activate this entry on creation.
e. Click Apply .
2. Navigate to the Configuration > Security > Authentication > L3 Authentication window.
a. Under the VPN Authentication profile , select Default > Server Group .
b. Select the internal server group from the Server Group drop-down menu.
c. Click Apply .
3. Navigate to the Configuration > Advanced Services > VPN Services > IPsec window.
a. Select Enable L2TP (this is enabled by default).
b. Select PAP for Authentication Protocols.
4. Configure other VPN settings as described in
Configuring a VPN for L2TP/IPsec with IKEv2 on page 356
, while ensuring that the following settings are selected: n n
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPsec tab, enable L2TP .
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPsec tab, select PAP as the authentication protocol.
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 362
In the CLI
The following example uses the command-line interface to configure a L2TP/IPsec VPN for username/password clients using IKEv1:
(host)(config) #vpdn group l2tp enable ppp authentication pap client dns 101.1.1.245
(host)(config) #ip local pool pw-clients 10.1.1.1 10.1.1.250
(host)(config) #crypto isakmp key <key> address 0.0.0.0 netmask 0.0.00
(host)(config) #crypto isakmp policy 1 authentication pre-share
Next, issue the following command in enable mode to configure client entries in the internal database:
(host)(config) #local-userdb add username <name> password <password>
Configuring Remote Access VPNs for XAuth
Extended Authentication (XAuth) is an Internet Draft that permits user authentication after IKE Phase 1 authentication. This authentication prompts the user for a username and password, in which user credentials are authenticated through an external RADIUS or LDAP server or the switch’s internal database. Alternatively, the user can initiate client authentication using a smart card, which contains a digital certificate to verify the client credentials. IKE Phase 1 authentication can be done with either an IKE preshared key or digital certificates.
Configuring VPNs for XAuth Clients using Smart Cards
This section describes how to configure a remote access VPN on the switch for Cisco VPN XAuth clients using smart cards. Smart cards contain a digital certificate, allowing user-level authentication without the user entering a username and password. IKE Phase 1 authentication can be done with either an IKE preshared key or digital certificates; for XAuth clients using smart cards, the smart card digital certificates must be used for IKE authentication. The client is authenticated with the internal database on the switch.
On the switch, you must configure the following:
1. Add entries for Cisco VPN XAuth clients to the switch’s internal database, or to an external RADIUS or LDAP server. For details on configuring an authentication server, see
Authentication Servers on page 178
.
For each client, you need to create an entry in the internal database with the entire Principal name (SubjectAltname in X.509 certificates) or Common Name as it appears on the certificate.
2. Verify that the server with the client data is part of the server group associated with the VPN authentication profile.
3. In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPsec tab, enable
L2TP .
4. In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPsec tab, enable
XAuth to enable prompting for the username and password.
5. The Phase 1 IKE exchange for XAuth clients can be either Main Mode or Aggressive Mode . Aggressive
Mode condenses the IKE SA negotiations into three packets (versus six packets for Main Mode). In the
Aggressive Mode section of the Configuration > VPN Services > IPsec tab, enter the authentication group name for aggressive mode to associate this setting to multiple clients. Make sure that the group name matches the aggressive mode group name configured in the VPN client software.
363 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
6. Configure other VPN settings as described in
Configuring a VPN for L2TP/IPsec with IKEv2 on page 356
, while ensuring that the following settings are selected: n
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPSEC tab, enable L2TP .
n n
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services> IPSEC tab, enable XAuth to enable prompting for the username and password.
Define an IKE policy to use RSA or ECDSA authentication.
Configuring a VPN for XAuth Clients Using a Username and Password
This section describes how to configure a remote access VPN on the switch for Cisco VPN XAuth clients using passwords. IKE Phase 1 authentication is done with an IKE preshared key; users are then prompted to enter their username and password, which is verified with the internal database on the switch.
On the switch, you must configure the following:
1. Add entries for Cisco VPN XAuth clients to the switch’s internal database. For details on configuring an authentication server, see
Authentication Servers on page 178
For each client, you need to create an entry in the internal database with the entire Principal name (SubjectAltname in X.509 certificates) or Common Name as it appears on the certificate.
2. Verify that the server with the client data is part of the server group associated with the VPN authentication profile.
3. Configure other VPN settings as described in
Configuring a VPN for L2TP/IPsec with IKEv2 on page 356
, while ensuring that the following settings are selected: n n n
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPSEC tab, enable L2TP .
In the L2TP and XAUTH Parameters section of the Configuration > VPN Services > IPSEC tab, enable XAuth to enable prompting for the username and password.
The IKE policy must use pre-shared authentication.
Working with Remote Access VPNs for PPTP
Point-to-Point Tunneling Protocol (PPTP) is an alternative to L2TP/IPsec. Like L2TP/IPsec, PPTP provides a logical transport mechanism using tunneling or encapsulation to send PPP frames across an IP network. PPTP relies on the PPP connection process to perform user authentication and protocol configuration.
With PPTP, data encryption begins after PPP authentication and connection process is completed. PPTP connections are encrypted through Microsoft Point-to-Point Encryption (MPPE), which uses the Rivest-Shamir-
Aldeman (RSA) RC-4 encryption algorithm. PPTP connections require user-level authentication through a PPPbased authentication protocol (MSCHAPv2 is the currently-supported method).
In the WebUI
1. Navigate to the Configuration > Advanced Services > VPN Services > PPTP page.
2. To enable PPTP, select Enable PPTP .
3. Select either MSCHAP or MSCHAPv2 as the authentication protocol.
4. Configure IP addresses of the primary and secondary DNS servers.
5. Configure the primary and secondary WINS Server IP addresses that are pushed to the VPN Dialer.
6. Configure the VPN Address Pool.
a. Click Add . The Add Address Pool window displays.
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 364
b. Specify the pool name, start address, and end address.
c. Click Done .
7. Click Apply to apply the changes before navigating to other pages.
In the CLI
(host)(config) #vpdn group pptp enable client configuration {dns|wins} <ipaddr1> [<ipaddr2>] ppp authentication {mschapv2}
(host)(config) #pptp ip local pool <pool> <start-ipaddr> <end-ipaddr>
Working with Site-to-Site VPNs
Site-to-site VPNs allow sites in different locations to securely communicate with each other over a Layer-3 network such as the Internet. You can use Alcatel-Lucent switches instead of VPN concentrators to connect the sites. You can also use a VPN concentrator at one site and a switch at the other site.
The Alcatel-Lucent switch supports the following IKE SA authentication methods for site-to-site VPNs: n n n
Preshared key: Note that the same IKE shared secret must be configured on both the local and remote sites.
Suite-B cryptographic algorithms
Digital certificates: You can configure an RSA or ECDSA server certificate and a CA certificate for each siteto-site VPN IPsec map configuration. If you use certificate-based authentication, the peer must be identified by its certificate subject name, distinguished name (for deployments using IKEv2), or by the peer’s IP address (for IKEv1). For more information about importing server and CA certificates into the switch, see
Management Access on page 833 .
Certificate-based authentication is only supported for site-to-site VPN between two switches with static IP addresses.
IKEv1 site-to-site tunnels cannot be created between master and local switches.
Enable IP compression in an IPsec map to reduce the size of data frames transmitted over a site-to-site VPN between OAW-4x50 Series or OAW-40xx Series switches using IKEv2 authentication. IP compression can reduce the time required to transmit the frame across the network. When this hardware-based compression feature is enabled, the quality of unencrypted traffic (such as Lync or Voice traffic) is not compromised by increased latency or decreased throughput. IP compression is disabled by default.
This feature is only supported in an IPv4 network using IKEv2. This feature cannot be enabled on a OAW-4450 switch or on a site-to-site VPN established using IKEv1.
Working with Third-Party Devices
Alcatel-Lucent switches can use IKEv1 or IKEv2 to establish a site-to-site VPN with another Alcatel-Lucent switch or third-party remote client devices. Devices running Microsoft
®
Windows 2008 can use Suite-B cryptographic algorithms and IKEv1 to support authentication using RSA or ECDSA. StrongSwan
®
4.3 devices can use IKEv2 to support authentication using RSA or ECDSA certificates, Suite-B cryptographic algorithms, and pre-shared keys. These two remote clients are tested to work with Alcatel-Lucent switches using Suite-B cryptographic algorithm.
Working with Site-to-Site VPNs with Dynamic IP Addresses
AOS-W supports site-to-site VPNs with two statically addressed switches, or with one static and one dynamically addressed switch. Two methods are supported to enable dynamically addressed peers:
365 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
n n
Pre-shared Key Authentication with IKE Aggressive Mode: The Alcatel-Lucent switch with a dynamic
IP address must be configured as the initiator of IKE Aggressive-mode for Site-Site VPNs, while the switch with a static IP address must be configured as the responder of IKE Aggressive mode. Note that when the switch is operating in FIPS mode, IKE aggressive mode must be disabled.
X.509 certificates: IPsec peers will identify each other using the subject name of X.509 certificates. IKE operates in main mode when this option is selected. This method is preferred from a security standpoint.
Understanding VPN Topologies
You must configure VPN settings on the switches at both the local and remote sites. In the following figure, a
VPN tunnel connects Network A to Network B across the Internet.
Figure 51 Site-to-Site VPN Configuration Components
To configure the VPN tunnel on switch A, you must configure the following: n n n n
The source network (Network A)
The destination network (Network B)
The VLAN on which switch A’s interface to the Layer-3 network is located (Interface A in
The peer gateway, which is the IP address of switch B’s interface to the Layer-3 network (Interface B in
Configure VPN settings on the switches at both the local and remote sites.
Configuring Site-to-Site VPNs
Use the following procedures to create a site-to-site VPN through the WebUI or CLI.
In the WebUI
1. Navigate to the Configuration > Advanced Services > VPN Services > Site-to-Site page.
2. In the IPsec Maps section, click Add to open the Add IPsec Map window.
3. Enter a name for this VPN connection in the Name field.
4. In the Priority field, enter a priority level for the IPsec map. Negotiation requests for security associations try to match the highest-priority map first. If that map does not match, the negotiation request continues down the list to the next-highest priority map until a match is made.
5. Select a Source Network Type to specify whether the VPN source , the local network connected to the switch, is defined by an IP address or a VLAN ID.
n
If you selected IP , enter the IP address and netmask for the source network. (See switch A in
n
If you selected VLAN , click the Source Network VLAN drop-down list and select the VLAN ID for the source network.
6. In the Destination Network and Destination Subnet Mask fields, enter the IP address and netmask for the destination , the remote network to which the local network communicates. (See switch B in
7. Select one of the supported peer gateway types:
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 366
n n
IP Address : Select this option to identify the remote end point of the VPN tunnel using an IP address.
FQDN : This option allows you to use same FQDN across different branches. The FQDN resolves to different IP addresses for each branch, based on its local DNS setting.
8. Define the Peer Gateway using an IP address or FQDN.
n
If you use IKEv1 to establish a site-to-site VPN for a statically addressed remote peer and selected
IP Address in the previous step, enter the IP address of the interface used by the remote peer to connect to the L3 network in the Peer Gateway field (See Interface B in
).
n n
If you are configuring an IPsec map for a dynamically addressed remote peer, and selected IP Address in the previous step, leave the peer gateway set to its default value of 0.0.0.0
.
If you selected FQDN as the peer gateway type in the previous step, enter the fully qualified domain name for the remote peer.
9. If you use IKEv2 to establish a site-to-site VPN for a statically addressed remote peer, identify the peer device by entering its certificate subject name in the Peer Certificate Subject Name field.
To identify the subject name of a peer certificate, issue the following command in the CLI: s how crypto-local pki servercert <certname> subject
10.The
Security Association Lifetime parameter defines the lifetime of the security association in seconds and kilobytes. The default value is 7200 seconds. To change this value, uncheck the default checkbox and enter a value between 300 and 86400 seconds or 1000 and 1000000000 kilobytes.
11.Click the Version drop-down list and select V1 to configure the VPN for IKEv1, or V2 for IKEv2.
12.(Optional) Click the IKEv Policies drop-down list and select a predefined or custom IKE policy to apply to the IPsec map. For more information on default IKE policies, see
.
13.IKEv2 site-to-site VPNs between master and local OAW-40xx Series switches support traffic compression between those devices. Select the IP Compression checkbox to enable compression for traffic in the siteto-site tunnel.
14.Select the VLAN containing the interface of the local switch that connects to the Layer-3 network. (See
Interface A in
This determines the source IP address used to initiate IKE. If you select 0 or None , the default is the VLAN of the switch’s IP address (either the VLAN where the loopback IP is configured, or VLAN 1 if no loopback IP is configured).
15.If you enable Perfect Forward Secrecy (PFS) mode, new session keys are not derived from previously used session keys. Therefore, if a key is compromised, that compromised key does not affect any previous session keys. PFS mode is disabled by default. To enable this feature, click the PFS drop-down list and select one of the following Perfect Forward Secrecy modes: n n n group1 : 768-bit Diffie–Hellman prime modulus group.
group2 : 1024-bit Diffie–Hellman prime modulus group.
group14 : 2048-bit Diffie–Hellman prime modulus group.
n n group19 : 256-bit random Diffie–Hellman ECP modulus group.
group20 : 384-bit random Diffie–Hellman ECP modulus group.
16.Click the Route ACL name drop-down list and select the name of a routing access control list (ACL) to attach a route ACL to inbound traffic on the VPN tunnel interface.
When you associate a routing ACL to inbound traffic on a switch terminating an L3 GRE tunnel, that ACL can forward traffic as normal, route traffic to a nexthop router on a nexthop list, or redirect traffic over an L3
GRE tunnel or tunnel group. For more information on creating a routing ACL, see
Creating a Firewall Policy on page 376
367 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
17.Select
Pre-Connect to establish the VPN connection, even if there is no traffic being sent from the local network. If you do not select this, the VPN connection is established only when traffic is sent from the local network to the remote network.
18.Select
Trusted Tunnel if traffic between the networks is trusted. If you do not select this, traffic between the networks is untrusted.
19.Select the Enforce NATT checkbox to enforce UDP 4500 for IKE and IPSEC. This option is disabled by default.
20.Select the Force Tunnel Mode checkbox to enforce forced-tunnel mode instead of transport mode for site-to-site IPsec SA. This option is disabled by default.
21.Add one or more transform sets to be used by the IPsec map. Click the Transform Sets drop-down list, select an existing transform set, then click the arrow button by the drop-down list to add that transform set to the IPsec map.
22.For site-to-site VPNs with dynamically addressed peers, enable Dynamically Addressed Peers .
a. Select Initiator if the dynamically addressed switch is the initiator of IKE Aggressive-mode for Site-Site
VPNs, or select Responder if the dynamically addressed switch is the responder for IKE Aggressivemode.
b. In the FQDN field, enter a fully qualified domain name (FQDN) for the switch. If the switch is defined as a dynamically addressed responder, you can select all peers to make the switch a responder for all VPN peers, or select Per Peer ID and specify the FQDN to make the switch a responder for one specific initiator.
23.Select one of the following authentication types: a. For pre-shared key authentication, select Pre-Shared Key , then enter a shared secret in the IKE Shared
Secret and Verify IKE Shared Secret fields. This authentication type is generally required in IPsec maps for a VPN with dynamically addressed peers, but can also be used for a static site-to-site VPN.
b. For certificate authentication, select Certificate , then click the Server Certificate and CA certificate drop-down lists to select certificates previously imported into the switch. See
for more information.
24.Click
Done to apply the site-to-site VPN configuration.
25.Click
Apply .
26.Click the IPSEC tab to configure an IKE policy.
a. Under IKE Policies, click Add to open the IPSEC Add Policy configuration page.
b. Set the Priority to 1 for this configuration to take priority over the Default setting.
c. Set the Version type to match the IKE version you selected in Step 10.
d. Set the Encryption type from the drop-down list .
e. Set the HASH Algorithm from the drop-down list.
f. Set the Authentication to PRE-SHARE if you use pre-shared keys. If you use certificate-based IKE, select
RSA or ECDSA .
g. Set the Diffie–Hellman Group from the drop-down list.
h. The IKE policy selections, including any pre-shared key, must be reflected in the VPN client configuration.
When using a third-party VPN client, set the VPN configuration on clients to match the choices made above. If you use the Alcatel-Lucent dialer, you must configure the dialer prior to downloading the dialer onto the local client.
i.
Click Done to activate the changes.
j.
Click Apply.
AOS-W 6.5.3.x
| User Guide Virtual Private Networks | 368
In the CLI
To configure a site-to-site VPN with two static IP switches using IKEv1, issue the following commands in the CLI:
(host)(config) #crypto-local ipsec-map <name> <priority> src-net <ipaddr> <mask> dst-net <ipaddr> <mask> peer-ip <ipaddr> vlan <id> version v1|v2 peer-cert-dn <peer-dn> pre-connect enable|disable trusted enable
For certificate authentication: set ca-certificate <cacert-name> set server-certificate <cert-name>
(host)(config) #crypto isakmp policy <priority> encryption {3des|aes128|aes192|aes256|des} version v1|v2 authentication {rsa-sig|ecdsa-256ecdsa-384} group {1|2|19|20} hash {md5|sha|sha1-96|sha2-256-128|sha2-384-192} lifetime <seconds>
For pre-shared key authentication:
(host)(config) #crypto-local isakmp key <key> address <ipaddr> netmask <mask>
(host)(config) #crypto isakmp policy <priority> encryption {3des|aes128|aes192|aes256|des} version v1|v2 authentication pre-share group {1|2|19|20} hash {md5|sha|sha1-96|sha2-256-128|sha2-384-192} lifetime <seconds>
To configure site-to-site VPN with a static and dynamically addressed switch that initiates IKE Aggressive-mode for Site-Site VPN:
(host)(config) #crypto-local ipsec-map <name> <priority> src-net <ipaddr> <mask> dst-net <ipaddr> <mask> peer-ip <ipaddr>local-fqdn <local_id_fqdn> vlan <id> pre-connect enable|disable trusted enable
For the Pre-shared-key:
(host)(config) #crypto-local isakmp key <key> address <ipaddr> netmask 255.255.255.255
For a static IP switch that responds to IKE Aggressive-mode for Site-Site VPN: crypto-local ipsec-map <name2> <priority> src-net <ipaddr> <mask> dst-net <ipaddr> <mask> peer-ip 0.0.0.0
peer-fqdn fqdn-id <peer_id_fqdn> vlan <id> trusted enable
For the Pre-shared-key:
(host)(config) #crypto-local isakmp key <key> fqdn <fqdn-id>
369 | Virtual Private Networks AOS-W 6.5.3.x | User Guide
For a static IP switch that responds to IKE Aggressive-mode for Site-Site VPN with one PSK for All FQDNs:
(host)(config) #crypto-local ipsec-map <name2> <priority> src-net <ipaddr> <mask> peer-ip 0.0.0.0
peer-fqdn any-fqdn vlan <id> trusted enable
For the Pre-shared-key for All FQDNs:
(host)(config) #crypto-local isakmp key <key> fqdn-any
Supporting Null Encryption for IKEv1
Starting from AOS-W 6.5.1, XLP based switches are supported with null encryption for IKEv1 as an encryption algorithm. This helps in reducing the load on the local router for internet destined traffic.
Null encryption does not increase the security of traffic routed but is used only to imply that no encryption method is used over a particular transmission. Null Encryption can now be configured as an encryption algorithm in transform set, which can be used in any crypto map.
Since null encryption is supported only for IKEv1, it should be used only for crypto maps with version 1.
In the WebUI
To create a new transformation set with null encryption as the encryption algorithm, perform the following steps in the WebUI:
1. Navigate to Configuration > Advanced Services > VPN Services > Advanced tab.
2. Under IPSEC Transform Sets click Add .
3. Enter a name in Transform Set Name .
4. Select ESP-NULL from the Encryption drop-down list.
5. Click Done .
6. Click Apply .
To add the transformation set