Link Search Menu Expand Document
calendar_month 07-Mar-24

Enforcement Models

Policy enforcement involves allowing or denying traffic for a connected user or device using a set of rules based on role assignment, additional user or device attributes, and traffic type.

While ClearPass or Central Global Policy Manager define policy and perform authentication services, policy enforcement occurs on network devices such as switches, gateways, and APs (Bridge Mode or Microbranch).

Table of contents

NetConductor Enforcement Models

This section discusses the two primary NetConductor enforcement models within a campus, and how policy is propagated and enforced across a WAN network.

Centralized Enforcement

When building networks using a centralized policy architecture, APs and switches form GRE tunnels to a gateway cluster to which all user traffic is tunneled. Centralized design is effective and efficient for client-initiated, north-south-bound traffic such as that destined for a data center or the Internet. All policy enforcement is performed on the gateways incorporating role and VLAN assignments.

An authentication server in an 802.1X authentication exchange responds with an assigned role and RADIUS attributes, and gateways apply the policy associated with the role for all sessions initiated by the client.

Centralized fabrics are commonly deployed in branch or campus environments. Find more information in the campus design guide.

Wireless

Aruba gateway clusters provide a high-performance, scalable solution for centralized policy enforcement using Aruba’s high-throughput Policy Enforcement Firewall and Deep Packet Inspection features.

The illustration below demonstrates a high-level example of centralized wireless policy enforcement performed by an AOS 10 Gateway cluster.

Centralized Wireless Enforcement

Wi-Fi clients associate to a tunnel mode AP that forwards traffic to the Gateway cluster via a GRE tunnel. The Gateways decapsulate and analyze the traffic, enforce user role policy, then forward the traffic to its destination:

  • Security cameras are assigned the Surveillance role that allows communication only with the media server.
  • The laptop associated with a login belonging to a user in the finance department is assigned the Finance role that allows communication with the finance server and the Internet.
  • The Guest role is assigned to the guest phone traffic and is sent to the Internet only.

All the roles are assigned dynamically at the Gateways by Aruba ClearPass or Cloud Auth.

Wired

Much like the centralized wireless enforcement diagram, the diagram below demonstrates a high-level example of centralized wired policy enforcement performed by an AOS 10 Gateway cluster.

Centralized Wired Enforcement

With centralized wired enforcement, user-based tunneling (UBT) provides a tunnel between Aruba switches and an AOS 10 Gateway cluster. A granular, role-based policy is applied to prioritize application traffic and dictate the network resources that can be accessed as part of Aruba’s Dynamic Segmentation. The roles can be assigned by ClearPass or Cloud Auth.

Distributed Enforcement

In a distributed policy architecture, Aruba CX switches form an EVPN-VXLAN overlay fabric. Data traffic is encapsulated in a VXLAN packet that includes a group policy ID (GPID) in the header. This enables policy enforcement on any VXLAN-GBP-aware device configured with a corresponding role and policy.

Distributed policy enforcement implemented in Aruba Central NetConductor provides consistent and efficient policy enforcement in all directions of traffic flow.

The policy enforced on a switch is configured within Aruba Central and downloaded to the switch when it is added to the overlay fabric. The same is done for gateways connected into a NetConductor fabric.

Distributed fabrics are commonly deployed in branch or campus environments as well as data centers. In data centers, EVPN-VXLAN fabrics are deployed using Aruba Fabric Composer (AFC), and Aruba roles are not currently used for policy enforcement. More information on distributed fabric designs can be found in the campus design guide and datacenter design guide.

Wired

The Aruba CX switch operating system provides a sophisticated suite of Layer 3 capabilities necessary for building highly resilient overlay networks based on EVPN-VXLAN, using the Group Based Policy field of the VXLAN header to carry a Group Policy ID. Each user or device session carried through the fabric is assigned a role ID enabling each switch in the network to enforce role-based policy.

Distributed Enforcement

In the example above, traffic is inspected and policy is enforced locally at each switch or switch stack, for a more efficient data path between source and destination.

  • User roles are applied to each session, permitting traffic for each device as defined by the organization’s IT security policy.
  • Surveillance traffic is permitted only between cameras and media servers.
  • Finance users are permitted to communicate with their Finance servers, print servers, and the Internet.
  • Guests are restricted to only Internet access.

