Every client in an Arubauser-centric network is associated with a user role, which determines the client’s network privileges, how often it must re-authenticate, and which bandwidth contracts are applicable. A policy is a set of rules that applies to traffic that passes through the Arubacontroller. You specify one or more policies for a user role. Finally, you can assign a user role to clients before or after they authenticate to the system.
This chapter describes assigning and creating roles and policies using the ArubaOSCLI or WebUI. Roles and policies can also be configured for WLANs associated with the “default” ap-group via the WLAN Wizard: Configuration >Wizards > WLAN Wizard. Follow the steps in the workflow pane within the wizard and refer to the help tab for assistance.
This chapter describes the following topics:
-
This chapter describes configuring firewall policies and parameters that relate to IPv4 traffic. See Chapter 32, “IPv6 Client Support” for information about configuring IPv6 firewall policies and parameters.
A firewall policy identifies specific characteristics about a data packet passing through the Arubacontrollerand takes some action based on that identification. In an Arubacontroller, that action can be a firewall-type action such as permitting or denying the packet, an administrative action such as logging the packet, or a quality of service (QoS) action such as setting 802.1p bits or placing the packet into a priority queue. You can apply firewall policies to user roles to give differential treatment to different users on the same network, or to physical ports to apply the same policy to all traffic through the port.
Firewall policies differ from access control lists (ACLs) in the following ways:
-
Firewall policies are stateful, meaning that they recognize flows in a network and keep track of the state of sessions. For example, if a firewall policy permits telnet traffic from a client, the policy also recognizes that inbound traffic associated with that session should be allowed.
-
Firewall policies are bi-directional, meaning that they keep track of data connections traveling into or out of the network. ACLs are normally applied to either traffic inbound to an interface or outbound from an interface.
-
Firewall policies are dynamic, meaning that address information in the policy rules can change as the policies are applied to users. For example, the alias userin a policy automatically applies to the IP address assigned to a particular user. ACLs typically require static IP addresses in the rule.
You can apply IPv4 and IPv6 firewall policies to the same user role. See Chapter 32, “IPv6 Client Support” for information about configuring IPv6 firewall policies.
Access control lists (ACLs) are a common way of restricting certain types of traffic on a physical port. ArubaOS provides the following types of ACLs:
-
Standard ACLs permit or deny traffic based on the source IP address of the packet. Standard ACLS can be either named or numbered, with valid numbers in the range of 1-99 and 1300-1399. Standard ACLs use a bitwise mask to specify the portion of the source IP address to be matched.
-
Extended ACLs permit or deny traffic based on source or destination IP address, source or destination port number, or IP protocol. Extended ACLs can be named or numbered, with valid numbers in the range 100-199 and 2000-2699.
-
MAC ACLs are used to filter traffic on a specific source MAC address or range of MAC addresses. Optionally, you can mirror packets to a datapath or remote destination for troubleshooting and debugging purposes. MAC ACLs can be either named or numbered, with valid numbers in the range of 700-799 and 1200-1299.
-
Ethertype ACLs are used to filter based on the Ethertype field in the frame header. Optionally, you can mirror packets to a datapath or remote destination for troubleshooting and debugging purposes. Ethertype ACLs can be either named or numbered, with valid numbers in the range of 200-299.These ACLs can be used to permit IP while blocking other non-IP protocols, such as IPX or AppleTalk.
ArubaOSprovides both standard and extended ACLs for compatibility with router software from popular vendors, however firewall policies provide equivalent and greater function than standard and extended ACLs and should be used instead.
You can apply MAC and Ethertype ACLs to a user role, however these ACLs only apply to non-IP traffic from the user.
This section describes how to configure the rules that constitute a firewall policy. A firewall policy can then be applied to a user role (until the policy is applied to a user role, it does not have any effect).
Table 56 describes required and optional parameters for a rule.
The following example creates a policy ‘web-only’ that allows web (HTTP and HTTPS) access.
1. Navigate to the Configuration >Security >Access Control > Policies page on the WebUI.
2. Click Addto create a new policy.
3. Enter web-only for the Policy Name.
4. To configure a firewall policy, select IPv4 Session for Policy Type.
5. Click Add to add a rule that allows HTTP traffic.
a. Under Service, select service from the drop-down list.
b. Select svc-http from the scrolling list.
c. Click Add.
6. Click Add to add a rule that allows HTTPS traffic.
a. Under Service, select service from the drop-down list.
b. Select svc-https from the scrolling list.
c. Click Add.
|
|
Rules can be re-ordered by using the up and down buttons provided for each rule. |
7. Click Apply to apply this configuration. The policy is not created until the configuration is applied.
ip access-list session web-only
any any svc-http permit
any any svc-https permit
Creating a Network Service Alias
A network service alias defines a TCP, UDP or IP protocol and a list or range of ports supported by that service. When you create a network service alias, you can use that alias when specifying the network service for multiple session ACLs.
1. Navigate to the Configuration > Advanced Services>Stateful Firewall > Network Services page on the WebUI.
2. Click Add to create a new alias. ]
3. Enter a name for the alias in the Service Name field.
4. In the Protocolsection, select either TCP or UDP, or select Protocol and enter the IP protocol number of the protocol for which you want to create an alias.
5. In the Port Typesection, specify whether you want to define the port by a contiguous range of ports, or by a list of non-contiguous port numbers.
-
If you selected Range, enter the starting and ending port numbers in the Starting Portand End Port fields.
-
If you selected list, enter a comma-separated list of port numbers.
6. To limit the service alias to a specific application, click the Application Level Gateway (ALG) drop-down list and select one of the following service types
-
dhcp: Service is DHCP
-
dns: Service is DNS
-
ftp: Service is FTP
-
h323: Service is H323
-
noe: Service is Alcatel NOE
-
rtsp: Service is RTSP
-
sccp: Service is SCCP
-
sip: Service is SIP
-
sips: Service is Secure SIP
-
svp: Service is SVP
-
tftp: Service is TFTP
-
vocera: Service is VOCERA
7. Click Apply to save your changes.
To define a service alias via the command-line interface, access the CLI in config mode and issue the following command:
netservice <name> <protocol>|tcp|udp {list <port>,<port>}|{<port> [<port>]}
[ALG <service>]
The ACL White List consists of rules that explicitly permit or deny session traffic from being forwarded to or blocked from the controller. The white list protects the controllerduring traffic session processing by prohibiting traffic from being automatically forwarded to the controllerif it was not specifically denied in a blacklist. The maximum number of entries allowed in the ACL White List is 64. To create an ACL white list, you must first define a white list bandwidth contract, and then assign it to an ACL.
Configuring a White List Bandwidth Contract in the WebUI
1. Navigate to the Configuration >Advanced Services >Stateful Firewall > White List BW Contracts page.
2. Click Add to create a new contract.
3. In the White list contract name field, enter the name of a bandwidth contract.
4. The Bandwidth Ratefield allows you to define a bandwidth rate in either kbps or Mbps. Enter a rate value the Bandwidth rate field, then click the drop-down list and select either kbps or Mbps.
5. Click Done.
Configuring the ACL White List in the WebUI
1. Navigate to the Configuration > Stateful Firewall> ACL White List page.
2. To add an entry, click the Add button at the bottom of the page. The Add New Protocol section displays.
3. Click the Actiondrop-down list and select Permitor Deny. Permitallows session traffic to be forwarded to the controllerwhile Deny blocks session traffic.
4. In the IP Protocol Number field, enter the number for a protocol used by session traffic.
5. In the Starting Portsfield, enter a starting port. This is the first port, in the port range, on which permitted or denied session traffic is running. Port range: 1–65535.
6. In the End Ports field, enter an ending port. This is the last port, in the port range, on which permitted or denied session traffic is running. Port range: 1–65535.
7. (Optional) Click the White list Bandwidth Contractdrop-down list and specify the name of a bandwidth contract to apply to the session traffic. For further information on creating Bandwidth Contracts, see “Configuring a Bandwidth Contract in the WebUI”
8. Click Done. The ACL displays on the white list section.
9. To delete an entry, click Delete next to the entry you want to delete.
10. Click Apply to save changes.
Configuring the White List Bandwidth Contract in the CLI
cp-bandwidth-contract <name> {mbits <1..2000>}|{kbits <256..2000000>}
Configuring the ACL White List in the CLI
Use the following CLI command to create ACL White Lists.
(host) (config) #firewall cp {deny|permit} proto <IP protocol number> ports <start port number> <last port number> [bandwidth-contract <name>]
To create a whitelist ACL entry that permits traffic using protocol 6 on ports 5000 through 6000 to be forwarded to the controller:
(host) (config-fw-cp) #firewall cp permit proto 6 ports 5000 6000
To create a a whitelist ACL entry that denies traffic using protocol 2 on port 5000 from being forwarded to the controller:
(host) (config-fw-cp) #firewall cp deny proto 2 ports 5000 5000
This section describes how to create a new user role. When you create a user role, you specify one or more policies for the role.
Table 57 describes the different parameters you can configure for the user role.
|
Field |
Description |
|---|---|
|
Firewall Policies (required) |
One or more policies that define the privileges of a wireless client in this role. There are three ways to add a firewall policy to a user role: l Choose from configured policies (see “Creating a Firewall Policy” ): Select a policy from the list of configured policies and click the “Done” button to add the policy to the list of policies in the user role. If this policy is to be applied to this user role only for specific AP groups, you can specify the applicable AP group. l Create a new policy from a configured policy: This option can be used to create a new policy that is derived from an existing policy. l Create a new policy: The rules for the policy can be added as explained in “Creating a Firewall Policy”. |
|
Re-authentication Interval (optional) |
Time, in minutes, after which the client is required to reauthenticate. Enter a value between 0-4096. 0 disables reauthentication. Default: 0 (disabled) |
|
Role VLAN ID (optional) |
By default, a client is assigned a VLAN on the basis of the ingress VLAN for the client to the controller. You can override this assignment and configure the VLAN ID that is to be assigned to the user role. You configure a VLAN by navigating to the Configuration >Network > VLANspage. |
|
Bandwidth Contract (optional) |
You can assign a bandwidth contract to provide an upper limit to upstream or downstream bandwidth utilized by clients in this role. You can select the Per User option to apply the bandwidth contracts on a per-user basis instead of to all clients in the role. For more information, see “Bandwidth Contracts”. |
|
VPN Dialer (optional) |
This assigns a VPN dialer to a user role. For details about VPN dialer, see Chapter 14, “Virtual Private Networks”. Select a dialer from the drop-down list and assign it to the user role. This dialer will be available for download when a client logs in using captive portal and is assigned this role. |
|
L2TP Pool (optional) |
This assigns an L2TP pool to the user role. For more details about L2TP pools, see Chapter 14, “Virtual Private Networks”. Select the required L2TP pool from the list to assign to the user role. The inner IP addresses of VPN tunnels using L2TP will be assigned from this pool of IP addresses for clients in this user role. |
|
PPTP Pool (optional) |
This assigns a PPTP pool to the user role. For more details about PPTP pools, see Chapter 14, “Virtual Private Networks”. Select the required PPTP pool from the list to assign to the user role. The inner IP addresses of VPN tunnels using PPTP will be assigned from this pool of IP addresses for clients in this user role. |
|
Captive Portal Profile (optional) |
This assigns a Captive Portal profile to this role. For more details about Captive Portal profiles, see Chapter 12, “Captive Portal”. |
|
Max Sessions |
This configures a maximum number of sessions per user in this role. The default is 65535. You can configure any value between 0-65535. |
The following example creates the user role ‘web-guest’ and assigns the previously-configured ‘web-only’ policy to this user role.
1. Navigate to the Configuration >Security >Access Control > User Roles page.
2. Click Add to create and configure a new user role.
3. Enter web-guest for Role Name.
4. Under Firewall Policies, click Add. From Choose from Configured Policies, select the ‘web-only’ session policy from the list. You can click Createto create and configure a new policy.
5. Click Done to add the policy to the user role.
|
|
If there are multiple policies for this role, policies can be re-ordered by the using the up and down buttons provided for each policy. |
6. You can optionally enter configuration values as described in Table 57.
7. Click Apply to apply this configuration. The role is not created until the configuration is applied.
After assigning the user role (see “User Role Assignments” ), you can click the Show Reference button to see the profiles that reference this user role.
To a delete a user role in the WebUI:
1. Navigate to the Configuration >Security >Access Control > User Roles page.
2. Click the button against the role you want to delete.
|
|
You cannot delete a user-role that is referenced to profile or server derived role. Deleting a server referenced role will result in an error. Remove all references to the role and then perform the delete operation. |
user-role web-guest
access-list session web-only position 1
After assigning the user role (see “User Role Assignments” ), you can use the show reference user-role <role> command to see the profiles that reference this user role.
You can manage bandwidth utilization by assigning maximum bandwidth rates, or bandwidthcontracts, to user roles. You can configure bandwidth contracts, in kilobits per second (Kbps) or megabits per second (Mbps), for the following types of traffic:
-
from the client to the controller (“upstream” traffic)
-
from the controller to the client (“downstream” traffic)
You can assign different bandwidth contracts to upstream and downstream traffic for the same user role. You can also assign a bandwidth contract for only upstream or only downstream traffic for a user role; if there is no bandwidth contract specified for a traffic direction, unlimited bandwidth is allowed.
By default, all users that belong to the same role share a configured bandwidth rate for upstream or downstream traffic. You can optionally apply a bandwidth contract on a per-userbasis; each user who belongs to the role is allowed the configured bandwidth rate.
For example, if clients are connected to the controllerthrough a DSL line, you may want to restrict the upstream bandwidth rate allowed for eachuser to 128 Kbps. Or, you can limit the totaldownstream bandwidth used by all users in the ‘guest’ role to 128 Mbps. The following example configures a bandwidth rate of 128 Kbps and applies it to upstream traffic for the previously-configured ‘web-guest’ user role on a per-user basis.
Configuring a Bandwidth Contract in the WebUI
In the WebUI, you can first configure a bandwidth contract and then assign it to a user role:
1. Navigate to the Configuration >Advanced Services >Stateful Firewall > BW Contracts page.
2. Click Add to create a new contract.
3. In the Contract Namefield, enter BC512_up.
4. The Bandwidthfield allows you to define a bandwidth rate in either kbps or Mbps. For this example, enter 512in the Bandwidth field, then click the drop-down list and select kbps.
5. Click Done.
Assigning a Bandwidth Contract to a User Role in the WebUI
Now that you have a defined bandwidth contract, you can assign that contract to a user role.
1. Navigate to the Configuration >Security >Access Control > User Roles page.
2. Select Edit for the web-guest user role.
3. Under Bandwidth Contract, select BC512_up from the drop-down menu for Upstream.
4. Select Per User.
5. Scroll to the bottom of the page, and click Apply.
You can also can configure the user role and create the bandwidth contract from the User Roles page:
1. Navigate to the Configuration >Security >Access Control > User Roles page.
2. Select Edit for the web-guest user role.
3. In the Bandwidth Contract section, click the Upstreamdrop-down list and select Add New. The New Bandwidth Contract fields appear.
a. In the Namefield, enter BC512_up.
b. In the Bandwidth field, enter 512.
c. Click the Bandwidth drop-down list and select kbps.
d. Click Doneto add the new contract and assign it to the role. The New Bandwidth Contractsection closes.
4. In the Bandwidth Contractsection, select the Per User checkbox.
5. Scroll to the bottom of the page, and click Apply.
Configuring and Assigning Bandwidth Contracts in the CLI
aaa bandwidth-contract BC512_up kbps 512
user-role web-guest
bw-contract BC512_up per-user upstream
Bandwidth contracts on a VLAN can limit broadcast and multicast traffic. ArubaOSincludes an internal exception list to allow broadcast and multicast traffic using the VRRP, LACP, OSPF, PVST and STP protocols. To remove per-vlan bandwidth contract limits on an additional broadcast or multicast protocol, add the MAC address for that broadcast/multicast protocol to the Vlan Bandwidth Contracts MAC Exception List
Viewing the Current Exceptions List
To view the current bandwidth contract exception list, access the command-line interface in enable mode and issue the command show vlan-bwcontract-explist. To view the preconfigured internal bandwidth contract exception list, include the optional internal parameter, as shown in the example below:
Configuring Bandwidth Contract Exceptions
To add the MAC address of a protocol to the exception list for bandwidth contracts, access the command-line interface in config mode and issue the command vlan-bwcontract-explist <mac-addr>.
The following example adds the MAC address for CDP (Cisco Discovery Protocol) and VTP (Virtual Trunking Protocol to the list of protocols that are not limited by VLAN bandwidth contracts.
(host) (config) #vlan-bwcontract-explist mac 01:00:0C:CC:CC:CC
A client is assigned a user role by one of several methods. A user role assigned by one method may take precedence over a user role assigned by a different method. The methods of assigning user roles are, from lowest to highest precedence:
1. The initial user role for unauthenticated clients is configured in the AAA profile for a virtual AP (see Chapter 4, “Access Points”).
2. The user role can be derived from user attributes upon the client’s association with an AP (this is known as a user-derived role). You can configure rules that assign a user role to clients that match a certain set of criteria. For example, you can configure a rule to assign the role “VoIP-Phone”to any client that has a MAC address that starts with bytes xx:yy:zz.User-derivation rules are executed beforeclient authentication.
3. The user role can be the default user role configured for an authentication method, such as 802.1x or VPN. For each authentication method, you can configure a default role for clients who are successfully authenticated using that method.
4. The user role can be derived from attributes returned by the authentication server and certain client attributes (this is known as a server-derived role). If the client is authenticated via an authentication server, the user role for the client can be based on one or more attributes returned by the server during authentication, or on client attributes such as SSID (even if the attribute is not returned by the server). Server-derivation rules are executed after client authentication.
5. The user role can be derived from ArubaVendor-Specific Attributes (VSA) for RADIUS server authentication. A role derived from an Aruba VSA takes precedence over any other user roles.
The following sections describe the methods of assigning user roles.
An AAA profile defines the user role for unauthenticated clients (initial role) as well as the default user role for MAC and 802.1x authentication. To configure user roles in the AAA profile:
1. Navigate to the Configuration >Security >Authentication > AAA Profiles page.
2. Select the “default” profile or a user-defined AAA profile.
3. Click the Initial Role drop-down list, and select the desired user role for unauthenticated users.
4. Click the 802.1x Authentication Default Roledrop-down list and select the desired user role for users who have completed 802.1x authentication.
5. Click the MAC Authentication Default Roledrop-down list and select the desired user role for clients who have completed MAC authentication.
6. Click Apply.
aaa profile <profile>
initial-role <role>
dot1x-default-role <role>
mac-default-role <role>
For additional information on creating AAA profiles, see “AAA Profile Parameters” .
The user role can be derived from attributes from the client’s association with an AP. You configure the user role to be derived by specifying condition rules; when a condition is met, the specified user role is assigned to the client. You can specify more than one condition rule; the order of rules is important as the first matching condition is applied. You can optionally add a description of the user rule.
|
|
User-derivation rules are executed before the client is authenticated. |
Table 58 describes the conditions for which you can specify a user role.
Configuring a User-derived Role
1. Navigate to the Configuration >Security >Authentication > User Rules page.
2. Click Addto add a new set of derivation rules. Enter a name for the set of rules, and click Add. The name appears in the User Rules Summary list.
3. In the User Rules Summary list, select the name of the rule set to configure rules.
4. Click Addto add a rule. For Set Type, select Role from the drop-down menu. (You can select VLAN to configure derivation rules for setting the VLAN assigned to a client.)
5. Configure the condition for the rule by setting the Rule Type, Condition, Value parametersand optional description of the rule.See Table 58 for descriptions of these parameters.
6. Select the role assigned to the client when this condition is met.
7. Click Add.
8. You can configure additional rules for this rule set. When you have added rules to the set, use the up or down arrows in the Actions column to modify the order of the rules. (The first matching rule is applied.)
9. Click Apply.
Configure a User-derived Role in the CLI
aaa derivation-rules user <name>
set role condition <condition> set-value <role> position <number>
where conditionconsists of rule_type condition valueparameters. See Table 58for descriptions of these parameters.
Default Role for Authentication Method
For each authentication method, you can configure a default role for clients who are successfully authenticated using that method. To configure a default role for an authentication method:
1. Navigate to the Configuration >Security > Authentication page.
2. To configure the default user role for MAC or 802.1x authentication, select the AAA Profilestab. Select the AAA profile. Enter the user role for MAC Authentication Default Role or 802.1x Authentication Default Role.
3. To configure the default user role for other authentication methods, select the L2 Authenticationor L3 Authenticationtab. Select the authentication type (Stateful 802.1x or stateful NTLM for L2 Authentication, Captive Portal or VPN for L3 Authentication), and then select the profile. Enter the user role for Default Role.
4. Click Apply.
For additional information on configuring captive portal authentication, see “Captive Portal” .
To configure the default user role for MAC or 802.1x authentication:
aaa profile <profile>
mac-default-role <role>
dot1x-default-role <role>
To configure the default user role for other authentication methods:
aaa authentication captive-portal <profile>
default-role <role>
aaa authentication stateful-dot1x
default-role <role>
aaa authentication stateful-ntlm
default-role <role>
aaa authentication vpn
default-role <role>
If the client is authenticated via an authentication server, the user role for the client can be based on one or more attributes returned by the server during authentication. You configure the user role to be derived by specifying condition rules; when a condition is met, the specified user role is assigned to the client. You can specify more than one condition rule; the order of rules is important as the first matching condition is applied. You can also define server rules based on client attributes such as ESSID, BSSID, or MAC address, even though these attributes are not returned by the server.
For information about configuring a server-derived role, see “Configuring Server-Derivation Rules”.
Many Network Address Server (NAS) vendors, including Aruba, use VSAs to provide features not supported in standard RADIUS attributes. For Arubasystems, VSAs can be employed to provide the user role and VLAN for RADIUS-authenticated clients, however the VSAs must be present on your RADIUS server. This involves defining the vendor (Aruba) and/or the vendor-specific code (14823), vendor-assigned attribute number, attribute format (such as string or integer), and attribute value in the RADIUS dictionary file. VSAs supported on controllersconform to the format recommended in RFC 2865, “Remote Authentication Dial In User Service (RADIUS)”.
Dictionary files that contain ArubaVSAs are available on the Arubasupport website for various RADIUS servers. Log into the Aruba support website to download a dictionary file from the Tools folder.
Table 59describes optional firewall parameters you can set on the controllerfor IPv4 traffic. To set these options in the WebUI, navigate to the Configuration >Advanced Services >Stateful Firewall > Global Setting page and select or enter values in the IPv4 column. To set these options in the CLI, use the firewallconfiguration commands.
See Chapter 32, “IPv6 Client Support” for information about configuring firewall parameters for IPv6 traffic.