Link Search Menu Expand Document
Table of contents

Campus Policy Layer

The Policy Layer runs on top of the connectivity layer and is responsible for the creation, maintenance and enforcement of network security policies. An endpoint security posture is determined from information gathered using multiple points of context such as date and time, geographic location, authentication method, device type, operating system, as well as other behavioral aspects of the device. After a determination is made, a user role is assigned, and policy can be applied based on the trust level of the device. The ESP architecture supports consistent policy for wired and wireless that includes options for access control at the edge of the network and also traffic tunneling for additional inspection by the stateful firewall on the Gateway.

Endpoint device policy is a pivotal component of the Aruba ESP architecture because it gives an organization a way to create business logic in the network. From the business perspective, this allows dynamic connectivity, a consistent experience across wired and wireless networks, as well as increased network security. From a technical perspective, devices are identified using RADIUS and device profiles. Once an endpoint device has been identified and a user role assigned, the network can drive the security posture. Aruba supports micro and macro segmentation which, depending on the use case, can be used separately or together. The Aruba ESP Architecture achieves this using Dynamic Segmentation, which covers a range of features that include User-Based Tunneling, Virtual Network-Based Tunneling, Device Profiles and User Roles. This section will cover the different ways policy can be implemented within the ESP campus architecture.

Network Authentication

The main responsibility of a secure network is to guarantee that only authorized users are allowed access to the network. Security protocols need to let authorized users in, while keeping the rest out. There are several ways to authenticate and authorize users but using a centralized service to maintain user and device profiles is the easiest approach. A central service running a secure networking protocol provides better security and ease of maintenance, allowing an organization to apply policy from a single administered network point, which also makes it simpler to track usage.

Local Accounts

Outside of the default accounts, local accounts should not be created. All management access should be authenticated through TACACS or RADIUS for accountability purposes. Service accounts are included in this, the local admin/root account should not be used for service accounts or monitoring systems. Any local account that is deemed a necessity should comply with password complexity requirements and password rotation requirements set by the organization. Account information on any local account should also be limited to as few people as possible with strict access and usage requirements.

Session Timeouts

Users that have connected to Central, Gateways or switches should not be allowed to stay connected for extended periods of time without any activity. This is to protect the number of open sessions to the devices as well as anyone who could potentially edit something on the devices that should not have access via an idle connection. The Recommended Timeout can vary between 1 and 5 minutes depending on security policy of the environment. When setting the session timeout ensure that it is consistent across the entire network.

Minimum password

Complex passwords are a requirement for just about everything these days and there is no exception for the network infrastructure. Having complex passwords drastically decrease the likelihood of a password cracking. It is best practice across all Aruba platforms to have a complex password. Passwords should be 8 characters or more, with a combination of capital letters, lower case letters, numbers and special characters. It is also recommended that few to no local accounts exist on devices and the admin/root account password is set to a 64-character complex password and stored in a safe or password management app. Setting this long of a password and storing it in a safe will typically mitigate the need to rotate the local account on a regular basis. All management access should be authenticated through TACACS or RADIUS for accountability purposes. Service accounts are included in this, the local admin/root account should not be used for service accounts or monitoring systems. With RADIUS and TACACS the password complexity is typically controlled by a directory service that will comply with password age and complexity requirements set by the organization.


SSH is one of the most common ways to connect to Network infrastructure as it is the most secure way to interact with network devices. It is important to ensure that the strongest ciphers are being used to connect into the network devices. Pending the region and supported ciphers on different systems it is recommended to review the Aruba hardening guide for details on which cipher should be selected. The Hardening guide can be found on the Aruba support site.


Terminal Access Control System (TACACS) is a security protocol that provides centralized authentication and validation of users who are attempting to access to a network device. TACACS servers should be integrated with an existing directory service to enforce group permission, password complexity, and password life cycle requirements. It is recommended to have all Aruba devices TACACS enabled for authentication, command authorization, and auditing. Aruba ClearPass Policy manager supports TACACS services for any hardware vendor that supports the TACACS protocol including Aruba devices.

Certificate Replacement

