Reference Architectures
The orchestrated integration of SD-Branch and Microbranch with Prisma Access allows for a wide variety of scenarios. This section describes the most common ones, which have been validated by the HPE Aruba Networking Engineering and QA teams.
Table of contents
Microbranch Integration with Prisma Access
The Microbranch integration with Prisma Access is the simplest of all. In this case, Cloud Connect will build tunnels to the nearest SPN (unless overridden as part of the configuration), and Internet-bound traffic will be forwarded through said SPNs using PBR policies applied to the user roles. For Microbranch deployments with dual uplink interfaces, tunnel definitions will be created for both uplinks, but only those tunnels sourced from the active interfaces will come up.
Gateway Integrations with Prisma Access
Branch Gateway forwarding Internet traffic via Prisma Access
Just as in the case of Microbranch, Branch Gateways are often integrated with Prisma Access with the sole intention of forwarding traffic destined to the Internet. For simplicity’s sake, Cloud Connect will always establish the BGP peering between the Gateways and Prisma Access, but there won’t be a need for any prefixes to be learned, as the traffic should be forwarded through Prisma Access using PBR policies.
Branch Gateway Uplink Sharing
When redundancy is required inside the branch, Branch Gateways can share WAN uplinks with their HA pairs. This establishes a virtual uplink through the LAN to share such WAN circuits. The result, as shown in the image below, is that each Branch Gateway would have “physical” uplinks as well as “virtual” uplinks.
In a scenario like this, each Branch Gateway establishes tunnels to Prisma Access through all public uplink interfaces (those labeled as INET or LTE), regardless of whether they’re physical or virtual. Cloud Connect would define both Branch Gateways as separate “Remote Networks”, each one with separate IKE/IPsec Gateways, VPN Credentials, etc.
Headend Gateway forwarding Internet traffic through Prisma Access
Branch traffic is sometimes aggregated at a local hub and then routed to the Internet or to other corporate resources. This case is mostly common when using private WAN in the branch locations. In such scenarios, Headend Gateways (VPNCs) can set up tunnels to the nearest SPN to have branch traffic go through additional security inspection.
East-West connectivity through Prisma Access
Aruba generally recommends leveraging the SD-WAN overlay for site-to-site communications; it allows for simpler deployments that are more cost-effective and provide better performance (the SD-WAN overlay features like Forward Error Correction, faster DPS, etc.). East-West communications can also be done through Prisma Access, leveraging SSE as the transport between sites. To facilitate that, Cloud Connect automates the configuration of key routing features from Prisma Access and the SD-Branch gateways.
A network where all East-West communications happen between Prisma Access would look like the following:
Note: Routing site-to-site traffic via Prisma Access may require additional license entitlement. For more detailed information on Prisma Access, its capabilities as well as licensing please check directly with a Palo Alto Networks representative or a certified partner.
Ensuring Traffic Symmetry in Branch HA locations
When the integration with Prisma Access is exclusively being used to forward Internet-bound traffic through Prisma Access, SPNs will always return traffic through the tunnel where it was initiated, which means that traffic symmetry is guaranteed regardless of the routing configurations. However, when Prisma Access is also being used for downstream connectivity into the branch locations, it’s important to ensure the preferred downstream path is the one through the primary gateway.
To do so, the route redistribution done in the secondary gateway should prepend the Autonomous System (AS) to make routes advertised by the secondary gateway less attractive than those advertised by the primary gateway.
Note: This additional step is only necessary when there’s a desire to route site-to-site Traffic via Prisma Access.