Листовка для HP ProCurve Wireless Edge Services xl Module J9001A

2

Introduction

This white paper will walk you through the configuration steps for setting up the ProCurve Wireless Edge 
Service Module (5400 series) to use Layer 3 Access Control Lists (ACLs) on the uplink physical interface.

WESM OS Versions covered:
• WT.01.15 or later (5400 Series zl)

Access Control lists overview

What does an ACL do
An Access Control List or ACL in short, allows you to control wireless users’ network rights. You can configure 
ACLs for purposes such as:
• Limiting certain groups of wireless users to Internet access only
• Permitting certain groups of wireless users access to a limited list of network servers
• Limiting certain groups of wireless users to certain types of applications
• Restricting access to a particular private server to a select group of users only

Types of ACLs
The WESM supports two types of ACLs: IP or Layer 3 ACLs and MAC or Layer 2 ACLs. Each is supported by 
two subtypes: standard and extended. You can check the WESM manual for more details.

How is an ACL created
The WESM lets you create ACLs in the Web UI or in the CLI, you can refer to the manual for a detailed step by 
step explanation of how these ACLs are created.

Application scenarios

When configuring a set of ACLs on the uplink port of your WESM, there are two main scenarios that you may 
encounter. First is that the wired servers or devices you want to restrict the traffic from are in the same VLAN as 
the wireless clients. The other scenario is when the wired servers or devices are on a different VLAN than the 
wireless clients.

For both cases you should confirm that traffic from the wireless clients is received on the wired servers, and vice 
versa, to test appropriately with a ping. The set up required for communication from devices in one VLAN to 
another on a different VLAN is out of the scope of this document.

Setting it up

Before proceeding with the set up of the Layer 3 ACLs on the uplink port, there are a few things that you need 
to know.

It is important to know that traffic flowing through the uplink port is checked by the ACLs in the inbound 
direction, meaning traffic flowing from the chassis to the WESM. For example, if you have a wireless laptop 
contacting a web server on your wired network via http, the request from the laptop to the web server won’t 
be checked to see if it matches any ACL on the uplink port. Rather, the response from the web server to the
laptop will be checked against the ACL. So, to correctly apply an ACL on the uplink port you need to invert the 
destination and source hosts (if you are applying the ACL to specific hosts) or invert the destination and source 
ports (if your ACL is port oriented).

In addition, when applying L3 ACLs on the uplink port, you also need to apply a L2 ACL (in other words, a 
MAC ACL). This is because the ACL engine used for physical interfaces includes an implicit “deny any” L2 ACL 
rule that will effectively deny any L2 packets like ARP traffic. For the L3 ACL to work properly you need to set
an extended L2 ACL that doesn’t specify any host, but instead specifies a protocol. Use caution if you match an 
MAC ACL with all the traffic of a higher level, this causes ACLs of a higher level to not take effect, for instance, 
if you don’t select a protocol or select IPv4. For the following examples we are going to use ARP (Address
Resolution Protocol) as the protocol for the L2 ACL that will accompany all the L3 ACLs set on the uplink port.
Setting “any” as the source and destination hosts, we can avoid selecting specific hosts which can cause all the 
hosts that aren’t specified to hit the implicit deny rule and derail their network traffic destination.