Replacing the factory certificates is part of the Aruba hardening guide. Certificates should always be replaced before being devices go into production. TLS 1.2 should be the only Cipher enabled on any web interface. On Gateways you also have the ability to set the Cipher strength to high which is recommended as part of the hardening guide. Using a wildcard certificate for web interfaces for management is acceptable across all Aruba platforms.

API Access

When using any API interface, it is critical that the interface is protected. If the API interface is enabled, it is recommended an ACL be enabled so that only a management subnet is able to access that interface. Depending on the Aruba product the management interface may no longer be required to be enabled. If devices are managed through Aruba Central there is no longer a need to enable the local web interface and it can be disabled.


Remote Authentication Dial-In User Service (RADIUS) is a secure networking protocol to enforce security policies on user devices connecting to the network. The network infrastructure becomes a client to the RADIUS server and a user device connecting to the network is authenticated by the RADIUS server which permits or denies the user device. When using a RADIUS sever, the network will no longer have control over what happens to a user device connected to an enabled interface. Besides just the users that should be authenticated, it is important consider the authentication priority, Change of Authorization (CoA), Critical Authentication and Rejection Roles.

Authentication Priority - There are two main authentication methods: 802.1X and MAC authentication. It is recommended to have access switches and Gateways prefer 802.1X and then, fall back to MAC authentication.

Change of Authorization (CoA) - After a device has been authenticated, the authorization can be modified through a CoA. This is typically done for devices that have triggered a security alert and need to be moved to a quarantine VLAN. It is recommended to enable CoA for all switches and Gateways.

Critical Authentication - If the RADIUS sever fails or authentication request are not getting to the server, it is important to have a critical authentication role on the switching infrastructure to allow devices on the network while the RADIUS server is unreachable. The critical authentication role by itself will not allow basic network connectivity, so it is important to ensure that there is a role with network connectivity to critical applications and Internet access. Remember, devices in the critical authentication role may not be trusted, so their access should only allow basic connectivity to prevent potential exploitations.

Rejection Role - When devices do not have the appropriate credentials to connect to the network, the rejection role should restrict, but not deny all access. The rejection role should place the device in a VLAN where there is basic internet connectivity, but also allow the device to be re-authenticated and placed in the correct VLAN.

Client limit - This will limit the number of clients allowed to on a port, this will also protect users from a potential mac flooding attack as the number of clients cannot go past this limit. The maximum number of clients on a port should be 5, however this is flexible depending on the deployment.

User Role

The benefits of assigning roles to user and devices is well known within the Aruba wireless portfolio. This concept has been adapted to the Aruba wired portfolio and eases the burden of configuration by grouping policies into a role that can be referenced by the Administrator. When ClearPass is used, time of day, type of machine, and device profiling are available when deciding if a user and their device should be allowed on the network, and what access rights are granted.

The following is a list of key points regarding User Roles:

  • A User Role will dictate if traffic is locally switched or tunneled back to the Gateway.
  • Any RADIUS server can be used to return a Local User Role (LUR).
  • LURs are assigned from the RADIUS server using the ‘HPE-User-Role’ VSA.

A role will dictate what VLAN is assigned, tagged or untagged, and if the traffic is locally switched or tunneled back to a Gateway. Optionally, a role can also assign a policy ACL or QOS, re-authentication timers, and captive portal redirect. It doesn’t matter if the role is pre-defined or downloaded from ClearPass, it must exist on the network device before it can be applied.

Dynamic Segmentation

Dynamic Segmentation unifies policy enforcement across wired and wireless networks, keeping traffic secure and separate. It utilizes intelligence gathered from Aruba’s role-based policy capability, user firewalls, Layer 7 application visibility and integrated web content filtering. Dynamic Segmentation has two main components. The first one assigns policy or User Roles dynamically to a device based on authentication. This means network administrators do not have to preconfigure access switch ports or APs with VLANs for each device that is connected. This allows an organization to use colorless ports on the wired side which significantly reduces the operations planning for initial deployments and on-going changes to accommodate moves, adds, and changes.

The second component is the segmentation of traffic on a given subnet using local VLANs or by tunneling traffic back to centralized Gateways for further inspection and micro-segmentation. The Gateway’s advanced firewall feature set provides enhanced security and performance benefits based on increased visibility from profiling and deep packet inspection of traffic.

