Integration Fundamentals

This section describes the fundamentals about how the Zscaler integration works.

Table of contents

• Integration Fundamentals
  • ZIA Service Orchestration
    • Aruba Cloud Connect
    • ZIA Location and Tunnel Orchestration
      • IPSec Tunnel Details
  • Service Chaining traffic through ZIA
    • Policy Based Routing
    • Uplink Load-balancing and Dynamic Path Steering on Branch Gateways
  • Manual Integrations

ZIA Service Orchestration

Aruba Cloud Connect

Aruba Central provides a unified framework to manage all integrations with cloud infrastructure or security services: Cloud Connect. This service allows automating connectivity by making use of partner APIs to define sites/locations, finding the nearest point of presence, and automatically establish IPsec tunnels. Furthermore, it can also help provide advanced capabilities such as defining 3rd party options or establishing routing neighborhoods.

ZIA Location and Tunnel Orchestration

Aruba Gateways (not Microbranch APs) can be configured to bring up tunnels to the ZIA service manually. This requires creating “locations” (as well as unique VPN credentials) in the ZIA service for each branch site. It also requires configuring the Gateways to bring up tunnels to the nearest ZIA Public Service Edge. In the case of large deployments this can be a very labor-intensive task.

This function is automated in the Aruba SD-Branch solution by the Cloud Connect Service, in conjunction with the SD-WAN Orchestrator. These are cloud-native, multi-tenant control plane services included as part of Aruba Central to automate SD-WAN deployments. When building the SD-WAN fabric with the SD-WAN Orchestrator, WAN links are automatically discovered and tunnels and routes are orchestrated based on business and topological needs, such as mapping data centers to branch offices. More information can be found in the Aruba SD-WAN documentation.

In the context of the Zscaler integration, the Cloud Connect Service handles the tunnel establishment between Gateways and Microbranch APs and the nearest ZIA Public Service Edge. It does so by executing the following steps:

Step 1 Bind Aruba Gateways with the nearest ZIA Public Service Edges. The Orchestrator queries the ZIA API for the nearest node(s) for each Gateway public IP address. If needed, these can be easily overriden by selecting which public or private Service Edge nodes a certain group of Gateways or Microbranch APs should be connecting to.

Step 2 Create “locations” in the Zscaler portal. Aruba Central creates the “Locations” for all Gateways or Microbranch in the selected groups using the ZIA APIs. Unique VPN credentials are also created for each Gateway or Microbranch AP. Additional options such as site-specific configurations, sublocations, bandwidth contracts, etc. are also defined in Aruba Central and automatically pushed through the APIs.

Step 3 Orchestrate tunnels. Aruba Central instructs each Gateway or Microbranch to establish tunnels with the nearest two ZIA Public Service Edges (or the service edges selected by the network administrator) using the credentials negotiated in step 2.

The Aruba Cloud Connect service will also monitor ZIA for any changes such as new ZIA Public Service Edges, it will also monitor the deployment. If a new Gateway or Microbranch is added to a group that is set to integrate with ZIA, the whole discovery/site-creation/tunnel-establishment would be automatically triggered for that device.

IPSec Tunnel Details

The tunnels between Gateway or Microbranch and ZIA Public Service Edges (formerly referred to as Zscaler Enforcement Nodes - ZENs) use IPsec with null encryption. This is done to maximise performance (as traffic is anyways Internet-bound) while retaining the ability to use dynamic IP addresses, traverse NAT/PAT boundaries and leverage IKEv2 for authentication. All that’s required to bring up the tunnels is to have a location with VPN credentials in ZIA and have the Gateways or Microbranches authenticate themselves using them. Such tunnels can be established manually or by using the Aruba SD-WAN Orchestrator.

A summary of the tunnel characteristics is provided in the following table:

Table 2 — Tunnel Characteristics

Service Chaining traffic through ZIA

Policy Based Routing

Once tunnels are established, the next step would be to make sure relevant traffic is sent through these tunnels. Aruba Gateways and Microbranch APs use policy-based routing (or role-based routing) to determine which traffic flows are to be sent through the ZIA service.

The following parameters can be taken into consideration when determining traffic types to be sent through the ZIA service:

• VLAN/User Role; PBR policies can be applied to roles or VLANs
• Stateful Firewall attributes; Protocol, source/destination address, source/destination port
• FQDN; ArubaOS supports creating “netservices” based on FQDN, which can be used to build PBR policies.
• Application/Application Group; Thanks to caching capabilties in the DPI engine, both Gateways and Microbranch APs support 1st packet classification technologies necessary to route traffic based on applications or application groups.

The following figure illustrates how Gateways selectively redirect traffic to ZIA; In this example, cameras are full-tunneled to the DC, Guest is sent directly to the Internet, and Employees/IoT are sent to the Internet through the ZIA service with the exception of specific well-known SaaS applications. A similar topology would also be possible using Microbranch.

Uplink Load-balancing and Dynamic Path Steering on Branch Gateways

Aruba Branch Gateways (BGWs) support uplink load-balancing. The Branch Gateway would simply set up a tunnel from every WAN interface to each ZIA Public Service Edge. To ensure traffic symmetry, all traffic that enters ZIA through a tunnel is guaranteed to return (egress) through the same tunnel.

Moreover, the Aruba Branch Gateway is capable of selecting the WAN circuit to be used by each traffic flow based on rich policies such as the ones built for PBR. The routing engine (global routing table or PBR) provides a set of “next-hops” and the DPS engine selects the optimal path. On top of that, Branch Gateways can monitor different WAN circuits to steer traffic to the optimal path based on SLAs set for each application. To do so, it sends synthetic L7 probes to http://gateway./vpntest to measure loss, latency and jitter over the tunnels to the ZIA service.

An example workflow would look like this:

• ClearPass (or another RADIUS server) assigns the role “PoS” to the device
• The firewall classifies the session as “Payment”.
• The routing for a PoS device using a “Payment” app states that the next-hop is a certain ZIA node, and the paths are, for example: INET and LTE

• Because the traffic is classified as “Payment”, it’s handled by the DPS policy “Payment”. This policy has INET as preferred path, as well as an SLA that has to be met.

• If the measured values for INET meet the SLA for the “Payment” policy the session goes through the tunnel that’s established using the INET uplink. If at any point in time the measured SLA for INET drops, the Gateway will steer it to any other active tunnel that’s meeting the SLA. If no circuit meets the SLA, the system will chose the one that deviates the least from the configured SLA.

Manual Integrations

Even though the orchestrated integration is generally more popular, there are also options for manual integrations, configuring IPsec or GRE tunnels in the Gateways (Microbranch only supports orchestrated integration). When using IPsec tunnels, tunnel details and overall topology don’t differ significantly from those of the orchestrated integration. In case of GRE integration, Gateways would build standard GRE tunnels to ZIA.

Given the nature of GRE tunnels, the public IP address of both ends of the tunnel needs to be known beforehand. It’s also important to note that GRE tunnels can’t traverse PAT boundaries, meaning that a public IP address has to be used in the WAN interfaces of the Gateways.

---