Integration Fundamentals
This section describes the fundamentals about how the Palo Alto Prisma Access integration works.
Table of contents
Service Orchestration
Cloud Connect Service
HPE Aruba Networking Central is a multi-tenant cloud platform serving 1000s of customers. As such, it’s composed of many microservices handling all sorts of tasks.
Cloud Connect is a horizontally scalable service that takes care of establishing communications with third-party (cloud) solutions. It does so 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.
In the case of Palo Alto Prisma Access, Cloud Connect orchestrates the connectivity between edge devices (Microbranch APs and Gateways) and Security Processing Nodes (SPNs). To do so, it builds tunnels between the Edge Devices and the SPNs and ensures reachability by configuring static routes or Border Gateway Protocol (BGP) peering relationships.
Geolocation and Tunnel Orchestration
Gateways (not Microbranch APs) could integrate with Prisma Access with manual IPsec tunnels and routes; This would require creating “Remote Networks”, IKE Gateways, IPsec Gateways, unique VPN credentials, etc. for each branch site. It could also even require defining routing configurations for every IPsec tunnel… 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-Branch Orchestrator. These are cloud-native, multi-tenant control plane services included as part of Aruba Central to automate network deployments. When building the SD-WAN fabric with the SD-Branch 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 SD-Branch Orchestrator Tech Note.
In the context of the Prisma Access integration, the Cloud Connect Service handles the tunnel establishment between Gateways or Microbranch APs and the nearest Prisma Access SPNs. It does so by executing the following steps:
Step 1 Find the nearest Prisma Access Region. Cloud Connect queries the insights API in Strata Cloud Manager to find the nearest node(s) for each Gateway public IP address. If needed, these can be easily overridden by selecting which public or private Service Edge nodes a certain group of Gateways or Microbranch APs should be connecting to.
Step 2 Create “Remote Networks” in Strata Cloud Manager. Cloud Connect creates the “Remote Networks” for all Gateways or Microbranch in the selected groups through the Strata Cloud Manager APIs. Unique VPN credentials are also created for each Gateway or Microbranch AP. Additional options such as BGP configurations (applicable only for gateways) are also pushed via API. As part of this process, a given site is “bound” to one of the SPNs in a Prisma Access Region.
Step 3 Orchestrate tunnels. HPE Aruba Networking Central then instructs each Gateway or Microbranch to establish tunnels with the correspondning SPN using the credentials (as well as the routing configuration in case of gateways) negotiated in step 2.
After this, the Cloud Connect service will keep monitoring the deployment. If a new Gateway or Microbranch is added to a group that is set to integrate with Prisma Access, the whole discovery/site-creation/tunnel-establishment would be automatically triggered for that device.
IPSec Tunnel Details
The tunnels between Gateway or Microbranch and Prisma Access SPNs use IPsec with the settings described below. One notable aspect is that tunnels are set to be sourced from dynamic IP addresses, which allows for tunnels to form from changing IP addresses, behind a NAT gateway, etc. All that’s required to bring up the tunnels is to define the VPN credentials Prisma Access and have the Gateways or Microbranches authenticate themselves using them.
A summary of the tunnel characteristics is provided in the following table:
| Phase 1 | Phase 2 | |
|---|---|---|
| Encryption | AES-256 | AES-256 |
| Integrity | SHA2-256 | SHA2-256 |
| Authentication | Local FQDN (IKE ID) & PSK | N/A |
| Key Exchange Method | Diffie-Hellman | Diffie-Hellman |
| Diffie-Hellman Group | 14 | 14 |
| NAT-Transversal | Enabled | N/A |
| Dead Peer Detection (DPD) | Enabled | |
| Perfect Forward Secrecy (PFS) | DH group 14 | - |
| VPN Type | N/A | Policy-based VPN |
Table 1 — Tunnel Characteristics
Service Chaining Internet-bound traffic through Prisma Access
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 Prisma Access.
The following parameters can be taken into consideration:
- VLAN/User Role; Policy Based Routing (PBR) policies can be applied to roles or VLANs
- Stateful Firewall attributes; Protocol, source/destination address, source/destination port
- Domain; Gateways and Microbranches allow using domain-based “netservices” 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 the tunnels; 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 Prisma Access 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 a given SPN. To ensure traffic symmetry, all traffic that enters the SPN through a tunnel is guaranteed to return 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 HTTPS probes to a cloud service offered by HPE Aruba Networking to measure loss, latency and jitter over the tunnels to Prisma Access.
An example workflow would look like this:
- The role “PoS” is assigned to the device (this can be statically tied to a VLAN/SSID or derived from an authentication).
- 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 SPN, and the paths are, for example: INET and LTE.
Because the traffic is classified as “Payment”, it’s handled by the Dynamic Path Steering (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 Service Level Assurance (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.
Routing between Gateways and Prisma Access
While static routes are certainly an option, Palo Alto allows (and promotes) the use of routing protocols (in this case, BGP) to exchange routes between SPNs and on-premises routers or firewalls. This is used to facilitate the connectivity between remote access clients connecting through Zero Trust Network Access (ZTNA) and workloads hosted in on-premises locations (Data Center, Headquarters and even branch locations). As part of the orchestration between SD-Branch Gateways and Prisma Access, Cloud Connect also takes care of establishing the BGP peering between the gateways and Prisma Access. Every Gateway will have one or multiple Equal Cost Multi Path (ECMP) IPsec tunnels with BGP Peering being orchestrated by Cloud Connect.
Click here to learn more more about routing capabilities of Prisma Access and overall design best practices.
BGP over IPsec
To establish the BGP peering, SD-Branch Gateways and Prisma Access will use “always up” host (/32) interfaces as source/destination to establish BGP peering inside every IPsec tunnel. Cloud Connect will automatically install host routes to reach the Prisma Access BGP Peers through the tunnels and will add “auto_cloud_connect_in” and “auto_cloud_connect_out” route-maps (with an index of 20) to every BGP neighbor it creates. The default IPv4 address block used to carve out IP addresses for this integration is 169.254.0.0/16, although this can be easily modified. Likewise, the default interface range for the “always up” host interfaces is interface VLANs 4000-4008, but this also can be modified from the Cloud Connect configuration page.