Untrusted traffic on the network from wired and wireless devices is tunneled to centralized Gateways. They inspect the traffic and apply security policy before allowing it to continue. Traffic can be micro-segmented to prevent east-west flows within a given subnet or it can be prevented from traveling north-south to other locations within the campus.

User-Based Tunneling

On the wired side, User-Based Tunneling (UBT) sends device traffic to centralized Gateways, which apply a consistent set of rules with a User Role. UBT provides the flexibility to maintain existing VLAN segmentation which allows for simple adoption and an easy migration path. Traffic added to the policy overlay can coexist with traffic using the connectivity underlay without disruption of services.

Policy is enforced at the Gateway using intelligence gathered from a User Role defined in ClearPass combined with the Layer 7 firewall capability. Dynamic Segmentation provides unique context on user attributes, ranging from their role in the organization, type of device, and their network location. This helps an organization deploy a Zero Trust security policy in their environment by providing a consistent set of rules for wired and wireless users.

A User Role can contain an ACL policy, QoS policy, captive portal redirection, VLAN assignment, and device attributes. When the User Role is received from the RADIUS server, a command to redirect traffic to a Gateway can be included. When traffic is redirected to a Gateway, the authentication sub-system provides a secondary role to the Gateway. The secondary role is the User Role on the Gateway where policy exists for tunneled users applying the advanced firewall and security rules. This secondary role information is an indication to the Gateway that it has to enforce additional policies to the traffic based on the configuration associated with the secondary role and then, form the tunnel. The tunnel also provides high availability and load balancing with the Gateway clustering feature to extend resilient secure access to all wired devices within the Intelligent Edge network.

The following diagram shows UBT in the three-tier wired design. The employee, visitor and IoT devices have different access capabilities based on their specific User Role policies even though they come from the same VLAN subnet in the access layer.

Policy enforcement using UBT in three-tier wired

Colorless Ports

Colorless ports are a wired solution that do not require static configurations of VLANs to access ports. They allow the administrator to configure access switches generically with only a management VLAN on each port. When a device is connected, a policy is automatically applied to the connected device using a local or downloadable user role in real-time.

The following is a list of key points regarding colorless ports on Aruba switches:

  • Colorless Ports are the “dynamic” in Dynamic Segmentation because there is no need to assign user VLANs to access-ports.
  • Colorless Ports are not exclusive to user-based tunneling, nor do they require ClearPass.
  • Colorless Ports can be used with LURs.

Tunnel-mode SSID

On the wireless side, tunnel-mode SSIDs consist of APs with Layer 2 tunnels to centralized Gateways, which apply the same set of rules for all wired and wireless devices. The policy is configured in Central or ClearPass and the Gateway acts as the policy enforcement point with intelligence gathered from the role-based policy and firewall capabilities. The tunnel-mode SSIDs are terminated at the Gateway which offer micro-segmentation for all traffic using the stateful firewall. Dynamic Segmentation provides unique context on user attributes, ranging from their role in the organization, type of device, and their network location. This helps an organization deploy a Zero Trust Security policy in their environment by providing a consistent set of rules for wired and wireless users. From the scaling perspective, Gateways are recommended when customers expect to deploy more than 500 APs and 5000 clients at a single site.

Tunnel-mode in three-tier wired

Network Segmentation

Trusted traffic on the network can be controlled at the switch or AP when an organization does not want to tunnel to a centralized location for inspection. Wired traffic will use LUR assigned VLANs and Layer 3 / Layer 4 ACLs to prevent north-south access to other areas of the network. Wireless traffic will use bridge-mode SSIDs to segment traffic into the existing VLANs on the access switches.

Access Control Lists

ACLs identify traffic based on IP address, port numbers or both. Once the traffic has been identified, ACL’s have the option to permit, deny, tag or log. ACLs can be used to deny traffic from one destination to another, to identify traffic for QoS or to filter routes in a route map. In addition to the three instances, there are three types of ACL’s supported on Aruba devices, MAC-based, IPv4 and IPv6 ACL’s. This section will not cover QoS classification, because it is covered in the “Quality of Service” section of the guide. Route maps are used when redistributing traffic from one routing instance to another or in the case of route leaking between VRFs. Guidance for how to write route map rules is specific to each network installation.

