Configuring Firewall Policies

A firewall policy identifies specific characteristics about a data packet passing through the Aruba controller and takes some action based on that identification. In an Aruba controller, 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 user in 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 IPv6 Support for information about configuring IPv6 firewall policies.

Working With 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.
Service ACLs provide a generic way to restrict how protocols and services from specific hosts and subnets to the controller are used. Rules with this ACL are applied to all traffic on the controller regardless of the ingress port or VLAN.

ArubaOS provides 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.

Support for Desktop Virtualization Protocols

ArubaOS supports desktop virtualization protocols by providing preconfigured ACLs for Citrix and VMware clients. You can apply these ACLs to the user-role when using the Virtual Desktop Infrastructure (VDI) clients. This ensures that any enterprise application that uses the VDI client performs optimally with appropriate QoS.

 

 

Disable the voice aware ARM when applying the ACLs for the VDI clients as the virtual desktop sessions may prevent the ARM scanning.

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 1 describes required and optional parameters for a rule.

Table 1: Firewall Policy Rule Parameters

Field

Description

Source (required)

Source of the traffic, which can be one of the following:

any: Acts as a wildcard and applies to any source address.
user: This refers to traffic from the wireless client.
host: This refers to traffic from a specific host. When this option is chosen, you must configure the IP address of the host.
network: This refers to a traffic that has a source IP from a subnet of IP addresses. When this option is chosen, you must configure the IP address and network mask of the subnet.
alias: This refers to using an alias for a host or network. You configure the alias by navigating to the Configuration > Advanced Services > Stateful Firewall > Destination page.

Destination (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:

any: This option specifies that this rule applies to any type of traffic.
tcp: Using this option, you configure a range of TCP port(s) to match for the rule to be applied.
udp: Using this option, you configure a range of UDP port(s) to match for the rule to be applied.
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.
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 controller to perform on a packet that matches the specified criteria. This can be one of the following:

permit: Permits traffic matching this rule.
drop: Drops packets matching this rule without any notification.
reject: Drops the packet and sends an ICMP notification to the traffic source.
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 the Configuration > Advanced > Security > Advanced > NAT Pools). Source IP changes to the outgoing interface IP address (implied NAT pool) or from the pool configured (manual NAT pool). This action functions in tunnel/decrypt-tunnel forwarding mode.
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 Aruba controller as used in the pre-defined policy called “captiveportal”. This action functions in tunnel/decrypt-tunnel forwarding mode. User should configure the NAT pool in the controller.
dual-nat: This option performs both source and destination NAT on packets matching the rule. Forward packets from source network to destination; re-mark them with destination IP of the target network. This action functions in tunnel/decrypt-tunnel forwarding mode. User should configure the NAT pool in the controller.
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.
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.
route: Specify the next hop to which packets are routed, which can be one of the following:
  • dst-nat: Destination IP changes to the IP configured from the NAT pool. This action functions in bridge/split-tunnel forwarding mode. User should configure the NAT pool in the controller.
  • src-nat:Source IP changes to RAP’s external IP. This action functions in bridge/split-tunnel forwarding mode and uses implied NAT pool.

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 High for 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 Ranges page.

Pause ARM Scanning (optional)

Pause ARM scanning while traffic is present. Note that you must enable “VoIP 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. To configure a firewall policy, select the policy type from the Policies title bar. You can select All, IPv4 Session, IPv6 Session, Ethernet, MAC, Standard or Extended.
3. Click Add to create a new policy.
4. If you selected All in Step 2, then select the type of policy you are adding from the Policy Type drop-down menu.
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

(host)(config) #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 Protocol section, 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 Type section, 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 Port and 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:

(host)(config) #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 controller during traffic session processing by prohibiting traffic from being automatically forwarded to the controller if 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.

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 Rate field 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 Listpage.
2. To add an entry, click the Addbutton at the bottom of the page. The Add New Protocolsection displays.
3. Click the Action drop-down list and select Permit or Deny. Permit allows session traffic to be forwarded to the controller while Deny blocks session traffic.
4. Click the IP Version drop-down list and select theIPv4 or IPv6 filter. You need to select one of three following choices from the Source drop-down list:
For a specific IPv4 or IPv6 filter, select IP/Mask. Enter the IP address and mask of the IPv4 or IPv6 filter in the corresponding fields.
For a IPv4 or IPv6 host, select Any and enter the source address.
5. In the IP Protocol Number or IP Protocol field, enter the number for a protocol or select the protocol from the drop-down list used by session traffic.
6. In the Starting Ports field, 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.
7. 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.
8. (Optional) Click the White list Bandwidth Contract drop-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
9. Click Done. The ACL displays on the white list section.
10. To delete an entry, click Delete next to the entry you want to delete.
11. Click Apply to save changes.

Configuring the White List Bandwidth Contract in the CLI

(host)(config) #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-fw-cp)ipv4|ipv6 deny|permit <ip-addr><ip-mask>|any|{host <ip-addr>} proto{<ip-protocol-number> ports <start port number> <end port number>}|ftp|http|https|icmp|snmp|ssh|telnet|tftp [bandwidth-contract <name>]

To create a whitelist ACL that allows traffic on an ipv4 filter with the ipv4 source address 10.10.10.10 and the ipv4 source mask 2.2.2.2 where the protocol is ftp and the the bandwidth contract name is mycontract.

(host) (config-fw-cp) #ipv4 permit 10.10.10.10 2.2.2.2 proto ftp bandwidth-contract name mycontract

to create a whitelist ACL entry that denies traffic using protocol 2 on port 5000 from being forwarded to the controller:

(host) (config-fw-cp) deny proto 2 ports 5000 5000