ws5100 series switch migration guide

WS5100 Series Switch

Migration Guide

© 2007 Motorola, Inc. All rights reserved.

MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office. Symbol is a registered trademark of Symbol Technologies, Inc. All other product or service names are the property of their respective owners.

Contents

Chapter 1. Overview

Chapter 2. Switch Web UI and Image Upgrades2.1 Accessing the Switch Web UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.1.1 Web UI Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12.1.2 Connecting to the Switch Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.2 Switch Password Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32.2.1 Recovering the Switch Password using the Web UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32.2.2 Recovering the Switch Password using the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

2.3 Shutting Down the Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42.3.1 Shutting Down the Switch using the 1.4.x/2.x Shutdown Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42.3.2 Shutting Down the Switch using the 3.0 Halt Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

2.4 Upgrading the Switch Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-52.4.1 Upgrading the Switch Image from 1.4.x or 2.x to Version 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

2.5 Downgrading the Switch Image from Version 3.0 to 1.4.x or 2.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

Chapter 3. Use Cases3.1 Tempest University’s Hotspot Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13.2 Tempest University’s Current WS5100 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13.3 Migrating the Existing Configuration to the 3.0 Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

3.3.1 Migrating Up to the 3.0 Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23.3.2 Porting a WS5100 2.0 Configuration to a 3.0 Migrated WS5100. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33.3.3 Configure New Hotspots on Campus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33.3.4 Configuring a Windows 2003 IIS Server for Hotspot Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13

3.3.4.1 IIS Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-153.3.5 Sample HTML Pages / CGI Script for External Hotspots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16

3.4 Use Case: Remote VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-183.4.1 Network Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-183.4.2 Configuring DHCP Sever to serve public IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19

3.4.2.1 Adding a New DHCP Pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-193.4.2.2 Adding a New DHCP Pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20

