Gateway Deployment Workflows
This section describes the configurations and expected outcomes for the orchestrated integration between Gateways and Palo Alto Prisma Access. As described in the Reference Architectures section, these workflows will allow for a wider variety of deployments, as Cloud Connect will not only orchestrate IPsec tunnels, but also build route peerings.
Table of contents
Route and Tunnel Orchestration
At this point, Aruba Central is able to communicate with Strata Cloud Manager through its API and it is therefore capable of orchestrating communications between Microbranches and Prisma Access. This is as simple as selecting a group and clicking “connect” from the Cloud Connect page, but before we do so, we need to make sure BGP is enabled and an Autonomous System is configured in the Gateway group configuration.
Note: Make sure the AS you configure does not overlap with the ones used by the SD-WAN Orchestrator or Prisma Access.
Now that BGP is configured, go to Global > Network Services > Cloud Connect and click “Connect” in one or more of the Gateway groups you wish to connect to Prisma Access. In the case of Gateways, before Once you’re done selecting groups, click on “Preview” and then “Submit”. Upon hitting submit, Cloud Connect will generate “Remote Locations” in Prisma Access for every Gateway present in the group, each with active tunnels from all public uplink interfaces (Cloud Connect won’t attempt to build tunnels from MPLS WAN interfaces). Additionally, and as discussed in greated detail in the “Design” sections, Cloud Connect with carve out host subnets on both the Prisma Access as well as the Gateway side to form a BGP Peering.
When connecting a Gateway group to Prisma Access, additional deployment options can be configured by clicking on the cog on the right side of the table. The options are as follows:
- Max number of sites per SPN. This will allow the administrator to limit the number of gateways that would eventually establish tunnels to a given SPN. When doing so, please consult Palo alto Networks on the forwarding capacity of an SPN.
- Override location. This will allow the administrator to override the Prisma Access Location tunnels that will be associated with sites in this group. In absence of this, Cloud Connect will automatically find the closest Prisma Access location for every gateway. Please note that this requires having every Gateway assigned to a site, with a physical address defined in every site.
- Advanced Routing Options. This field allows the administrator to modify the VLAN interface and IP address ranges from which Cloud Connect will carve out the necessary interfaces and IP addresses to establish the BGP peering. It also allows for the configuration of neighbor-specific configurations such as “Allow AS-IN” in the Gateways and BGP export options in the case of Prisma Access.
Validating the orchestration process in Aruba Central
For any group set to “connect” to Prisma Access, Cloud Connect will constantly scan for changes in the corresponding groups. Any Gateways added or removed to a group or any changes in the uplink configurations will trigger an update to the deployment. New connections would be automatically established (with the corresponding configurations done in Prisma Access); Conversely, stale configurations would also be removed from Prisma Access when Gateways or uplinks are removed from Central.
This process can be observed from Central. Go to Global > Network Services > Cloud Connect > List > Prisma to observe the orchestration process throughout the entire lifecycle of the project. All actions happening in Cloud Connect are additionally registered in the Audit Trail in Central.
In the unfortunate event that any deployment were to run into issues, further details can be observed from the deployment page, by going to the group potentially having issues and clicking on Failed Deployments > View Details:
Forwarding Internet-bound traffic through Prisma Access
Establishing IPsec tunnels and BGP peering between Gateways and Prisma Access is the first step, but for the integration to be complete, traffic needs to be forwarded through these tunnels. In the case of Internet-bound traffic, this can be done using PBR policies. Given that this process will be substantially different between Branch Gateways and Headend Gateways, we’ll break this in two sections.
Policy Based Routing in Branch Gateways
Branch Gateways establish tunnels to Prisma Access through all active (public) uplink interfaces. Traffic can be forwarded through all active tunnels concurently or selectively through the ones offering a better service for each type of traffic. To do so, tunnels going to the same SPN must be bundled into a PBR “next-hop-list”, with the same routing priority assigned to all the tunnels. That will allow DPS policies to regulate how traffic is forwarded through the different paths.
Note: To better understand how routing and WAN policies interact with each other refer to the WAN Policies section of the SD-Branch Design Guide.
Go to the corresponding group and then to Devices > Gateways Routing > NextHop Configuration.
Once the PBR “next-hop-list” has been created, all that remains is to define a PBR policy that selectively forwards Internet-bound traffic via Prisma Access. As shown in the example below, exceptions can be made for applications that should take the local Internet breakout. In the example below, the policy is sending all traffic to certain applications (Zoom and Microsoft Teams) as well as private-networks (an alias representing RFC1918 addresses) through the regular path, and it’s sending the rest of the traffic through Prisma Access Public using the next-hop list previously defined.
After the next-hop list with tunnels to Prisma Access is created, add it to a PBR policy in Routing > Policy-Based Routing.
In the example below, the policy is sending traffic to certain applications (Zoom and Microsoft Teams) as well as private-networks (an alias representing RFC1918 addresses) through the regular path, and it’s sending the rest of the traffic through Prisma Access using the next-hop list defined above.
After the routing policy is created, the last step would be to apply it to relevant traffic.
In the case of Branch Gateways, these policies would be applied to roles or VLANs where there are devices that should be forwarded via Prisma Access:
- To apply a policy to a VLAN, go to Security > Apply Policies and select it from the dropdown next to each VLAN.
- To apply a policy to a role, go to Security > Roles” and edit the role you want to send through ZIA by adding a routing policy (routing policies always come at the end).
Validate tunnels and PBR
Monitoring tunnels and BGP peering
To confirm things are working as expected, we need to check that tunnels are up and the BGP peering is formed. This can be observed in Aruba Central by going to the gateway details page.
First check the state of the tunnels from the WAN > Tunnels page:
And then the BGP Peering from the Overview > Routing page:
On the Strata Cloud Manager side, go to Monitor > Branch Sites to check the tunnel and BGP status for every remote location:
Monitor traffic forwarding (Policy Based Routing)
Once tunnels are up and BGP peering is “Established”, the next step is to ensure traffic is effectively being forwarded via Prisma Access.
First check the client is effectively in the correct user role.
And then validate that Internet-bound traffic is in fact hitting the right PBR policy and that it is being forwarded though the next-hop associated with the tunnels to Prisma Access.
Lastly, on the Strata Cloud Manager side, the firewall logs will of course show how traffic is being inspected: