Microbranch Deployment Workflows
This section describes the configurations and expected outcomes for the orchestrated integration between Microbranch and Palo Alto Prisma Access.
Table of contents
Tunnel Orchestration
At this point, Aruba Central is able to communicate with Strata Cloud Manager through its API and it’s therefore capable of orchestrating communications between Microbranches and Prisma Access. To do so, simply go to Global > Network Services > Cloud Connect and click “Connect” in one or more of the Microbranch groups you wish to connect to Prisma Access. 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 Microbranch, each with active and optionally standby tunnels from active and backup uplinks. Cloud Connect will only attempt to orchestrate tunnels to Prisma Access from public uplink interfaces such as those labeled as “INET” or “LTE”.
When connecting a Microbranch group to Prisma Access, additional deployment options can be configured by clicking on the cog on the right side of the table. This will allow limiting the number of Microbranches that would be set to go any given SPN as well as overriding the Prisma Access Region a group of Microbranch APs would tunnel to.
Note: Please note that, in order for Cloud Connect to associate every Microbranch with its closest Prisma Access Region, APs must be assigned to a site, and that site must have a physical address defined.
Validating the orchestration process in Central
For any group set to “connect” with Prisma Access, Cloud Connect will constantly scan for changes in the corresponding groups. Any APs added or removed to a group or any changes in the uplink configuration 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 APs or uplinks are removed from Aruba 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:
Forwarding Internet-bound traffic through Prisma Access
Establishing IPsec tunnels from Microbranches to Prisma Access is the first step. For the integration to be complete, traffic needs to be forwarded through these tunnels. To do so, go to the Microbranch and configure the following:
Step 1 Create a Next-Hop-List including all the tunnels to Prisma Access. Tunnels over the primary uplink should have higher priority.
Step 2 Define a PBR policy that forwards Internet-bound traffic through the recently configured NextHop List. RFC1918 addresses or real-time applications that shouldn’t be forwarded via Prisma Access should be set to “Forward Regularly”.
Step 3 Apply the PBR policy to the corresponding user roles.
Validate tunnels and PBR
Tunnel Monitoring
To confirm things are working as expected, the first step is to validate that the tunnels are indeed established. This can be observed in Aruba Central:
As well as in the Strata Cloud Manager:
Policy Based Routing
Once it’s established the tunnels are up, the first step is to validate the user is in the right user-role. This can be checked from the client details and client list pages.
Lastly, once the user is in the role that redirects Internet-bound traffic via Prisma Access, the firewall logs in Strata Cloud Manager will show how traffic is hitting Prisma Access, as well as the security policies being applied.
If you wish to do more advanced debugging, you can also go into the Microbranch CLI to trace the entire traffic flow.
First check that the next hop-list is created and pointing to the right tunnel(s):
RWC-Lab-Microbranch# sh ip nexthop-list
Nexthop-List Entries
--------------------
Name Dest Preemptive Failover Nexthop Nexthop Dest Priority
---- ---- ------------------- ------- ------------ --------
prisma-access 0x4402 Enabled pan-init-sase-orchestration-primary-lab 128
RWC-Lab-Microbranch#
!
...
!
RWC-Lab-Microbranch# sh access-list
Access list table
-----------------
Name AclId Type Use Count Roles
---- ----- ---- --------- -----
"default policy" 471 route
l2-full-tunnel 472 route
netskope-internet 473 route 1 LAN
pbr-fqdn 474 route
prisma-access-internet 475 route 1 LAB-Microbranch
RWC-Lab-Microbranch#
And then make sure the traffic is effectively hitting the PBR policy:
RWC-Lab-Microbranch# show datapath session | i -
------------------------------
Flags: A - Application Firewall Inspect
C - client, D - deny, E - Media Deep Inspect
F - fast age, G - media signal, H - high prio
I - Deep inspect, L - ALG session, M - mirror, N - dest NAT
O - Session is programmed through SDN/Openflow controller
P - set prio, R - redirect, S - src NAT,
T - set ToS, U - Locally destined, V - VOIP
X - Http/https redirect for dpi denied session
Y - no syn
a - rtp analysis, h - Https redirect error page
i - in offload flow, m - media mon
p - Session is marked as permanent
s - media signal
d - DPI cache hit
f - FIB init pending in session
RAP Flags: 0 - Q0, 1 - Q1, 2 - Q2, r - redirect to conductor
t - time based, i - in flow, l - local redirect
Flow Offload Denylist Flags: O - Openflow, E - Default, U - User os unknown, T - Tunnel
R - L3 route
---------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- ------- ----- ------ -------------
1.1.1.1 10.127.17.80 17 53 55172 0 0 0 1 pbr-nhl 2 116 0 0 FId
10.127.17.80 1.1.1.1 17 59453 53 0 0 0 1 pbr-nhl 2 117 1 41 FCId E
10.127.17.80 1.1.1.1 17 59449 53 0 0 0 1 pbr-nhl 2 117 1 40 FCId E
1.1.1.1 10.127.17.80 17 53 54999 0 0 0 1 pbr-nhl 2 117 0 0 FId
1.1.1.1 10.127.17.80 17 53 63225 0 0 0 1 pbr-nhl 2 116 0 0 FId
1.1.1.1 10.127.17.80 17 53 54941 0 0 0 1 pbr-nhl 2 fb 0 0 FId
1.1.1.1 10.127.17.80 17 53 54959 0 0 0 1 pbr-nhl 2 fb 0 0 FId
10.127.17.80 1.1.1.1 17 61422 53 0 0 0 0 pbr-nhl 2 116 5 159 FCId E
1.1.1.1 10.127.17.80 17 53 54292 0 0 0 1 pbr-nhl 2 117 0 0 FId
1.1.1.1 10.127.17.80 17 53 54058 0 0 0 1 pbr-nhl 2 116 0 0 FId
1.1.1.1 10.127.17.80 17 53 65348 0 0 0 2 pbr-nhl 2 116 0 0 FId
1.1.1.1 10.127.17.80 17 53 57182 0 0 0 1 pbr-nhl 2 fb 0 0 FId
1.1.1.1 10.127.17.80 17 53 65136 0 0 0 2 pbr-nhl 2 116 0 0 FId
10.127.17.80 1.1.1.1 17 65136 53 0 0 0 1 pbr-nhl 2 116 5 13b FCId E
10.127.17.80 1.1.1.1 17 65348 53 0 0 0 1 pbr-nhl 2 116 5 140 FCId E
1.1.1.1 10.127.17.80 17 53 55579 0 0 0 2 pbr-nhl 2 fb 0 0 FId
10.127.17.80 1.1.1.1 17 63225 53 0 0 0 1 pbr-nhl 2 116 5 140 FCId E
1.1.1.1 10.127.17.80 17 53 55402 0 0 0 2 pbr-nhl 2 10f 0 0 FId
1.1.1.1 10.127.17.80 17 53 55350 0 0 0 2 pbr-nhl 2 116 0 0 FId
1.1.1.1 10.127.17.80 17 53 51120 0 0 0 2 pbr-nhl 2 10f 0 0 FId
1.1.1.1 10.127.17.80 17 53 50834 0 0 0 2 pbr-nhl 2 fb 0 0 FId
10.127.17.80 1.1.1.1 17 50834 53 0 0 0 1 pbr-nhl 2 fb 3 f0 FCId E
10.127.17.80 1.1.1.1 17 51120 53 0 0 0 1 pbr-nhl 2 10f 4 f8 FCId E
1.1.1.1 10.127.17.80 17 53 61422 0 0 0 2 pbr-nhl 2 116 0 0 FId
10.127.17.80 1.1.1.1 17 55350 53 0 0 0 1 pbr-nhl 2 116 5 13b FCId E
10.127.17.80 1.1.1.1 17 55402 53 0 0 0 1 pbr-nhl 2 10f 4 f8 FCId E
10.127.17.80 1.1.1.1 17 55579 53 0 0 0 1 pbr-nhl 2 fb 3 b4 FCId E
10.127.17.80 1.1.1.1 17 57182 53 0 0 0 1 pbr-nhl 2 fb 3 f0 FCId E
10.127.17.80 1.1.1.1 17 54058 53 0 0 0 1 pbr-nhl 2 116 1 3e FCId E
10.127.17.80 1.1.1.1 17 54292 53 0 0 0 1 pbr-nhl 2 117 1 3f FCId E
10.127.17.80 1.1.1.1 17 54959 53 0 0 0 1 pbr-nhl 2 fb 1 54 FCId E
10.127.17.80 1.1.1.1 17 54941 53 0 0 0 0 pbr-nhl 2 fb 3 c3 FCId E
10.127.17.80 1.1.1.1 17 54999 53 0 0 0 1 pbr-nhl 2 117 1 3f FCId E
10.127.17.80 1.1.1.1 17 55172 53 0 0 0 1 pbr-nhl 2 116 2 9c FCId E
1.1.1.1 10.127.17.80 17 53 59453 0 0 0 1 pbr-nhl 2 117 0 0 FId
1.1.1.1 10.127.17.80 17 53 59449 0 0 0 1 pbr-nhl 2 117 0 0 FId