3.4.3 Configuring Crypto Policy (IKE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-203.4.3.1 Create IKE Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-213.4.3.2 Configure Pre-Shared Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-223.4.3.3 Enable or Disable IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

3.4.4 Set Global Lifetimes for IPSec Security Associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-233.4.5 Define Transform Sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-233.4.6 Create Client Related Mode Configuration (Remote Access VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

TOC-2 WS5100 Series Switch Migration Guide

3.4.7 Configuring IPSec Security Associations (Crypto Map). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-243.4.7.1 Creating Crypto Map Entry for Establishing Manual Security Associations . . . . . . . . . . . . . . . . 3-243.4.7.2 Creating Crypto Map Entry that Use IKE to Establish Security Association . . . . . . . . . . . . . . . . 3-24

3.4.8 Apply Crypto Map Sets to Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-253.4.9 Monitor and Maintain IPSec Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25

3.4.10 Network Address Translation in IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25

Chapter 4. Web UI Menu Path Comparison4.1 Web UI Menu Path Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.1.1 High-Level Device Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14.1.2 Configuring the System Time (NTP) Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34.1.3 Managing Software, Configuration and Log Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

4.1.3.1 WS5100 Switch Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34.1.3.2 WS5100 Switch Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44.1.3.3 WS5100 Log Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

4.1.4 VLAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-54.1.5 Configuring Switch Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

4.1.5.1 ACL Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-64.1.5.2 Encryption and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-84.1.5.3 Rouge AP Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-124.1.5.4 Configuring the On-Board Radius Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13

4.1.6 Viewing Switch Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-144.1.7 Switch Certificate Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15

Chapter 5. WS5100 LED Behavior Comparison5.1 WS5100 1.4.x and 2.x Baseline LED Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

5.1.1 Start Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15.1.2 Configured as a Primary Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15.1.3 Configured as a Standby Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25.1.4 Error Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

5.2 WS5100 LED Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25.2.1 Start Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-25.2.2 Primary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35.2.3 Standby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35.2.4 Error Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

Chapter 6. DHCP6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16.2 Managing the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26.3 Configuring DHCP Server using the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

6.3.1 Creating network pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-36.3.2 Creating host pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-36.3.3 Troubleshooting DHCP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-36.3.4 Creating DHCP option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5

6.4 Configuring DHCP Client using SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-56.5 WS-SW-DHCP-MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5

6.5.1 wsSWDhcpModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

TOC-3

6.5.2 wsSWDhcpClient. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-66.5.2.1 wsSWDhcpClient Sub Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-66.5.2.2 wsSWDhcpClientSvrInfor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7

6.6 WS-SW-DHCP-SERVER-MIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-96.6.1 wsSwDhcpServerModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10

6.6.1.1 wsSwDhcpSvrGlobal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-106.6.1.2 wsSwDhcpSvrExcludeTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-116.6.1.3 wsSwDhcpSvrPoolTable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-116.6.1.4 wsSwDhcpSvrIncludeTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-116.6.1.5 wsSwDhcpSvrPoolOptionTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-116.6.1.6 wsSwDhcpBindingStatusTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-126.6.1.7 wsSwDhcpSvrGlobalOptionTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-126.6.1.8 wsSwDhcpRelayTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12

6.6.2 wsSWDhcpSvrGlobal Sub Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-126.6.2.1 wsSwDhcpSvrBootp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-136.6.2.2 wsSwDhcpSvrPingInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-136.6.2.3 wsSwDhcpSvrEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-136.6.2.4 wsSwDhcpSvrRestart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13

6.6.3 wsSwDhcpSvrExcludeTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-146.6.3.1 wsSwDhcpSvrExcludeEntry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-146.6.3.2 wsSwDhcpSvrExcludeLowIpAddr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-156.6.3.3 wsSwDhcpSvrExcludeHighIpAddr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-156.6.3.4 wsSwDhcpSvrExcludeRowStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15

6.6.4 wsSwDhcpSvrPoolTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-166.6.4.1 wsSwDhcpSvrPoolEntry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-176.6.4.2 wsSwDhcpSvrPoolNameIndex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-186.6.4.3 wsSwDhcpSvrPoolType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-186.6.4.4 wsSwDhcpSvrPoolHostIp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-186.6.4.5 wsSwDhcpSvrPoolSubnetIpAndMask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-196.6.4.6 wsSwDhcpSvrPoolClientId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-196.6.4.7 wsSwDhcpSvrPoolClientName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-196.6.4.8 wsSwDhcpSvrPoolHardWareAddrAndType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-206.6.4.9 wsSwDhcpSvrPoolDomainName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20

6.6.4.10 wsSwDhcpSvrPoolNetBiosNodeType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-206.6.4.11 wsSwDhcpSvrPoolBootfile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-216.6.4.12 wsSwDhcpSvrPoolDdnsUpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-216.6.4.13 wsSwDhcpSvrPoolDdnsUpdateAll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-216.6.4.14 wsSwDhcpSvrPoolDdnsIp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-226.6.4.15 wsSwDhcpSvrPoolDdnsDomainName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-226.6.4.16 wsSwDhcpSvrPoolDdnsTtl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-236.6.4.17 wsSwDhcpSvrPoolDdnsMultiUserClass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-236.6.4.18 wsSwDhcpSvrPoolDefaultRouter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-236.6.4.19 wsSwDhcpSvrPoolBootpNextSvrIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-246.6.4.20 wsSwDhcpSvrPoolDnsSvrIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-246.6.4.21 wsSwDhcpSvrPoolNetbiosSvrIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-246.6.4.22 wsSwDhcpSvrPoolNoDefault. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25


6.6.4.23 wsSwDhcpSvrPoolLeaseTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-256.6.4.24 wsSwDhcpSvrPoolRowStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25

6.7 Configuring DHCP using the WebUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-266.7.1 Creating a Network Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-266.7.2 Creating a Host Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29

Chapter 7. Dynamic DNS7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17.2 Managing DDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17.3 Configuring DDNS using the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

7.3.1 Creating Pool with DDNS Updates Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27.3.1.1 Important DDNS Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3

7.4 Configuring DDNS using SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-47.5 WS-SW-DHCP-SERVER-MIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4

7.5.1 wsSwDNSModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-57.5.1.1 wsSwDNSDomainName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-57.5.1.2 wsSwDNSNameSvrTable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

7.5.2 wsSwDNSDomainName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-57.5.2.1 wsSwDNSDomainNameStatic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-67.5.2.2 wsSwDNSDomainNameLookup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6

7.5.3 wsSwDNSNameSvrTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-67.5.3.1 wsSwDNSNameSvrEntry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-77.5.3.2 wsSwDNSNameSvrIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-77.5.3.3 wsSwDNSNameSvrPriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-87.5.3.4 wsSwDNSNameSvrType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-87.5.3.5 wsSwDNSNameSvrRowStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

7.6 Configuring DDNS using the Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9

Chapter 8. Certificate Management8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18.2 Configuring the Certificate Manager using CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

8.2.1 Generating a Self-Signed Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28.2.2 Generating a Certificate Request and Importing the Server Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28.2.3 Importing CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-38.2.4 Porting the Certificate Onto Another Switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3

8.2.4.1 Create a Keypair and Associate it to a Trustpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-38.2.4.2 Importing the Certificate to Another Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4

8.2.5 Configuring Trustpoint using the Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48.2.5.1 Creating a Trustpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-58.2.5.2 Uploading the Server Certificate/CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9

Chapter 9. Radius9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

9.1.1 User Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29.1.2 Authentication of Terminal/Management User(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29.1.3 Access Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29.1.4 Proxy to External Radius Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

TOC-5

9.1.5 LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-39.1.6 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

9.2 Configuring Onboard Radius Server using CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-39.2.1 Sending an Access Request to the Local Radius Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-59.2.2 Enable Debug Logs for Radius. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6

9.3 Configuring Radius using GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-69.3.1 Configuring Radius Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6

9.3.1.1 Configuring a Radius Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-79.3.1.2 Authenticating a Local Radius Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-89.3.1.3 Creating a Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-99.3.1.4 Creating a User. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10

9.3.2 Configuring WLAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-129.3.3 Configuring LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14

9.4 Use Case – Configuring Onboard RADIUS to use Active Directory as user database?9-15

Chapter 10. ACL10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

10.1.1 Supported ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-110.1.1.1 Router ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-210.1.1.2 Port ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-310.1.1.3 Wireless LAN ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3

10.1.2 ACL Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-310.1.3 Precedence Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4

10.2 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-410.3 Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5

10.3.1 Static NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-510.3.2 Port NAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6

10.4 Configuring ACL using CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-610.4.1 Configure an IP Standard ACL/IP Extended ACL or MAC Extended ACL . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6

10.4.1.1 Configuring IP Standard ACL using CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-710.4.1.2 Configuring IP Extended ACL using CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-710.4.1.3 Configuring MAC Extended ACL using CLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8

10.4.2 Applying ACLs to Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-810.4.2.1 Configuring Port ACLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-810.4.2.2 Configuring Router ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-910.4.2.3 Configuring Wireless LAN ACLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10

10.5 Configuring ACL using the Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1210.5.1 Configuring IP Standard ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1210.5.2 Configuring MAC Extended ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1410.5.3 Attaching an ACL on a WLAN Interface/Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16

10.5.3.1 Adding a New ACL WLAN Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17

Chapter 11. VPN11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

11.1.1 Types of VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-211.2 Managing VPN in WS5100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2


11.2.1 Traffic Secured in VPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-311.3 Configuring VPN using CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

11.3.1 Configure Peer Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-411.3.2 Configure Parameters for Control Traffic using ISAKMP Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4

11.3.2.1 Create IKE Polices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-511.3.2.2 Configure Pre-Shared Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-511.3.2.3 Configure Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-511.3.2.4 Configuring ISAKMP using CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6

11.3.3 Security Parameters for Data Traffic using Transform Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-611.3.3.1 Define Transform Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-711.3.3.2 Selecting Appropriate Transform Sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-711.3.3.3 Configuring transform-set using CLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-711.3.3.4 Set Global Lifetimes for IPSec Security Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8

11.3.4 Specifying Traffic to Protect using Crypto ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-811.3.5 Binding all Parameters to a Remote Peer using Crypto Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-911.3.6 Activating IPSec to a Remote Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1011.3.7 Configuring for Remote VPN Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11

11.3.7.1 Configuring Remote VPN using CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1111.3.8 Apply Crypto Map Sets to Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1211.3.9 Monitor and Maintain IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12

11.3.10 Network Address Translation in IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1211.4 Special Configuration for Windows XP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13

11.4.1 Windows XP VPN Client Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1311.5 Configuring VPN using the WebUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1811.6 Use Case for Remote VPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3111.7 Use Case for Site-to- Site VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-33

Appendix A.Technical Support

About This Guide

IntroductionThis guide provides information for those familiar with using the 1.4.x and 2.x version WS5100 switch software who require orientation to the new WS5100 3.0 switch features and functionality.

Documentation SetThe documentation set for the WS5100 Series Switch is partitioned into the following guides to provide information for specific user needs.

• WS5100 System Reference Guide - describes advanced setup and configuration activities for all facets of the the WS5100 Series Switch.

• WS5100 Installation Guide - describes the basic setup and configuration required to transition to more advanced configuration of the switch.

• WS5100 CLI Reference - describes the Command Line Interface (CLI) and Management Information Base (MIB) commands used to configure the WS5100 Series Switch.

• WS5100 Troubleshooting Guide - describes workarounds to known conditions the user may encounter.

Document ConventionsThe following conventions are used in this document to draw your attention to important information:

NOTE: Screens and windows pictured in this guide are samples and can differ from actual screens.

NOTE: Indicate tips or special requirements.

CAUTION: Indicates conditions that can cause equipment damage or data loss.

WARNING! Indicates a condition or procedure that could result in personal injury or equipment damage.

!

viii WS5100 Series Switch Migration Guide

Notational ConventionsThe following additional notational conventions are used in this document:

• Italics are used to highlight the following:

• Chapters and sections in this and related documents

• Dialog box, window and screen names

• Drop-down list and list box names

• Check box and radio button names

• Icons on a screen.

• GUI text is used to highlight the following:

• Screen names

• Menu items

• Button names on a screen.

• bullets (•) indicate:

• Action items

• Lists of alternatives

• Lists of required steps that are not necessarily sequential

• Sequential lists (e.g., those that describe step-by-step procedures) appear as numbered lists.

Overview

This WS5100 Series Switch Migration Guide is designed to provide users familiar with the 1.4.x and 2.x switch baselines an overview of the significant changes to the switch Web UI and switch LED activity. The Web UI used for the new 3.0 baseline shares almost no similarities with the applet used in previous releases. Therefore, Motorola recommends you familiarize yourself with the following content to make your WS5100 3.0 configuration activity more effective.

• Switch Web UI and Image Upgrades.

• Use Cases.

• Web UI Menu Path Comparison.

• WS5100 LED Behavior Comparison.

• DHCP.

• Dynamic DNS.

• Certificate Management.

• Radius.

• ACL.

• VPN.

1-2 WS5100 Series Switch Migration Guide

Switch Web UI and Image Upgrades

This chapter provides information about the following:

• Accessing the Switch Web UI.

• Switch Password Recovery.

• Shutting Down the Switch.

• Upgrading the Switch Image.

• Downgrading the Switch Image from Version 3.0 to 1.4.x or 2.x.

2.1 Accessing the Switch Web UI

2.1.1 Web UI RequirementsThe switch Web UI is accessed using Internet Explorer version 5.5 (or later) and SUN JRE (Java Runtime Environment) 1.5 (or later). Refer to the Sun Microsystems Web site for information on downloading JRE.

To prepare Internet Explorer to run the Web UI:

1. Open IE’s Tools > Internet Options panel and select the Advanced tab.

2. Uncheck the following checkboxes:

• Use HTTP 1.1

• Java console enabled (requires restart)

• Java logging enabled

• JIT compiler for virtual enabled (requires restart).

2.1.2 Connecting to the Switch Web UITo display the Web UI, launch a Web browser on a computer with the capability of accessing the switch.

NOTE: Ensure you have HTTP connectivity to the switch, as HTTP is a required to launch the switch Web UI from a browser.


To display the switch Web UI:

1. Point the browser to the IP address assigned to the wired Ethernet port (port 2). Specify a secure connection using the https:// protocol.

The switch login screen displays:

2. Enter the User ID admin, and Password superuser. Both are case-sensitive. Click the Login button.

Once the Web UI is accessed the Switch main menu item displays a configuration tab with high-level switch information. Click the Show Dashboard button to display an overall indicator of switch health. Once the switch is fully configured, the dashboard is the central display for the user to view the version of firmware running on the switch, quickly assess the last 5 alarms generated by the switch, view the status of the switch’s Ethernet connections and view switch CPU and memory utilization statistics.

NOTE: If using HTTP to login into the switch, you may encounter a Warning screen if a self-signed certfificate has not been created and implemented for the switch. This warning sceen will continue to display on future login attempts until a self-signed certificate is implemented. Motorola recommends only using the default certificate for the first few login attempts until a self-signed certficiate can be generated.

NOTE: If your password is lost, there is a means to access the switch, but you are forced to revert the switch back to its factory default settings and lose your existing configuration (unless saved to a secure location). Consequently, Motorola recommends keeping the password in a secure location so it can be retrieved. For information on password recovery, see Switch Password Recovery on page 2-3.

NOTE: The chapters within this System Reference Guide are arranged to be complimentary with the main menu items in the menu tree of the switch Web UI. Refer to this content to configure switch network addressing, security and diagnostics as required.

Switch Web UI and Image Upgrades 2-3

2.2 Switch Password RecoveryWith the release of the 3.0 version switch software, your Web UI login password can be recovered, but at the expense of updates you have made to your configuration file since the default image was updated.

If the switch Web UI password is lost, you cannot get passed the Web UI login screen for any viable switch configuration activity. Consequently, a password recovery login must be used that will default your switch back to its factory default configuration. The switch password can be recovered using either the Web UI or the switch CLI.

If you know your existing password and wish to change it, go to the Switch main menu item, select the Configuration tab and click the Reset Password button. A screen displays prompting for the existing password and the new password.

2.2.1 Recovering the Switch Password using the Web UITo access the switch using a password recovery username and password:

1. Point the browser to the IP address assigned to the wired Ethernet port (port 2).

The switch login screen displays:

2. Enter a password recovery username of restore and password recovery password of restoreDefaultPassword. Click the Login button.

The switch will login into the Web UI with its reverted default configuration. If you had exported the switch’s previous configuration to an external location, it now can be imported back to the switch. For information on importing switch configuration files, see Porting a WS5100 2.0 Configuration to a 3.0 Migrated WS5100 on page 3-3.

2.2.2 Recovering the Switch Password using the CLITo access the command line interface and using a password recovery username and password:

1. Connect to the CLI using either Telnet, SSH or a Serial cable. You should see the following:Please press Enter to activate this console.

2. Press Enter and enter cli at the login prompt.

WS5100 login: cli

3. Once you enter the User Access Verification. Enter the username restore and press Enter.User Access Verification

CAUTION: Using this recovery procedure erases the switch’s current configuration and data files from the switch /flash dir. Only the switch’s license keys are retained. You should be able to log in using the default username and password (admin/superuser) and restore the switch’s previous configuration (only if it has been exported to a secure location before the password recovery procedure was invoked).

CAUTION: Using this recovery procedure erases the switch’s current configuration and data files from the switch /flash dir. Only the switch’s license keys are retained. You should be able to log in using the default username and password (admin/superuser) and restore the switch’s previous configuration (only if it has been exported to a secure location before the password recovery procedure was invoked).

!

!


Username: restore

When prompted to enter a password enter restoreDefaultPassword and press Enter. For security reasons the password you enter is not displayed.

Password:

4. When the warning prompt appears type y and press Enter. The following will display:

WARNING:This will wipe out the configuration (except license key) and userdata under "flash:/" and reboot the device

Do you want to continue? (y/n):y

Switch will be rebooted with default configuration...The system is going down NOW !!

5. Once the switch has rebooted login using the default username and password.

2.3 Shutting Down the SwitchThe CLI commands used to shutdown the switch have changed with the release of the 3.0 version WS5100 Series Switch. Please refer to the following to differentiate between the shutdown command (1.4.x and 2.x) from the halt command (3.0).

2.3.1 Shutting Down the Switch using the 1.4.x/2.x Shutdown CommandTo gracefully shutdown the WS5100, issue the shutdown command from the configure context in the CLI:

WS5000.(Cfg)> shutdown

This command will halt the system. A manual power cycle will be required to re-start the switch.

Do you want to proceed (yes/no) : yes

System shut down might take a few mins....

Shutting down the switch...

Shutting down dhcp daemon.. doneShutting down apache server in the OPEN mode...done.

Shutting down cell controller........ done

Shutting down snmpd agent...done.Shutting down Postgres....done.

INIT: Sending processes the TERM signal

Hostname: WS5000.motorola.com.Shutting down PacketSwitch interface .....

Shutting down dhcp daemon.. done

Shutting down apache server in the OPEN mode...done.Cell controller not running.

i2c-core: Device or resource busy

Shutting down Postgres....done.Stopping periodic command scheduler: cron.

Stopping internet superserver: inetd.

Saving random seed... done.

Stopping deferred execution scheduler: atd.Stopping kernel log daemon: klogd.

Stopping system log daemon: syslogd.

flushing ide devices: hda


System halted.

As directed, wait 10 seconds and turn off the device by toggling the power switch.

2.3.2 Shutting Down the Switch using the 3.0 Halt CommandTo shut down the WS5100 from the CLI, issue a halt command, as the halt command is now used to shut down the WS5100 Series Switch with the release of the 3.0 version WS5100 baseline:

WS5100#haltWireless switch will be halted, do you want to continue? (y/n):yThe system is going down NOW !!

% Connection is closed by administrator!WIOS_SECURITYMGR[395]: DNSALG: Shutting down.

WIOS_SECURITYMGR[395]: FTPALG: Shutting down.

The system is halted.

2.4 Upgrading the Switch ImageThe WS510 ships with a factory installed firmware image with the full feature functionality described in this System Reference Guide. However, Motorola periodically releases switch firmware that includes enhancements or resolutions to known issues. Verify your current switch firmware version with the latest version available from the Motorola Web site before determining if your system requires an upgrade.

Additionally, legacy users running either the 1.4.x or 2.x version switch firmware may want to upgrade to the new 3.0 baseline to take complete advantage of the new diverse feature set available to them. This chapter describes the method to upgrade from either the 1.4.x or 2.x baseline to the new 3.0 baseline.

NOTE: The WS5100 will power off after issuing a halt command through a software toggle of the power supply. Be sure to flip the power switch to the Off position. If the power cord is removed and reinstalled, or power is lost and restored, the switch will power back on.

CAUTION: Motorola recommends caution when upgrading your WS5100 switch image to the 3.0 baseline as portions of your configuration will be lost and unrecoverable. Ensure that you have exported your switch configuration to a secure location before upgrading your switch. The upgrade.log file will contain a list of the issues found in the conversion of the configuration file to the new format.

CAUTION: If using a 1.4.x or 2.x admin user password shorter than 8 characters (such as the default Motorola password), the password will be converted to the 3.0 baseline admin password of “password” upon a successful update to the 3.0 baseline. Ensure your existing 1.4.x or 2.x admin password is longer than 8 characters before updating, or leave as is and use “superuser” to login into an updated 3.0 baseline.

CAUTION: After upgrading the switch baseline from 1.4.x or 2.x to the 3.0 baseline, applet caching can produce unpredictable results and contents. After the upgrade, ensure your browser is restarted. Otherwise, the credibility of the upgrade can come into question.

!

!

!


2.4.1 Upgrading the Switch Image from 1.4.x or 2.x to Version 3.0To upgrade a switch running either a 1.4.x or 2.x version to the latest 3.0 version switch firmware:

1. Execute the PreUpgradeScript utility (or use the CLI) to ensure there is enough space on your system to perform the upgrade. The PreUpgradeScript utility should be in the same directory as the upgrade files.

2. Install the Cfgupgrade1.x-setup utility on a Windows desktop system by double clicking the Cfgupgrade 1.x-setup file.

Follow the prompts displayed by the installer to install Cfgupgrade 1.x-setup.

A WS5100 Configuration Upgrade icon gets created within the Program Files folder. The icon can be optionally created on your Windows desktop as well.

3. From the WS5100 running either 1.4.x or 2.x, create a configuration and save it on the switch.

WS5100# save <file name> <.cfg>

This is the configuration that will be upgraded to the new 3.0 baseline.

4. Copy the configuration file <.cfg> from the legacy WS5100 to the Windows system where the conversion utility resides.

Use ftp or tftp to transfer the file.

5. Click on the WS5100 configuration Upgrade icon (from the Windows system).

6. Select the config file copied on to the windows system and run it.

A folder having the same name as the config file is created. The folder contains the converted startup-config file (in the new upgraded format) along with other log files.

7. Copy the startup-config file back to the WS5100 running using either tftp or ftp.

8. Download or copy the image file <WS5100-3.0.0.0-XX.v1> or <WS5100-3.0.0.0-XX.v2> to the WS5100 running the legacy switch firmware.

9. On the WS5100, type:

WS5100#service

WS5100#password "password"exec

Upon reboot, the switch runs the 3.0 image using startup-config as the running configuration.

10.Repeat the instructions above for additional switch upgrades, ensuring that <WS5100-3.0.0.0-XX.v1> is used for 1.4.x version upgrades, and <WS5100-3.0.0.0-XX.v2> is used for 2.x version upgrades.

NOTE: Motorola recommends saving a copy of the switch configurartion to a secure location before the upgrade. If an error occurs with the upgrade a viable configuration will be needed to restore on the switch.

NOTE: If upgrading a 1.4.x version WS5100 to the new 3.0 baseline, be sure you are using the <WS5100-3.0.0.0-XX.v1> image file. If upgrading a 2.x version WS5100 to the new 3.0 baseline, be sure you are using the <WS5100-3.0.0.0-XX.v2> image file.


2.5 Downgrading the Switch Image from Version 3.0 to 1.4.x or 2.xIf for some reason you want to downgrade your WS5100 back down to a 1.4.x or 2.x version firmware image, use one of the two following image files:

• WS5100-1.4.3.0-012R.img

• WS5100-2.1.0.0-029R.img

Use Cases

3.1 Tempest University’s Hotspot DeploymentThis chapter presents a use case illustrating the challenges faced by Tempest University when migrating their existing WS5100 2.x implementation to the new WS5100 3.0 baseline.

Tempest University (inaugurated in 1993) has grown rapidly in recent years and is one of the most popular universities in Ireland. The university has approximately 18,000 students, but has increased its student enrollment applications 70% in the last three years.

With this expanding student population in mind, the Tempest University IT department needed to provide its students a flexible and convenient means to access the their wireless infrastructure. The University purchased 1500 wired PCs for student access in fixed areas, but faced the problem of providing students wireless access to the university’s network using mobile devices connecting to the campus WLAN.

The University required a system that could be easily administered, secure and be relocated as their campus grew. The IT department determined a wireless switch system would significantly lower the cost of deploying a scalable network infrastructure and drive down the cost of managing, maintaining and upgrading wireless systems as the student population and number of mobile users grew.

The University decided to standardize on Motorola’s WS5100 and AP300 Access Port. The first switches and access ports were deployed at the University network in December 2002 and the system provided students with wireless networking speeds of up to 54 Mbps.

Free from the constraints of cables, the new WS5100 managed WLAN allowed student network access from seminar rooms, lecture theatres, student unions and other areas across campus. In addition, the WS5100 deployment allowed the University to increase the computer-to-students ratio without having to dedicate additional (and expensive) floor space to fixed PCs.

3.2 Tempest University’s Current WS5100 ConfigurationTempest University currently deploys the following WS5100 configuration:

• Five primary WS5100 switches (running the 2.x baseline) backed by an additional five switches for redundancy.

• 400 AP300 Access Ports to support the 1500 PCs receiving wireless radio coverage around the campus.

• EAP support on each switch with 5 switches configured as masters and the remaining 5 configured as slaves.


3.3 Migrating the Existing Configuration to the 3.0 BaselineTempest University wants to update their switches to the new Motorola 3.0 baseline, add support for its increasing student population and create hotspots strategically on campus that optimize data, video and or wireless traffic depending on the requirement for specific campus segments. Specific challenges include:

• Adding wireless support for an additional 1500 students in addition to the existing 1500 on wired PCs. Adding the 1500 students constitutes migrating the existing 2.0 configuration to the 10 existing switches, then adding 5 new WS5100 switches and moving the newly created WS5100 3.0 configuration to the 5 new switches.

• Create new hot spots on campus. Some hot spots are intended to cover a single large room, others cover complete buildings (to support separate departments on campus). The new hot spot implementation would allow students more flexibility to conduct research, access the internet, check email and obtain files from their respective departments using their own laptops or PDAs.

3.3.1 Migrating Up to the 3.0 BaselineTempest University is required to migrate each of its existing ten WS5100s to the new 3.0 baseline to optimize the 3.0 feature set to achieve its goals for expanding their coverage area and utilizing the 3.0 feature set.

To migrate up to the 3.0 baseline, the Tempest University IT department completes the following:

1. Download the Cfgupgrade1.0-setup conversion utility from http://www.symbol.com/downloads.

2. Install the utility on a Windows desktop system by double clicking the Cfgupgrade 1.0-setup file.

Follow the prompts displayed by the installer to install Cfgupgrade 1.0-setup.

A WS5100 Configuration Upgrade icon gets created within the Program Files folder. The icon can be optionally created on your Windows desktop as well.

3. From the WS5100 running 2.x, create a configuration and save it on the switch.

WS5100# save <file name> <.cfg>

This is the configuration that will be upgraded to the new 3.0 baseline.

4. Copy the configuration file <.cfg> from the legacy WS5100 to the Windows system where the conversion utility resides.

Use ftp or tftp to transfer the file.

5. Click on the WS5100 configuration Upgrade icon (from the Windows system).

NOTE: Migrating the 2.0 baseline up to the 3.0 baseline does not preserve the switch’s previous 2.0 configuration. Consequently, the IT Department at Tempest University must save each switch’s existing configuration and port it to the new 3.0 baseline as a separate activity from the switch operating system migration.

CAUTION: Motorola recommends caution when upgrading the WS5100 switch image to the 3.0 baseline as portions of your configuration will be lost and unrecoverable. Ensure that you have exported your switch configuration to a secure location before upgrading your switch.

NOTE: Motorola recommends saving a copy of the switch configurartion to a secure location before the upgrade. If an error occurs with the upgrade a viable configuration will be needed to restore on the switch.

!

Use Cases 3-3

6. Select the config file copied on to the windows system and run it.

A folder having the same name as the config file is created. The folder contains the converted startup-config file (in the new upgraded format) along with other log files.

7. Copy the startup-config file back to the WS5100 running using either tftp or ftp.

8. Download or copy the image file <WS5100-3.0.0.0-XX.v2> to each WS5100 running the 2.x legacy switch firmware.

9. On WS5100 running the legacy switch firmware, type:

WS5100#service

WS5100#password "password"

exec

Upon reboot, the switch runs the 3.0 image using startup-config as the running configuration.

10.Tempest University repeats the instructions above for each switch upgrade, ensuring <WS5100-3.0.0.0-XX.v2> is used for 2.x version upgrades.

3.3.2 Porting a WS5100 2.0 Configuration to a 3.0 Migrated WS5100Configuration upload tool currently not available (3-31-06)

3.3.3 Configure New Hotspots on Campus Tempest University wants to extend its WLAN access to students in various parts of the campus to provide Internet hotspot access using their existing wireless infrastructure (WS5100 + AP300). Security requirements in extending the guest access include separating the secured corporate WLAN from the less secure hotspot WLAN and limiting student access to Web browsing the Internet and student periodical resources only. FTP, Telnet and all other applications will be blocked.

The Tempest University IT team wishes to deploy the hotspots with each hotspot using the external hotspot option using Windows 2003 IIS servers + WS5100 Onboard Radius servers with the built-in user database. The team will use the switch Web UI to configure the hotspots.

The Tempest University IT team wants to begin by creating a VLAN interface for use with the hotspot supported Humanities WLAN.

NOTE: If upgrading a 2.x version WS5100 to the new 3.0 baseline, be sure you are using the <WS5100-3.0.0.0-XX.v2> image file.

NOTE: Once each Tempest University switch has been migrated up to the 3.0 baseline, each switch is ready to have its configuration ported from the 2.x baseline to the 3.0 baseline.

NOTE: The Tempest University IT team plans to develop hotspot supported WLANs for different academic areas and gathering areas on campus. Though each hotspot will share numerous attributes, there will be subtle differences between them, as certain user populations will be included (excluded) from accessing the resources within specific hotspots. The Tempest University IT team will begin by developing a hotspot for the Humanities area. Once completed with this initial example, the team will define additional hotspots to support the entire campus.


1. The Tempest University IT team selects Network > Switch Virtual Interface from the main menu tree and ensures the Configuration tab is selected.

2. The team clicks the Add button to create a new switch virtual interface.

3. The team assigns a VLAN ID of 101. The team wants IP address assignments to be made automatically, so the Use DHCP to obtain IP Address automatically checkbox is selected. With these changes made, the team clicks the OK button.

The Tempest University IT team is now ready to define a VLAN for use with the WLAN the team will eventually configure. for the hotspot enabled WLAN.

Use Cases 3-5

4. The Tempest University IT team selects Network > Layer 2 Virtual LANs from the main menu tree.

5. The Tempest University IT team highlights eth2 (from within the Name column) and clicks the Edit button.

A Port VLAN Change Warning message displays, The team clicks OK to continue.

6. The Tempest University IT team selects Trunk from the Mode drop-down menu.

The Selected VLANs option becomes available for additions.

7. The Tempest University IT team adds VLAN 101 to the Selected VLANs listed (separated by a comma). The team clicks OK to continue.

The Tempest University IT team is now to create an IP Extended ACL for the hotspot. This step is recommended for hotspot developers but can be skipped.


8. The Tempest University IT team selects Security > ACLs from the main menu tree, and clicks the Add button within the Configuration tab.

9. The Tempest University IT team selects Extended IP List from the ACL Type drop-down menu. This options uses source and destination IP addresses and an optional protocol type.

10.The Tempest University IT team enters a ACL ID of 2000. This is the ID to be used specifically for the Humanities Department ACL. The team clicks OK to continue.

11.The Extended IP List 2000 displays in the list of ACLs. The Tempest University IT team highlights the Extended IP List 2000 by selecting it and then clicks Add from the Associated Rules field to display the Add Rule sub screen.

12.The Tempest University IT team defines a Precedence of 1 and permit designation for the ACL.

Use Cases 3-7

13.With the changes complete, the Tempest University IT team clicks OK to continue.

The Tempest University IT team is now ready to apply the ACL to the VLAN interface created for the Humanities department hotspot.

14.From the ACLs screen the team selects the Attach tab and clicks the Add button.

15.The Tempest University IT team selects (the previously configured values) of vlan 101 from the Interface drop-down menu and the ACL ID of 2000 from the IP ACL drop-down menu. OK is then selected to continue.

The Tempest University IT team is now ready to create a hotspot enabled WLAN for the Humanities department hotspot.


16.The Tempest University IT team selects Network > Wireless LANs from the switch main menu tree.

17.The IT team selects an available ESSID (not already enabled) and clicks the Edit button at the bottom of the screen.

18.The Tempest University IT team changes the ESSID to Humanities Hotspot.

It is the team’s plan to assign an ESSID to each hotspot representative of where the target hotspot is to be deployed on campus.

19.The Tempest University IT team changes the VLAN ID to 101.

Use Cases 3-9

20.The Tempest University IT team selects Hotspot from the Authentication options.

The team is now ready to define the properties of the external hotspot’s configuration.


21.The Tempest University IT team clicks the Config button next to the hotspot authentication item.

22.The Tempest University IT team selects External from the drop-down menu and enters the URL locations for the 3 HTML pages as displayed above.

23.The Tempest University IT team references the Allow List to enter an IP address for the Humanities department Web site (that may be accessed by the Hotspot user even without authentication).

When setting up hotspots for various segments on campus, the team plans to make the online periodicals relevant to the area the hotspot supports available to the student population. By just making the Humanities periodicals available to the Humanities hotspot, the user base is better served and radio traffic noise is reduced.

24.The Tempest University IT team clicks OK to exit the screen and return to the Wireless LAN Edit window.

With the properties of the Humanities department external hotspot defined, the Tempest University IT department can now configure how users are authenticated to access the hotspot’s resources.

NOTE: For information on enabling an External We Server, see Configuring a Windows 2003 IIS Server for Hotspot Support on page 3-13. For sample HTML Page/CGI Script content, see Sample HTML Pages / CGI Script for External Hotspots on page 3-16.

Use Cases 3-11

25.The Tempest University IT team clicks on Radius Config button to display the Network Wireless LANs Edit Radius Configuration sub screen.

26.The Tempest University IT team enters 157.235.10.1 as the Radius Server IP address for the Primary Radius server and 157.235.10.2 as the address for the secondary server.

27.The Tempest University IT team sets the shared secret password to humanities for both servers. The team clicks OK to save the change. The team clicks OK again within the Wireless LANs Edit screen.

The Tempest University IT team is now ready to adjust the Hotspot WLAN QoS policy to customize it for data throughput within the Humanities hotspot. Once customized, the WLAN can be enabled.

28.The Tempest University IT team selects Network > Wireless LANs > WMM from the main menu tree.

29.The team locates the Humanities Hotspot within the list of hotspots and selects the Background access method (since the Humanities department needs to prioritize data transfers) from among the four access methods listed per WLAN.

NOTE: Other hotspot supported WLANs on campus would have different access methods selected and configured based on the priority of the data proliferating within that campus segment (video and voice versus data etc.).


30.The Edit button is selected, and the AIFSN, Transmit Ops, CW Minimum and CW Maximum are adjusted to provide Background traffic priority. When completed, the team clock the OK button.

The Tempest University IT team is now ready to enable (activate) the Humanities WLAN and begin supporting the student population within that area of campus.

Use Cases 3-13

31.Still within the Network > Wireless LANs screen, the team switches from the WMM tab to the Configuration tab.

32.The Tempest University IT team selects the Humanities Hotspot WLAN from those displayed within the table and clicks the Enable button.

The WLAN supporting the Humanities hotspot is now ready to be supported by the switch managed network.

3.3.4 Configuring a Windows 2003 IIS Server for Hotspot SupportThe IIS services installed on the Windows 2003 Server are part of the Application Server. The Application Server in turn has other components which can selectively be installed during the Windows 2003 Server installation or can be later added.

The Tempest University IT team is working with a Windows Server installation that does not include IIS services. Therefore, they need to add ISS though the following steps:

1. The Tempest University IT team selects Start > Settings > Control Panel > Add or Remove Programs.

NOTE: The Tempest University IT team is now ready to define additional hotspots for all of the other departments and areas on campus requiring user access to the switch managed network. Each hotspot will have a unique ESSID and the external hotspot page will most likely have a different allow list as Web resources are restricted based on the access needs of each hotspot. Additionally, each WLAN should have an ACL and QoS policy configured supporting the user base and data type proliferating that part of the campus. For instance, the Audio Visual Department should have a QoS policy defined that prioritizes video and voice at the expense of data transfers, whereas the Humanities hotspot described in this use case requires data prioritization at the expense of high priority traffic like video and voice.


2. The Tempest University IT team selects Add/Remove Windows Components from the left-hand side of the screen.

3. The Tempest University IT team selects the Application Server checkbox (if not already selected). Click the Details button.

Use Cases 3-15

4. The Tempest University IT team selects the Internet Information Services (IIS) checkbox and clicks OK. They then click Next.

This will start the IIS installation. The Tempest University IT team may be prompted to insert their Windows 2003 Server CD to complete installation. The Tempest University IT team is now ready to configure the IIS Server, for more information, see IIS Server Configuration on page 3-15

3.3.4.1 IIS Server Configuration

To configure the IIS Server to support the their hotspot, the Tempest University IT team does the following:

1. The Tempest University IT team uses Start > All Programs > Administrative Tools > Internet Information Service (IIS) Manager to Start/ Stop the Default Web Site.

After the Tempest University IT team has the IIS Server up and running, their 3 hotspot Web Pages (Login.htm, Welcome.htm and Failure.htm) need to be copied to the ISS Web Server's root directory.

2. The Tempest University IT team copies text for the 3 HTML files into a text editor (MS Word) and saves them as (Login.htm, Welcome.htm and Failure.htm).

3. The Tempest University IT team edits the 3 HTML pages to change the IP address in the HTML page to the IP address of their switch (running the Radius Server).

NOTE: For sample text of the content of the Login, Welcome and Failure pages, see Sample HTML Pages / CGI Script for External Hotspots on page 3-16.


4. The Tempest University IT team copies these 3 htm files onto their Windows IIS Servers root directory, launch Windows file explorer and copy the files under C:\Inetpub\wwwroot directory.

3.3.5 Sample HTML Pages / CGI Script for External HotspotsLogin.htm<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">

<html><head>

<title>Login Page 111</title></head><body link="#FFFF77" alink="#FFFF77" vlink="

#FFFF77" bgcolor="#225599"><font face="Verdana" color="#EEEEFF">

<center><h2>Network Login 111</h2></center><br><center><h4>Please enter your use

rname and password 111</h4></center><br><center><table border="0" cellspacing="7

" cellpadding="5" bgcolor="#5A77AB"><form action="https://10.0.1.77:444/cgi-bin/hslogin.cgi" method="POST" >

<tr><td><b>Username:</b></td><td><input type="text" size="20" name="f_user"></td></tr>

<tr><td><b>Password:</b></td><td><input type="password" size="20" name="f_pass">

</td></tr>

<tr><td colspan="2" align="center"><input type="submit" name="submit" value="LogIn"></td></tr></form></table></center>

<center><h5><i>Contact the network administrator if you do not have an account 111</i></h5></center></font></body></html>

Use Cases 3-17

Welcome.htm<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">

<html><head>

<title>Authentication success.222</title></head><body link="#FFFF77" alink="#FFFF77" vlink="#FFFF77" bgcolor="#225599"><font face="Verdana" color="#EEEEFF">

<center><img src="222"></center><center><h2>Authentication Success. 222 </h2><br><center><h4>You now have network access.<BR>Click the disconnect link

below to end this session 222.</h4></center><br><br><br><center><a href="https://10.0.1.77:444/cgi-bin/hslogout.cgi"><h4>Disconnect</h4></a></center><center><img src="222"></center><center><h5><i>222</i></h5></center></font></body></html>

Failure.htm<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><html>

<head>

<title>Unable to authenticate 333</title></head><body link="#FFFF77" alink="#FFFF77" vlink="#FFFF77" bgcolor="#225599"><font face="Verdana" color="#EEEEFF">

<center><img src="333"></center><center><h2>Authentication Failed. 333</h2></center><br><center><h4>Either the username and password are invalid, or service isunavailable at this time 333</h4></center><br><br><br><center><a href="http://192.168.1.1/login.htm"><h4>Try Again</h4></a></center><center><img src="333"></center><center><h5><i>Contact the network administrator if you do not have an

account 333</i></h5></center></font></body></html>

This should be the IP address of your WS5100This should be the IP address of your IIS Server


3.4 Use Case: Remote VPNIn this scenario we have a mobile unit connected wirelessly to a WS5100 switch which needs to access a corporate network (trusted network) securely using the switch’s IPSec VPN functionality.

In the above diagram, a Motorola client is associated to WLAN 1 that is attached to VLAN1 on the switch. VLAN1 is on the 157.235.188.x subnet and is running a DHCP Server that supplies IP addresses for this subnet. The corporate network is on VLAN3 of the switch, which has a 192.168.0.x subnet.

The two networks use unregistered addresses and are connected over the public Internet by site-to-site VPN. In this example NAT is required for the connections to the public Internet. However NAT is not required for traffic between the two networks, which can be transmitted using a VPN tunnel over the public Internet. This allows a wired LAN in branch offices to be bridged directly to the central site while maintaining security.

3.4.1 Network OverviewThe Motorola client in this example is associated with WLAN1 and received an IP address of 157.235.188.4 from the DHCP server on VLAN1. This client wants to access the 192.168.0.x network securely. This will be accomplished using the switch’s IP Sec, IKE and XAuth VPN features.

If the client is VPN enabled, it initiates a connection with the VPN server on the switch, the client and server then exchange device authentication via Internet Key Exchange (IKE), followed by user authentication using IKE Extended Authentication (Xauth). Client related configuration is then pushed to the client using Mode Configuration, and an IPsec security association (SA) is created. Once the client establishes an IKE SA configured for Xauth, the client must wait for a "username/password" challenge and then responds to the challenge with their username and password.

If the switch indicates that authentication was successful, the client requests further configuration parameters from the switch. At this stage the internal IP address (virtual IP) is pushed to the client from a pool configured under Client Mode Configuration, IPsec SAs are created, and the connection is complete.

Use Cases 3-19

Once the client has received a virtual IP (192.168.0.11), additional packets from the client within the IPSec tunnel are routed to the corresponding interface (VLAN3) and the client gains access to the corporate network.

The following sections provide step-by-step instructions for seting up the remote VPN setup described in the example above. To configure this on your own network substitue your networks parameters for the ones described in the example.

3.4.2 Configuring DHCP Sever to serve public IP addressesThe client needs to have an IP address before it can connect to the VPN Server on our switch to create an IPSec tunnel. To do this we need the DHCP Server on the interface to provide public IP address to the IPSec clients.

3.4.2.1 Adding a New DHCP Pool

The first step is to enable the DHCP server to assign an IP address to the client.

1. Select Services > DHCP Server from the main menu tree.

The DHCP Server screen displays with the Configuration tab is displayed.

2. Select the Enable DHCP Server checkbox to enable the switch’s internal DHCP Server on the current interface.

NOTE: The IPSec tunnel is only between the client and the switch Once the tunnel is established the packets on the trusted network are sent without any encryption.


3.4.2.2 Adding a New DHCP Pool

1. Click the Add button at the bottom of the screen.

2. In the Pool Name field, enter the name of the IP pool from which IP addresses can be issued to client requests on this interface. In the case of our example we’ll call this pool Wireless Clients.

3. For the sake of this example, we will skip the Domain, NetBios Node, and Boot File fields as they are not necessary for this setup.

4. Enter the name of the boot file used for this pool within the Boot File parameter.

5. From the Network field, define the IP Address and Subnet Mask used for DHCP discovery and requests between the DHCP Server and DHCP clients. For this example enter 157.235.188.0 for IP address and 24 for subnet.

6. The Lease Time field defines one of the two kinds of leases the DHCP Server assigns to its clients. For this example leave the Lease Time field, set at the default of 1:00:00.

7. We will also skip the Server section since it is irrelevant to this example.

8. Provide the Included Ranges (starting and ending IP addresses) for this particular pool. For this example enter 157.235.188.2 in the Start IP field and 157.235.188.50 in the End IP field.This provides 49 addresses that can be assigned to clients on this network.

9. Click OK to save and add the changes to the running configuration and close the dialog.

10.Click the Apply button on the main DHCP screen to save the configuration and then click the Restart DHCP Server button to restart the DHCP server with the new settings.

3.4.3 Configuring Crypto Policy (IKE)IKE automatically negotiates IPSec security associations (SAs) and enables IPSec secure communications without costly manual pre-configuration.

IKE provides the following benefits:

• Eliminates the need to manually specify all the IPSec security parameters in the crypto maps at both peers.

Use Cases 3-21

• Allows you to specify a lifetime for the IPSec security association.

• Allows encryption keys to change during IPSec sessions.

• Permits Certification Authority (CA) support for a manageable, scalable IPSec implementation.

• Allows dynamic authentication of peers.

If you do not want IKE to be used with your IPSec implementation, you can disable it for all IPSec peers.

To configure IKE, perform the following steps:

• Create IKE Policies

• Configure Pre-Shared Keys

• Enable IKE

3.4.3.1 Create IKE Policies

An IKE policy must be established identically on both the peers including the pre-shared key. An IKE policy defines a combination of security parameters to be used during the IKE negotiation. Before configuring a crypto policy five parameters must be decided upon by both ends of the VPN tunnel. If any of these parameters do not match, the VPN tunnel cannot be established.

These are the five parameters to define in each IKE policy:

NOTE: IKE must be enabled or disabled at all IPSec peers; you cannot have a mix of IKE-enabled and IKE-disabled peers within your IPSec network you must manually specify all the IPSec security associations in the crypto maps at all peers.

NOTE: Only main mode of IKE negotiation will be supported.

Parameter Accepted Values Keyword Default Value

Encryption algorithm 56-bit DES-CBC

128-bit AES

Des

Aes

56-bit DES-CBC

Hash Algorithm SHA-1 (HMAC variant)

MD5 (HMAC variant)

sha

md5

SHA-1 (HMAC variant)

Authentication Method Pre-Shared Keys

CA-Certificate

pre-share

cert

Pre-Shared Keys

Security Association's Lifetime Can specify any number of seconds - 86400 seconds (one day)


Navigate to the Security > IKE Settings > IKE Policy screen. For this example set those parameters as follows:

1. Enter a Priority value of 1.

2. Set the Encryption to DES.

3. Set the Hash Value to MD5.

4. Set the Authentication type to Pre-Shared Key.

5. Set the SA Lifetime to 10800 seconds (3 hours).

6. Click OK to return to the IKE Policy screen.

7. Click Apply to save the new IKE Policy.

3.4.3.2 Configure Pre-Shared Keys

To configure pre-shared keys, specify the shared keys at each peer.

For this example we will only set up the pre-shared key for the one client that wishes to connect to the remote network. In your network you will likely set up pre-shared keys for each of the clients using VPN.

Navigate to the Security > IKE Settings > Configuration screen.

1. Click the Add button.

2. In the Add Pre-shared Key dialog, choose Peer IP Address and enter in the IP address of the client. In this case 157.235.188.4

3. Enter a Key to be used as the pre-shared key for both client and server. For this example enter in test12345 as the key.

Diffie-Hellman Group Identifier 768-bit Diffie-Hellman

1024-bit Diffie-Hellman

1

2

5

14

15

16

17

18


NOTE: A given pre-shared key is shared between two peers. At a given peer you can specify the same key to share with multiple remote peers; however, a more secure approach is to specify different keys to share between different pairs of peers.

Use Cases 3-23

4. Click Ok to return to the Configuration screen.

5. Click Apply to save the new pre-shared key.

6. You must then set up the pre-shared key of test12345 on the client. Refer to the client’s documentation for information on adding an IKE Pre-shared key.

3.4.3.3 Enable or Disable IKE

IKE is enabled by default. IKE does not have to be enabled for individual interfaces, but is enabled globally for all interfaces at the switch.

For this example we will leave IKE enabled.

3.4.4 Set Global Lifetimes for IPSec Security AssociationsYou can change the global lifetime values which are used when negotiating new IPSec security associations. (These global lifetime values can be overridden for a particular crypto map entry).

These lifetimes only apply to security associations established via IKE. Manually established security associations do not expire.

There are two lifetimes: a "timed" lifetime and a "traffic-volume" lifetime. A security association expires after the first of these lifetimes is reached. The default lifetimes are 3600 seconds (one hour) and 4,608,000 kilobytes (10 megabytes per second for one hour).

If you change a global lifetime, the new lifetime value will not be applied to currently existing security associations, but will be used in the negotiation of subsequently established security associations. If you wish to use the new values immediately, you can clear all or part of the security association database.

3.4.5 Define Transform SetsA transform set represents a certain combination of security protocols and algorithms. During the IPSec security association negotiation, the peers agree to use a particular transform set for protecting data flow.

With manually established security associations, there is no negotiation with the peer, so both sides must specify the same transform set. If you change a transform set definition, the change is only applied to crypto map entries that reference the transform set. The change will not be applied to existing security associations, but will be used in subsequent negotiations to establish new security associations. If you want the new settings to take effect sooner, you can clear all or part of the security association database by using the clear crypto sa command.

3.4.6 Create Client Related Mode Configuration (Remote Access VPN)When the client initiates a connection with the VPN server on our switch, the "conversation" that occurs between the peers consists of device authentication via Internet Key Exchange (IKE), followed by user authentication using IKE Extended Authentication (Xauth), push client relate configuration (using Mode Configuration), and IPsec security association (SA) creation.

An overview of this process is as follows:

1. The client attempts to establish an IKE SA between its public IP address and the public IP address of the switch where the VPN server is running.

NOTE: The following information is not needed to complete the IPSec VPN use case outlined above, but contains additional information on IPSec VPN configuration that may be useful in your implementation.


2. After the IKE SA is successfully established, and if the switch is configured for Xauth, the client waits for a "username/password" challenge and then responds to the challenge of the switch.

3. The information that is entered is checked against authentication entities (either configured on the switch or using radius server).

4. If the switch indicates that authentication was successful, the client requests further configuration parameters from the switch. The remaining system parameters (for example, IP address, DNS, and split tunnel attributes) are pushed to the client at this time using Client Mode Configuration.

5. After the client has received the configuration parameters, IKE quick mode is initiated to negotiate IPsec SA establishment.

6. Following this IPsec SAs are created and the connection is complete.

Once we configure the client related parameters as a group using mode configuration, we can attach this group to the cryto map entry that will be assigned on an interface.

3.4.7 Configuring IPSec Security Associations (Crypto Map)To configure SA’s we will use the concept of crypto-map entries. Crypto map entries created for IPSec pull together the various parts used to set up IPSec security associations, including:

• Crypto access list defines what traffic should be protected and what traffic should not be protected – for example access list can be created to protect traffic between Subnet A and Subnet Y or between Host A and Host B. The particular crypto map entry will reference the specific access list that defines whether IPSec processing is to be applied to the traffic matching the permit in the access list.

• Where IPSec-protected traffic should be sent (who the remote IPSec peer is)

• The local address to be used for the IPSec traffic

• What IPSec security should be applied to this traffic (selecting from a list of one or more transform sets)

• Whether security associations are manually established or are established via IKE

• Other parameters that might be necessary to define an IPSec security association

The policy described in the crypto map entries is used during the negotiation of security associations. For IPSec to succeed between two IPSec peers, both peers' crypto map entries must contain compatible configuration statements.

3.4.7.1 Creating Crypto Map Entry for Establishing Manual Security Associations

The use of manual security associations is a result of a prior arrangement between the users of the local switch and the IPSec peer. If IKE is not used for establishing the security associations, there is no negotiation of security associations, so the configuration information in both systems must be the same in order for traffic to be processed successfully by IPSec.

3.4.7.2 Creating Crypto Map Entry that Use IKE to Establish Security Association

When IKE is used to establish security associations, the IPSec peers can negotiate the settings they will use for the new security associations. This means that you can specify lists (such as lists of acceptable transforms) within the crypto map entry.

NOTE: You can apply only one crypto map set to a single interface. The crypto map set can include a combination of IPSec/IKE, and IPSec/manual entries. Multiple interfaces can share the same crypto map set if you want to apply the same policy to multiple interfaces.

Use Cases 3-25

3.4.8 Apply Crypto Map Sets to InterfacesYou need to apply a crypto map set to each interface through which IPSec traffic will flow. Applying the crypto map set to an interface instructs the switch to evaluate all the interface's traffic against the crypto map set and to use the specified policy during connection or security association negotiation on behalf of traffic to be protected by crypto (either CET or IPSec).

3.4.9 Monitor and Maintain IPSec TunnelsNew configuration changes will only take effect when negotiating subsequent security associations. If you want the new settings to take immediate effect, you must clear the existing security associations so that they will be re-established with the changed configuration.

For manually established security associations, you must clear and reinitialize the security associations or the changes will never take effect.

3.4.10 Network Address Translation in IPSecNAT is most often used to convert private address into routable public addresses. With static NAT each private address maps to one public address. In a dynamic/hide NAT both IP address and Port are mapped, allowing many privately addressed hosts to share one public IP address. Check sums must be recomputed and embedded IP addresses carried in application protocols like FTP may be translated. There is a problem when NAT is applied before IPSec.

• The IPSec Authentication Header protects entire IP packets including IP headers, against modification in transit. NAT will modify the IP header so inherently NAT is incompatible with AH.

• The IPSec Encapsulating Security Payload (ESP) usually encrypts IP packets. NAT modifies TCP and UDP ports, but clearly can’t do so when the packet is encrypted. Hence NAT is incompatible with ESP.

The solution to over come this problem is UDP encapsulation. In this approach the IPSec packet is encapsulated in an UDP/IP header which lets NAT do their thing. This works for IPSec ESP. ESP encapsulated packets are exchanged between IKE peers. The peers must support the same method of UDP ESP encapsulation. IKE peers will exchange a known value to determine whether they both support NAT traversal (UDP Encapsulation) . if the IKE peers agree, they use IKE probes or discovery payloads to determine whether NAT is being applied at some point between them. Only when IKE peers agree and NAT is encountered UDP encapsulation is used.

IKE peers communicate over UDP port 500, UDP encapsulated ESP communicates on the same port. It ensures that IKE and UDP encapsulated ESP packets are subjected to the same mid-stream address translation. The sender indicates that an encapsulated packet follows by setting the first 8 bytes of UDP payload to zero. These bytes overlap the IKE initiator cookie field, for which zero is an invalid value. Thus, implementations can use these bytes to discriminate between the IKE and UDP-encapsulated ESP arriving on port 500. Because only peers that agree will ever send UDP-encapsulated ESP packets.

In hide NAT private IP address and source port are temporarily bound to a shared public IP address and a used port. A timeout dissolves this binding after seconds or minutes of inactivity, enabling hide NAT pool reuse. IPSec VPN’s protect traffic exchanged between mutually authenticated endpoints. For NAT traversal to work, end points cannot be dynamically remapped mid-session. To preserve dynamic NAT bindings for the life of an IPSec session, a one byte UDP “keepalive” may be used.

Web UI Menu Path Comparison

This chapter provides a sample of the differences a user will experience when navigating within the WS5100 3.0 Web UI. The new WS5100 3.0 Web UI is a departure from the applet used in previous WS5100 switch releases. Consequently, every previous navigation used to access a specific feature in the 1.4.x and 2.x baselines is different in the 3.0 baseline. The goal of this chapter is to provide Web UI navigation samples enabling 1.4.x and 2.x users to familiarize themselves with the differences within the new WS5100 3.0 baseline.

4.1 Web UI Menu Path NavigationThis section provides a comparison in Web UI menu navigation amongst the 1.4.x, 2.x and 3.0 baselines. This information is presented by displaying the menu paths and button actions used to navigate to the target feature.

4.1.1 High-Level Device InformationThis section describes the differences in Web UI menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when accessing high-level switch information. Information is also provided for re-booting and powering off the switch using the WS51005100 Web UI.

CAUTION: This chapter does not contain information on how to configure switch settings. This chapter’s intention is to define the differences in Web UI navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines. This chapter does not include an overview of the CLI differences for each Web UI function described. For information on the implications of configuring your WS5100, see the WS5100 System Reference Guide available from the Motorola Web site. For an extensive description of the new CLI commands available to the new WS5100 3.0 baseline, see WS5100 CLI Reference Guide.

!


From the 1.4.x and 2.x WS5100 baselines, accessing high-level device information (such as the quick start and chassis information) is accomplished from submenu items within the View parent menu. Table 4.1 High-Level Device Information

Configuration Option/Feature 1.4.x Location 2.x Location 3.0 Location

Accessing Switch Quick Start Data

View > Quick Start View > Quick Start Switch >--------------------------------------

• Click the Configuration Tab.

• Click the Show. Dashboard button.

Accessing System, Network and Diagnostic Performance Information

View > Chassis View > Chassis Switch >

Click the Configuration tab.

--------------------------------------

Network >

• Click the Configuration tab.

--------------------------------------

Diagnostics >

• Click the Environment, CPU, Memory, Disk, Processes or Other Resources tabs.

Reboot (Restart) or Shutdown the Switch

Run a “reset” command using the switch CLI.

or

Run a “shutdown” command using the switch CLI.

System Settings > Device > Reboot --------------------------------------

• Click OK when the warning message states connection will be lost.

System Settings > Device > Shutdown

• Click OK if warning message states Web UI connection will be lost.

Switch>--------------------------------------


• Click the Restart or Shutdown buttons.

Web UI Menu Path Comparison 4-3

4.1.2 Configuring the System Time (NTP) Settings This section describes the differences in menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when using the Web UI to define the switch system time.

4.1.3 Managing Software, Configuration and Log Files

4.1.3.1 WS5100 Switch Firmware

This section describes the differences in menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when using the Web UI to manage switch software.

Table 4.2 Configuring the System Time (NTP) Settings


Setting System Time and Synchronizing WS5100 with NTP Server

For switch time:

System Settings >Date/Time

For NTP time:

System Settings > Kerberos > Configuration > NTP

For switch time:

System Settings >Date/Time

For NTP time:

System Settings > Kerberos > Configuration > NTP

For secure NTP:

Services > Secure NTP

Table 4.3 WS5100 Switch Firmware


Viewing the Attributes of Existing Switch Firmware Files

System Settings >Firmware Management >Available Images


Switch > Firmware

Setting Global Software Settings

Not Available Not Available Switch > Firmware

--------------------------------------

• Select a firmware file and click the Global Settings button.

Upload/Update Firmware


--------------------------------------

Select a target firmware version.

• Click the Upload Files button.

• Use the Browse button to select the target firmware version.


--------------------------------------

Select a target firmware version.

• Click the Upload Files button.

• Use the Browse button to select the target firmware version.

Switch > Firmware

--------------------------------------

Select a firmware file and click the Update Firmware button.


4.1.3.2 WS5100 Switch Configuration Files

This section describes the differences in menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when using the Web UI to manage switch configuration files.

4.1.3.3 WS5100 Log Files

This section describes the differences in menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when using the Web UI to manage the logging of system events.

Table 4.4 WS5100 Switch Configuration Files


Review Existing Config Files

Use the “directory” CLI command (System Context).

Use the “directory” CLI command (System Context).

Switch > Configurations

Editing Existing Config Files

Use the “configure” CLI command (System Context).

Use the “configure” CLI command (System Context).


--------------------------------------

• Select an existing file and click Edit.

Viewing the Contents of a Config File

Use the “show” CLI command (System Context).

Use the “show” CLI command (System Context).


--------------------------------------

• Select an existing file and click View.

Transferring Config Files

Use the “copy” CLI command (System Context).

Use the “copy” CLI command (System Context).


--------------------------------------

• Select an existing file and click Transfer Files.

Table 4.5 WS5100 Log Files


Configure (Enable) Event Logging

System Settings >

Event Notification >--------------------------------------

• Select the Events tab.

System Settings >

Event Notification >

--------------------------------------


Diagnostics > System Logging > --------------------------------------

• Click the Enable Logging Module checkbox.

• Set logging configuration.


4.1.4 VLAN ConfigurationThis section describes the differences in menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when using the Web UI to configure VLANs.

Manipulating Individual Log Files

System Settings >

Event Notification >--------------------------------------


• Select the checkboxes of specific target events to generate a log file upon their occurrence.

System Settings >

Event Notification >

--------------------------------------


• Select the checkboxes of specific target events to generate a log file upon their occurrence.


• Click the Log Options tab.

• Select the File Mgt tab.

• View, clear buffer or transfer files as needed.

Viewing the Contents of Individual Files

Use an “logdir” CLI command (System Context).

Use an “logdir” CLI command (System Context).


• Select the File Mgt tab.Select a single log file.

• Click the View button.

Transferring Log Files

Use an “export” CLI command (System Context).

Use an “export” CLI command (System Context).


• Select the File Mgt tab.Select a single log file.

• Click the Transfer Files button.

Table 4.6 VLAN Configuration


Viewing the Existing Switch VLAN Configuration

Create > Ethernet > New Policy

--------------------------------------

• Enter a name and description for the policy.

• Click Next.• Click VLAN Discovery...


--------------------------------------


• Click Next.• Click VLAN Discovery...

Network >Layer 2 Virtual LANs

Table 4.5 WS5100 Log Files (Continued)



4.1.5 Configuring Switch Security

4.1.5.1 ACL Configuration

This section describes the differences in menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when accessing the switch Access Control List (ACL).

Adding a New VLAN ID


--------------------------------------


• Click Next.• Click Add.


--------------------------------------


• Click Next.• Click Add.

Network >Wireless LANs---------------------------------


• Click the Add button.

• Select the VLAN ID checkbox.

• Assign a new VLAN ID.

Removing a VLANor removing a VLAN/WLAN Assignment


--------------------------------------


• Click Next.• Select a target VLAN.

• Click Remove.


--------------------------------------


• Click Next.• Select a target VLAN.

• Click Remove.

Network >Layer 2 Virtual LANs

--------------------------------------

• Select the VLAN Assignment tab.

• Remove the VLAN assignment checkmarks as required to remove the WLAN/VLAN assignment.

Table 4.7 ACL Configuration


Creating an ACL Create >Access Port >Access Control List >

Create >Access Port >Access Control List

Security > ACLs

--------------------------------------


• Click the Add button.

Table 4.6 VLAN Configuration (Continued)



Adding an ACL Rule

Create >Access Port >Access Control List >

--------------------------------------

• Enter an ACL Name• Define an Allow/Deny

designation

• Click the Use an existing Access Control List as a template checkbox

• Click the Next button

• Click the Add button

Create >Access Port >Access Control List >

--------------------------------------


designation



• Click the Add button

Security > ACLs

--------------------------------------


• Click the Add button (from the Associated Rules field).

Edit an Existing ACL

Modify >Access Port >Access Control List >--------------------------------------


action



• Select an ACL

• Click the Edit button



action



• Select an ACL


Security > ACLs

--------------------------------------


• Click the Edit button (from the Associated Rules field).

Deleting an Existing ACL Policy



action



• Select an ACL

• Click the Delete button



action



• Select an ACL


Security > ACLs

--------------------------------------


• Click the Delete button (from the either the ACLs or Associated Rules fields).

Table 4.7 ACL Configuration (Continued)



4.1.5.2 Encryption and Authentication

This section describes the differences in menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when using the Web UI to define an encryption or authentication based security policy.

This section describes how to navigate to the target security screen described in the Configuration Option/Feature portion of the table. Once you navigate to the target security screen, a thorough knowledge of the security feature is required to adequately protect the data within your network.Table 4.8 Encryption and Authentication


Access the Security Configuration Screen(s)

Create > Access Port >Security Policy

Create >Access Port >Security Policy

Network>Wireless LANs>--------------------------------------

• Click the Configuration tab

• Select a WLAN.

• Click the Edit button.

• Select an authentication or encryption checkbox.

• Click the Config button.

Create an “Open” Configuration

Create >Access Port >Security Policy--------------------------------------

• Name the policy.

• Enter a description.

• Select the None checkbox.

• Click Next.




• Select the None checkbox.

• Click Next.



• Select a WLAN Index.


• Revise the SSID (if necessary).

• Revise the configuration description (if necessary).

• Select the No Authentication checkbox.


Configure WEP Create >Access Port >Security Policy--------------------------------------



• Select the WEP checkbox.

• Click Next.

Create >Access Port >Security Policy

--------------------------------------



• Select the WEP checkbox.

• Click Next.







• Select either the WEP 64 or WEP 128 checkbox.


Configure KeyGuard


• Name the policy

• Enter a description

• Select the KeyGuard checkbox

• Click Next


• Name the policy


• Select the KeyGuard checkbox

• Click Next





• Revise the SSID (if necessary.)


• Select the KeyGuard checkbox.


Table 4.8 Encryption and Authentication (Continued)



Configure TKIP Create >Access Port >Security Policy--------------------------------------

• Name the policy


• Select the TKIP checkbox

• Click Next


• Name the policy



• Click Next







• Select the WPA/WPA2-TKIP checkbox.


Configure AES CCMP or WPA2-AES


• Name the policy



• Click Next


• Name the policy



• Click Next



• Select a WLAN Index


• Revise the SSID (if necessary)

• Revise the configuration description (if necessary)

• Select the WPA2-CCMP checkbox

• Click the Config button

Configure a Manual Pre-Shared Key


• Name the policy


• Click Next • Select the Manually

Pre-Shared Key checkbox

• Click Next


• Name the policy


• Click Next • Select the Manually

Pre-Shared Key checkbox

• Click Next

Not Supported




Configure Kerberos




• Click Next.• Select the Kerberos

checkbox.

• Click Next.




• Click Next. • Select the Kerberos

checkbox.

• Click Next.

Network >Wireless LANs >--------------------------------------






• Select the Kerberos checkbox

• Click the Config button

Configure EAP Create >Access Port >Security Policy--------------------------------------

• Name the policy


• Click Next • Select the EAP checkbox

• Click Next


• Name the policy


• Click Next • Select the EAP checkbox

• Click Next

Network >Wireless LANs>--------------------------------------






• Select the 802.1x EAP checkbox


Configure Hotspot

Not Supported Not Supported Network >Wireless LANs>--------------------------------------






• Select the Hotspot checkbox





4.1.5.3 Rouge AP Detection

This section describes the differences in menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when using the Web UI to manage Rouge AP Detection. Rogue AP is not available in the 1.4.x switch software Table 4.9 Rouge AP Detection


Access Rogue AP Detection Menu

Not Supported System Settings > Rogue AP Detection.

Security >Access Point Detection

Define Rogue AP Detection Method

Not Supported System Settings > Rogue AP Detection--------------------------------------

• Select amongst the RF Scan by MU, RF Scan by AP and RF Scan by Detector AP checkboxes button within Detection Method field.

Security >Access Point Detection--------------------------------------

• Select Configuration tab.

• Select Enable checkbox.

• Select Allowed APs tab.

• Click Add or Edit button.

Rogue AP Rule Management


• Click Add, Delete or Delete All from within the Rule Management tab.


• Select Configuration tab.

• Select Enable checkbox.

• Select Allowed APs tab.

• Click Add or Edit button.

Add a Detected AP to Approved AP List

Not Supported System Settings > Rogue AP Detection

--------------------------------------

• Click the AP List tabSelect an AP and click the Add AP to Rule List button.


• Select Unapproved APs tab.

• Select an unapproved AP.

• Click the Allow button.

View Rogue AP Details


• Click the AP List tabSelect an AP and click the View Details button.


• Select Unapproved APs tab.


4.1.5.4 Configuring the On-Board Radius Server

This section describes the differences in menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when accessing the switch’s on-board Radius server.Table 4.10 Configuring the On-Board Radius Server


Accessing the Radius Configuration

No On-Board Radius Support. System Settings > Radius >Configuration

Security > Radius Server

Editing the Existing Radius Configuration


--------------------------------------

• Select an existing Server.

• Click the Edit Configuration button.


--------------------------------------

• Click the Configuration and Authentication tabs.

• Define the configuration.

Configuring LDAP Authentication


--------------------------------------

• Select the LDAP Configuration tab.


--------------------------------------

• Click the Authentication tab.

• Select the Primary or Secondary tab.

• Define the configuration.

Radius Client Configuration


--------------------------------------

• Select the Clients Configuration tab.


--------------------------------------


• Select the Clients tab.

• Click Add or Delete.

Configuring Radius Accounting


--------------------------------------

• Select the Radius Accounting Server tab.


--------------------------------------

• Click the Accounting Logs tab.

Configuring the Radius Proxy Configuration


--------------------------------------

• Select the Proxy tab.


--------------------------------------


• Select the Proxy Servers tab.

• Click Add or Delete.


4.1.6 Viewing Switch StatisticsThis section describes the differences in menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when accessing switch statistics.

Configuring Radius Users and Groups

No On-Board Radius Support. System Settings > Radius >

Users

--------------------------------------

• Click the Add or Delete button as needed to for User and Group inclusions.


--------------------------------------

• Click the Users or Groups tab.

• Click Add, Delete or Edit as needed.

Table 4.11 Viewing Switch Statistics


Display High-Level Wireless Statistics

View > Chassis View > Chassis Switch >

--------------------------------------

• Click the Show Dashboard button.

Display High-Level Switch Statistics

Use a “show switchpolicy” CLI command.

Use a “show switchpolicy” CLI command.

Switch >

--------------------------------------


Display Ethernet Statistics

Use a “show ethernet” CLI command.

Use a “show ethernet” CLI command.

Network >

--------------------------------------


Display Detailed Ethernet Statistics

Use a “show etherpolicy” CLI command.

Use a “show etherpolicy” CLI command.

Network >

Access Port Radios

--------------------------------------

• Click the Statistics tab.

Display High-Level Radio Statistics

Use a “show WSrfstats” CLI command.

Use a “show WSrfstats” CLI command.

Network >

Access Port Radios

--------------------------------------


Display MU Details

Use a “show mu” or “show musummary” CLI command.

Use a “show mu” or “show musummary” CLI command.

Network >

Mobile Units

--------------------------------------


Table 4.10 Configuring the On-Board Radius Server (Continued)



4.1.7 Switch Certificate ManagementThis section describes the differences in menu path navigation amongst the WS5100 1.4.x, 2.x and 3.0 baselines when displaying switch certificate information and generating a request for a signed certificate.

Display Detailed Radio Statistics

Use a “show rfstats” CLI command.

Use a “show rfstats” CLI command.

Network >Access Port Radio

--------------------------------------

• Click on Statistics tab.

• Select an existing radio.

• Click the Details button.

Display WLAN Statistics

View > Quick Start

• Refer to WLAN tabs on bottom of screen.

• Click on the target WLAN tab.

View > Quick Start

• Refer to WLAN tabs on bottom of screen.

• Click on the target WLAN tab.

Network >

Wireless LANs

--------------------------------------



• Click the Graph button.

Display Detailed WLAN Statistics

Use a “show wlan” CLI command.

Use a “show wlan” CLI command.

Network >Wireless LANs

--------------------------------------

• Click on Statistics tab.


• Click the Details button.

Table 4.12 Switch Certificate Management


Display Current Certificate Information

System Settings >Server Certificate >Show Current Certificate

System Settings >Server Certificate >Show Current Certificate

Security > Server Certificates

Upload a New Certificate

System Settings >Server Certificate >Upload New Certificate

System Settings >Server Certificate >Upload New Certificate

Security > Server Certificates--------------------------------------

• Click the Certificates Wizard button.

• Select the Create a new Certificate option.

Table 4.11 Viewing Switch Statistics (Continued)



Revert to Default Certificate

System Settings >Server Certificate >Revert to Default Certificate

--------------------------------------

A Warning Message displays stating that reverting back to the default certificate destroys the certificate currently in use.

• Click OK to revert to default certificate.

System Settings >Server Certificate >Revert to Default Certificate

--------------------------------------

A Warning Message displays stating that reverting back to the default certificate destroys the certificate currently in use.

• Click OK to revert to default certificate.


---------------------------------

• Select Trustpoints tab.

• View the configuration of default trustpoint.

Create a Self-Signed Certificate

System Settings >Server Certificate >Create a Self-Signed Certificate

--------------------------------------

A Warning Message displays stating that creating a self-signed certificate destroys the certificate currently in use.

• Click OK to continue.

System Settings >Server Certificate >Create a Self-Signed Certificate

--------------------------------------

A Warning Message displays stating that creating a self-signed certificate destroys the certificate currently in use.



--------------------------------------



• Click Next.• Select the Generate a

self-signed certificate checkbox.

• Click Next.

Create a Certificate Request

System Settings >Server Certificate >Create Certificate Request

--------------------------------------

• Complete required fields within the Create Certificate Request screen.

• Click the OK button when completed.

System Settings >Server Certificate >Create Certificate Request

--------------------------------------

• Complete required fields within the Create Certificate Request screen.

• Click the OK button when completed.

Security > Server Certificates--------------------------------------



Table 4.12 Switch Certificate Management (Continued)



Restart Web Request

System Settings >Server Certificate >Restart Web Request

--------------------------------------

A Warning Message displays stating that restarting the switch Web UI could render the switch inoperable if the data within the certificate request does not match the actual certificate.

• Verify the contents of the certificate match the data within the certificate request.


System Settings >Server Certificate >Restart Web Request

--------------------------------------

A Warning Message displays stating that restarting the switch Web UI could render the switch inoperable if the data within the certificate request does not match the actual certificate.

• Verify the contents of the certificate match the data within the certificate request.


Not supported.

Table 4.12 Switch Certificate Management (Continued)


WS5100 LED Behavior Comparison

The 1.4.x and 2.x version WS5100 switches have LED behavior that differs from the new 3.o baseline switch. The 3.0 version switch does not have the same “standby” switch LED functionality that was present in the 1.4.x and 2.x baselines. Additionally, the new 3.0 version switch has a cluster functionality resulting in LED behavior previously unseen in the earlier baselines. This chapter contains an overview of the differences in LED behavior between the 1.4.x and 2.x baselines and the WS5100 baseline.

5.1 WS5100 1.4.x and 2.x Baseline LED BehaviorAll versions of the WS5100 switch have two vertically-stacked LEDs on its front panel. The LEDs display three colors (blue, amber, and red), and three lit states (solid, blinking, and off). However, there are some states that are unique to the WS5100 1.4.x and 2.x version models.

5.1.1 Start Up

5.1.2 Configured as a Primary Switch

Event Top LED Bottom LED

Power off Off Off

Power On Self Test (POST) running All colors in rotation All colors in rotation

POST succeeded Blue solid Blue solid

Software initializing Blue solid Off

Software initialized Blue blinking Off


Active Blue blinking Blue solid

Monitoring Blue blinking Amber solid

Standby missing or not enabled Blue blinking Off

Inactive Amber blinking Blue blinking


5.1.3 Configured as a Standby Switch

5.1.4 Error Codes

5.2 WS5100 LED BehaviorThe WS5100 version switch uses an LED scheme that takes advantage of the switch’s failover capabilities in addition to displaying LED events central to power up and error reporting. Refer to the following for LED behavior unique to the 3.0 version WS5100 switch:

5.2.1 Start Up


Active (acting as primary) Blue blinking Blue blinking

Monitoring Blue blinking Amber solid

Standby not enabled Blue blinking Off

Inactive Amber blinking Amber blinking

NOTE: The Primary and Standby LED activity described above is unique to the WS5100 1.4.x and 2.x baselines. The primary and standby designations do not apply to the 3.0 version switch.


POST failed (critical error) Red blinking Red blinking

Software initialization failed Amber solid Off

Country code not configured.

Note: During first time setup, the LEDs will remain in this state until the country code is configured.

Amber solid Amber blinking

No access ports have been adopted Blue blinking Amber blinking

Primary inactive or failed Amber blinking Blue blinking


Power off Off Off

Power On Self Test (POST) running All colors in rotation All colors in rotation

POST succeeded Blue solid Blue solid

WS5100 LED Behavior Comparison 5-3

5.2.2 Primary

5.2.3 Standby

5.2.4 Error Codes


Active (Continually Adopting Access Ports) Blue blinking Blue solid

No License to Adopt Amber blinking Amber blinking


Active (Failed Over and Adopting Ports) Blue blinking Blue blinking

Active (Not Failed Over) Blue blinking Amber solid


POST failed (critical error) Red blinking Red blinking

Software initialization failed Amber solid Off

Country code not configured.

Note: During first time setup, the LEDs will remain in this state until the country code is configured.

Amber solid Amber blinking

No access ports have been adopted Blue blinking Amber blinking

DHCP

This chapter provides detailed feature and configuration information for the DHCP features in the WS5100 switch.

• Overview

• Managing the DHCP Server

• Configuring DHCP Server using the CLI

• Configuring DHCP Client using SNMP

• Configuring DHCP using the WebUI

6.1 OverviewDHCP (Dynamic Host Configuration Protocol) automatically assigns temporary IP addresses to client stations logging onto an IP network. It eliminates the need to manually assign permanent "static" IP addresses. The DHCP Server is a server in the network or a service within a server that assigns IP addresses.

The switch DHCP service dynamically assigns an IP address to individual MUs or workstations.This protocol delivers IP information on a local area network (LAN) or across several LANs. DHCP reduces the work spent administering statically assigned IP addresses on a large network. The administrator does not have to visit each work station on the network to configure or manually make changes to its IP address if there is a network topology change. Other network configuration parameters, such as gateway and DNS (Domain Name Services), can be passed along to a workstation with the IP.


Figure 6.1 DHCP service running on a WS5100.

DHCP allows hosts on an IP network to request and be assigned IP addresses and discover information about the network to which they are attached. The Network administrator configures address pools for each subnet. Whenever a DHCP client in subnet requests IP address, the DHCP server assigns an IP address from the address pool configured for that subnet.

When the DHCP server allocates an address for a DHCP client, the client is assigned a lease. The lease expires after an interval defined by the administrator. Before leases expire, the clients to which leases are assigned are expected to renew them to continue to use the addresses. Once a lease has expired, the client is no longer permitted to use the leased IP address.

6.2 Managing the DHCP ServerThe purpose of the DHCP Server is to assign IP addresses to hosts and provide a method clients can request IP addresses and configuration information.

DHCP can be configured using either:

• CLI

• SNMP

• Web UI

6.3 Configuring DHCP Server using the CLIDHCP configuration is accomplished by creating pools and mapping them to L3 interfaces (SVI).

A pool can be configured either as a network pool or host pool.

• A Network pool is the pool having include ranges. When this network pool is mapped to a L3 interface, the DHCP clients requesting IPs from this L3 interface will get an IP from a range of available addresses.

• A host pool is used to assign static/fixed IP address to DHCP clients.

DHCP 6-3

6.3.1 Creating network poolFollow the steps below to create a network pool using the CLI:

1. Create a DHCP Server dynamic address pool.WS5100(config)#ip dhcp pool test

2. Map the DHCP pool to the network pool.

WS5100(config-dhcp)#network 192.168.0.0/24

3. Add the address range for the dynamic pool.

WS5100(config-dhcp)#address range 192.168.0.30 192.168.0.60

4. Assign a domain name as appropriate to this dynamic pool.

WS5100(config-dhcp)#domain-name test.com

5. Configure the DNS servers IP address.

WS5100(config-dhcp)#dns-server 192.168.0.10 192.168.0.11

6. Configure the DHCP clients IP address lease period.

WS5100(config-dhcp)#lease 10

7. Exit the DHCP instance on creation of the network pool.

WS5100(config-dhcp)#exit

8. Start the DHCP Server to instantiate the network pool.

WS5100(config)#service dhcp

6.3.2 Creating host pool1. Create a DHCP Server host address pool.

WS5100(config)#ip dhcp pool hostpool

2. Assign the client name of the host for which static allocation is required.

WS5100(config-dhcp)#client-name linuxbox

3. Assign an IP Address for the host.

WS5100(config-dhcp)#host 192.168.0.50

4. Configure the hardware address of the host.

WS5100(config-dhcp)#hardware 00:a0:f8:6f:6b:88

5. Exit from the DHCP instance on creation of the network pool.


6. Start the DHCP Server to instantiate the network pool.


6.3.3 Troubleshooting DHCP configuration1. DHCP Server is disabled by default. Use the following command to enable DHCP Server.


This command will administratively enable the DHCP server. In case the DHCP configuration is incomplete, then it is possible that the DHCP server will be operationally disabled even after the execution of this CLI.


2. Use the network CLI command to map the network pool to interface.

network 192.168.0.0/24

In the above example, 192.168.0.0/24 represents the L3 interface. When you execute this command, no check is performed to verify whether any interface with the specified IP/Netmask exists. The verification is not performed because you can create a pool and map it to non existing L3 interface.

Later, when you add a L3 interface and assign an IP address to it, the DHCP Server is enabled/started on this interface. If you have a pool for network 192.168.0.0/24, but the L3 interface is 192.168.0.0/16, DHCP wont be enabled on 192.168.0.0/16 as it is different from 192.168.0.0/24.

3. A network pool without any include range is as good as not having that pool, because it won't be useful. You can add a include range using the address range CLI command

address range 192.168.0.30 192.168.0.30

4. To work properly, a host pool should have the following 3 items configured:

• client-name (CLI is client-name <name>)

• fixed-address CLI is host <ip>)

• hardware-address/client-identifier

CLI for hardware address is hardware-address <addr>

CLI for client-identifier is client-identifier <id>

If you use client-identifier instead of hardware-address. The DHCP client sends the client-identifier when it requests for IP address. The Client - identifier has to be configured in the DHCP Client as ASCII value and the same has to be used in the DHCP server option i.e. Client- identifier option.

5. A host pool should have its corresponding network pool configured, otherwise the host pool will be rendered useless. The fixed IP address configured in the host pool must be in the subnet of the corresponding network pool.

6. If you create a pool and map it to interface, it automatically gets enabled, provided the DHCP is enabled at global level. Use the no network command to disable DHCP on per pool/interface basis.

7. To make a newly created pool as network pool, use one of the following CLI commands:

• network (for example, network 192.168.0.0/24)

• address range (for example, address range 192.168.0.30 192.168.0.50)

8. To make a newly created pool as host pool, use one of the following CLI commands:

• host (for example, host 192.168.0.1)

• client-name (Eg client-name "kaveri")

• client-identifier (Eg client-identifier "aabb:ccdd")

• hardware-address (Eg hardware-address aa:bb:cc:dd:ee:ff)

9. A pool can be configured either as the host pool or network pool but not both.

10.A host pool can have either client-identifier or hardware-address configured on it but not both.

11.Excluded address range has higher precedence than included address range. If a range is part of both- an excluded and included address range it will be excluded.

12.DHCP options are first defined at the global level using ip dhcp option <name> <code> <type>. The value for these options are associated using the option which is under DHCP pool context.

DHCP 6-5

6.3.4 Creating DHCP option1. To create a non standard option named “tftp-server”.

WS5100(config)#ip dhcp option tftp-server 183 ip

2. Enter the DHCP pool —”test”.

WS5100(config)#ip dhcp pool test

3. Assign a value to the DHCP option configured above.

WS5100(config-dhcp)#option tftp-server 192.168.0.100

4. Exit from the DHCP instance.


6.4 Configuring DHCP Client using SNMPThe SNMP information described below is an extract from the MIB, which is a hierarchial database where each entry is addressed by an object identifier.

Object identifiers are unique Ids that identify each object in a MIB database. A typical example of an Object Identifier (OID) is: 1.3.6.1.4.1.388.14.2.3.4.1

Objects can be classified as Scalar and Tabular.

• Scalar objects can be accessed directly through the OID that are unique to each object.

• Tabular objects are referred through a combination of the OID of the columns and the unique index assigned to each row in the table.

Refer to following SNMP table structure to confiure DHCP using SNMP:

• WS-SW-DHCP-MIB

• WS-SW-DHCP-SERVER-MIB

6.5 WS-SW-DHCP-MIBThe WS-SW-DHCP-MIB.mib file provides a description of all the OIDs defined for managing and configuring the Dynamic Host Control Protocol (DHCP) Client.


The objects under WS-SW-DHCP-MIB can be classified into Scalar Objects or Tabular Objects. Table 6.1 lists the Scalar objects and Table 6.2 the Tabular objects.

6.5.1 wsSWDhcpModule This OID defines the DHCP module.

6.5.2 wsSWDhcpClientThis OID defines the Client object for the DHCP module.

For the sub objects under this OID, see wsSWDhcpClient Sub Objects.

6.5.2.1 wsSWDhcpClient Sub Objects

The following objects are defined under the wsSWDhcpClient object.

• wsSWDhcpClientSvrInfor

• wsSWDhcpClientVendorInfor

Table 6.1 Scalar Objects for DHCP Client MIB

wsDhcpClientDomainName 1.3.6.1.4.1.388.14.2.3.4.1.1.1 Read-Only

wsDhcpClientDefaultGateway 1.3.6.1.4.1.388.14.2.3.4.1.1.2 Not Accessible

wsDhcpClientVendorInfor 1.3.6.1.4.1.388.14.2.3.4.1.2 Not Accessible

wsDhcpClientUpgSvrInfo 1.3.6.1.4.1.388.14.2.3.4.1.2.1 Read-Only

wsDhcpClientUpgImgName 1.3.6.1.4.1.388.14.2.3.4.1.2.2 Read-Only

wsDhcpClientUpgCfgName 1.3.6.1.4.1.388.14.2.3.4.1.2.3 Read-Only

wsDhcpClientUpgClusterCfgName

1.3.6.1.4.1.388.14.2.3.4.1.2.4 Read-Only

Table 6.2 Tabular Objects for DHCP Client MIB

wsDhcpClientNameSvrTable 1.3.6.1.4.1.388.14.2.3.4.1.1.3

Object Identifier (OID) 1.3.6.1.4.1.388.14.2.3.4

Parent Module wsSwDhcp

Object Number 4

Description Defines the OID for the DHCP module

Object Identifier (OID) 1.3.6.1.4.1.388.14.2.3.4.1

Parent Object wsSWDhcpModule

Object Number 1

Description Defines the OID for the Client object

DHCP 6-7

6.5.2.2 wsSWDhcpClientSvrInfor

The wsSWDhcpClientSvrInfor object is a sub-object of wsSWDhcpClient object. It is defined as:

The following objects are contained in the wsSWDhcpClientSvrInfor object.

• wsDhcpClientDomainName

• wsDhcpClientDefaultGateway

• wsDhcpClientNameSvrTable

wsDhcpClientDomainName

The wsDhcpClientDomainName object identifies the domain where the DHCP server is located.

wsDhcpClientDefaultGateway

The wsDhcpClientDefaultGateway object identifies the default gateway address for the DHCP server.

wsDhcpClientNameSvrTable

This OID defines the table that stores information about the Name Server.

Object Identifier (OID) 1.3.6.1.4.1.388.14.2.3.4.1.1

Parent Object wsDhcpClient

Object Number 1

Description Defines the OID for the DHCP Client Server Information object

Object Identifier (OID) 1.3.6.1.4.1.388.14.2.3.4.1.1.1

Parent Object wsDhcpClientSvrInfor

Object Number 1

Type String with length between 0 and 80 characters

Access Read-Only

Status Current

Description Defines the OID for the Client Domain Name received from the DHCP Server



Object Number 2

Type IP Address - 32-bit internet address

Access Read-Only

Status Current

Description Defines the OID for the Client Domain Name received from the DHCP Server


.

The wsDhcpClientNameSvrTable is defined as:

The wsDhcpClientNameSvrTable is made up of a number of wsDhcpClientNameSvrEntry objects. The wsDhcpClientNameSvrTableEntry object is a sequence of these objects:

• wsDhcpClientNameSvrEntry

• wsDhcpClientNameSvrIndex

• wsDhcpClientNameSvrIP

wsDhcpClientNameSvrEntry

The object wsDhcpClientNameSvrEntry defines the OID for the contents of the wsDhcpClientNameSvrTable object. It is defined as:

wsDhcpClientNameSvrIndex

The object wsDhcpClientNameSvrIndex is defined as:



Object Number 3

Type Conceptual Table made up of a sequence of WsDhcpClientNameSvrEntry objects

Access Not accessible

Status Current

Description Defines the OID for a table that contains the DHCP Client Name Server information

Object Identifier (OID) 1.3.6.1.4.1.388.14.2.3.4.1.1.3.1

Parent Object wsDhcpClientNameSvrTable

Object Number 1

Type WsDhcpClientNameSvrEntry object definition


Status Current

Index wsDhcpClientNameSvrIndex

Description Name Sever Table entry

Object Identifier (OID) 1.3.6.1.4.1.388.14.2.3.4.1.1.3.1.1

Parent Object wsDhcpClientNameSvrEntry

DHCP 6-9

wsDhcpClientNameSvrIP

The object wsDhcpClientNameSvrIP is defined as:

6.6 WS-SW-DHCP-SERVER-MIBThe WS-SW-DHCP-SERVER-MIB.mib file provides a description of all the Object Identifiers (OID) that are defined for managing and configuring the Dynamic Host Control Protocol (DHCP) Server.

The objects under WS-SW-DHCP-SERVER-MIB can be classified into Scalar Objects or Tabular Objects. Table 6.3 lists the Scalar objects and Table 6.4 the Tabular objects.

Object Number 1

Type Integer with values between 1 and 8 (both inclusive)


Status Current

Description Index of the entry in the wsDhcpClientNameSvrTable table object

Object Identifier (OID) 1.3.6.1.4.1.388.14.2.3.4.1.1.3.1.2

Parent Object wsDhcpClientNameSvrEntry

Object Number 2

Type IP address - 32-bit internet address

Access Read Only

Status Current

Description Name Server IP

Table 6.3 Scalar Objects for DHCP Server MIB

wsSwDhcpServerModule 1.3.6.1.4.1.388.14.2.3.5 Not Accessible

wsSwDhcpSvrGlobal 1.3.6.1.4.1.388.14.2.3.5.1 Not Accessible

wsSwDhcpSvrBootp 1.3.6.1.4.1.388.14.2.3.5.1.1 Read-Write

wsSwDhcpSvrPingInterval 1.3.6.1.4.1.388.14.2.3.5.1.2 Read-Write


6.6.1 wsSwDhcpServerModuleThis OID defines the DHCP Server module.

The following objects are defined under the wsSwDhcpServer object.

• wsSwDhcpSvrGlobal

• wsSwDhcpSvrExcludeTable

• wsSwDhcpSvrPoolTable

• wsSwDhcpSvrIncludeTable

• wsSwDhcpSvrPoolOptionTable

• wsSwDhcpBindingStatusTable

• wsSwDhcpSvrGlobalOptionTable

• wsSwDhcpRelayTable

6.6.1.1 wsSwDhcpSvrGlobal

This OID defines the Server Global object for the DHCP Server module.

wsSwDhcpSvrEnable 1.3.6.1.4.1.388.14.2.3.5.1.3 Read-Write

wsSwDhcpSvrRestart 1.3.6.1.4.1.388.14.2.3.5.1.4 Read-Write

Table 6.4 Tabular Objects for DHCP Server MIB

wsSwDhcpSvrExcludeTable 1.3.6.1.4.1.388.14.2.3.5.2

wsSwDhcpSvrPoolTable 1.3.6.1.4.1.388.14.2.3.5.3

wsSwDhcpSvrIncludeTable 1.3.6.1.4.1.388.14.2.3.5.4

wsSwDhcpSvrPoolOptionTable 1.3.6.1.4.1.388.14.2.3.5.5

wsSwDhcpSvrBindingStatusTable

1.3.6.1.4.1.388.14.2.3.5.6

wsSwDhcpSvrGlobalOptionTable

1.3.6.1.4.1.388.14.2.3.5.7

wsSwDhcpSvrRelayTable 1.3.6.1.4.1.388.14.2.3.5.8


Parent Module wsSwDhcp

Object Number 5

Description Defines the OID for the DHCP Server module


Parent Object wsSwDhcpServerModule

Table 6.3 Scalar Objects for DHCP Server MIB

DHCP 6-11

For the sub objects under this OID, refer wsSWDhcpClient Sub Objects.

6.6.1.2 wsSwDhcpSvrExcludeTable

This OID defines the Server Exclude Table object.

For the sub objects under this OID, refer wsSwDhcpSvrExcludeTable.

6.6.1.3 wsSwDhcpSvrPoolTable

This OID defines the Server Pool Table object.

For the sub objects under this OID, refer wsSwDhcpSvrPoolTable.

6.6.1.4 wsSwDhcpSvrIncludeTable

This OID defines the Server Include Table object.

For the sub objects under this OID, refer to wsSwDhcpSvrIncludeTable.

6.6.1.5 wsSwDhcpSvrPoolOptionTable

This OID defines the Server Pool Option Table object.

Object Number 1

Description Defines the OID for the Server Global object



Object Number 2

Description Defines the OID for the Server Exclude Table



Object Number 3

Description Defines the OID for the Server Pool Table



Object Number 4

Description Defines the OID for the Server Include Table



Object Number 5

Description Defines the OID for the Server Pool Option Table


For the sub objects under this OID, refer to wsSwDhcpSvrPoolOptionTable.

6.6.1.6 wsSwDhcpBindingStatusTable

This OID defines the Binding Status Table object.

For the sub objects under this OID, refer to wsSwDhcpBindingStatusTable.

6.6.1.7 wsSwDhcpSvrGlobalOptionTable

This OID defines the Server Global Option Table object.

For the sub objects under this OID, refer to wsSwDhcpSvrGlobalOptionTable.

6.6.1.8 wsSwDhcpRelayTable

This OID defines the DHCP Relay Table object.

For the sub objects under this OID, refer to wsSwDhcpRelayTable.

6.6.2 wsSWDhcpSvrGlobal Sub ObjectsThe following objects are defined under the wsSWDhcpClient object.

• wsSwDhcpSvrBootp

• wsSwDhcpSvrPingInterval

• wsSwDhcpSvrEnable

• wsSwDhcpSvrRestart



Object Number 6

Description Defines the OID for the Binding Status Table



Object Number 7

Description Defines the OID for the Server Global Option Table



Object Number 8

Description Defines the OID for the DHCP Relay Table

DHCP 6-13

6.6.2.1 wsSwDhcpSvrBootp

The wsSwDhcpSvrBoop object sets the access for bootp requests. Access can be Allow / Ignore Bootp requests. It is defined as:

6.6.2.2 wsSwDhcpSvrPingInterval

The wsSwDhcpSvrPingInterval object sets the time interval between pings It is defined as:

6.6.2.3 wsSwDhcpSvrEnable

The wsSwDhcpSvrEnable object enables the switch’s internal DHCP Server. It is defined as:

6.6.2.4 wsSwDhcpSvrRestartThe wsSwDhcpSvrRestart object set the values for restarting the DHCP Server. It is defined as:


Parent Object wsDhcpSvrGlobal

Object Number 1

Type TruthValue

Access Read-Write

Status Current

Description Defines the OID for the Bootp access



Object Number 2

Type Integer with values between 0 and 10, both inclusive

Access Read-Write

Status Current

Description Defines the OID for the ping interval



Object Number 3

Type TruthValue

Access Read-Write

Status Current

Description Enable the switch’s internal DHCP Server.




6.6.3 wsSwDhcpSvrExcludeTableThis OID defines the table that stores IP addresses unavailable to the DHCP Server when assigning IP addresses.

The wsSwDhcpSvrExcludeTable is described as:

The wsSwDhcpSvrExcludeTable is made up of a sequence of WsSwDhcpSvrExcludeEntry objects. The WsSwDhcpSvrExcludeEntry is a sequence of these objects:

• wsSwDhcpSvrExcludeLowIpAddr

• wsSwDhcpSvrExcludeHighIpAddr

• wsSwDhcpSvrExcludeRowStatus

6.6.3.1 wsSwDhcpSvrExcludeEntry

The object wsSwDhcpSvrExcludeEntry defines the OID for the contents of the wsSwDhcpSvrExcludeTable object. It is defined as:

Object Number 4

Type Integer Array. Defined as:{

restart(1),idle(2)

}

Access Read-Write

Status Current

Description Defines the OID for the time interval before the DHCP Server restarts



Object Number 2

Type Conceptual Table made up of a sequence of WsSwDhcpSvrExcludeEntry objects


Status Current

Description This OID defines the table that stores IP addresses unavailable to the DHCP Server when assigning IP addresses.


DHCP 6-15

6.6.3.2 wsSwDhcpSvrExcludeLowIpAddr

The object wsSwDhcpSvrExcludeLowIpAddr defines the OID for the low IP address excluded from assignment by the DHCP server. It is defined as:

6.6.3.3 wsSwDhcpSvrExcludeHighIpAddr

The object wsSwDhcpSvrExcludeHighIpAddr defines the OID for the high IP address excluded from assignment by the DHCP server.. It is defined as:

6.6.3.4 wsSwDhcpSvrExcludeRowStatus

The object wsSwDhcpSvrExcludeRowStatus defines the OID for row status for the excluded entry. It is defined as:

Parent Object wsSwDhcpSvrExcludeTable

Object Number 1

Type WsSwDhcpSvrExcludeEntry object definition


Status Current

Index wsSwDhcpSvrExcludeLowIpAddr, wsSwDhcpSvrExcludeHighIpAddr

Description Defines the IP addresses excluded from assignmnet by the DHCP server.


Parent Object wsSwDhcpSvrExcludeEntry

Object Number 1

Type IP Address

Access Read-Only

Status Current

Description Defines the OID for the low IP address excluded from assignment by the DHCP server.



Object Number 2

Type Display String

Access Read-Only

Status Current

Description Excluded High Address



6.6.4 wsSwDhcpSvrPoolTable

The wsSwDhcpSvrPoolTable is described as:

The wsSwDhcpSvrPoolTable is made up of a sequence of WsSwDhcpSvrPoolEntry objects. The WsSwDhcpSvrPoolEntry is a sequence of these objects:


Object Number 3

Type Row Status

Access Read-Create

Status Current

Description Status of the row for the wsSwDhcpSvrExcludeEntry object



Object Number 3

Type Conceptual Table made up of a sequence of WsSwDhcpSvrPoolEntry objects


Status Current

DHCP 6-17

• wsSwDhcpSvrPoolNameIndex

• wsSwDhcpSvrPoolType

• wsSwDhcpSvrPoolHostIp

• wsSwDhcpSvrPoolSubnetIpAndMask

• wsSwDhcpSvrPoolClientId

• wsSwDhcpSvrPoolClientName

• wsSwDhcpSvrPoolHardWareAddrAndType

• wsSwDhcpSvrPoolDomainName

• wsSwDhcpSvrPoolNetBiosNodeType

• wsSwDhcpSvrPoolBootfile

• wsSwDhcpSvrPoolDdnsUpdate

• wsSwDhcpSvrPoolDdnsUpdateAll

• wsSwDhcpSvrPoolDdnsIp

• wsSwDhcpSvrPoolDdnsDomainName

• wsSwDhcpSvrPoolDdnsTtl

• wsSwDhcpSvrPoolDdnsMultiUserClass

• wsSwDhcpSvrPoolDefaultRouter

• wsSwDhcpSvrPoolBootpNextSvrIp

• wsSwDhcpSvrPoolDnsSvrIp

• wsSwDhcpSvrPoolNetbiosSvrIp

• wsSwDhcpSvrPoolNoDefault

• wsSwDhcpSvrPoolLeaseTime

• wsSwDhcpSvrPoolRowStatus

6.6.4.1 wsSwDhcpSvrPoolEntry

The object wsSwDhcpSvrPoolEntry defines the OID for the contents of the wsSwDhcpSvrPoolTable object. It is defined as:


Parent Object wsSwDhcpSvrPoolTable

Object Number 1

Type WsSwDhcpSvrPoolEntry object definition


Status Current

Index wsSwDhcpSvrPoolNameIndex

Description Defines the name of a new DHCP pool entry.


6.6.4.2 wsSwDhcpSvrPoolNameIndex

The object wsSwDhcpSvrPoolNameIndex defines the OID for the index value for unique identification of each row in the wsSwDhcpSvrPoolTable. It is defined as:

6.6.4.3 wsSwDhcpSvrPoolType

The object wsSwDhcpSvrPoolType defines the OID for the type of DHCP pool used. It is defined as:

6.6.4.4 wsSwDhcpSvrPoolHostIp

The object wsSwDhcpSvrPoolHostIp defines the OID for host pool IP address. It is defined as:


Parent Object wsSwDhcpSvrPoolEntry

Object Number 1

Type Display String

Access Read-Only

Status Current

Description Index entry for the wsSwDhcpSvrPoolEntry object in the wsSwDhcpSvrPoolTable



Object Number 2

Type Index with the syntax{

unDefined(0),network(1),host(2)

}

Access Read-Only

Status Current

Description Defines the OID for the type of DHCP pool used.



Object Number 3

Type IP Address

Access Read-Create

Status Current

Description Defines the OID for host pool IP address.

DHCP 6-19

6.6.4.5 wsSwDhcpSvrPoolSubnetIpAndMask

The object wsSwDhcpSvrPoolSubnetIpAndMask defines the OID for the Subnet IP address and the Subnet Mask used. It is defined as:

6.6.4.6 wsSwDhcpSvrPoolClientId

The object wsSwDhcpSvrPoolClientId defines the OID for the Client Identifier. It is defined as:

6.6.4.7 wsSwDhcpSvrPoolClientName

The object wsSwDhcpSvrPoolHostIp defines the OID for the name of the client requesting DHCP Server support over this interface. It is defined as:



Object Number 4

Type Display String

Access Read-Create

Status Current

Description Defines the OID for the Subnet IP address and the Subnet Mask used



Object Number 5

Type Octet String

Access Read-Create

Status Current

Description Defines the OID for the Client Identifier



Object Number 6

Type Display String

Access Read-Create

Status Current

Description Defines the name of the client requesting DHCP Server support over this interface.


6.6.4.8 wsSwDhcpSvrPoolHardWareAddrAndType

The object wsSwDhcpSvrPoolHardWareAddrAndType defines the OID for Hardware Address and its type. It is defined as:

6.6.4.9 wsSwDhcpSvrPoolDomainName

The object wsSwDhcpSvrPoolDomainName defines the OID for the Domain Name. It is defined as:

6.6.4.10 wsSwDhcpSvrPoolNetBiosNodeType

The object wsSwDhcpSvrPoolNetBiosNodeType defines the OID for the Netbios node type. It is defined as:



Object Number 7

Type Display String

Access Read-Create

Status Current

Description Defines the OID for the Hardware address and the Hardware type.

Entry should be in the format:

• XX:XX:XX:XX:XX:XX, ethernet

• XX:XX:XX:XX:XX:XX, token-ring



Object Number 8

Type Display String

Access Read-Create

Status Current

Description Defines the OID for the Domain Name



Object Number 9

Type Integer with the syntax{

undefined(0),nodeB(1),nodeP(2),nodeM(4),nodeH(8),

}

DHCP 6-21

6.6.4.11 wsSwDhcpSvrPoolBootfile

The object wsSwDhcpSvrPoolDomainName defines the OID for the boot file name. It is defined as:

6.6.4.12 wsSwDhcpSvrPoolDdnsUpdate

The object wsSwDhcpSvrPoolDdnsUpdate defines the OID for the DDNS updates. It is defined as:

6.6.4.13 wsSwDhcpSvrPoolDdnsUpdateAll

The object wsSwDhcpSvrPoolDdnsUpdateAll defines the OID for updating DDNS server settings used with the DHCP server. It is defined as:

Access Read-Create

Status Current

Description Defines the OID for the Netbios node type



Object Number 10

Type Display String

Access Read-Create

Status Current

Description Defines the OID for the name of the boot file in use



Object Number 11


noUpdate(0),serverUpdate(1),clientUpdate(2)

}

Access Read-Create

Status Current

Description Defines the OID for the DDNS updates



Object Number 12


6.6.4.14 wsSwDhcpSvrPoolDdnsIp

The object wsSwDhcpSvrPoolDdnsIp defines the OID for the DDNS Ip addresses. This OID can take a maximum of two (2) IP addresses. It is defined as:

6.6.4.15 wsSwDhcpSvrPoolDdnsDomainName

The object wsSwDhcpSvrPoolDdnsUpdateAll defines the OID for the DDNS domain name. It is defined as:


updateAll(1),idle(2)

}