The model is configured and supported from Aruba Central’s comprehensive interface.

Wireless

For the wireless LAN, Gateways and the overlay fabric are connected through a static VXLAN tunnel configured between a Gateway cluster and the aggregation switch to which they are connected. This static tunnel ensures that the role ID is communicated between the WLAN and the EVPN fabric by preserving the VXLAN header.

Based on the role ID, gateways enforce policy on traffic using the integrated policy enforcement firewall (PEF).

WLAN in Distributed Enforcement

The animated diagram above demonstrates how client traffic is handled in a distributed enforcement deployment. First, note that EVPN-VXLAN tunnels are set up between switch stacks, and static VXLAN tunnels are set up between the Gateways and switches in the overlay fabric. GRE tunnels are formed between the AP and Gateways. Client traffic is GRE-encapsulated at the AP and forwarded through the underlay to the Gateway cluster, not the overlay fabric.

When the surveillance camera associates to the AP, its traffic is sent to the Gateway via the GRE tunnel, where it is decapsulated and inspected. It is then VXLAN-encapsulated and assigned the GPID associated with the Surveillance role. The Gateway then forwards the traffic to the local LAN using the static VXLAN tunnel, after which it is forwarded to the Media Server.

The Finance user is processed in the same manner, but traffic is forwarded based on the security policy assigned to the Finance role, which permits three possible destinations.

The guest phone is handled similarly, but only permitted to access the Internet based on the Guest role policy.

Currently, only Tunnel Mode is supported in a distributed model.

WAN Enforcement: EdgeConnect SD-Branch

In the Centralized Multi-site Fabric with Aruba SD-Branch deployment, the ArubaOS 10 Aruba Gateways act as WLAN and user-based tunnel gateways, and enable connectivity and role propagation over the SD-Branch WAN network. The following example explains the Centralized Multi-Site Fabric deployment using ArubaOS 10 Aruba Gateways.

SD-Branch WAN Policy

In the Centralized Multi-Site Fabric deployment, customers can propagate role information and enforce role-based policies for client traffic across multiple sites connected by an Aruba SD-Branch fabric. The ArubaOS 10 Gateways act as the WLAN and user-based tunnel Gateways for wired and wireless clients within each site, and act as the policy enforcement point for the clients within the site. To enforce role-based policies destined to clients across the fabric, the ArubaOS 10 Gateways encapsulate the client traffic using both VXLAN and IPsec, which contain role information in the GPID field in the VXLAN header. The ArubaOS 10 Gateway in the destination site then enforces the role-based policies for client traffic. Role propagation also can be selectively enabled on a per-group basis for SD-Branch deployments.

More information on SD-Branch WAN policy enforcement is found in the branch design guide.

CX 10000 and Pensando Policy Services Manager

Implementation of the Aruba ESP data center policy layer is dependent on the chosen network architecture. An EVPN-VXLAN design offers a rich combination of overlay technologies and traffic filtering mechanisms to isolate user and application traffic, configured primarily on leaf switches. A Two-Tier design offers many of the same filtering options, requiring configuration at both the core and access layers.

The Aruba CX 10000 Distributed Services Switch (DSS) enforces east-west traffic policy using an inline stateful firewall in hardware within the switch. A DSS optimizes performance and traffic flow characteristics over a centralized firewall strategy and can replace hypervisor-based firewalls, increasing hypervisor CPU and memory resources for hosted workloads. The CX 10000 can be placed in both EVPN and Two-Tier architectures, but with greater policy flexibility in an EVPN design.

Aruba Fabric Composer (AFC) integration with both vCenter and AMD Pensando Policy Services Manager (PSM) provides a powerful combination for managing east-west data center policy using CX 10000 switches and VM guest policy assignment. Network and security administrators can manage all policy elements centrally, while empowering VM administrators to assign VM guests to a policy block in their own independent workflow through the assignment of VM tags. AFC also supports centralized configuration of access control lists (ACLs).

More detailed information on policy enforcement in the data center is found in the Datacenter Design Guide.


Back to top

© Copyright 2024 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.