Roles and Policies
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. SeeChapter 32, “IPv6 Client Support” for information about configuring IPv6 firewall policies and parameters.
|
Policies
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.
Access Control Lists (ACLs)
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.
Creating a Firewall Policy
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.
Table 56 Firewall Policy Rule Parameters (Continued)
|
Field
|
Description
|
Source (required)
|
Source of the traffic, which can be one of the following:
l any: Acts as a wildcard and applies to any source address.
l user: This refers to traffic from the wireless client.
l host:This refers to traffic from a specific host. When this option is chosen, you must configure the IP address of the host.
l network:This refers to a traffic that has a source IP from a subnet of IP addresses. When this option is chosen, you must configure the IP address and network mask of the subnet.
l alias:This refers to using an alias for a host or network. You configure the alias by navigating to the Configuration >Advanced Services >Stateful Firewall > Destinationpage.
|
Destination (required)
|
Destination of the traffic, which can be configured in the same manner as Source.
|
Service (required)
|
Type of traffic, which can be one of the following:
l any: This option specifies that this rule applies to any type of traffic.
l tcp: Using this option, you configure a range of TCP port(s) to match for the rule to be applied.
l udp: Using this option, you configure a range of UDP port(s) to match for the rule to be applied.
l service: Using this option, you use one of the pre-defined services (common protocols such as HTTPS, HTTP, and others) as the protocol to match for the rule to be applied. You can also specify a network service that you configure by navigating to the Configuration >Advanced Services >Stateful Firewall > Network Services page.
l protocol: Using this option, you specify a different layer 4 protocol (other than TCP/UDP) by configuring the IP protocol value.
|
Action (required)
|
The action that you want the controllerto perform on a packet that matches the specified criteria. This can be one of the following:
l permit: Permits traffic matching this rule.
l drop: Drops packets matching this rule without any notification.
l reject: Drops the packet and sends an ICMP notification to the traffic source.
l src-nat: Performs network address translation (NAT) on packets matching the rule. When this option is selected, you need to select a NAT pool. (If this pool is not configured, you configure a NAT pool by navigating to theConfiguration >Advanced > Security >Advanced > NAT Pools.)
l dst-nat:This option redirects traffic to the configured IP address and destination port. An example of this option is to redirect all HTTP packets to the captive portal port on the Arubacontrolleras used in the pre-defined policy called “captiveportal”.
l dual-nat: This option performs both source and destination NAT on packets matching the rule.
l redirect to tunnel: This option redirects traffic into a GRE tunnel. This option is used primarily to redirect all guest traffic into a GRE tunnel to a DMZ router/switch.
l redirect to ESI group: This option redirects traffic to the specified ESI server group. You also specify the direction of traffic to be redirected: forward, reverse, or both directions.
|
Log (optional)
|
Logs a match to this rule. This is recommended when a rule indicates a security breach, such as a data packet on a policy that is meant only to be used for voice calls.
|
Mirror (optional)
|
Mirrors session packets to datapath or remote destination.
|
Queue (optional)
|
The queue in which a packet matching this rule should be placed. Select Highfor higher priority data, such as voice, and Low for lower priority traffic.
|
Time Range (optional)
|
Time range for which this rule is applicable.
Configure time ranges on the Configuration >Security >Access Control > Time Rangespage.
|
Pause ARM Scanning (optional)
|
Pause ARM scanning while traffic is present. Note that you must enable “Voice Aware Scanning” in the ARM profile for this feature to work.
|
Black List (optional)
|
Automatically blacklists a client that is the source or destination of traffic matching this rule. This option is recommended for rules that indicate a security breach where the blacklisting option can be used to prevent access to clients that are attempting to breach the security.
|
White List (optional)
|
A rule must explicitly permit a traffic session before it is forwarded to the controller. The last rule in the white list denies everything else. Configure white list ACLs on the Configuration > Advanced Services> Stateful Firewall> White List (ACL)page.
|
TOS (optional)
|
Value of type of service (TOS) bits to be marked in the IP header of a packet matching this rule when it leaves the controller.
|
802.1p Priority (optional)
|
Value of 802.1p priority bits to be marked in the frame of a packet matching this rule when it leaves the controller.
|
The following example creates a policy ‘web-only’ that allows web (HTTP and HTTPS) access.
In the WebUI
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.
In the CLI
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.
In the WebUI
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.
In the CLI
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>]
Creating an ACL White List
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
User Roles
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.
Table 57 User Role Parameters (Continued)
|
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, seeChapter 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.
|
Creating a User Role
The following example creates the user role ‘web-guest’ and assigns the previously-configured ‘web-only’ policy to this user role.
In the WebUI
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 Delete 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.
|
In the CLI
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.
Bandwidth Contracts
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 Contract Exceptions
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
User Role Assignments
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.
User Role in AAA Profile
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:
In the WebUI
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.
In the CLI
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” .
User-Derived Role
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.
Table 58 Conditions for User-Derived Role (Continued)
|
Rule Type
|
Condition
|
Value
|
BSSID of AP to which client is associated
|
One of the following:
l contains
l ends with
l equals
l does not equal
l starts with
|
MAC address (xx:xx:xx:xx:xx:xx)
|
User class identifier (option 77) returned by DHCP server
|
equals
|
string
|
Encryption type used by client
|
One of the following:
l equals
l does not equal
|
l Open (no encryption)
l WPA/WPA2 AES
l WPA-TKIP (static or dynamic)
l Dynamic WEP
l WPA/WPA2 AES PSK
l Static WEP
l xSec
|
ESSID to which the client is associated
|
One of the following:
l contains
l ends with
l equals
l does not equal
l starts with
l value of (does not take string; attribute value is used as role)
|
string
|
Location–AP name of the AP to which the client is associated
|
One of the following:
l equals
l does not equal
|
string
|
MAC address of the client
|
One of the following:
l contains
l ends with
l equals
l does not equal
l starts with
|
MAC address (xx:xx:xx:xx:xx:xx)
|
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:
In the WebUI
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” .
In the CLI
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>
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. 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”.
VSA-Derived Role
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.
Global Firewall Parameters
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.
Table 59 IPv4 Firewall Parameters (Continued)
|
Parameter
|
Description
|
Monitor Ping Attack
|
Number of ICMP pings per second, which if exceeded, can indicate a denial of service attack. Valid range is 1-255 pings per second. Recommended value is 4.
Default: No default
|
Monitor TCP SYN Attack rate
|
Number of TCP SYN messages per second, which if exceeded, can indicate a denial of service attack. Valid range is 1-255 messages per second. Recommended value is 32.
Default: No default
|
Monitor IP Session Attack
|
Number of TCP or UDP connection requests per second, which if exceeded, can indicate a denial of service attack. Valid range is 1-255 requests per second. Recommended value is 32.
Default: No default
|
Monitor/Police CP Attack rate (per sec)
|
Rate of misbehaving user’s inbound traffic, which if exceeded, can indicate a denial or service attack.
Recommended value is 100 frames per second.
|
Deny Inter User Bridging
|
Prevents the forwarding of Layer-2 traffic between wired or wireless users. You can configure user role policies that prevent Layer-3 traffic between users or networks but this does not block Layer-2 traffic. This option can be used to prevent traffic, such as Appletalk or IPX, from being forwarded.
Default: Disabled
|
Deny All IP Fragments
|
Drops all IP fragments.
Note: Do not enable this option unless instructed to do so by an Arubarepresentative.
Default: Disabled
|
Prevent L2 Bridging between Wireless users
|
Prevents the forwarding of Layer-2 traffic between wired or wireless users. You can configure user role policies that prevent Layer-3 traffic between users or networks but this does not block Layer-2 traffic. This option can be used to prevent traffic, such as Appletalk or IPX, from being forwarded.
Default: Disabled
|
Enforce TCP Handshake Before Allowing Data
|
Prevents data from passing between two clients until the three-way TCP handshake has been performed. This option should be disabled when you have mobile clients on the network as enabling this option will cause mobility to fail. You can enable this option if there are no mobile clients on the network.
Default: Disabled
|
Prohibit IP Spoofing
|
Enables detection of IP spoofing (where an intruder sends messages using the IP address of a trusted client). When this option is enabled, IP and MAC addresses are checked for each ARP request/response. Traffic from a second MAC address using a specific IP address is denied, and the entry is not added to the user table. Possible IP spoofing attacks are logged and an SNMP trap is sent.
Default: Disabled
|
Prohibit RST Replay Attack
|
When enabled, closes a TCP connection in both directions if a TCP RST is received from either direction. You should not enable this option unless instructed to do so by an Aruba representative.
Default: Disabled
|
Log ICMP Errors
|
Enables logging of received ICMP errors. You should not enable this option unless instructed to do so by an Aruba representative.
Default: Disabled
|
Disable stateful SIP Processing
|
Disables monitoring of exchanges between a voice over IP or voice over WLAN device and a SIP server. This option should be enabled only when there is no VoIP or VoWLAN traffic on the network.
Default: Disabled (stateful SIP processing is enabled)
|
Allow Tri-session with DNAT
|
Allows three-way session when performing destination NAT. This option should be enabled when the controlleris notthe default gateway for wireless clients and the default gateway is behind the controller. This option is typically used for captive portal configuration.
Default: Disabled.
|
Session Mirror Destination
|
Destination (IP address or port) to which mirrored session packets are sent. This option is used only for troubleshooting or debugging.
Packets can be mirrored in multiple ACLs, so only a single copy is mirrored if there is a match within more than one ACL.
You can configure the following:
Ethertype to be mirrored with the Ethertype ACL mirror option.
IP flows to be mirrored with the session ACL mirror option.
MAC flows to be mirrored with the MAC ACL mirror option.
If you configure both an IP address and a port to receive mirrored packets, the IP address takes precedence.
Default: N/A
|
Session Idle Timeout
|
Set the time, in seconds, that a non-TCP session can be idle before it is removed from the session table. Specify a value in the range 16-259 seconds. You should not set this option unless instructed to do so by an Arubarepresentative.
Default: 15 seconds
|
Disable FTP Server
|
Disables the FTP server on the controller. Enabling this option prevents FTP transfers. You should not enable this option unless instructed to do so by an Aruba representative.
Default: Disabled (FTP server is enabled)
|
GRE Call ID Processing
|
Creates a unique state for each PPTP tunnel. You should not enable this option unless instructed to do so by an Aruba representative.
Default: Disabled
|
Per-packet Logging
|
Enables logging of every packet if logging is enabled for the corresponding session rule. Normally, one event is logged per session. If you enable this option, each packet in the session is logged. You should not enable this option unless instructed to do so by an Arubarepresentative, as doing so may create unnecessary overhead on the controller.
Default: Disabled (per-session logging is performed)
|
Broadcast-filter ARP
|
Reduces the number of broadcast packets sent to VoIP clients, thereby improving the battery life of voice handsets. You can enable this option for voice handsetsin conjunction with increasing the DTIM interval on
clients.
Default: Disabled
|
Session VOIP Timeout (sec)
|
Sets the idle session timeout for sessions that are marked as voice sessions. If no voice packet exchange occurs over a voice session for the specified time, the voice session is removed. Range is 16 – 300 seconds.
Default: 300 seconds
|
Disable Stateful H.323 Processing
|
Disables stateful H.323 processing.
Default: Enabled
|
Disable Stateful SCCP Processing
|
Disables stateful SCCP processing.
Default: Disabled
|
Only allow local subnets in user table
|
Adds only IP addresses, which belong to a local subnet, to the user-table.
Default: Disabled
|
Session mirror IPSEC
|
Configures session mirroring of all frames that are processed by IPsec. Frames are sent to IP address specified by the session-mirror-destination option.
Note: Use this option for debugging or troubleshooting only.
Default: Disabled
|
Enforce WMM Voice Priority Matches Flow Content
|
If traffic to or from the user is inconsistent with the associated QoS policy for voice, the traffic is reclassified to best effort and data path counters incremented.
Default: Disabled
|
Rate limit CP untrusted ucast traffic (Mbps)
|
Specifies the untrusted unicast traffic rate limit. Range is 1-200 Mbps.
Default: 10 Mbps
|
Rate limit CP untrusted mcast traffic (Mbps)
|
Specifies the untrusted multicast traffic rate limit. Range is 1-200 Mbps.
Default: 2 Mbps
|
Rate limit CP trusted ucast traffic (Mbps)
|
Specifies the trusted unicast traffic rate limit. Range is 1-200 Mbps.
Default: 80 Mbps
|
Rate limit CP trusted mcast traffic (Mbps)
|
Specifies the trusted multicast traffic rate limit. Range is 1-200 Mbps.
Default: 2 Mbps
|
Rate limit CP route traffic (Mbps)
|
Specifies the traffic rate limit that needs ARP requests. Range is 1-200 Mbps.
Default: 1 Mbps
|
Rate limit CP session mirror traffic (Mbps)
|
Specifies the session mirrored traffic forwarded to the controller. Range is 1-200 Mbps.
Default: 1 Mbps
|
Rate limit CP auth process traffic (Mbps)
|
Specifies the traffic rate limit that is forwarded to the authentication process. Range is 1-200 Mbps.
Default: 1 Mbps
|