Access Read-Create

Status Current

Description Defines the settings used by the mobility domain to pass layer 2 and layer 3 traffic amongst peer switches.



Object Number 13

Type Display String

Access Read-Create

Status Current

Description Defines the OID for the DDNS Ip addresses. This OID takes two IPs in the formatIP1, IP2

To remove IP1 and retain IP2 use the syntax, IP2 or 0.0.0.0, IP2

To remove IP2 and retain IP1 use the syntaxIP1, or IP1, 0.0.0.0

To remove both IP1 and IP2 use the syntax, or ““ (empty string)



Object Number 14

Type Display String

Access Read-Create

Status Current

Description Defines the OID for the DDNS domain name

DHCP 6-23

6.6.4.16 wsSwDhcpSvrPoolDdnsTtl

The object wsSwDhcpSvrPoolDdnsTtl defines the OID for the DDNS TTL (Time To Live) value. It is defined as:

6.6.4.17 wsSwDhcpSvrPoolDdnsMultiUserClass

The object wsSwDhcpSvrPoolDdnsMultiUserClass defines the OID for enabling the DDNS multi user class. It is defined as:

6.6.4.18 wsSwDhcpSvrPoolDefaultRouter

The object wsSwDhcpSvrPoolDefaultRouter defines the OID for the default router. It is defined as:



Object Number 15

Type Integer with values between 0 and 65535 (both inclusive)

Access Read-Create

Status Current

Description Defines the OID for the DDND TTL (Time To Live) value



Object Number 16

Type Truth Value

Access Read-Create

Status Current

Description Defines the OID for enabling the DDNS multi user class



Object Number 17

Type Display String

Access Read-Create

Status Current

Description Defines the OID for the address of the default router. The values have to be in the format

xxx.xxx.xxx.xxx, yyy.yyy.yyy.yyy

The maximum number of entries is 8


6.6.4.19 wsSwDhcpSvrPoolBootpNextSvrIP

The object wsSwDhcpSvrPoolBootpNextSvrIP defines the OID for the address of the next Bootp Server. It is defined as:

6.6.4.20 wsSwDhcpSvrPoolDnsSvrIP

The object wsSwDhcpSvrPoolDnsSvrIP defines the OID for DNS Server address. It is defined as:

6.6.4.21 wsSwDhcpSvrPoolNetbiosSvrIP

The object wsSwDhcpSvrPoolNetbiosSvrIP defines the OID for Netbios Server address. It is defined as:



Object Number 18

Type IP Address

Access Read-Create

Status Current

Description Defines the OID for the address of the next Bootp Server.

Setting this value to 0.0.0.0 indicates that there is no bootp next server address.



Object Number 19

Type Display String

Access Read-Create

Status Current

Description Defines the OID for the address for the DNS Server. The values have to be in the format





Object Number 20

Type Display String

Access Read-Create

Status Current

DHCP 6-25

6.6.4.22 wsSwDhcpSvrPoolNoDefault

The object wsSwDhcpSvrPoolNoDefault defines the OID for No Default. It is defined as:

6.6.4.23 wsSwDhcpSvrPoolLeaseTime

The object wsSwDhcpSvrPoolLeaseTime defines the OID for lease time for the DHCP Server Pool. It is defined as:

6.6.4.24 wsSwDhcpSvrPoolRowStatus

The object wsSwDhcpSvrPoolRowStatus defines the OID for row status for the Server Pool entry. It is defined as:

Description Defines the OID for the address for the Netbios Server. The values have to be in the format





Object Number 21


noDefaultRouter(1),noDnsSvrIP(2),noNetbiosSvrIP(3),idle(4)

}

Access Read-Create

Status Current

Description Defines the OID for the No Default values



Object Number 22

Type Display String

Access Read-Create

Status Current

Description Defines the OID for the lease time for the DHCP Server Pool. The values have to be in the format

DD:HH:MM - represents days:hours:minutes

00:00:00 indicates infinite lease value.



6.7 Configuring DHCP using the WebUI

6.7.1 Creating a Network PoolTo configure DHCP and create a network pool using the Web UI:

1. Select Service > DHCP Server from the main menu tree. The DHCP Server window by default displays the Configuration tab.


Object Number 23

Type Row Status

Access Read-Create

Status Current

Description Status of the row for the wsSwDhcpSvrPoolEntry object

DHCP 6-27

2. Click on the Add button at the bottom of the screen.

a. Enter the name of the IP pool from which IP addresses can be issued to client requests on this interface.

b. Provide the Domain name as appropriate for the interface using the pool.

c. Enter the NetBios Node used with this particular pool. The NetBios Node could have one of the following types:

• A b-broadcast (broadcast node) uses broadcasting to query nodes on the network for the owner of a NetBIOS name.

• A p-peer (peer-to-peer node) uses directed calls to communicate with a known NetBIOS name server, such as a Windows Internet Name Service (WINS) server, for the IP address of a NetBIOS machine.

• An m-mixed is a mixed node that uses broadcasted queries to find a node, and failing that, queries a known p-node name server for the address.

• An h-hybrid is a combination of two or all of the nodes mentioned above.

d. Enter the name of the boot file used for this pool within the Boot File parameter.

e. From the Network section, select the VLAN associated with this DHCP server from the Associated Interface drop down box. The IP Address and Subnet Mask feilds, used for DHCP discovery and


requests between the DHCP Server and DHCP clients, are populated with the details based on the selection of the associated VLAN.

f. Within the Lease Time section, define one of the two kinds of leases the DHCP Server assigns to its clients:

• Infinite - If selected, the client can used the assigned address indefinitely.

• Actual Interval - Select this checkbox to manually define the time interval for clients to use the DHCP server assigned addresses. The default lease time is 600 seconds, with a minimum setting of 10 seconds and a maximum value of 946080000 seconds.

g. Within the Servers section, change the server type used with the pool and use the Insert and Remove buttons to add and remove the IP addresses of the routers used.

h. Provide the Included Ranges (starting and ending IP addresses) for this particular pool. Use the Insert and Remove buttons as required to define the range of supported IP addresses.A network pool without any include range is as good as not having a pool, because it won't be useful in assigning addresses.

i. Click OK to save and add the changes to the running configuration and close the dialog. This completes the creation of a Network Pool.

j. Click on Restart DHCP Server button to activate the network pool.

For more information on DHCP Network Pool configuration, refer to Creating network pool on page 6-3

NOTE: To avoid multiple restarts of DHCP Server, restart the DHCP Server only after making all the required configuration updates.

DHCP 6-29

6.7.2 Creating a Host Pool1. Select Service > DHCP Server from the main menu tree. Select the Host Pool tab to create and add a

new host pool.

A host pools reserve IP addresses for specific MAC addresses. This information can be an asset in determining if a new pool needs to be created or an existing pool requires modification.


2. Click on Add button at the bottom of the window.

a. Enter a unique name to the server host pool in the Pool Name field.

b. Enter the domain name for the host pool in the Domain field.

c. Assign the IP address for the host in the IP Address field.

d. Use the Host Address section to enter the hardware address of the host.

e. Click on OK button. This creates a Host pool.

For more information on DHCP Host Pool configuration, refer to Creating network pool on page 6-3.

Dynamic DNS

This chapter provides detailed feature and configuration information for the Dynamic DNS feature:

• Overview

• Managing DDNS

• Configuring DDNS using the CLI

• Configuring DDNS using SNMP

• Configuring DDNS using the Web UI

7.1 OverviewThe Domain Name System or Domain Name Server (DNS) is a system that stores information associated with domain names in a distributed database on networks, such as the Internet. The domain name system (Domain Name Server) associates many types of information with domain names, but most importantly, it provides the IP address associated with the domain name. It also lists mail exchange servers accepting e-mail for each domain. In providing a worldwide keyword-based redirection service, DNS is an essential component of contemporary Internet use.

7.2 Managing DDNSDynamic DNS is a method of keeping a domain name linked to a changing IP address. Typically when a user connects to a network the users ISP assigns it an unused IP address from a pool of IP addresses (Usually done through DHCP server). This address is only valid for a period of time. This way of dynamically assigning IP addresses increases the pool of assignable IP addresses. DNS is a service, which maintains a database to map a given name to an IP address, which is used for communication on the Internet. The dynamic assignment of IP addresses makes it necessary to update the DNS database to reflect the current IP address