When using ACLs to segment traffic, it is best to use an IPv4 ACL and have distinguishable network boundaries. If an ACL is used to segment devices, it is important these devices are not within the same subnet because traffic within a subnet does not pass through the Layer 3 portion of the switch where the ACL is applied. The recommended ACL denies user VLANs (BYOD, Employee and Visitor) from accessing the network infrastructure management VLAN with SSH or HTTP/HTTPS.

On AOS-CX devices, ACLs can only be applied to an interface in specific direction depending on the platform, so it is important to note which direction ACLs are applied in order to have a desired result. The following tables list the AOS-CX capability to apply ACL inbound or outbound per interface type and per ACL type.

ACL Interface Type8400X83608325832064xx630062006100
Ingress v4 ACL on portsYesYesYesYesYesYesYesYes
Ingress v4 ACL on vlansYesYesYesYesYesYesYesYes
Ingress Routed v4 ACL on vlansYesYesYesYesYesYes--
Ingress v6 ACL on portsYesYesYesYesYesYesYesYes
Ingress v6 ACL on vlansYesYesYesYesYesYesYesYes
Ingress Routed v6 ACL on vlansYesYesYesYesYesYes--
Ingress MAC ACL on portsYesYesYesYesYesYesYesYes
Ingress MAC ACL on vlansYesYesYesYesYesYesYesYes
Egress v4 ACL (on route-only ports)YesYesYesYesYesYes--
Egress v4 ACL (on bridged ports)-Yes--YesYesYes-
Egress Routed v4 ACL on vlans-YesYesYesYesYes--
Egress v6 ACL on ports-Yes--YesYesYes-
Egress v4 ACL on vlans-YesYesYesYesYesYes-
Egress Routed v6 ACL on vlans-YesYesYesYesYes--
Egress v6 ACL on vlans-YesYesYesYesYesYes-
Egress MAC ACL on ports-Yes--YesYesYes-
Egress MAC ACL on vlans-Yes--YesYesYes-
Control Plane ACLsYesYesYesYesYesYesYesYes
Ingress ADC on ports*YesYesYesYesYesYesYesYes

Bridge-mode SSID

In the AP model using bridge-mode SSIDs, the user VLANs exist on the APs, and wireless traffic is bridged locally to the AP. In the AP with Gateway model using tunnel-mode SSIDs described in the Dynamic Segmentation section, the user VLANs are terminated on the Gateway or the AP, and the wireless traffic is tunneled to the Gateway or bridge locally depending on traffic requirement.

With bridge-mode SSIDs, the AP acts as the policy enforcement point by segmenting the traffic into the appropriate VLAN. The AP is trunked to the access switch, and the VLANs are terminated in the collapsed core. The policy is configured in Central or ClearPass, which provide easy ways to administer and manage policy across an organization from a centralized location. Bridge-mode SSIDs are recommended when customers expect to deploy less than 500 APs and have less then 5000 clients per site.

Bridge-mode in two-tier wired

Mixed-mode SSID

Aruba also supports a new SSID forwarding mode called mixed-mode. This mode allows a customer to enable both bridge and tunnel forwarding modes on a single SSID without requiring separate SSIDs for each mode. The benefits of a mixed-mode SSID is to reduce the overall number of SSIDs. Fewer SSIDs in a busy network, and the reduced percentage of management/control frames and beacons, help boost the WLAN network performance and simplify overall network management. Mixed-mode SSIDs are recommended when a deployment needs bridged and tunneled traffic and wants to use 802.1X authentication for both tunneled and bridged traffic.

The key thing to note is mixed-mode SSIDs only support 802.1X for authentication. Aruba ClearPass is preferred but not mandatory to deploy mixed-mode SSIDs. Bridged and tunneled VLAN derivation are done using a standard vendor-specific attribute VSA (example filter-id) or an Aruba VSA (example user-role), which is provided by ClearPass or any RADIUS server.

Back to top

© Copyright 2021 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to Aruba EULA.