for a given name. Dynamic DNS is a service, which updates the DNS database to reflect the correct mapping of a given name to an IP address in the scenario of non-static (dynamic) IP addresses for domain-names.

DHCP Server version 3.0.3 and later support dynamic assignment of IP addresses. This DHCP server has support for DDNS functionality. The DHCP server will be configured to use the vendor class-id, client MAC address received in the DHCP request message and the forward zone (same as domain name) for the given interface to derive the fully qualified name for the DHCP client. The DHCP server will use the fully qualified domain name constructed in this way to send the DNS update message. This dynamic DNS request will be sent to DNS server on receiving the DHCP request message from the DHCP client.

DHCP server will also issue dynamic DNS update request to the configured DNS server on receiving a DHCP release request from the DHCP client

A DHCP configuration daemon will be developed which will modify the configuration file of DHCP Server when requested by IMI daemon. Integrated Management Interface (IMI) is the command line interface given to the user to configure the switch. The IMI communicates the DHCP/DDNS requests to the DHCP Configuration daemon. The DHCP configuration daemon restarts the DHCP Server after modifying the DHCP Server configuration file for the changes to come into effect.

7.3 Configuring DDNS using the CLIDDNS updates are sent by onboard DHCP Server for the clients to which it issues IP Address. TheOnboard DHCP Server should be configured before configuring DDNS. Refer to Chapter 6.3, Configuring DHCP Server using the CLI to configure onboard DHCP server.

7.3.1 Creating Pool with DDNS Updates EnabledDDNS updates are configured on a per pool basis. Follow the steps provided in the example below to create a pool with DDNS updates enabled.

1. Create a DHCP network pool —”test”.WS5100(config)#ip dhcp pool test

Dynamic DNS 7-3

2. Map the pool to a network.


3. Add the address range to the DHCP network pool.


4. Enable the DDNS Server update.

WS5100(config-dhcp)#update dns override

update dns override indicates that the DDNS updates will be sent by DHCP Server for the clients to which it issues IP address.

5. Configure the DDNS Server.

WS5100(config-dhcp)#ddns server 192.168.0.1

The command DDNS server 192.168.0.1 indicates the DDNS updates will be sent to 192.168.0.1. Therefore, 192.168.0.1 should have an DNS server which accepts dynamic updates as per RFC 2136.

6. Configure the forward zone of the DNS Server.

WS5100(config-dhcp)#ddns domainname example.com

The command ddns domainname example.com indicates that the domain-name/forward-zone name used for DDNS update is example.com.

If ddns domain name is not configured then the domain-name configured using domain-name CLI will be used for DDNS updates.

In the above example, the DNS name that will sent for DDNS update will be <user-class>-<mac-address>.example.com where <mac-address> is the MAC address of the DHCP client and <user-class> is the user-class sent by DHCP client. If user-class is not sent by client then the dns name will be <mac-address>.example.com

7. Exit from the DHCP instance.


You can also configure DNS in global configuration context. In the above example replace ddns server 192.168.0.1 used in the pool context with ip name-server 192.168.0.1 to configure DNS under global context.

The above example, when configured under global configuration context will look as follows:

WS5100(config)#ip name-server 192.168.0.1

WS5100(config)#ip dhcp pool test



WS5100(config-dhcp)#update dns override

WS5100(config-dhcp)#ddns domainname example.com


7.3.1.1 Important DDNS Configurations

1. Use update dns to enable DDNS updates by clients. The DHCP client is itself is responsible for sending DDNS updates for the IP that is receives from DHCP Server. This indicates DHCP Server that it should not perform any DDNS updates for the clients to which it issues IP address.

2. A DDNS domain-name is not configured, DDNS updates will be sent using the domain name configured for that L3 interface using domain-name <example.com >, which is part of the DHCP pool context.


3. A DDNS update will not occur when neither DDNS domain-name nor domain-name is configured.

4. The ddns update-all will send DDNS updates only for those DHCP leases for which DDNS update was sent earlier. This command does not require ip dhcp restart for the DDNS update to happen.

7.4 Configuring DDNS using SNMPThe SNMP information described below is an extract from the MIB, which is a hierarchial database where each entry is addressed by an object identifier.

Object identifiers are unique Ids that identifies each object in a MIB database. A typical example of an Object Identifier (OID) is:

1.3.6.1.4.1.388.14.2.3.4.1

Objects can be classified as Scalar and Tabular.

• Scalar objects can be accessed directly through the OID that are unique to each object.

• Tabular objects are referred through a combination of the OID of the columns and the unique index assigned to each row in the table.

Refer to following SNMP table structure to confiure DHCP using SNMP:

• WS-SW-DHCP-SERVER-MIB

7.5 WS-SW-DHCP-SERVER-MIBThe WS-SW-DHCP-SERVER-MIB.mib file provides a description of all the Object Identifiers (OID) that are defined for the Domain Name Server information.

The objects under WS-SW-DHCP-SERVER-MIB can be classified into Scalar Objects or Tabular Objects. .Table 7.1 Scalar Objects

Object Name Object Identifier (OID) Access Permission

wsSwDNSModule 1.3.6.1.4.1.388.14.2.2.1 Not Accessible

wsSwDNSDomainName 1.3.6.1.4.1.388.14.2.2.1.1 Not Accessible

wsSwDNSDomainNameStatic 1.3.6.1.4.1.388.14.2.2.1.1.1 Read-Write

wsSwDNSDomainNameLookup 1.3.6.1.4.1.388.14.2.2.1.1.2 Read-Write

Dynamic DNS 7-5

7.5.1 wsSwDNSModuleThis OID defines module object for the DNS MIBs.

The following objects are defined under the wsSwDNSModule

• wsSwDNSDomainName

• wsSwDNSNameSvrTable

7.5.1.1 wsSwDNSDomainName

This OID defines the object for storing the domain name information.

For the sub objects under this OID, refer wsSwDNSDomainName

7.5.1.2 wsSwDNSNameSvrTable

This OID defines the static DNS table.

For the sub objects under this OID, refer wsSwDNSNameSvrTable

7.5.2 wsSwDNSDomainNameThe following objects are defined under the wsSwDNSDomainName object:

• wsSwDNSDomainNameStatic

Table 7.2 Tabular Objects

Object Name Object Identifier (OID)

wsSwDNSNameSvrTable 1.3.6.1.4.1.388.14.2.2.1.2


Parent Module wsSwDNS

Object Number 1

Description This OID defines the module object for the DNS MIBs1


Parent Module wsSwDNSModule

Object Number 1

Description This OID defines a container for storing DNS domain name information



Object Number 2

Description Defines the OID for the static DNS table


• wsSwDNSDomainNameLookup

7.5.2.1 wsSwDNSDomainNameStatic

This OID defines the object for storing the static domain name information.

7.5.2.2 wsSwDNSDomainNameLookup

This OID defines the object for enabling domain name lookup feature.

7.5.3 wsSwDNSNameSvrTableThis OID defines the DNS name server table.

The wsSwDNSNameSvrTable is described as:


Parent Module wsSwDNSDomainName

Object Number 1

Type Display String

Access Read-Write

Status Current

Description This OID defines an object to store the static domain name


Parent Module wsSwDNSDomainName

Object Number 2

Type Truth Value

Access Read-Write

Status Current

Description This OID defines an object to enable or disable domain name lookup



Object Number 2

Type Conceptual table made up of WsSwDNSNameSvrEntry entries

Dynamic DNS 7-7

The wsSwDNSNameSvrTable is made up of sequence of WsSwDNSNameSvrEntry objects. The WsSwDNSNameSvrEntry is a sequence of these objects:

• wsSwDNSNameSvrEntry

• wsSwDNSNameSvrIp

• wsSwDNSNameSvrPriority

• wsSwDNSNameSvrType

• wsSwDNSNameSvrRowStatus

7.5.3.1 wsSwDNSNameSvrEntry

The wsSwDNSNameSvrEntry defines the OID for the contents of the swSwDNSNameSvrTable object. It is defined as:

7.5.3.2 wsSwDNSNameSvrIP

This OID defines the IP address object for the DNS Name Server Table.

Access Not Accessible

Status Current

Description Table containing entries that are the DNS Name Server entries


Parent Module wsSwDNSNameSvrTable

Object Number 1

Type WsSwDNSNameSvrEntry object definition

Access Not Accessible

Status Current

Index wsSwDNSNameSvrIp, wsSwDNSNameSvrType

Description Defines the OID that defines the DNS name server entry


Parent Module wsSwDNSNameSvrEntry

Object Number 1

Type IP Address

Access Read-Only

Status Current

Description Defines the OID that stores the IP address for the DNS entry


7.5.3.3 wsSwDNSNameSvrPriority

This OID defines the priority object for the DNS Name Server Table.

7.5.3.4 wsSwDNSNameSvrType

This OID defines the server type object for the DNS Name Server Table.

7.5.3.5 wsSwDNSNameSvrRowStatus

This OID defines the IP address object for the DNS Name Server Table.



Object Number 2

Type Unsigned 32-bit Integer

Access Read-Only

Status Current

Description Defines the OID that stores the priority level for the DNS entry



Object Number 3

Type Unsigned 32-bit Integer

Access Read-Only

Status Current

Description • The valid values for DNS name server type are:Static

• Dynamic



Object Number 4

Type Row Status

Access Read-Only

Status Current

Description Status of the row for the wsSwDNSNameSvrEntry object

Dynamic DNS 7-9

7.6 Configuring DDNS using the Web UITo create a dynamic DNS, first create a DHCP network pool as described in Creating network pool on page 6-3.

1. Select Service > DHCP Server from the main menu tree. By default, the Configuration tab is displayed with network pool details.

2. Select the network pool list from the table and click on DDNS button.

a. Enter a Domain Name representative of the layer 2 and layer 3 traffic proliferating the mobility domain.

b. Define the TTL (Time to Live) to specify how many more hops a packet can travel before being discarded or returned. The maximum value is 65535.

c. Use the Automatic Update drop-down menu to specify whether the automatic update feature is on or off. Select Server Update to use the setting defined within this screen on both mobility domain peer switches and MUs.

d. Select the Enable Multiple User Class checkbox to enable all users (despite their designation) access to DHCP server resources and the mobility domain.

e. Use the DDNS Servers field to define the IP addresses used by the mobility domain to pass layer 2 and layer 3 traffic amongst peer switches.

f. Click the Send All button (within the Manual Updates field) to send manual DDNS updates to all servers.

g. Click OK to save and add the changes to the running configuration and close the dialog.

h. Click on Restart DHCP Server button to activate the DDNS.


For more information on DHCP Network Pool configuration, refer Configuring DHCP using the WebUI on page 6-26.

Certificate Management

This chapter provides detailed feature and configuration information for the Certificate Manger.

• Overview

• Configuring the Certificate Manager using CLI

• Configuring Trustpoint using the Web UI

8.1 OverviewCertificates are of two types:

a. CA root certificate

b. Server Certificate signed by a CA (External Certificate Authority)

Certificate Manager manages and maintains a set of certificates used by the applications such as HTTPS, VPN, Hotspot and Radius.

Certificates are uniquely identified by a trustpoint. Each trustpoint has the following attributes:

• Subject (Common Name, Organizational unit, Organization, Location, State, Country)

• Subject Alternate Name (email, ip-address, fqdn)

• Certificate Request

• Private key

• Server certificate

• CA certificate

For each trust point, certificate manager: provides the following functionality:

• Generate a certificate request for a configured trustpoint.

• Installs the server certificate signed by CA in either PEM or DER format.

• Installs CA's root certificate in either PEM or DER format.

• Certificate Manager maintains and manages set of keys. Keys may be used by applications such as SSH or may be associated with trustpoints explicitly.

The Certificate manager also has the option to generate RSA keys.


8.2 Configuring the Certificate Manager using CLICertificate Management configuration involves the following

• Configuration of Trustpoint.

• Configuration of RSA Key pairs.

• Generation of Self signed Certificate.

• Generation of Certificate Request.

• Uploading of Server Certificate Corresponding to the request and

• Uploading of CA Certificate.

A Trustpoint is either associated with (Server Certificate & Key pair) or (CA Certificate) or both.

8.2.1 Generating a Self-Signed Certificate1. Configure Trustpoint named symbol

WS5100(config)# crypto pki trustpoint symbol

WS5100(config-trustpoint)#subject-name symbol in karnatka bangalore symbol wid

WS5100(config-trustpoint)#email [email protected]

WS5100(config-trustpoint)#ip-address 111.222.102.x

WS5100(config-trustpoint)#fqdn www.symbol.com

WS5100(config-trustpoint)#exit

WS5100(config)#

2. Generate a Selfsigned Certificate

WS5100(config)#crypto pki enroll symbol selfsigned

3. Show the contents of Trustpoints

WS5100(config)#show crypto pki trustpoints

Trustpoint :symbol

Server Certificate

Subject: /C=in/ST=karntaka/L=bangalore/O=symbol/OU=wid/CN=symbol

Issuer: /C=in/ST=karntaka/L=bangalore/O=symbol/OU=wid/CN=symbol

Valid From: Jan 6 13:53:36 2007 GMT

Valid Until: Jan 6 13:53:36 2008 GMT

8.2.2 Generating a Certificate Request and Importing the Server Certificate1. Configure a trustpoint named External and generate a certificate request for it.

WS5100(config)# crypto pki trustpoint external

WS5100(config-trustpoint)#subject-name ws5100 us kkk sj symbol wid





WS5100(config)#

Certificate Management 8-3

2. Generate Certificate Request for the trustpoint external.

WS5100(config)#crypto pki enroll external request

This generates a Certificate Request.

3. Send the request to the ftp server specified.Get the request signed by Appropriate CA.( Windows 2003 Server will also do).

WS5100(config)#crypto pki export external request ftp://<user:password>@ IP/ Path/File

4. Import the Signed Certificate on to the WS5100 Switch through either ftp or tftp

WS5100(config)#crypto pki import external certificate ftp://<user:password>@ IP/ Path/servcert.pem

If the certificate is valid and matches the key then it is successfully imported. This allows import of certificate in either PEM or DER format from the specified URL.

8.2.3 Importing CA CertificateCA certificate can be associated with an existing trustpoint which already has server certificate associated with it or a new trustpoint.

CA Certificate can be imported to a trustpoint ‘external’.

WS5100(config)#crypto pki authenticate external ftp://<user:password>@ IP/Path/cacert.pem

Where cacert.pem is a Ca Certificate. This allows import of ca certificate in either PEM or DER format from the specified URL.

8.2.4 Porting the Certificate Onto Another SwitchA key pair can be generated seperated and can be exported, imported and assigned to a trustpoint. The following usecase explains how a certificate is ported to another switch.

8.2.4.1 Create a Keypair and Associate it to a Trustpoint

Create key pair key1 and associate it to trustpoint tpt1. Generate a certificate request for the trustpoint and get the request signed by a certificate authority. Next import the signed server certificate and export the key that is associated to the trustpoint tpt1.

To port the same server certificate on to another switch, import the key and certificate onto another switch specified in Importing the Certificate to Another Switch.

1. Generate an rsa key pairWS5100(config)#crypto key generate rsa key1 1024

WS5100(config)#show crypto key mypubkey rsa

Keypair <name> Configured

************************************************

key1


2. Create a trustpoint tpt1 and associate a keypair using rsakeypair command.

WS5100(config)#crypto pki trustpoint tpt1

WS5100(config-trustpoint)#subject-name ws5100 us kkk sj symbol wid




WS5100(config-trustpoint)#rsakeypair key1


3. Generate Certificate Request for the trustpoint tpt1.

WS5100(config)#crypto pki enroll tpt1 request

This generates a Certificate Request.

4. Send the request to the ftp server specified.Get the request signed by Appropriate CA.( Windows 2003 Server will also do).

WS5100(config)#crypto pki export external request ftp://<user:password>@ IP/ Path/File

5. Import the Signed Certificate on 111.222.111.x through either ftp or tftp.

WS5100(config)#crypto pki import external certificate ftp://<user:password>@ IP/ Path/servcert.pem

If the Certificate is valid and matches the key then gets successfully imported.

6. Export the keypair to an ftp/tftp server.

WS5100(config)#crypto key export rsa key1 ftp://<user:password>@ IP/ Path/key.pem

8.2.4.2 Importing the Certificate to Another Switch

1. Import the key, that had been exported in the previous step from the specified URL, to the switch.WS5100(config)#crypto key import rsa key1 ftp://<user:password>@ IP/ Path/key.pem

2. Create a dummy trustpoint and assign rsa keypair.

WS5100(config)#crypto pki trustpoint dummy

WS5100(config-trustpoint)#rsakeypair key1


WS5100(config)#

3. Import the certificate for the truspoint dummy.

WS5100(config)#crypto pki import dummy ftp://<user:password>@ IP/ Path/servcert.pem

8.2.5 Configuring Trustpoint using the Web UITo create a certificate using Web UI you need to:

• Creating a Trustpoint

• Uploading the Server Certificate/CA Certificate


8.2.5.1 Creating a Trustpoint

To configure a trustpoint using Web UI, follow the steps mentioned below:

1. Create an trustpoint using Security > Server Certificate from the main menu tree. By default the Server Certificate window displays the Trustpoint tab.

2. Click on the Certificate Wizard button to create the certificate.

NOTE: WS5100 comes with a default trustpoint. You can create a maximum of 5 trustpoints using the Web UI.


a. Select Create a new certificate option in the first page of the wizard and click on Next button.

b. Use the second page of the wizard to configure a trustpoint and create a private key for the certificate. Ensure you do not have more than 5 trustpoints at the time of creating the trustpoint.

• Select Prepare a certificate request to send to certificate authority option.

• Select Create a new trustpoint option and assign a new trustpoint name.

• Select Create a new key option and create a new private key. Enter the Key Name and Key Size to create a encryption value for the private key.


• Click on the Next button to continue.

c. Use the third page of the wizard to enter the mandatory details required to create a certificate.All fields marked with an astreik (*) are mandatory.

• Select the Configure the trustpoint checkbox to enable the new self signed certificate to be configured as a trustpoint.

• Define the Country used in the Self-Signed Certificate. By default, the Country is US. The field can be modified by the user to other values. This is a required field and must not exceed 2 characters.

• Enter a State/Prov. for the state or province name used in the Self-Signed Certificate. By default, the State/Prov. field is Province. This is a required field.

• Enter a City to represent the city name used in the Self-Signed Certificate. By default, the City name is City. This is a required field.

• Define an Organization for the organization used in the Self-Signed Certificate. By default, it is Company Name. The user is allowed to modify the Organization name. This is a required field.

• Enter an Org. Unit for the name of the organization unit used in the Self-Signed Certificate. By default, it is Department Name. This is a required field.

• Define a Common Name for the URL of the switch. This is a required value. The Common Name must match the URL used in the browser when invoking the switch applet.

• Enter a fully qualified domain name (FQDN) is an unambiguous domain name that specifies the node's position in the DNS tree hierarchy absolutely. To distinguish an FQDN from a regular domain name, a trailing period is added. ex: somehost.example.com. An FQDN differs from a regular domain name by its absoluteness; as a suffix is not added.

• Specify the switch IP address used as the switch destination for certificate requests.

• Enter an alphanumeric password used to access the certificate configuration.


• Provide a Company name to be used on behalf of the certificate.

• Select the Enroll the trustpoint checkbox to enroll the certificate request with the CA.

• Click on Next button to continue.

d. Use the fourth page of the wizard to copy the content of the request on a clip board or save it to your local machine or transfer it to your machine using FTP/TFTP Server.


3. To generate a self-signed certificate, select Generate a self-signed certificate option in the Page 2 of the wizard.

8.2.5.2 Uploading the Server Certificate/CA Certificate

You need to upload the Server Certificate request generated for trustpoint testTP to the CA. The CA generates the Server certificate by signing the server certificate request.

The CA certificate which is the root certificate of the CA can be downloaded from the CA itself.

1. Select Security > Server Certificates from the main menu tree.

2. Click the Certificate Wizard button.


3. Select the Upload an external certificate radio button to upload an existing Server Certificate or CA Root Certificate. and click on Next button to continue.

4. Use this page of the wizard to upload the Server Certificate an/or CA Root Certificate to a trustpoint on the switch.


5. This complete the creation of CA/Server certificate.

Radius

This chapter provides detailed feature and configuration information for the Radius features.

• Overview

• Configuring Onboard Radius Server using CLI

• Configuring Radius using GUI

• Configuring Radius Server

• Configuring WLAN

• Configuring LDAP

9.1 OverviewThe Radius server is used to define authentication and authorization schemes in the WS5100 switch for granting the access to the wireless clients. Radius is also used for authenticating hotspot and remote VPN Xauth.

The WS5100 switch can be configured to use 802.1x EAP for authenticating the wireless clients with a RADIUS server. The following EAP authentication types are supported by the onboard Radius server:

• TLS*

• TTLS and MD5

• TTLS and PAP

• TTLS and MSCHAPv2

• PEAP and GTC

• PEAP and MSCHAPv2

Apart from EAP authentication, the WS5100 switch’s capabilities allows enforcement of User based policies. User based policies include dynamic VLAN assignment, access based on time of day, etc.

The WS5100 switch uses the default trustpoint. A certificate is required for EAP type TTLS,PEAP and TLS Radius authentication, which can be configured with the Radius service.

Dynamic VLAN assignment is done based on the Radius server response. A user who associates to WLAN1 (mapped to VLAN1) can be assigned to a different VLAN after authentication with the Radius server. This dynamic VLAN assignment overrides the WLAN's VLAN ID to which the User associates.

For 802.1x EAP authentication, the WS5100 switch initiates the authentication process by sending EAPoL message to the access port only after the wireless client joins the wireless network. The RADIUS client in


the WS5100 switch processes the EAP messages that it receives. It encapsulates them to RADIUS access requests and sends it to the configured RADIUS server, in this case the local Radius server.

The RADIUS server investigates the user credentials and the challenge information received in the RADIUS access request frames. If the user is authorized and authenticated, the wireless client is granted access by sending a RADIUS access accept frame. This is transmitted to the wireless client in a EAPoL frame format.

Figure 9.1 802.1x EAP Authentication Process

9.1.1 User DatabaseUser Group names and the associated users in each group can be created in the local database. User ID in the received access requests is mapped to the associated wireless group for the authentication and the authorization policies.

The WS5100 supports creation of 500 users and 100 groups on its local database. Each group can have a maximum of 500 users configured.

9.1.2 Authentication of Terminal/Management User(s)The local radius server can be used to authenticate the management and terminal users. For this, the normal user with the password should be created in the local database. These users should not be a part of any group.

9.1.3 Access PolicyAccess policies are defined in for a group created in local database. Each user is authorized based on the access policies defined for the groups to which the user belongs.The access policies allow the administrator to control the access to a set of users based on the WLANs (essid).

Group to wlan access will be controlled by using Time of the day access policy.

For example, consider User1 who's a part of Group1, which is mapped to wlan1 (i.e. essid of wlan1). When the user tries to connect to wlan1, the user will be prompted to enter his/her credentials. Once the authentication and authorization phases are successful then only user1 will be able to access the wlan1, only for the allowed duration but not any other wlan.

Radius 9-3

Each user group can be configured to be a part of one vlan. All the users in that particular group will be assigned with the same vlan id. If the vlan-type is user-based then the users will become the part of a configured vlan. If the user group is not configured with a particular vlan then the user will be assigned with the default vlan ID 1.

9.1.4 Proxy to External Radius ServerProxy realms is configured on the WS5100 switch, which has the details of the external radius server to which the corresponding realm users are to be proxied.

The obtained user ID will be parsed in the format (user@realm, realm/user, user%realm) to determine which proxy Radius server has to be used.

9.1.5 LDAPIn the Radius configuration, the onboard user database is used, while this may be an optimal solution for smaller enterprises, it may not be well suited for a very large enterprise. Specially those customer who have rolled out Active Directory services across their enterprise.

External data source based on LDAP can be used to authorize the users. Radius server looks for the user credentials in the configured external LDAP server and authorizes the users, in case LDAP is used as a data source for the users.

The WS5100 switch supports two LDAP server configurations are supported.

9.1.6 AccountingAccounting should be initiated by the radius client. Once the Local/Onboard radius server is started, it will listen for both authentication and accounting records.

Administrators can retrieve the files using TFTP from the CLI and SNMP initiated TFTP. Accounting log file generated can be listed both in the applet and the CLI. The WS5100 switch also supports directing the accounting logs to external accounting server or a syslog server.

9.2 Configuring Onboard Radius Server using CLITo configure Onboard Radius Server follow the CLI commands mentioned below:

1. Enter into radius-server context and configure the local radius server.

WS5100(config)# radius-server local

2. Configure the authentication data source.The authentication data source can be set to local or remote ldap server.

WS5100(config-radsrv)# authentication data-source local

3. Configure EAP type and Authentication type.

WS5100(config-radsrv)# authentication eap-auth-type all


4. Configure the CA/Server certificates. Execute the following commands with the corresponding trust point names. Trust point must be configured before executing these commands. For more details refer to Configuring the Certificate Manager using CLI.

WS5100(config-radsrv)# ca trust-point tp1

WS5100(config-radsrv)# server trust-point tp1

If the CA or Server trust point is not configured, then the default trust-point will be used.

5. Create users in the local database.

WS5100(config-radsrv)# rad-user adam password 0 mypassword

WS5100(config-radsrv)# rad-user bob password 0 secret!!

6. Create groups in the local database.

WS5100(config-radsrv)# group sales

7. Add users to the group.

WS5100(config-radsrv-group)# rad-user bob

WS5100(config-radsrv-group)# rad-user adam

To remove the user—adam from group sales, use

WS5100(config-radsrv-group # no rad-user adam

8. Configuring group policies:

a. Day policy.

WS5100(config-radsrv-group)# policy day sa su

b. Time policy

WS5100(config-radsrv-group)# policy time start 12 00 end 03 00

c. WLAN access policy

WS5100(config-radsrv-group)# policy wlan 1 2

d. VLAN configuration

WS5100(config-radsrv-group)#policy vlan 1

9. Create a guest group in the local database.

WS5100(config-radsrv)# group guest-group1

10.Configure group policies for the group—guest-group1. Enable guest access for this group.

WS5100(config-radsrv-group)# guest enable

11.Create a guest user and add that user to group guest.

WS5100(config-radsrv)# rad-user guest-user password 0 symbol group guest-group1 guest expiry-date 21:07:2006 expiry-time 13:30

12.Configure NAS to add radius client (NAS) entries.

WS5100(config-radsrv)# nas 157.235.207.0/24 key 0 symbol123

13.Configure proxy server and add realms.

WS5100(config-radsrv)# proxy retry-delay 5

WS5100(config-radsrv)# proxy retry-count 4

Radius 9-5

a. Add a proxy realm,

WS5100(config-radsrv)# proxy realm symbol.com server 157.235.207.16 port

1812 secret 0 symbol

14.Configure LDAP servers. If the users are configured in the remote database, then use the LDAP server for user authentications. For this,

a. Configure the authentication data source as ldap.

WS5100(config-radsrv)# authentication datasource ldap

b. Configure the ldap servers.

WS5100(config-radsrv)# ldap-server primary host 157.235.207.16

port 639

login(uid= %{ Stripped-User-Name :-%{ User-Name}})

bind-dn cn=Manager, o=symbol, c=India

base-dn o=symbol, c=India

password mypassword

passwd-attr userPassword

group-attr cn

group-filter (| (& (objectClass=GroupOfNames) (member= %{ Ldap

-UserDn})) (& (objectClass=GroupOfUniqueNames) (uniquemember= %{ Ldap-UserDn})))

group-membership radiusGroupName

15.Save the changes.

WS5100(config-radsrv)# service radius restart

This will update the config files and sends a sig-up if the radius server is already running, otherwise the radius server will be started.

16.List accounting log directory.

WS5100(config)# dir flash:/radius/radacct

17.Send accounting logs to remote machine.

WS5100(config)# copy flash:/radius/radacct/acct-20061230 ftp://

user:password@hostname:/

9.2.1 Sending an Access Request to the Local Radius ServerAfter configuring the local Radius server, configure the WLAN to use local Radius server for authentication.

1. Configure the wlan to use local radius server for authentication.

WS5100(config-wireless)# wlan 1 radius server primary 157.235.208.90 auth-

port 1812

WS5100(config-wireless)# wlan 1 radius server primary radius-key 0 symbol123


2. Connect the MU to the ssid of the wlan 1, with proper user profile. The user profile in the MU should have the following parameters to connect to the wlan1.

The user name bob

User password as secret!!

EAP type TTLS

Auth type md5

The user bob will get access only on Saturday’s & Sunday’s from 12pm to 3pm

3. While proxying the request to the remote home server, The MU user profile should be

The user name: [email protected]

User password: symbol

4. The remote home server configuration

users file default location:/usr/local/etc/raddb/user:

add this entry: [email protected], Auth-Type:= Local, User-Password == "symbol"

clients.conf file

client 157.235.208.0/24 {

secret = symbol

shortname = wios

9.2.2 Enable Debug Logs for RadiusExecute the command given below to enable debug logs (errors, info, warning, all logs) for Radius.

WS5100# debug radius all

9.3 Configuring Radius using GUISetting up Radius on the switch entails configuring the following:

• Configure Radius server

• Configure WLAN

• Configure LDP

9.3.1 Configuring Radius ServerFollow the steps mentioned below to configure Radius server:

Radius 9-7

9.3.1.1 Configuring a Radius Server

1. Click on Security > Radius Server from the main menu tree. By default, the Radius Server window displays the details of Configuration tab.

By default, the Radius server is set in Start mode.

2. Click the Start the RADIUS server link to use the switch’s own Radius server to authenticate users accessing the switch managed network.

3. The Configuration tab by default displays the details of Client tab details.It displays the IP address and subnet mask of the switch’s existing Radius clients.

4. In the Client tab, click on the Add button to add Radius client (NAS).

a. Specify the IP Address/Mask of the subnet or host authenticating with the Radius client.

b. Specify a Radius Shared Secret for authenticating the RADIUS client.

Shared secrets are used to verify Radius messages (with the exception of the Access-Request message) are sent by a Radius -enabled device configured with the same shared secret. The shared secret is a case-sensitive string that can include letters, numbers, or symbols. Make the shared secret at least 22 characters long to protect the Radius server from brute-force attacks.

c. Click OK to use the changes to the running configuration and close the dialog.


9.3.1.2 Authenticating a Local Radius Server

1. Click on Authentication tab in the main Radius Server window, to configure the authentication for the local Radius server.

a. Refer to the Authentication section to define the following Radius authentication information. Specify the EAP and Auth Type for the RADIUS server.

• PEAP uses a TLS layer on top of EAP as a carrier for other EAP modules. PEAP is an ideal choice for networks using legacy EAP authentication methods.

• TTLS is similar to EAP-TLS, but the client authentication portion of the protocol is not performed until after a secure transport tunnel has been established. This allows EAPTTLS to protect legacy authentication methods used by some RADIUS servers.

• If PEAP is selected as the EAP type, specify a Auth Type for PEAP to use from the drop-down menu. The options are GTC and MSCHAP-V2.

- Generic Token Card (GTC) — This is a challenge handshake authentication protocol that uses a hardware token card to provide the response string.

- Microsoft CHAP (MSCHAP-V2)— This is an encrypted authentication method based on Microsoft's challenge/ response authentication protocol.

• If TTLS is selected as the EAP type, specify a Default Auth Type for TTLS to use from the drop down menu. The options are MD5, PAP and MSCHAP-V2.

- Message Digest 5 (MD5)— This is a secure hash function which converts a long data stream into a fixed size digest.

- Password Authentication Protocol (PAP)— This is a protocol where the user sends an identifier and password pair to the server. This information is sent un-encrypted.

- Microsoft CHAP (MSCHAP-V2)— This is an encrypted authentication method based on Microsoft's challenge/ response authentication protocol.

• Use Auth Data Source drop-down menu to select the data source for the local RADIUS server.

Radius 9-9

• If Local is selected, the switch’s internal user database serves as the data source for user authentication. Refer to the Users and Groups tabs to define user and group permissions for the switch’s local Radius server.

• If LDAP is selected, the switch uses the data within an LDAP server.

• Select a trustpoint Cert Trustpoint drop down box. Refer to Creating a Trustpoint for more details.

• Select a CA certificate from the CA Cert Trustpoint drop down box. Refer to Creating a Trustpoint for more details.

2. Click OK to set authentication for the local Radius server.

9.3.1.3 Creating a Group

Follow the steps mentioned below to create a group to the Radius servers database.

1. Click on Groups tab in the main Radius Server window. It displays the existing group for the Radius server.

2. Click on Add button to create a new group.

a. Enter a unique group name for the group in the Name field.

b. Enter a VLAN ID for the new group. The VLAN ID is representative of the shared SSID each group member (user) employs to interoperate with one another within the switch managed network (once authenticated by the local Radius server).


c. Use Time of Access Start field to set the time the group is authenticated to interoperate within the switch managed network. Each user within the group will be authenticated with the local Radius server. Those group members successfully authenticated are allowed access to the switch managed network using the restrictions defined for the group.

d. Use Time of Access End field to set the time each group’s user base will loose access privileges within the switch managed network. After this time, users within this group will not be authenticated by the local Radius server.However, if a user is part of a different group that has not exceeded their access end interval, then the user may still interoperate with the switch (remain authenticated) as part of that group.

e. Use the Available WLANs Add -> and Remove <- functions to move WLANs for this new group from the available list to the Configured WLANS list. Once on the configured list (and the changes applied), the members of this group can interoperate with the switch on these WLANs (once authenticated by the local Radius server).

f. The Configured WLANs columns displays the WLANs this new group can operate within (once users are configured). Use the Add -> and Remove <- functions to move WLANs from the available list to the configured list.

g. In the Time of Access in days section, select the checkboxes corresponding to the days of the week you would like this new group to have access to the switch managed network using the WLANs configured.

h. Click OK to use the changes to the running configuration and close the dialog box.

9.3.1.4 Creating a User

Follow the steps mentioned below to create a user and assign him to the group created in Creating a Group.

1. Click on Users tab in the main Radius Server window. It displays the existing users for the Radius server.

2. Click on the Add button to add a new user.

Radius 9-11

a. In the Name field, enter a unique user ID that differentiates this user from others with similar attributes.

b. Enter the password used to add the user to the list of approved users displayed within the Users tab.

c. Re-enter (confirm) the password used to add the user to the list of approved users displayed within the Users tab.

d. Use the Available Groups Add -> and Remove <- functions to map groups (for inclusion) for this specific user.

e. The Configured Group section displays the group which the user is assigned to.

f. Click OK to use the changes to the running configuration and close the dialog box.


9.3.2 Configuring WLANFollow the steps mentioned below to create and configure a WLAN.

1. Click on Network > Wireless LANs from the main menu tree. The Wireless LANs window by default displays the Configuration tab details. WS5100 by default has 32 WLANs and you need to use one of them for configuring the Radius server.

2. Select a WLAN from the table and click on Edit button.

a. In configuration section, change the ESSID and create a new ESSID named—PEAP-TEST.

b. In the Authentication section, select the 802.1x authentication option for this WLAN.

c. In the Encryption section, select WEP128 under Encryption checkbox.

d. For generating Accounting Log, go to the Advanced section and select RADIUS as the Accounting Mode from the drop down box.

Radius 9-13

3. Click on the Radius Config Button.

a. In the Server section, enter WS5100 switch’s IP address in the Radius Server Address field.

b. In the Server section, assign the Radius Shared Secret.


c. In the Accounting section, enter the Accounting Server IP Address.

• This should be the same as mentioned in Step 4, Configuring a Radius Server for using Local Radius server accounting (or)

• As mentioned in Step 3a above.

d. Click on OK to save the configuration changes made in Radius Configuration dialog box.

e. Click OK to save and close the Wireless LANS Edit dialog box.

4. Repeat Steps 1 - 3 to create another ESSID called TLS-TEST. Ensure you have a DHCP server and other configurations like VLAN's etc setup appropriately.

9.3.3 Configuring LDAPFollow the steps mentioned below to configure a LDAP Radius.

1. Click on Security > Radius Server from the main menu tree.

2. Select Authentication tab to display the create a LDAP Radius configuration.

3. In the Authentication section, select ldap as the Auth Data Source.

4. Enter the Primary LDAP Server details by referring to the LDAP configuration table below.

5. Click Apply.

Attribute Value Comments

IP Address 192.192.4.42 This is the IP address of the Windows Active Directory Server

Port 389 LDAP Port Number. Don't change this

Bind-DN cn=blradmin,ou=WID,dc=TVLAB01,dc=com cn should be your server's administrator name. Copy the OU and DC values for your server looking at the Active Directory snapshot above.

Base-DN ou=WID,dc=TVLAB01,dc=com cn should be your server's administrator name. Copy the OU and DC values for your server looking at the Active Directory snapshot above.

Bind-Password Symbol123 This is the password for your Windows Server administrator account.

User Login Filter (sAMAccountName=%{Stripped-User-Name:-%{User-Name}})

Copy this Value as is.

Password Attribute UserPassword Copy this Value as is.

Group Membership Attribute

cn Copy this Value as is.

Group Filter (|(&(objectClass=group)(member=%{Ldap-UserDn

}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))

Copy this Value as is.

Radius 9-15

6. Enter the Primary LDAP Server details looking at the LDAP configuration table above. Click Apply.

9.4 Use Case – Configuring Onboard RADIUS to use Active Directory as user database?

This use case refers to the Active Directory configuration displayed in Figure 9.2. This configuration is for WS5100...

Figure 9.2 Sample Active Directory.

WS5100’s Onboard RADIUS Server uses local database to authenticate its users. Incase, the user has a existing Active Directory that can be used instead of local database, then use the LDAP configuration to reach the Active Directory Server.

Group Membership Attribute

radiusGroupName Copy this Value as is.

Net Timeout 2 2

Attribute Value Comments


WS5100 has primary and secondary LADAP servers. The table below displays the LDAP configuration used to access Active Directory. The parameters used within the parenthesis are WS5100 CLI parameters.

Parameter Used Value Description

LDAP Server IP (host) 192.192.4.42 The IP address of the server PC running the Active Directory Service.

LDAP Server Port (port) 389 The port number on which the active directory service is listening. Default port number is 389.

LDAP Bind DN (bind-dn) cn=blradmin,ou=WID,dc=TVLAB01,dc=com

Allows the radius server to get bind to the Active Directory using the administrator user name and password. In the above example the 'blradmin' is the user with administrative privileges for WID organization in the domain TVLAB01.com and the password for the user blradmin will be configured in the Password field. For the above example use the details displayed in Figure 9.2 as Active Directory.Bind DN = "cn=blradmin,ou=WID, dc=TVLAB01,dc=com"

Password = "Motorola123"

Another example as of above:Base DN = "cn= Administrator, cn=Users,dc=dynamic,dc=s99999,dc=jp,dc=wal-mart,dc=com".

Password= "Motorola123"

These fields (Base DN, Bind DN and Password) will be used by the radius server to log onto the active and search for the requested users within this base.

LDAP Base DN (base-dn) ou=WID,dc=TVLAB01,dc=com The top level of the LDAP directory tree is the base, referred to as the "base DN". In the above example we are working within a 'WID' organizational unit and under the domain TVLAB01.com as show in Figure 9.2. The format for BaseDN for the above example would beBase DN = "ou=WID,dc=TVLAB01,dc=com".

Another example, if you are using the users configured in the Users folder of Active Directory with in the domain dynamic.s99999.jp.wal-mart.com then the

Base DN = "cn=Users,dc=dynamic,dc=s99999,dc=jp,dc=wal-mart,dc=com".

Password (passwd) Motorola123 Password for accessing Active Directory (password for blradmin), mentioned in Bind DN.

LDAP Login Attribute (login)

(sAMAccountName=%{Stripped-User-Name:-%{User

-Name}})

This filter is used to bind to Active Directory.

Radius 9-17

1. Use the following WS5100 CLI command to populate LDAP configuration to access Active Directory.

WS5100(config-radsrv)#ldap-server primary host 192.192.4.42 port 389 login

(sAMAccountName=%{Stripped-User-Name:-%{User-Name}}) bind-dn cn=blradmin,ou=WID,dc=TV LAB01,dc=com base-dn ou=WID,dc=TVLAB01,dc=com passwd

Symbol123 passwd-attr UserPaswword group-attr cn group-filter

(|(&(objectClass=group)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn}))) group-

membership radiusGroupName

2. Use the following CLI command to view LDAP configuration.

WS5100(config)#show ldap configuration primary

Primary LDAP server configuration

_________________________________

IP Address : 192.192.4.42

Port : 389

Login : (sAMAccountName=%{Stripped-User-Name:-%{User-Na

me}})

Bind DN : cn=blradmin,ou=WID,dc=TVLAB01,dc=com

Base DN : ou=WID,dc=TVLAB01,dc=com

Password : 0 Symbol123

Password Attribute : UserPaswword

Group Name : cn

Group Membership Filter: (|(&(objectClass=group)(member=%{Ldap-UserDn}))

(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))

Group Member Attr : radiusGroupName

Net timeout : 1 second(s)

LDAP Password Attribute (passwd-attr)

UserPassword This password attribute is used by the LDAP server for authentication.

LDAP Group Name Attribute (group-attr)

cn This group attribute is used by the LDAP server.

LDAP Group Membership Filter (group-filter)

(|(&(objectClass=group)(member=%{Ldap-UserDn}))(& (objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))

Group filters used by the LDAP server.

LDAP Group Membership Attribute(group-membership)

radiusGroupName Group Member Attribute thats sent to LDAP server when authenticating the users.

Parameter Used Value Description

LDAP Server IP (host) 192.192.4.42 The IP address of the server PC running the Active Directory Service.


3. In the Active directory, user1 is used for RADIUS Authencation. User1 is part of group6 as displayed in Figure 9.3. Hence, you have to now create the same group (group6) in the local RADIUS database and allow access for WLAN in use.

Figure 9.3 Associating a user to RADIUS group6.

• Use the following command to allow the group access to WLAN.

WS5100(config-radsrv)#group group6

WS5100(config-radsrv-group)#policy wlan 1

Radius 9-19

4. Select Security >Radius Server >Authentication Tab from the main menu to view the LDAP configuration details using the WS5100’s applet.

ACL

This chapter provides detailed feature and configuration information for the ACL features.

• Overview

• Firewall

• Network Address Translation

• Configuring ACL using CLI

• Configuring ACL using the Web UI

10.1 OverviewAn Access Control List (ACL) is a sequential collection of permit and deny conditions that apply to packets. When a packet is received on an interface, the WS5100 Switch compares the fields in the packet against any applied ACLs. It verifies whether the packet has the required permissions to be forwarded based on the criteria specified in the access lists. This concept is known as packet filtering and it helps to limit network traffic and restricts network usage by certain users or devices.

An ACL contains an ordered list of Access Control Entries (ACEs). Each ACE specifies an action and a set of conditions that a packet must satisfy in order to match the ACE. The order of conditions in the list is critical because the WS5100 Switch stops testing conditions after the first match.

WS5100 Switch supports two types of ACLs:

1. IP ACLs — Filters IP traffic, including TCP, UDP, and ICMP. It includes Standard and Extended ACL

2. MAC ACLs — Filters non-IP traffic. This supports only Extended ACL.

10.1.1 Supported ACLsThe WS5100 Switch supports following applications of ACLs to filter traffic:

• Router ACLs — These are applied to VLAN (Layer 3) interfaces. These ACLs filter traffic based on Layer 3 parameters like Source IP, Destination IP, Protocol types and Port Numbers. They are applied on packets which are routed through the box.

• Port ACLs — These are applied to traffic entering a Layer 2 interface. Only switched packets are subjected to these kind of ACLs. Traffic filtering is based on Layer 2 parameters like–Source MAC,


Destination MAC, Ethertype, VLAN-ID, 802.1p bits (OR) Layer 3 parameters like– Source IP, Destination IP, Protocol, Port Number.

• Wireless LAN ACLs – A Wireless LAN ACL is designed to filter/mark packets based on the wireless LAN from which they arrived rather than filtering the packets arrived on L2 ports. WLAN ACLs can be attached, both, in inbound and outbound directions.

10.1.1.1 Router ACLs

Router ACLs are applied to Layer 3 or VLAN interfaces. If an ACL is already applied in a particular direction on an interface, applying a new one will replace the existing ACL. Router ACLs are applicable only if the switch acts as a gateway.

WS5100 Switch supports two types of Router ACLs based on the matching criteria. They are:

• Standard IP ACL — It uses Source IP address as matching criteria.

• Extended IP ACL — It uses Source IP address, Destination IP address and IP protocol type as basic matching criteria. It can also include other parameters specific to a protocol type, like–Source and Destination port for TCP/UDP protocols.

Router ACLs are stateful and are not applied on every packet that gets routed through the box. Whenever a packet is received from a Layer 3 interface, it is examined against all the existing sessions to determine if it belongs to an already established session. ACLs are applied on the packet in the following manner.

1. If the packet matches an existing session, it is not matched against ACL rules and the session decides where to send the packet.

2. If no existing sessions match the packet, it is matched against ACL rules to decide whether to accept it or reject it.If ACL rules accept the packet, a new session is created and all further packets belonging to that session are allowed. If ACL rules reject the packet, no session is established.

A session is computed based on the following parameters

• Source IP address

• Destination IP address

• Source Port

• Destination Port

• ICMP identifier

• Incoming interface index

• IP Protocol

Each session also has a default idle time-out interval. If no packets matching the session are received within this interval, the session is destroyed and a new session is created again. These intervals are fixed and can not be configured by the user.

The default idle time-out intervals for different sessions are:

• ICMP and UDP sessions— 30 seconds

• TCP sessions— 2 hours

NOTE: WS5100 Switch does not support applying ACLs in the outbound direction for both Layer 2 and Layer 3 interfaces.

ACL 10-3

10.1.1.2 Port ACLs

WS5100 supports Port ACLs on physical interfaces and inbound traffic only. The following types of Port ACLs are supported based on the matching criteria:

• Standard IP ACL — It uses Source IP address as matching criteria.

• Extended IP ACL — It uses Source IP address, Destination IP address and IP protocol type as basic matching criteria. It can also include other parameters specific to a protocol type, like–Source and Destination port for TCP/UDP protocols.

• MAC Extended ACL— It uses Source and Destination MAC Addresses, VLAN ID. It optionally, also uses ethertype information.

Port ACLs are not stateful as compared to Router ACLs. Hence it matches every packet against the configured ACL rules and takes action as defined by the ACL rules.

When a Port ACL is applied to a trunk port, the ACL filters traffic on all VLANs present on the trunk port. With Port ACLs, you can filter

• IP traffic by using IP ACL and

• Non-IP traffic by using MAC addresses.

Both IP and non-IP traffic on the same Layer 2 interface can be filtered by applying both an IP ACL and a MAC ACL to the interface.

You cannot apply more than one IP ACL and one MAC ACL to a Layer 2 interface. If an IP ACL or MAC ACL is already configured on a Layer 2 interface and a new IP ACL or MAC ACL is applied to the interface, the new ACL replaces the previously configured one.

10.1.1.3 Wireless LAN ACLs

Wireless LAN ACLs filter/mark packets based on the wireless LAN from which they arrive rather than filtering the packets arrived on L2 ports.

In general, a Wireless-LAN ACL can be used to filter wireless to wireless, wireless to wired and wired to wireless traffic. Typical wired to wired traffic can be filtered using a L2 port based ACL rather than a WLAN ACL.

Each WLAN is assumed to be a virtual L2 port. Configure one IP and one MAC ACL on the virtual WLAN port. In contrast to L2 ACLs, a WLAN ACL can be enforced on both the Inbound and Outbound direction.

10.1.2 ACL ActionsEvery ACE within an ACL is made up of an action and matching criteria. The action defines what to do with the packet if it matches the specified matching criteria. The following types of actions are supported.

• deny — It instructs the ACL to drop the packet if does not matches the criteria defined by the ACE.

• permit — It instructs the ACL to allows the packet to go to its destination.

• mark — It modifies certain fields inside the packet and then permits it. Hence mark is an action with an implicit permit. Using mark action the following fields in the packet can be can modified.

• VLAN 802.1p priority.


• TOS/DSCP bits in the IP header.

10.1.3 Precedence OrderThe rules or ACE’s within an ACL are applied to packets based on their precedence values. Every ACE has a unique precedence value which can be between 1 and 5000. You cannot add two ACE’s with the same precedence value.

The following points need to considered when adding rules with or without precedence values.

• Every ACL entry in an ACL is associated with a precedence value which is unique for every entry. You cannot enter two different entries in an ACL with the same precedence value. This value can be between 1 and 5000.

• Specifying a precedence value with each ACL entry is not mandatory and if you do not want to specify one then the system automatically generates a precedence value starting with 10. Subsequent entries are added with precedence values of 20, 30 and so on. 10 is the default offset between any two ACEs in an ACL.However, if the user specifies a precedence value with an entry, then that value overrides the system default value.

• If an entry with a max precedence value of 5000 exists, then you cannot add a new entry with a precedence value higher than this. In such a case, system throws an error saying Rule with max precedence value exists. In such a case you either have to delete that entry or add new entries with precedence values less than 5000.

• Rules within an ACL are displayed in ascending order of precedence.

• When matching rules against a received packet, rules with lower precedence values are matched first.

10.2 FirewallThe Firewall functionality in WS5100 switch supports packets received on Layer 3 interfaces only. No firewall protection is applied for packets getting switched. The firewall protects against various network level attacks and inspects each packet for possible corruption that can initiate some kind of attack.

The Firewall detects the following list of attacks:

• LAND attack– where Source IP = Destination IP and Source Port = Destination Port.

• Fragment death– caused by overflowing fragment length.

• Traceroute attack– caused by modifying IP TTL value.

• Xmas scan– all TCP flags set in TCP header.

• TCP fin scan

• TCP NULL scan– No flags set in TCP header.

NOTE: In WS5100, only Port ACL supports the mark action. In Router ACL, the mark action is treated as a permit action and the packet is allowed to its destination without performing any modifications.

NOTE: ACEs with lower precedence are always applied first to packets. Hence, it is advised to add more specific entries in the ACL first then the general ones. While displaying the ACL, the entries are displayed in ascending order of precedence.

ACL 10-5

Apart from detecting the above attacks, this feature also performs sanity checks on every packet. These sanity checks can drop a packet if the packet is malformed. A syslog message is generated whenever a packet gets dropped due to these sanity checks. It provides details as to why the packet was dropped along with the other packet information like – Source IP, Destination IP, Source Port, Destination Port, IP protocol etc.

Some of the packet corruption types are listed below:

• Multicast Source Address.

• Unknown IP option

• IP TTL zero

• IP Fragment overflow length—last fragment length creates a packet longer than 65k.

• IP Fragment Bad Length—non-last fragment length is not multiple of 8.

• Overlapping IP Fragment IDs —fragment ID collision.

The firewall feature executes a stateful packet inspection for any packet forwarded from one subnet to another subnet. It also applies a rate control on the number of sessions that can be created. This effectively helps the administrator in providing a defense against various network attacks. For example–SYN flood.

10.3 Network Address TranslationNetwork Address translation (NAT) allows an organization to present itself to the internet with a far fewer IP addresses than there are nodes on its internal network. NAT is implemented in router or firewall and it converts private IP address of the machine on the internal private network to one or more public IP addresses for the Internet. It changes the packet headers to the new address and keeps track of them via internal tables that it builds. When packets come back from the Internet, NAT uses the tables to perform the reverse conversion to the IP address of the client machine.

WS5100 supports NAT only for non-IPSec packets, which are routed by the switch. The following types of NAT will be supported:

• Static NAT

• Port NAT

10.3.1 Static NATA Static NAT is created by manually assigning public address to each internal machine, and that assignment is used all the time. Static NAT is used to define a one-to-one mapping between the source or destination IP address of a packet and the NAT IP address.

If the NAT translation changes the source IP address, it is called Source NAT and Destination NAT for destination IP address respectively. Specify the following parameters to define a Static NAT.

• IP Address— Match source or destination IP address based on the source or destination keyword.

• IP Protocol type— This is optional, either of TCP or UDP. It is valid only for destination NAT.

• Port No— This is optional and valid only with IP Protocol option and Destination NAT

• NAT IP Address— Source or destination based on the source or destination keyword.

• NAT Port— This is valid only for destination NAT.


IP Protocol and Port options are valid only for Destination NAT. This helps the switch administrator to host servers ( HTTP, FTP and DNS servers) in the inside network and map all of them to a single public IP address.

Use Destination NAT translation to request a connection to public IP Address and HTTP port and map it to an internal HTTP server.

The NAT port option is used when the server in the inside network is listening on some non-standard port.

Source NAT is when a host on the inside network is trying to access a host on the public network.

If both, Static and Port NAT translation are defined for the same host IP address, then Static NAT takes a higher precedence and packets from that host are NATed as defined by the NAT translation.

10.3.2 Port NATPort NAT is also known as NAPT or PAT. PAT ensures that a different TCP port number is used for each client session with a server on the Internet. When the response comes back from the server, the source port number, which becomes the destination port number on the return trip, determines which user to route the packets to.

Multiple local addresses are mapped to single global address and a dynamic port number. The user is not required to configure any NAT IP address. Instead IP address of the public interface of the switch is used to NAT packets going out from private network and vice versa for packets entering private network.

The following parameters are required to configuring a port NAT translation:

• ACL Identifier— This is used for deciding which packets to NAT. Only Standard IP ACLs and Extended IP ACLs can be specified.Packets matching a permit ACE within the ACL are NATed and the ones matching deny ACE are forwarded without performing NAT.

• Outgoing VLAN interface name— This is the public interface and defines the NAT IP address which will be used to NAT source IP address of packets.

10.4 Configuring ACL using CLIThe following sequence has to be followed to configure and ACL:

1. Configure an IP Standard ACL/IP Extended ACL or MAC Extended ACL

2. Applying ACLs to Interfaces

10.4.1 Configure an IP Standard ACL/IP Extended ACL or MAC Extended ACLACLs control access to the network through a set of rules. Each rule specifies an action which is taken when a packet matches it within the given set of rules. If the action is deny, the packet is dropped and if the action is permit, the packet is allowed. WS5100 switch supports the following types of ACLs:

• IP Standard ACLs

• IP Extended ACLs

• MAC Extended ACLs

NOTE: Port NAT can not be configured for NATing destination IP address or port.

ACL 10-7

ACLs are identified by either a number or a name. Numbers are predefined for IP Standard and Extended ACLs whereas name can be any valid alphanumeric string not exceeding 64 characters. In numbered ACLs, the rule parameters have to be specified on the same command line along with the ACL identifier.

This section explains the following:

• Configuring IP Standard ACL using CLI

• Configuring IP Extended ACL using CLI

• Configuring MAC Extended ACL using CLI

10.4.1.1 Configuring IP Standard ACL using CLI

IP Standard ACLs contain rules based on Source IP Address. You can create either a Numbered IP Standard ACL or a Named IP Standard IP Address.

Execute the following CLI commands to configure IP based standard ACL on WS5100 switch:

1. To configure numbered IP Standard ACL.

WS5100(config)#access-list 2 deny host 1.2.3.4 rule-precedence 10

WS5100(config)#access-list 3 deny host 1.2.3.4 rule-precedence 10

WS5100(config)#access-list 3 permit any rule-precedence 20

Valid numbers for numbered IP Standard ACLs are from 1-99 and 1300-1999. In the above CLI snippet ACL 3 denies host with IP 1.2.3.4 and allows all other hosts.

2. To configure named IP Standard ACL.

WS5100(config)#ip access-list standard ipst2

WS5100(config-std-nacl)#permit host 10.1.1.10 rule-precedence 30

WS5100(config-std-nacl)#deny any rule-precedence 20

10.4.1.2 Configuring IP Extended ACL using CLI

IP Extended ACLs contain rules based on the following parameters:

• Source IP address.

• Destination IP address.

• IP Protocol.

• Source Port–if protocol is TCP or UDP.

• Destination Port–if protocol is TCP or UDP.

• ICMP Type–if protocol is ICMP.

• ICMP Code–if protocol is ICMP.

IP protocol, Source IP and Destination IP are mandatory parameters.You can create either a Numbered IP Extended ACL or a Named IP Extended IP Address.

Execute the following CLI commands to configure IP Extended ACL on WS5100 switch:


1. To configure numbered IP Extended ACL.

WS5100(config)#access-list 2 deny ip host 1.2.3.4 any rule-precedence 10

WS5100(config)#access-list 2 permit tcp any host 2.3.4.5 eq 80 rule-precedence

20

WS5100(config)#access-list 2 deny icmp any host 2.3.4.5 rule-precedence 30

2. To configure named IP Extended ACL.

WS5100(config)#ip access-list extended ipextacl

WS5100(config-ext-nacl)#deny ip host 1.2.3.4 any rule-precedence 10

WS5100(config-ext-nacl)#permit tcp any host 2.3.4.5 eq 80 rule-precedence 20

WS5100(config-ext-nacl)#deny icmp any host 2.3.4.5 rule-precedence 30

10.4.1.3 Configuring MAC Extended ACL using CLI

MAC Extended ACLs contain rules based on the following parameters:

• Source MAC address

• Destination MAC address

• Ethertype– accepts well known types like IP, ARP, VLAN or an integer value between 1-65535.

• VLAN-ID

• VLAN 802.1p user priority

Source and Destination MAC address are mandatory parameters.

Execute the following CLI commands to configure a MAC extended ACL with different rule parameters on WS5100 switch:

WS5100(config)#mac access-list extended macextacl

WS5100(config-ext-macl)#permit 00:a0:f8:00:00:00 ff:ff:ff:00:00:00 any rule-

precedence 10

WS5100(config-ext-macl)#deny any any type arp rule-precedence 20

WS5100(config-ext-macl)#deny any any vlan 23 rule-precedence 30

10.4.2 Applying ACLs to InterfacesACLs can be applied to either an Ethernet or VLAN interface to filter packets coming IN from the interface. When ACLs (IP or MAC) are applied to Ethernet interfaces i.e. eth1 and eth2, they are called Port ACLs and when IP ACLs are applied to VLAN interfaces like— vlan1, vlan2 etc., they are called Router ACLs.

10.4.2.1 Configuring Port ACLs

Port ACLs filter packets which get switched in the same VLAN. Hence they should be applied on appropriate Ethernet interfaces, when the administrator wants to control traffic between hosts in the same VLAN. Port ACLs are not flow aware. The Port ACL rules are applied on every individual packet coming in through a particular interface. When allowing a certain MU or wired host, you should also add rules to allow return traffic from the MU or wired host.

ACL 10-9

1. Creating a IP ACL (Standard/Extended)

ws5100(config)#access-list 1 permit 192.168.1.0/24 rule-precedence 10

ws5100(config)#access-list 101 pemit ip 192.168.1.0/24 any rule-precedence 10

2. Creating a MAC Extended ACL.

WS5100(config)#mac access-list extended macacl

WS5100(config-ext-macl)#permit any any type arp

3. Apply Port ACL to an interface.

WS5100(config)#interface eth1

WS5100(config-if)#ip access-group 1 in

WS5100(config-if)#ip access-group macacl in

4. View the applied ACL.

WS5100(config)#show ip access-group eth1

Interface eth1

Inbound IP Access List : 1

Inbound MAC Access List : macacl

10.4.2.2 Configuring Router ACLs

Router ACLs filter traffic which gets routed by the WS5100 across two VLANs. The administrator should create appropriate IP (Extended or Standard) ACLs and apply them to either of the VLAN interfaces.

Router ACLs are applied only on VLAN interfaces and filter routed traffic between two different VLANs. These ACLs are flow aware and user need not configure a separate rule to allow return traffic. The below example shows this.

To configure a Router ACL on an Interface, let use the following example:

• The MU in VLAN1 has a IP of 192.168.1.140 and wired host in VLAN2 has a IP of 10.1.1.20.

• WS5100 VLAN1 IP is 192.168.1.110 and VLAN2 IP is 10.1.1.10.

The idea is to allow all traffic from wireless client to the wired client and deny all traffic from wired client to the wireless client.

Follow the CLI command below apply Router ACL to an interface.

1. Create a Standard ACL to permit a host.

WS5100(config)#access-list 20 permit host 192.168.1.140

2. Create a Standard ACL to deny a host

WS5100(config)#access-list 30 deny host 10.1.1.20

3. Apply the ACL (20)on VLAN interface.

WS5100(config)#interface vlan1


WS5100(config-if)#exit


4. Apply the ACL(30) on VLAN interface



WS5100(config-if)#exit

10.4.2.3 Configuring Wireless LAN ACLs

Follow the procedure mentioned below to upgrade Wireless LAN ACL from 3.0/3.0.1 to 3.0.2 :

WLAN index in ACL rules are configurable in WS5100 3.0/3.0.1. In WS5100 3.0.2, WLAN is treated as a virtual port and the user has to create ACL rules without WLAN index and attach ACLs to WLAN port.

While upgrading from WS5100 3.0/3.0.1 to 3.0.2, the ACLs having WLAN index as selectors are replaced with ACLs without having any WLAN index selectors. After the completion of the upgrade, user has to apply those ACLs to WLAN port manually.

A sample ACL configuration in 3.0/3.0.1

• Standard IP access list 10

permit host 1.2.3.4 wlan 3 log rule-precedence 10

• Extended IP access list 110

deny icmp host 5.6.7.8 host 5.6.7.9 wlan 4 rule-precedence 10deny icmp host 5.6.7.8 host 5.6.7.9 rule-precedence 20

• Extended IP access list extacl

permit icmp host 192.172.0.10 any wlan 12 rule-precedence 23deny icmp any any rule-precedence 33

• Extended MAC access list macacl

permit any host 00:01:02:03:04:05 type ip wlan 14 rule- precedence 11permit host 00:01:03:04:07:08 any wlan 14 rule-precedence 21permit any any wlan 14 rule-precedence 31

• Standard IP access list stdacl

permit any wlan 5 rule-precedence 34permit host 10.0.0.10 wlan 6 rule-precedence 44deny host 30.0.0.14 rule-precedence 54

After upgrade to 3.0.2 the configuration will look like

• Standard IP access list 10

permit host 1.2.3.4 log rule-precedence 10

• Extended IP access list 110

deny icmp host 5.6.7.8 host 5.6.7.9 rule-precedence 10

• Extended IP access list extacl

permit icmp host 192.172.0.10 any rule-precedence 23deny icmp any any rule-precedence 33

• Extended MAC access list macacl

permit any host 00:01:02:03:04:05 type ip rule-precedence 11permit host 00:01:03:04:07:08 any rule-precedence 21permit any any rule-precedence 31

• Standard IP access list stdacl

permit any rule-precedence 34permit host 10.0.0.10 rule-precedence 44deny host 30.0.0.14 rule-precedence 54

ACL 10-11

Follow the procedure mentioned below to manually upgrade the ACLs to the same configuration:

1. If all the rules in ACL have same WLAN index as selector and there are no other ACL rules then attach the ACL to the WLAN port.In the above example, the ACL "macacl" has two rules for WLAN 14 which can be attached to WLAN port as follows:

wlan-acl 14 macacl in

2. If ACL has mix of rules – with different WLAN indices and without an WLAN indices, then it should be grouped as follows.

a. Create separate ACLs for all rules with a given WLAN index.

b. Create separate ACLs for rules which do not have any WLAN index.

To manually configure the Standard ACL, in the above example, it has to be split into 3 ACLs.

ip access-list standard stdacl1permit any rule-precedence 34

ip access-list standard stdacl2permit host 10.0.0.10 rule-precedence 44

ip access-list standard stdacl3deny host 30.0.0.14 rule-precedence 54

no access-list stdacl

wlan-acl 5 stdacl1 in

wlan-acl 6 stdacl2 in

The stdacl must be detached from the interface to which it was associated and stdacl3 must be attached to that interface.

When the user explicitly creates ACL rules with WLAN index as selector, the switch consumes that ACL without WLAN index selector. During this process a warning is raised to the user as mentioned in the example below.

WS5100(config)#access-list 14 permit any wlan 19 logWarning : Acl rules with Wlan Index is deprecated. Wlan index configured for therule will be ignored. Please use wlan-acl CLI to apply ACLs on WLAN

Example

The example below applies an ACL to WLAN index 200 in inbound direction from the global config mode.

WS5100(config)#wlan-acl 2 150 inWS5100(config)#

The example below applies an ACL to WLAN index 200 in outbound direction from the global config mode.

NOTE: All ACLs which had WLAN index are now replaced with ones that don't have WLAN index. In the above process, the acl "110" had two rules which got replaced by only one rule because after removal of WLAN index selector, both the rules look similar.

NOTE: A MAC access list entry to allow arp is mandatory to apply an IP based ACL to an interface. MAC ACL always takes precedence over IP based ACL’s.


WS5100(config)#wlan-acl 2 150 out

WS5100(config)#

10.5 Configuring ACL using the Web UIThe following types of ACL configuration scenarios are explained below:

• Configuring IP Standard ACL

• Configuring MAC Extended ACL

•

10.5.1 Configuring IP Standard ACLTo configure IP Standard ACL using Web UI, follow the steps mentioned below:

1. Click on Security > ACL from the main menu tree. The ACLs window by default displays the Configuration tab.

2. To add a new ACL, click on the Add button in the ACLs section.

a. Select an Standard ACL from ACL Type drop down box. This uses source IP addresses for matching operations.

b. Click OK and close the dialog box.

ACL 10-13

3. To apply a rule to the ACL created in step 2 above, select it from the ACLs section and click on the Add button in the Associated Rules section.

a. Enter a precedence (priority) value between 1 and 5000 in the Precedence field.The rules within an ACL will be applied to packets based on their precedence value. Rules with higher precedence are always applied first.

b. Use the Operation drop-down menu to define a permit, deny or mark designation for the ACL.

c. In the Filters section, select a Source Wildcard/Mask from the drop-down menu.The source is the source address of the network or host in dotted decimal format. The Source-mask is the network mask.

d. Use the Source Address field to enter the IP address from where the packets are sourced.

e. Define a WLAN Index (between 1 -32) to associate an existing WLAN with this ACL Rule.

f. Click OK to apply the changes and close the dialog box.

4. Click on the Attach tab in the ACLs window and click on the Add button to attach the ACL to an interface.


a. Use the Interface drop-down menu to select the interface to configure on the switch. Available options include – Ethernet 1, Ethernet 2, VLAN 1 and VLAN 1.

b. Use the IP ACL drop-down menu to select an IP ACL used as the inbound IP for the layer 2 or layer 3 interface.

c. Click on OK button to save the changes and close the dialog box.

10.5.2 Configuring MAC Extended ACLTo configure MAC Extended ACL using Web UI, follow the steps mentioned below:

1. Click on Security > ACL from the main menu tree. The ACLs window by default displays the Configuration tab.

2. To add a new ACL, click on the Add button in the ACLs section.

a. Select an Extended IP List from ACL Type drop down box. This uses source and destination MAC addresses, VLAN ID and optional protocol type information.

b. Click OK and close the dialog box.

ACL 10-15

3. To apply a rule to the ACL created in step 2 above, select it from the ACLs section and click on the Add button in the Associated Rules section.

a. Enter a precedence (priority) value between 1 and 5000 in the Precedence field.The rules within an ACL will be applied to packets based on their precedence value. Rules with higher precedence are always applied first.

b. Use the Operation drop-down menu to define a permit, deny or mark designation for the ACL.

• Permit— This allows the traffic specified in this Filter section.

• Deny— This denies the traffic spcified in the Filter section.

• Mark— This marks the priority or type of service of the traffic in the Filter section.

c. In Attribute to mark section, select 802.1p or TOS if operation is set as mark.

d. In the Filters section, select a Source Wildcard/Mask and enter the value— any.

e. Enter the Source Address, if the source wildcard mask is set to host.

f. Similarly, in the Filters section, select a Destination Wildcard/Mask and enter the value— any.

g. Enter the Destination Address, if the Destination wildcard mask is set to host.

h. You can filter traffic based on the VLAN ID, ethernet type and mark packets using 802.1p.

i. Define a WLAN Index (between 1 -32) to associate an existing WLAN with this ACL Rule.

j. To select a VLAN ID, select the VLAN ID checkbox and enter the VLAN ID.

k. To select a Ethertype, use the drop down box and select ARP.

l. Click OK to apply the changes and close the dialog box.


4. Click on the Attach tab in the ACLs window and click on the Add button to attach the ACL to an interface.

a. Use the Interface drop-down menu to select the interface to configure on the switch. Available options include – Ethernet 1, Ethernet 2, VLAN 1 and VLAN 1.

b. Use the IP ACL drop-down menu to select an IP ACL used as the inbound IP for the layer 2 or layer 3 interface.

c. Use the MAC ACL drop-down menu to select an MAC ACL used as the MAC IP for the layer 2 interface.

d. Click on OK button to save the changes and close the dialog box.

10.5.3 Attaching an ACL on a WLAN Interface/PortUse the Attach- WLAN tab to view and assign an ACL to a WLAN on the switch. By default, arp is not supported. Create a MAC ACL to allow arp on the switch.

To configure a WLAN ACL:

1. Select Security > ACLs from the main menu tree.

NOTE: MAC ACLS cannot be applied on Router ACLs.

NOTE: WLAN based ACLs allows users to enforce rules/ACLs on both the inbound and outbound direction, as opposed to L2 ACLs, which just support the inbound direction.

ACL 10-17

2. Click the Attach - WLAN tab.

3. Refer to the following information as displayed within the Attach -WLAN tab:

4. Select a WLAN (by row) and click Edit to modify the WLAN Index, IP ACL and MAC ACL values.

5. Select a row and click the Delete button to delete the ACL from the list available (but not from the switch).

6. Click the Add button to add an ACL to a WLAN interface. For more information, see Adding a New ACL WLAN Configuration.

10.5.3.1 Adding a New ACL WLAN Configuration

After creating an ACL, it can be applied to one or more WLANs on the switch. To attach an ACL to a WLAN:

1. Select Security > ACLs from the main menu tree.

2. Click on the Attach-WLAN tab.

WLAN Index The WLAN Index displays the list of WLANs attached with ACLs.

IP ACL Displays the IP ACL configured.

MAC ACL Displays the MAC ACL configured.

Direction Displays whether the WLAN ACL is configured to work in the inbound or outbound direction.


3. Click the Add button.

4. Define a WLAN Index between 1 and 32.

5. Use the IP ACL drop-down menu to select an IP ACL to configure for the WLAN interface.

6. Use the MAC ACL drop-down menu to select the MAC ACL to configure for the WLAN interface.

7. Select either the Inbound or Outbound radio button to define which direction the ACL applies.

8. Refer to the Status field for the current state of the requests made from applet. This field displays error messages if something goes wrong in the transaction between the applet and the switch.

9. Click OK to use the changes to the running configuration and close the dialog.

10.Click Cancel to close the dialog without committing updates to the running configuration.

VPN

This chapter provides detailed feature and configuration information for the VPN features:

• Overview

• Managing VPN in WS5100

• Configuring VPN using CLI

• Special Configuration for Windows XP Client

• Configuring VPN using the WebUI

• Use Case for Remote VPN

• Use Case for Site-to- Site VPN

11.1 OverviewVirtual Private Network (VPN) is a private communications network often used within a company, or by several companies or organizations, to communicate confidentially over a publicly accessible network. VPN message traffic can be carried over a public networking infrastructure, like the Internet, on top of standard protocols.

VPN consists of the following:

• Protected or inside network – This provides physical and administrative security to protect the transmission.

• Outside network or Segment – This is less trustworthy, usually through the Internet.

Generally, a firewall sits between a remote user's workstation or client and the host network or server. As and when the user's client establishes the communication with the firewall, the client may pass authentication data to an authentication service inside the perimeter. A known trusted person can be provided with appropriate security privileges to access resources not available to general users.

VPN client program can be configured such that all IP traffic must pass through the tunnel while the VPN is active, for better security. This ensures all access outside the employers secure network must pass through the same firewall just as it would be the case while physically connected to the office ethernet.


11.1.1 Types of VPNVPNs can be broadly classified as:

• Secured VPNs – This uses cryptographic tunneling protocols to provide:

• Intended confidentiality – blocks snooping and thus preventing packet sniffing.

• Sender authentication – blocks identity spoofing.

• Message integrity – Blocks message alteration to achieve privacy.

Secure VPN protocols include the following:

• IPSec (IP security) , supported in WS5100.

• SSL

• PPTP (point-to-point tunneling protocol).

• L2TP (Layer 2 Tunnelling Protocol), supported in WS5100.

• L2TPv3 (Layer 2 Tunnelling Protocol version 3).

• VPN-Q

• Trusted VPNs – This type of VPN does not use cryptographic tunneling, and instead rely on the security of a single provider's network to protect the traffic.

Trusted VPN protocols include the following:

• Multi-protocol label switching (MPLS).

• L2F (Layer 2 Forwarding).

11.2 Managing VPN in WS5100The WS5100 switch uses IPSec types of VPN, which provides secure tunnels between two peers. You can define:

• Packets that are considered sensitive and must be sent through these secure tunnels.

• The parameters which should be used to protect these sensitive packets, by specifying characteristics of these tunnels.

When the IPSec peer encounters such a sensitive packet, it sets up the appropriate secure tunnel and sends the packet through the tunnel to the remote peer.

Figure 11.1 Creating a Secure Tunnel

These tunnels are sets of Security Associations (SA) that are established between two IPSec peers. The SA’s define which protocols and algorithms to apply to sensitive packets, and also specify the key to be used by the two peers. Security associations are uni-directional and are established per security protocol (AH or ESP).

VPN 11-3

The concept of crypto-map entries is used to configure IPSec security associations. Crypto map entries created for IPSec pull together the various parts used to set up IPSec security associations. Crypto map entries also include transform sets. A transform set is an acceptable combination of security protocols, algorithms and other settings to apply to IPSec protected traffic.

The Internet Key Exchange (IKE) protocol automatically negotiates IPSec SA’s and enables IPSec secure communications without manual pre-configuration.

11.2.1 Traffic Secured in VPNVPN is used to provide secure access between two subnet separated by an unsecured network. The WS5100 switch can be used to configure:

• Site -to-Site VPN — This might be for example one company branch office traffic to another branch office traffic with an unsecured link in between.

• Remote VPN — This gives remote user ability to access their company resources from outside the company premises.

IPSec VPN manages two types of traffic:

1. Control Traffic — This negotiates what type of encryption, authentication and group key algorithms should used for data traffic. This is referred to as IKE negotiation. There are two phases in IKE negotiation:

• Phase 1 – Is used for device authentication and negotiates IKE parameters to be used at local and remote peer.

• Phase 2 – Negotiates what security algorithms, encryption and authentication algorithms should be used for data traffic.

Phase-1 (IKE exchange) happens in plaintext and Phase-2 generally happens in encrypted traffic. In VPN terminology, tunnel established for control traffic is referred to as IKE SA.

2. Data Traffic — The tunnel usually consists of two SA for data traffic, one in each direction. The encryption, security algorithms, authentication, key group to use for data traffic is negotiated between two peers in IKE Phase 2.

11.3 Configuring VPN using CLI Execute the following steps to configure IPSec VPN functionality on the WS5100 switch:

• Configure Peer Properties

• Configure Parameters for Control Traffic using ISAKMP Policy

• Security Parameters for Data Traffic using Transform Set

• Specifying Traffic to Protect using Crypto ACL

• Binding all Parameters to a Remote Peer using Crypto Map

• Activating IPSec to a Remote Peer

• Configuring for Remote VPN Client

NOTE: In addition to the above phases, there is a sub-phase between IKE Phase-1 and IKE Phase-2 that is referred to as mode config. This is used only in case of remote VPN scenario and is used to authenticate remote client and assign private IP pool to the clients.


• Apply Crypto Map Sets to Interfaces

• Monitor and Maintain IPSec

• Network Address Translation in IPSec

The following additional configurations are required to configure a remote VPN:

• Configure on-board or external DHCP and provide public IP address to remote VPN clients when static IP is not being used.

• In authentication data source to use, specify whether to use radius or legacy authentication. If legacy authentication is specified, then configure local user/password on the switch.

• Configure IP address pools for remote VPN (optional).

Refer Configuring for Remote VPN Client for more details.

11.3.1 Configure Peer Properties Different peer require different authentication, encryption and security algorithms. Hence WS5100 Series Wireless Switch supports per peer configuration model.

The following configuration process helps you to specify how peer is authenticated.

1. Use the IP Address of the remote peer you are connecting to. In case of remote VPN, IP address is not known in advance, use 0.0.0.0 as wildcard.

2. Use shared secret/certificates for IKE Phase-1 device authentication

3. Use an identity to recognize the remote peer. Identity can either be an IP address that is present in the IP Header source address field or it can be embedded in the certificate.If certificate is used for authentication, then IP header is present in the server certificate.If it is not possible to use IP address (in a scenario where remote peer IP address is dynamic) then it is best to use DN as an identity for the remote peer. This field is present in the Subject field of the certificate.

4. For example, to create a tunnel to a remote peer 10.1.1.103 using pre-shared key, use

WS5100(config)# crypto isakmp key 12345678 address 10.1.1.103

5. In case of remote VPN, a special IP address of 0.0.0.0 is used to specify that all remote peers share the same secret key.

WS5100(config)# crypto isakmp key 12345678 address 0.0.0.0

11.3.2 Configure Parameters for Control Traffic using ISAKMP Policy As already stated IKE automatically negotiates IPSec SA’s and enables IPSec secure communications without costly manual pre-configuration.

Specifically, IKE provides these benefits:

• Eliminates the need to manually specify all the IPSec security parameters in the crypto maps at both peers.

• Allows you to specify a lifetime for the IKE security association.

• Allows encryption keys to change during IPSec sessions.

• Permits Certification Authority (CA) support for a manageable, scalable IPSec implementation.

• Allows dynamic authentication of peers.

VPN 11-5

If you do not want IKE to be used with your IPSec implementation, you can disable it at all IPSec peers.

To configure IKE, perform the following tasks:

• Create IKE Policies

• Configure Pre-Shared Keys (Optional, depending on IKE parameters)

• Configure CA Certificate (Optional, depending on IKE parameters)

11.3.2.1 Create IKE Polices

An IKE policy must be established on both the peers including the pre-shared key. Multiple IKE policies can be specified with priority. If any of these parameters matches one particular IKE policy, then IKE SA gets established.

You must create IKE policies at each peer. An IKE policy defines a combination of security parameters to be used during the IKE negotiation.

11.3.2.2 Configure Pre-Shared Keys

To configure pre-shared keys, specify the shared keys at each peer.

A given pre-shared key is shared between two peers. At a given peer you could specify the same key to share with multiple remote peers; however, a more secure approach is to specify different keys to share between different pairs of peers.

11.3.2.3 Configure Certificate

To configure certificate, we need to specify the trustpoint that references the CA and the server certificate. Refer to Configuring the Certificate Manager using CLI for further details.

NOTE: IKE must be enabled or disabled at all IPSec peers; you cannot have a mix of IKE-enabled and IKE-disabled peers within your IPSec network you must manually specify all the IPSec security associations in the crypto maps at all peers

Parameter Accepted Values Keyword Default Value

Encryption algorithm 56-bit DES-CBC

3DES-CBC

128-bit AES

192-bit AES

256 bits AES

Des

3Des

Aes

Aes 192

Aes 256

3DES

Hash algorithm SHA-1 (HMAC variant)

MD5 (HMAC variant)

Sha

md5

SHA-1

Authentication method pre-shared keys

ca-certificate

pre-share

rsa-sig

pre-shared

Diffie-Hellman group identifier

768-bit Diffie-Hellman or


1

2

5


Security association's lifetime

can specify any number of seconds

- 86400 seconds (one day)


11.3.2.4 Configuring ISAKMP using CLI

To configure a ISAKMP policy, follow the CLI commands mentioned below:

1. Create an IKE Policy.

WS5100(config)# crypto isakmp policy 10

2. Assign an encryption type to the IKE policy.

WS5100(config-crypto-isakmp)# encryption 3des

3. Assign an hash type to the IKE policy

WS5100(config-crypto-isakmp)# hash md5

4. Assign an authentication type to the IKE policy

WS5100(config-crypto-isakmp)# authentication pre-share

5. Define the lifetime for the IKE policy

WS5100(config-crypto-isakmp)# lifetime 600

To create more than one IKE policy with different priority, follow the CLI commands mentioned below:

1. Create another IKE policy

WS5100(config)# crypto isakmp policy 20

2. Assign different encryption type to the new IKE policy

WS5100(config-crypto-isakmp)# encryption 3des

3. Assign different hash type to the new IKE policy

WS5100(config-crypto-isakmp)# hash sha

4. Assign different authentication type to the new IKE policy

WS5100(config-crypto-isakmp)# authentication rsa-sig

5. Define different lifetime to the new IKE policy

WS5100(config-crypto-isakmp)# lifetime 1200

11.3.3 Security Parameters for Data Traffic using Transform Set A transform set specifies the combination of security algorithm, encryption and authentication to be used for protecting data traffic. To create a transform set select any one option from each of the following security protocol:

• AH Transform — ah-md5-hmac, ah-sha-hmac.

• ESP Encryption Transform — esp-3des, esp-des, esp-aes (-128), esp-aes 192, esp -aes 256

NOTE: If the IKE policies have different IKE Lifetime between two peers, then minimum of them will be selected during IKE negotiation.

VPN 11-7

• ESP Authentication Transform — esp - md5 - hmac, esp - sha - hmac

11.3.3.1 Define Transform Sets

A transform represents a certain combination of security protocols - AH and ESP and algorithms - encryption and authentication type. During the IPSec security association negotiation, the peers agree to use a particular transform for protecting data flow.

Both the AH and ESP protocols implement security services for IPSec. AH provides data authentication and anti-replay services. ESP provides packet encryption and optional data authentication and anti-replay services.

ESP encapsulates the protected data-either a full IP datagram (or only the payload)-with an ESP header and an ESP trailer. AH is embedded in the protected data; it inserts an AH header immediately after the outer IP header and before the inner IP datagram or payload. Traffic that originates and terminates at the IPSec peers can be sent in either tunnel or transport mode; all other traffic is sent in tunnel mode. Tunnel mode encapsulates and protects a full IP datagram, while transport mode encapsulates or protects the payload of an IP datagram.

11.3.3.2 Selecting Appropriate Transform Sets

The following tips may help you select transform sets that are appropriate for your situation:

• If you want to provide data confidentiality, include an ESP encryption transform set.

• If you want to ensure data authentication for the outer IP header as well as the data, include an AH transform set. (Some consider the benefits of outer IP header data integrity to be debatable.)

• If you use an ESP encryption transform set, also consider including an ESP authentication transform set.

• If you want data authentication (either using ESP or AH), you can choose from the MD5 or SHA (HMAC keyed hash variants) authentication algorithms. The SHA algorithm is generally considered stronger than MD5 but is slower.

Some transform sets might not be supported by the IPSec peer. With manually established security associations, there is no negotiation with the peer, so both sides must specify the same transform set.

If you change a transform set definition, the change is only applied to crypto map entries that reference the transform set. Any change done on the transform-set will delete the existing SA’s.

11.3.3.3 Configuring transform-set using CLI

To create a transform sets that specifies how traffic is to be protected in the Crypto ACL.,follow the CLI commands mentioned below:

1. Create an IPSec transform set by selecting the security protocol.

WS5100(config)# crypto ipsec transform-set <name> esp-3des

NOTE: You can also configure the mode for data traffic. AH and ESP authentication cannot be used together. The mode for data traffic can be either

• Transport — This mode protects only the payload of an IP datagram.• Tunnel — This mode protects a full IP datagram.


2. Create a mode for data traffic.

WS5100(config-crypto-ipsec)# mode tunnel

11.3.3.4 Set Global Lifetimes for IPSec Security Associations

The security association (and corresponding keys used to encrypt) will expire according to whichever occurs sooner, either after the number of seconds has passed (specified by the seconds keyword) or after the amount of traffic in kilobytes has passed (specified by the kilobytes keyword). A new security association is negotiated before the lifetime threshold of the existing security association is reached, to ensure that a new security association is ready for use when the old one expires.

You can change the global lifetime values which are used when negotiating new IPSec security associations. (These global lifetime values can be overridden for a particular crypto map entry).

These lifetimes only apply to security associations established via IKE. Manually established security associations do not expire.

There are two lifetimes: a “timed” lifetime and a “traffic-volume” lifetime. A security association expires after the first of these lifetimes is reached. The default lifetimes are 3600 seconds (one hour) and 4,608,000 kilobytes.

If you change a global lifetime, the new lifetime value will not be applied to currently existing security associations, but will be used in the negotiation of subsequently established security associations. If you wish to use the new values immediately, you can clear all or part of the security association database.

11.3.4 Specifying Traffic to Protect using Crypto ACL The purpose of crypto ACL is to define what traffic should be protected. Basically crypto ACL is an extended ACL with permit statements.

The following rule is implemented for incoming traffic:

• If the traffic matches a Crypto ACL, the switch applies the information in the appropriate crypto map entry, to protect it.

• If the traffic does not match a Crypto ACL entry, the switch forwards the traffic normally.

Do not use the keyword any in Crypto ACL for source or destination address as it treats all traffic from the source/destination as protected traffic. This can cause connectivity problems. Be as specific as possible about the traffic to be protected. This also reduces the encryption and decryption duration of traffic on the switch.

If the interface is enabled for NAT for outgoing traffic, then NAT is done first and then ACL is applied. Thus, the Crypto ACL should have NATed address in the source address field of the ACL statement. For inbound traffic, the router handles the IPSec part first and then NAT (if necessary).

NOTE: Set mode to tunnel if you creating a transform set for site-to-site VPN.Set mode to transport if you are using remote VPN with WindowXP client.

NOTE: Unlike the firewall ACL, the Cryto ACL is applied to a crypto map and not on the interface. The Crypto ACL does not take affect unless the crypto map set is applied to an interface.

NOTE: NAT and IPSec cannot be used together in WS5100.

VPN 11-9

Follow the CLI commands mentioned below, to configure IPSec traffic between local subnet 10.1.1.0/24 and remote subnet 192.168.0/24.

1. Create an Extended ACL

WS5100(config)#ip access-list extended 101

2. Configure the local subnet and the remote subnet to allow IP Sec traffic between them.

WS5100(config-ext-nacl)# permit ip 10.1.1.0/24 192.168.0/24

To establish an IPSec, the local subnet must always appear before remote subnet.

For more details on configuring ACLs, refer to Configuring ACL using CLI

11.3.5 Binding all Parameters to a Remote Peer using Crypto Map Use crypto-map entries to configure IPSec SA’s. Create one map entry for every remote peer. Crypto map entries created for IPSec extract various parts used to set up IPSec security associations, including:

• Crypto access list defines what traffic should be protected and what traffic should not be protected. For example an access list can be created to protect traffic between Subnet A and Subnet Y or between Host A and Host B. The particular crypto map entry will reference the specific access list that defines whether IPSec processing is to be applied to the traffic matching the permit in the access list.

• Where IPSec-protected traffic should be sent (who the remote IPSec peer is)

• The local address to be used for the IPSec traffic (this is determined automatically) when the crypto map is applied on an interface.

• What IPSec security and algorithms should be applied to this traffic (selecting transform set)

• How security associations are established - manually or via IKE

• If IKE is not used, then manual keys needs to be specified

• The lifetime of the data connections.

• Whether client configuration mode is for remote VPN or site-to-site VPN. If the configuration is for remote VPN, then specify whether the client uses IPSec L2TP (used with Windows VPN) or X-auth.

• A crypto map set consists of multiple crypto map entries.

The policy described in the crypto map entries is used during the negotiation of security associations. For IPSec to succeed between two IPSec peers, both peers' crypto map entries must contain compatible configuration statements.

CAUTION: Using any any as both source and destination subnet renders the box inaccessible via telnet/ssh and also site-site does not work. Hence, this should not be used. !


You can create Cypto Map Set if:

• Connection is required for multiple remote peers OR

• Different types of protection is required to the same peer

A crypto map entry has sequence number associated with it.

Follow the CLI commands mentioned below to create a Crypto Map:

1. Create a crypto map with sequence number10 for remote peer 10.1.1.103 using IKE.

WS5100(config)# crypto map Test1 10 ipsec-isakmp

2. Configure the remote peer address.

WS5100(config-crypto-map)# set peer 10.1.1.103

3. Specify the Crypto ACL to use.

WS5100(config-crypto-map)# match address 101

4. Define the transform set for the data traffic.

WS5100(config-crypto-map)# set transform-set transform1

To create multiple crypto maps, follow the CLI commands mentioned below:

1. Create another crypto map with sequence number20 for remote peer 10.1.1.103 using IKE.

WS5100(config)# crypto map Test2 10 isakmp

2. Configure the remote peer address.


3. Specify the Crypto ACL to use.


4. Define the transform set for the data traffic.

WS5100(config-crypto-map)# set transform-set transform2

11.3.6 Activating IPSec to a Remote Peer Crypto map set must applied to an VLAN interface, so that IKE and IPSec SA can be applied on traffic that matches the Crypto ACL.

If no crypto map set is applied to an interface, then the interface allows both incoming and outgoing traffic by default. If a crypto map gets applied and a traffic does not match the ACL, then the traffic is passed in plaintext packet.

To apply the crypto map to an interface, follow the CLI commands mentioned below:

1. Create an interface.

WS5100(config)# interface vlan1

2. Assign the crypto map to the interface.

WS5100(config-if)# crypto map Test1

NOTE: For site-site VPN, the interface on which crypto map is applied should represent the WAN subnet. For remote VPN, the interface should represent the local subnet.

VPN 11-11

11.3.7 Configuring for Remote VPN Client When the client initiates a connection with the VPN server on our switch, the “conversation” that occurs between the peers consists of device authentication via Internet Key Exchange (IKE), followed by user authentication using IKE Extended Authentication (Xauth), push client relate configuration like IP address, DNS, WINS using Mode Configuration, and IPsec security association (SA) creation. An overview of this process is as follows:

1. The client attempts to establish an IKE SA between its public IP address and the public IP address of the switch where the VPN server is running.

2. After the IKE SA is successfully established, and if the switch is configured for Xauth, the client waits for a "username/password" challenge and then responds to the challenge of the switch.

3. The information that is entered is checked against authentication entities (either configured on the switch or using radius server).

4. If the switch indicates that authentication was successful, the client requests further configuration parameters from the switch. The remaining system parameters (for example, IP address, DNS, WINS) are pushed to the client at this time using Client Mode Configuration.

5. After the client has received the configuration it negotiates an IPSec SA with the gateway using the private address

The configuration for client related parameters is done using client mode configuration. This client configuration group is then set in cryto map entry that will be assigned on an interface.

11.3.7.1 Configuring Remote VPN using CLI

The following additional CLI configurations are required for remote VPN configuration:

1. Specify the private address pool, also known as mode-config address.You can also configure address pool spanning different range.

WS5100(config)# ip local pool lo 192.168.0.2 hi 192.168.0.10

2. Specify the authentication type – either RADIUS or local authentication.

WS5100(config)# vpn-authentication [radius|local]

• For RADIUS authentication, you can configure upto two radius servers.

WS5100(config)# aaa vpn-authentication primary 10.1.1.103 key motorola

WS5100(config)# aaa vpn-authentication secondary 10.1.1.105 key motorola123

• Create username/password if you use local authentication

WS5100(config)# local username harry password motorola123

WS5100(config)# local username john password motorola234

3. Specify the dns/wins for the remote client.

WS5100(config)# crypto isakmp client configuration group default

WS5100(config-crypto-group)# dns 10.1.1.1

WS5100(config-crypto-group)# wins 10.1.1.1


4. Create an Extended ACL.

WS5100(config)#ip access-list extended 101

Configure the local subnet and the remote subnet to allow IP Sec traffic between them.

WS5100(config-ext-nacl)# permit ip 10.1.1.0/24 any


5. Specify dynamic crypto map. Use the keyword dynamic during crypto map entry. This indicates that this crypto map is for remote VPN.

WS5100(config)# crypto map anurag 30 ipsec-isakmp dynamic


<note special use of wildcard here>


WS5100(config-crypto-map)# set transform-set esp3des

6. Specify the remote client type . There are two types of remote clients – Pure IPSec VPN client and Windows IPSec Client.

• Pure IPSec VPN client — The remote-type should be set to xauth under crypto map context.By default, crypto map are set to xauth remote-type.

WS5100(config-crypto-map)#set remote-type xauth

• Windows IPSec Client — Supports IPSec/L2TP protocol

WS5100(config-crypto-map)#set remote-type ipsec-l2tp

11.3.8 Apply Crypto Map Sets to Interfaces You need to activate a crypto map, it needs to be applied to an interface. This interface is typically the RON/external/public interface of the switch.Applying the crypto map set to an interface instructs the switch to evaluate all the interface's traffic against the crypto map set and to use the specified policy during connection or security association negotiation on behalf of traffic to be protected by crypto.

If no crypto map is applied to an interface, then by default all traffic incoming and outgoing on that interface is allowed. If a crypto map gets applied and a traffic does not match the ACL, then the traffic is passed in plaintext packet.

11.3.9 Monitor and Maintain IPSec Any re-configuration changes will delete exisitng SA’s.

11.3.10 Network Address Translation in IPSec NAT is most often used to convert private address into routable public addresses. With static NAT each private address maps to one public address. In a dynamic/hide NAT both IP address and Port are mapped, allowing many privately addressed hosts to share one public IP address. Check sums must be recomputed and embedded IP addresses carried in application protocols like FTP may be translated. There is a problem when NAT is applied before IPSec.

NOTE: It is not possible to have both Windows XP and pure IPSec client on the same subnet. The work-around is to have these clients on different subnets.

VPN 11-13

• The IPSec Authentication Header protects entire IP packets including IP headers, against modification in transit. NAT will modify the IP header so inherently NAT is incompatible with AH.

• The IPSec Encapsulating Security Payload (ESP) usually encrypts IP packets. NAT modifies TCP and UDP ports, but clearly can't do so when the packet is encrypted. Hence NAT is incompatible with ESP.

The solution to over come this problem is UDP encapsulation. In this approach the IPSec packet is encapsulated in an UDP/IP header which lets NAT do their thing. This works for IPSec ESP. ESP encapsulated packets are exchanged between IKE peers. The peers must support the same method of UDP ESP encapsulation. IKE peers will exchange a known value to determine whether they both support NAT traversal (UDP Encapsulation). if the IKE peers agree, they use IKE probes or discovery payloads to determine whether NAT is being applied at some point between them. Only when IKE peers agree and NAT is encountered UDP encapsulation is used. IKE peers communicate over UDP port 500, UDP encapsulated ESP communicates on the same port. It ensures that IKE and UDP encapsulated ESP packets are subjected to the same mid-stream address translation. The sender indicates that an encapsulated packet follows by setting the first 8 bytes of UDP payload to zero. These bytes overlap the IKE initiator cookie field, for which zero is an invalid value. Thus, implementations can use these bytes to discriminate between the IKE and UDP-encapsulated ESP arriving on port 500. Because only peers that agree will ever send UDP-encapsulated ESP packets.

In hide NAT private IP address and source port are temporarily bound to a shared public IP address and a used port. A timeout dissolves this binding after seconds or minutes of inactivity, enabling hide NAT pool reuse. IPSec VPN's protect traffic exchanged between mutually authenticated endpoints. For NAT traversal to work, end points cannot be dynamically remapped mid-session. To preserve dynamic NAT bindings for the life of an IPSec session, a one byte UDP “keepalive” may be used.

11.4 Special Configuration for Windows XP ClientFollow the CLI commands mentioned below, to configure an Windows XP client to VPN gateway. This is in addition to what is described in Configuring for Remote VPN Client. Follow the steps mentioned below to configure the transform-set:

1. The transform-set to use should be set to esp-3des esp-sha-hmac and mode should be set to transport. This is the transform-set that Windows XP client uses and is pre-configured. If this is not set correctly on the switch then algorithm/encapsulation mismatch error will appear during IPSec negotiations.

WS5100(config)#crypto ipsec transform-set xyz esp-3des esp-sha-hmac

WS5100(config-crypto-ipsec)#mode transport

2. Under crypto map, set the remote-type to ipsec-l2tp. An e.g. is given below.

WS5100(config)#cr map mode 10 ipsec-isakmp dynamic


WS5100(config-crypto-map)#set transform-set xyz

11.4.1 Windows XP VPN Client Configuration To configure VPN Client running on Windows XP, you need to set:

• VPN connection and

NOTE: aes-192 and aes-256 is not supported with Windows XP client.


• Pre - shared key

Follow the steps below to configure the VPN Client in Windows XP:

1. From your computer, click Start > Control Panel > Network Connection and then click on Create a new connection.

2. Click on Next button in New Connection Wizard.

VPN 11-15

3. Select Connect to the network at my workplace option and click on the Next button to proceed further.

4. Select the Virtual Private Network connection and click on the Next button to proceed further.

5. Type a descriptive name for your VPN connection and click on Next button.


6. Select Do not dial the initial connection option and click on the Next button.

7. Type either a host name of IP address of the computer to which you wish to connect and click on the Next button.

8. Choose whether you want this connection to be shared by all users (Anyone's use) of this computer, or only for yourself (My use only). Click Next to conclude the creation of VPN client.

VPN 11-17

9. Click on the Finish button to complete the creation of VPN Client on a Windows XP machine.

Follow the steps below to configure the Pre - shared key in Windows XP:

1. From your computer, click Start > Control Panel > Network Connection.

2. Under the Virtual Private Network section, right click on the VPN icon and click on Properties button.

3. Click on the Security tab.


4. Click on the IPSec Setting button.Click to select Use pre-shared key for authentication checkbox and enter the pre-shared key in the text field. This value must match the pre-shared kay value that is entered on the VPN-based server.

11.5 Configuring VPN using the WebUITo configure VPN using Web UI, follow the steps mentioned below:

1. Create an IKE (ISAKMP)Peer using Security > IKE Setting from the main menu tree. By default the IKE Settings window displays the Configuration tab.

NOTE: IPSec Setting button is disabled if PPT VPN (Point-to-Point VPN) is selected as Type of VPN. A pre-shared key can only be configured if it is set to L2TP or Automatic. Click on Networking Tab and select either Automatic or L2TP as type of VPN.

VPN 11-19

a. Click on the Add button.

• Select the Peer IP Address option to associate an IP address with the specific tunnel used by a group of peers.

• Enter a Key. The key is used by the peer to interact with other peers within the tunnel.

• Select Aggressive Mode checkbox if required. Aggressive mode enables you to configure Internet Key Exchange (IKE) pre-shared keys as Radius tunnel attributes for IP Security (IPSec) peers.

• Click on OK button.

b. The new IKE peer is added and displayed in the Pre-shared Keys table.

For more details on IKE Peer configuration, refer to Create IKE Polices on page 11-5.


2. Create an IKE (ISAKMP) policy using Security > IKE Setting from the main menu tree. Select the IKE Policies tab from the IKE Settings window. The table displays the default IKE Policy values.


• Define the Priority for the IKE policy. The available range is from 1 to 65,543, with 1 being the highest priority value.

• Set the Encryption method used to protect the data transmitted between peers.

• Define the Hash algorithm used to ensure data integrity. The hash value validates a packet that comes from its intended destination, and has not been modified in transit.

• Set the Authentication Type used to validate the identity of each peer. Pre-shared keys do not scale accurately with a growing network but are easier to maintain in a small network.

• Define an integer for the SA lifetime. The default is 60 seconds. With longer lifetimes, security

VPN 11-21

defines future IPSec security associations quickly. Encryption strength is great enough to ensure security without using fast rekey times.

• Set the DH Group identifier. IPSec peers use the defined value to derive a shared secret without transmitting it to one another.


b. The new IKE Policy is added to the table.

For more details to configure an IKE Policy, refer Create IKE Polices on page 11-5

3. Create an IPSec transform set using Security > IPSec VPN from the main menu tree. By default, the IPSec VPN window displays the Configuration tab.



• Create a Name describing this new transform set.

• Define the AH Transform Authentication scheme or ESP Encryption Transform scheme.

• Define the ESP Authentication Transform scheme.

• Define the Transform Set Mode used with the transform set. The mode is either Tunnel or Transport.

• Click OK.

b. The transform set created above is added to the table in the Transform Sets window.

For more details to create an IPSec Transform Set, refer Activating IPSec to a Remote Peer on page 11-10.

VPN 11-23

4. Create an Extended ACL using Security > ACLs from the main menu tree. By Default, the ACLs window displays the Configuration tab.

a. In the ACLs section, click on the Add button.

• Select Extended IP List from the ACL Type drop down box.

• Enter a numeric index name for the Extended ACL in the ACL ID field.



b. In the main ACLs window, select the Extended ACL, created above, from the ACLs section and click on the Add button in the Associated Rules section.

• Enter a Precedence (priority) value between 1 and 500. The rules within an ACL will be applied to packets based on their precedence value. Rules with higher precedence are always applied first

• Select permit from the Operation drop-down menu to define a permit designation for the ACL.

• Select ip from the Protocol drop down box.

• You can select either host or any subnet from the Source Wildcard/Mask drop down box. Use the Source Address field to enter the IP address of the host or subnet from where the packets are sourced.

• You can select either host or any subnet from the Destination Wildcard/Mask drop down box. Use the Destination Address field to enter the IP address of the host or subnet from where the packets are delivered.


VPN 11-25

c. The ACL window will now have the following content:

For more details on configuring Extended ACLs, refer Configuring ACL using CLI on page 10-6.

5. Create a Crypto Map entry using Security > IPSec VPN from the main menu tree. A crypto map binds the ISAKMP Peer, IPSec Transform Set and the Extended ACL. Select Crypto Map tab which by default displays the Crypto Map Entries tab.


a. Click on Add button to define the attributes of a new crypto map.

• Assign a Seq # (sequence number) distinguishes one from the other. The sequence number determines its priority among the other crypto maps. The lower the number, the higher the priority.

• Assign the crypto map a Name to differentiate from others with similar configurations.

• Use the None, Domain Name or Host Name radio buttons to select and enter the fully qualified domain or host name of the host exchanging identity information.

• Define a SA Lifetime (secs) to define an interval (in seconds) that (when expired) forces a new association negotiation.

• Define a SA Lifetime (Kb) to time out the security association after the specified amount of traffic (in kilobytes) has passed through the IPSec tunnel using the security association.

• Use the ACL ID drop-down menu to permit a crypto map data flow using the permissions within the selected ACL. This will display the Extended ACL created in step 4 above.

• Use the PFS drop-down menu to specify a group to require perfect forward secrecy (PFS) in requests received from the peer.

• Use the Mode drop-down menu to specify a mode of Main or Aggressive. Aggressive mode enables you to configure pre-shared keys as Radius tunnel attributes for IP Security (IPSec) peers.

• Select SA Per Host checkbox to create multiple SAs per host for added security.

• The Mode Config checkbox option is used to configure a remote VPN. This enables the Remote Type field in the Add Crypto Maps dialog box.

• Click on OK button to save the new crypto map and display it within the Crypto Map tab.

For more details on configuring a IPSec Transform set, refer Specifying Traffic to Protect using Crypto ACL on page 11-8.

VPN 11-27

6. Create a crypto map peer using Security > IPSec VPN from the main menu tree. Select Crypto Map > Peers tab.

a. Click on Add button to create a new peer.

• Enter the Seq # for the new peer. This seq # should be the same as used when creating the crypto map Entry in step 5. The sequence number determines its priority among crypto maps. The lower the number, the higher the priority.

• Enter the Crypto Map Name created in step 5.

• Enter the IKE Peer key created in Step 1. This is used with the crypto map to build an IPSec security association.


• Click on OK button to save the configuration of the new crypto map peer.

For more details on configuring a IPSec Transform set, refer Activating IPSec to a Remote Peer on page 11-10.

7. Create a crypto map transform set using Security > IPSec VPN from the main menu tree. Select Crypto Map > Transform Sets tab.

VPN 11-29

a. Click on Add button to create an crypto map transform set.

• Enter the Seq # for the new transform set. This seq # should be the same as used when creating the crypto map entry in step 5. The sequence number determines its priority among crypto maps. The lower the number, the higher the priority.

• Enter the Crypto Map Name created in step 5.

• Enter the IP Sec Tranform set key created in Step 3.

• Click on OK button to save the configuration of the new crypto map transform set.

For more details on configuring a IPSec Transform set, refer to Configuring transform-set using CLI on page 11-7.


8. Create a crypto map interface using Security > IPSec VPN from the main menu tree. Select Crypto Map > Interfaces tab. This assigns a VLAN interface to the crypto map created in earlier steps. The table displays the crypto map binded values.

a. Select the list displayed in the table and click on Assign Interface button to assign an VLAN interface to this crypto map.

For more details on configuring crypto map interfaces, refer Specifying Traffic to Protect using Crypto ACL on page 11-8.

VPN 11-31

11.6 Use Case for Remote VPNLet's take an example of a mobile unit connected to a switch. The use case is that it wants an access to the corporate (trusted network) securely using our IPSec VPN functionality.

Figure 11.2 Configuring VPN

In the Figure 11.2, a Motorola client is associated to a WLAN (say wlan1) that is attached to vlan2 on the switch. vlan2 is on a subnet10.1.1.x and is running a DHCP Server that dishes out IP addresses for this subnet. Also the corporate is on vlan3 of the switch, which has 192.168.0.x subnet.

The client being associated to wlan1 has got an IP address of 10.1.1101x (lets say) and wants to access the 192.168.0.x network securely.

In case the client is VPN enabled, it initiates a connection with the VPN server on our switch, the “conversation” that occurs between the peers consists of device authentication via Internet Key Exchange (IKE), followed by user authentication using IKE Extended Authentication (Xauth), push client relate configuration (using Mode Configuration), and IPsec security association (SA) creation.

Depending on the switch IPSec configuration (as discussed in the previous sections), the client establishes an IKE SA and if the switch is configured for Xauth, the client waits for a "username/password" challenge and then responds to the challenge of the switch.

If the switch indicates that authentication is successful, the client requests further configuration parameters from the switch. At this stage the private IP address (mode-config) is pushed to the client from a private address pool, configured for remote VPN clients. Following this, IPsec SA’s are created and the connection is complete.

Once the client has got a virtual IP, further packets from the client within the IPSec tunnel are routed to the corresponding VLAN interface (in our case vlan3) and hence the client gets the access to the corporate. The thing to note is that the IPSec tunnel is only between the client and the switch. After that the packets on the trusted side are sent without any encryption.


The use case described above can be configured with the following CLI commands:

1. Create and configure a WLAN.

WS5100(config)#

WS5100(config)#wireless

WS5100(config-wireless)#wlan 2 enable

WS5100(config-wireless)#wlan 2 ssid MONARCH2

WS5100(config-wireless)#wlan 2 vlan 2

2. Create and configure a DHCP.

WS5100(config)#ip dhcp pool vlan2


WS5100(config-dhcp)#default-router 10.1.1.1


3. Create and configure a VLAN interface named vlan2.


WS5100(config-if)#ip address 10.1.1.1/24

4. Create and configure another VLAN interface named vlan3.

WS5100(config)#interface vlan 3

WS5100(config-if)#ip address dhcp

Use the CLI commands below to confiugre IPSec VPN on the Ws5100 switch:

1. Create an Extended ACL.

WS5100(config-ext-nacl)#ip access-list extended 101

2. Configure the local subnet and remote subnet as interesting traffic.



3. Configure private pool address.

WS5100(config)# ip local pool lo 192.168.0.2 hi 192.168.0.10

4. Specify DNS/WINS for the remote client.

WS5100(config)#crypto isakmp client configuration group default

WS5100(config-crypto-group)#dns 10.1.1.1

WS5100(config-crypto-group)#wins 10.1.1.1

5. Specify the authentication type.

WS5100(config)# aaa vpn-authentication local

WS5100(config)# local username harry password symbol123

NOTE: The CLI configuration shown below are for IPSec-L2TP connection over an mobile unit. Use a windows default client for this configuration.

VPN 11-33

6. Create a transform set.

WS5100(config)#crypto ipsec transform-set windows esp-3des esp-sha-hmac

WS5100(config-crypto-ipsec)#mode transport

7. Specify dynamic crypto map.

WS5100(config)#crypto map TestMap 30 ipsec-isakmp dynamic

WS5100(config-crypto-map)#set peer 0.0.0.0

WS5100(config-crypto-map)#match address 101

WS5100(config-crypto-map)#set transformset windows


8. Apply the cryto map to interface vlan2.


WS5100(config-if)cryto map TestMap

9. On successful connection the XP client will get a virtual IP address.

11.7 Use Case for Site-to- Site VPN The intranets use unregistered addresses and are connected over the public Internet by site-to-site VPN. In this scenario NAT is required for the connections to the public Internet. However NAT is not required for traffic between the two intranets, which can be transmitted using a VPN tunnel over the public Internet.

NOTE: Configure the default WIndows-XP client on the mobile unit, refer to Special Configuration for Windows XP Client on page 11-13, on completion of the above configuration and connect to the WS5100 Switch.

NOTE: To access external trusted hosts, you need to either:

• change the default gateway on these trusted hosts to the WS5100s VLAN3 interface IP (address) OR

• Add a route entry.


The site-to-site VPN allows branch office mobility controllers to connect back to the central office using a secure, encrypted tunnel, for all site-to-site traffic. This allows a wired LAN in the branch office to be bridged directly to the central site while marinating the full security.

The use case described above needs configuration of two WS5100 switches. It can be configured with the following CLI commands:

1. Configuration required on WS5100 Switch 1:

a. Create an extended ACL. This is used to define the tunnel used by the traffic.

WS5100(config)#access-list 150 permit ip 12.1.1.0/24 13.1.1.0/24 rule-precedence

b. Create and configure the ISAKMP parameters.

WS5100(config)#crypto isakmp keepalive 10

WS5100(config)#crypto isakmp key SYMBOLAD address 15.1.1.20

WS5100(config)#crypto ipsec security-association lifetime kilobytes

4608000

c. Create and configure ISAKMP policy.

WS5100(config)#crypto isakmp policy 199

WS5100(config-crypto-isakmp)#encryption aes

WS5100(config-crypto-isakmp)#hash sha

WS5100(config-crypto-isakmp)#authentication pre-share

WS5100(config-crypto-isakmp)#group 5

WS5100(config-crypto-isakmp)#lifetime 9496

d. Create and configure IPSec transform set.

WS5100(config)#crypto ipsec transform-set TFSET ah-sha-hmac esp-aes

WS5100(config-crypto-ipsec)#mode tunnel

VPN 11-35

e. Create and configure a crypto map.

WS5100(config)#crypto map THIRDMAP 435 isakmp



WS5100(config-crypto-map)#set transformset TFSET

WS5100(config-crypto-map)#set security-association lifetime seconds 3600

f. Associate the crypto map with a VLAN interface.



WS5100(config-if)#crypto map THIRDMAP

WS5100(config-if)#interface vlan2100


WS5100(config-if)#ip route 0.0.0.0/0 11.1.1.2

2. Configuration required on WS5100 Switch 2:

a. Create an extended ACL. This is used to define the tunnel used by the traffic.

WS5100(config)#access-list 155permit ip 13.1.1.0/24 12.1.1.0/24 rule-

precedence 1

b. Create and configure the ISAKMP parameters.

WS5100(config)#crypto isakmp keepalive 10

WS5100(config)#crypto isakmp key SYMBOLAD address 11.1.1.10

WS5100(config)#crypto ipsec security-association lifetime kilobytes

4608000

c. Create and configure ISAKMP policy.

WS5100(config)#crypto isakmp policy 100

WS5100(config-crypto-isakmp)#encryption aes

WS5100(config-crypto-isakmp)#hash sha

WS5100(config-crypto-isakmp)#authentication pre-share

WS5100(config-crypto-isakmp)#group 5

WS5100(config-crypto-isakmp)#lifetime 9496

d. Create and configure IPSec transform set.

WS5100(config)#crypto ipsec transform-set TFSET ah-sha-hmac esp-aes esp-sha-hmac

WS5100(config-crypto-ipsec)#mode tunnel

e. Create and configure a crypto map.

WS5100(config)#crypto map THIRDMAP 435 isakmp




WS5100(config-crypto-map)#set transformset TFSET

WS5100(config-crypto-map)#set security-association lifetime seconds 3600

f. Associate the crypto map with a VLAN interface.



WS5100(config-if)#crypto map THIRDMAP

WS5100(config-if)#interface vlan2100


WS5100(config-if)#ip route 0.0.0.0/0 15.1.1.2

Technical Support

Motorola provides its customers with prompt and accurate customer support. Use the Motorola Support Center as the primary contact for any technical problem, question or support issue involving Motorola products.

If the Motorola Customer Support specialists cannot solve a problem, access to all technical disciplines within Motorola becomes available for further assistance and support. Motorola Customer Support responds to calls by email, telephone or fax within the time limits set forth in individual contractual agreements.

When contacting Motorola Customer Support, please provide the following information:

• serial number of unit

• model number or product name

• software type and version number.

North American Contacts

Inside North America:

Motorola, Inc.One Symbol Plaza Holtsville, New York 11742-1300 Telephone: 1-631-738-2400/1-800-SCAN 234 Fax: 1-631-738-5990

Motorola Support Center (for warranty and service information):

telephone: 1-800-653-5350 fax: (631) 738-5410 Email: [email protected]

International Contacts

Outside North America:

Motorola, Inc.Symbol Place Winnersh Triangle, Berkshire, RG41 5TP United Kingdom 0800-328-2424 (Inside UK)+44 118 945 7529 (Outside UK)

A-2 WS5100 Series Switch Migration Guide

Web Support Sites

MySymbolCare

http://www.symbol.com/services/msc/msc.html

Symbol Services Homepage

http://symbol.com/services

Symbol Developer Program

http://devzone.symbol.com

Additional Information

Obtain additional information by contacting Symbol at:

1-800-722-6234, inside North America

+1-516-738-5200, in/outside North America

http://www.symbol.com/

MOTOROLA INC.1303 E. ALGONQUIN ROADSCHAUMBURG, IL 60196http://www.motorola.com

72E-100960-01 Revision AJune 2007

ws5100 series switch migration guide

Documents