Prisma Access
Integrate Prisma Access with Riverbed SteelConnect SD-WAN
Table of Contents
Expand All
|
Collapse All
Prisma Access Docs
-
5.2 Preferred and Innovation
- 5.2 Preferred and Innovation
- 5.1 Preferred and Innovation
- 5.0 Preferred and Innovation
- 4.2 Preferred
- 4.1 Preferred
- 4.0 Preferred
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
-
-
-
-
- Allocate Licenses for Prisma Access (Managed by Strata Cloud Manager)
- Plan Service Connections for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Add Additional Locations for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Enable Available Add-ons for Prisma Access (Managed by Strata Cloud Manager)
- Search for Subscription Details
- Share a License for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Increase Subscription Allocation Quantity
-
- Activate a License for Prisma Access (Managed by Strata Cloud Manager) and Prisma SD-WAN Bundle
- Activate and Edit a License for SASE 5G Through Common Services
-
- Prisma Access Onboarding Workflow
-
4.0 & Later
- 4.0 & Later
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
- Prisma Access China
-
- Set Up Prisma Access
- Configure the Prisma Access Service Infrastructure
- Remote Networks: IPSec Termination Nodes and Service IP Addresses
- Remote Networks: IP Address Changes Related To Bandwidth Allocation
- Remote Networks: Service IP Address and Egress IP Address Allocation
- API Examples for Retrieving Prisma Access IP Addresses
- Get Notifications When Prisma Access IP Addresses Change
- Prisma Access Zones
- DNS for Prisma Access
- High Availability for Prisma Access
-
- Enable ZTNA Connector
- Delete Connector IP Blocks
- Set Up Auto Discovery of Applications Using Cloud Identity Engine
- Private AWS Application Target Discovery
- Security Policy for Apps Enabled with ZTNA Connector
- Monitor ZTNA Connector
- View ZTNA Connector Logs
- Preserve User-ID Mapping for ZTNA Connector Connections with Source NAT
-
- Enable Dynamic Privilege Access for Prisma Access Through Common Services
- Authorize User Group Mapping in Cloud Identity Engine for Dynamic Privilege Access
- Enable the Access Agent
- Set Up the Agent Infrastructure for Dynamic Privilege Access
- Create a Snippet
- Create a Project
- Traffic Steering for Dynamic Privilege Access
- Push the Prisma Access Agent Configuration
- Download the Dynamic Privilege Access Enabled Prisma Access Agent Package
-
- Install the Prisma Access Agent
- Log in to the Dynamic Privilege Access Enabled Prisma Access Agent
- Change Preferences for the Dynamic Privilege Access Enabled Prisma Access Agent
- Connect the Dynamic Privilege Access Enabled Prisma Access Agent to a Different Location
- Switch to a Different Project
- Connect the Dynamic Privilege Access Enabled Prisma Access Agent to a Different Server
- Disable the Dynamic Privilege Access Enabled Prisma Access Agent
- Switch Between the Prisma Access Agent and GlobalProtect App
- View and Monitor Dynamic Privilege Access Users
- View and Monitor Dynamic Privilege Access Projects
- Automatic Tunnel Restoration in Dynamic Privilege Access Prisma Access Agents
- Manage Prisma SASE 5G
- App Acceleration in Prisma Access
-
-
- Planning Checklist for GlobalProtect on Prisma Access
- Set Up GlobalProtect Mobile Users
- GlobalProtect — Customize Tunnel Settings
- GlobalProtect — Customize App Settings
- Ticket Request to Disable GlobalProtect
- GlobalProtect Pre-Logon
- GlobalProtect — Clientless VPN
- Monitor GlobalProtect Mobile Users
- How the GlobalProtect App Selects Prisma Access Locations for Mobile Users
- Allow Listing GlobalProtect Mobile Users
-
- Explicit Proxy Configuration Guidelines
- GlobalProtect in Proxy Mode
- GlobalProtect in Tunnel and Proxy Mode
- Private IP Address Visibility and Enforcement for Agent Based Proxy Traffic
- SAML Authentication for Explicit Proxy
- Set Up Explicit Proxy
- Cloud Identity Engine Authentication for Explicit Proxy Deployments
- Proxy Mode on Remote Networks
- How Explicit Proxy Identifies Users
- Explicit Proxy Forwarding Profiles
- PAC File Guidelines
- Explicit Proxy Best Practices
- Monitor and Troubleshoot Explicit Proxy
- Block Settings for Explicit Proxy
- Use Special Objects to Restrict Explicit Proxy Internet Traffic to Specific IP Addresses
- Access Your Data Center Using Explicit Proxy
- App-Based Office 365 Integration with Explicit Proxy
- Chromebook with Prisma Access Explicit Proxy
- Configure Proxy Chaining with Blue Coat Proxy
- Configure Proxy Chaining on Prisma Access Explicit Proxy
- IP Address Optimization for Explicit Proxy Users- Proxy Deployments
- DNS Resolution for Mobile Users—Explicit Proxy Deployments
- View User to IP Address or User Groups Mappings
- Report Mobile User Site Access Issues
- Enable Mobile Users to Access Corporate Resources
-
-
- Planning Checklist for Remote Networks
- Allocate Remote Network Bandwidth
- Onboard a Remote Network
- Connect a Remote Network Site to Prisma Access
- Enable Routing for Your Remote Network
- Onboard Multiple Remote Networks
- Configure Remote Network and Service Connection Connected with a WAN Link
- Remote Networks—High Performance
- Integrate a Shared Desktop VDI with Prisma Access Using Terminal Server
-
- Multitenancy Configuration Overview
- Plan Your Multitenant Deployment
- Create an All-New Multitenant Deployment
- Enable Multitenancy and Migrate the First Tenant
- Add Tenants to Prisma Access
- Delete a Tenant
- Create a Tenant-Level Administrative User
- Sort Logs by Device Group ID in a Multitenant Deployment
-
- Add a New Compute Location for a Deployed Prisma Access Location
- How BGP Advertises Mobile User IP Address Pools for Service Connections and Remote Network Connections
- Proxy Support for Prisma Access and Strata Logging Service
- Block Incoming Connections from Specific Countries
- Prisma Access for No Default Route Networks
-
-
- Default Routes With Prisma Access Traffic Steering
- Traffic Steering in Prisma Access
- Traffic Steering Requirements
- Default Routes with Traffic Steering Example
- Default Routes with Traffic Steering Direct to Internet Example
- Default Routes with Traffic Steering and Dedicated Service Connection Example
- Prisma Access Traffic Steering Rule Guidelines
- Configure Zone Mapping and Security Policies for Traffic Steering Dedicated Connections
- Configure Traffic Steering in Prisma Access
- Preserve User-ID and Device-ID Mapping for Service Connections with Source NAT
-
- Prisma Access Internal Gateway
-
- Configure Privileged Remote Access Settings
- Set Up the Privileged Remote Access Portal
- Configure Applications for Privileged Remote Access
- Set Up Privileged Remote Access Profiles
- Define Permissions for Accessing Privileged Remote Access Apps
- Configure Split Tunneling for Privileged Remote Access Traffic
- Manage Privileged Remote Access Connections
- Use Privileged Remote Access
-
- Integrate Prisma Access With Other Palo Alto Networks Apps
- Integrate Third-Party Enterprise Browser with Explicit Proxy
- Integrate Third-Party NDRs with Prisma Access
- Juniper Mist Integration for SASE Health
-
-
- Connect your Mobile Users in Mainland China to Prisma Access Overview
- Configure Prisma Access for Mobile Users in China
- Configure Real-Name Registration and Create the VPCs in Alibaba Cloud
- Attach the CEN and Specify the Bandwidth
- Create Linux Instances in the Alibaba Cloud VPCs
- Configure the Router Instances
- Onboard the GlobalProtect Gateway and Configure the Prisma Access Portal
-
-
-
- INC_CIE_AGENT_DISCONNECT
- INC_CIE_DIRECTORY_DISCONNECT
- INC_GLOBALPROTECT_GW_USER_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_GLOBALPROTECT_GW_USER_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_GLOBALPROTECT_PORTAL_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_GLOBALPROTECT_PORTAL_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_MU_AUTH_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_MU_AUTH_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_MU_DNS_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_MU_DNS_SERVER_UNREACHABLE_ PER_PA_LOCATION
- INC_PORTAL_CLIENTLESS_VPN_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_PORTAL_CLIENTLESS_VPN_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_RN_AUTH_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_RN_AUTH_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_RN_DNS_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_RN_DNS_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_RN_ECMP_TUNNEL_RTT_EXCEEDED_ BASELINE
- INC_RN_PRIMARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_RN_SECONDARY_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_RN_SITE_CAPACITY_PREDICTION
- INC_SC_PRIMARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_SC_SECONDARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_SC_SITE_CAPACITY_PREDICTION
-
- INC_CERTIFICATE_EXPIRY
- INC_GP_CLIENT_VERSION_UNSUPPORTED
- INC_MU_IP_POOL_BLOCK_UTILIZATION_ EXCEEDED_CAPACITY
- INC_MU_IP_POOL_BLOCK_UTILIZATION_ EXCEEDED_THRESHOLD
- INC_PA_INFRA_DEGRADATION
- INC_PA_SERVICE_DEGRADATION_PA_LOCATION
- INC_PA_SERVICE_DEGRADATION_RN_ SITE_CONNECTIVITY
- INC_PA_SERVICE_DEGRADATION_SC_ CONNECTIVITY
- INC_RN_ECMP_BGP_DOWN
- INC_RN_ECMP_BGP_FLAP
- INC_RN_ECMP_PROXY_TUNNEL_DOWN
- INC_RN_ECMP_PROXY_TUNNEL_FLAP
- INC_RN_ECMP_TUNNEL_DOWN
- INC_RN_ECMP_TUNNEL_FLAP
- INC_RN_PRIMARY_WAN_BGP_FLAP
- INC_RN_PRIMARY_WAN_PROXY_TUNNEL_DOWN
- INC_RN_PRIMARY_WAN_PROXY_TUNNEL_FLAP
- INC_RN_PRIMARY_WAN_TUNNEL_DOWN
- INC_RN_PRIMARY_WAN_TUNNEL_FLAP
- INC_RN_SECONDARY_WAN_BGP_DOWN
- INC_RN_SECONDARY_WAN_BGP_FLAP
- INC_RN_SECONDARY_WAN_PROXY_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_PROXY_TUNNEL_FLAP
- INC_RN_SECONDARY_WAN_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_TUNNEL_FLAP
- INC_RN_SITE_DOWN
- INC_RN_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- INC_RN_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_RN_SPN_LONG_DURATION_CAPACITY_EXCEEDED _THRESHOLD
- INC_RN_SPN_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_SC_PRIMARY_WAN_BGP_DOWN
- INC_SC_PRIMARY_WAN_BGP_FLAP
- INC_SC_PRIMARY_WAN_PROXY_TUNNEL_DOWN
- INC_SC_PRIMARY_WAN_PROXY_TUNNEL_FLAP
- INC_SC_PRIMARY_WAN_TUNNEL_DOWN
- INC_SC_PRIMARY_WAN_TUNNEL_FLAP
- INC_SC_SECONDARY_WAN_BGP_DOWN
- INC_SC_SECONDARY_WAN_BGP_FLAP
- INC_SC_SECONDARY_WAN_PROXY_TUNNEL_DOWN
- INC_SC_SECONDARY_WAN_PROXY_TUNNEL_FLAP
- INC_SC_SECONDARY_WAN_TUNNEL_DOWN
- INC_SC_SECONDARY_WAN_TUNNEL_FLAP
- INC_SC_SITE_DOWN
- INC_SC_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- INC_SC_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_ZTNA_CONNECTOR_APP_STATUS_DOWN
- INC_ZTNA_CONNECTOR_APP_STATUS_DOWN_PARTIAL
- INC_ZTNA_CONNECTOR_CPU_HIGH
- INC_ZTNA_CONNECTOR_MEMORY_HIGH
- INC_ZTNA_CONNECTOR_TUNNEL_DOWN
-
- AL_CIE_AGENT_DISCONNECT
- AL_CIE_DIRECTORY_DISCONNECT
- AL_MU_IP_POOL_CAPACITY
- AL_MU_IP_POOL_USAGE
- AL_RN_ECMP_BGP_DOWN
- AL_RN_ECMP_BGP_FLAP
- AL_RN_PRIMARY_WAN_BGP_DOWN
- AL_RN_PRIMARY_WAN_BGP_FLAP
- AL_RN_PRIMARY_WAN_TUNNEL_DOWN
- AL_RN_PRIMARY_WAN_TUNNEL_FLAP
- AL_RN_SECONDARY_WAN_BGP_DOWN
- AL_RN_SECONDARY_WAN_BGP_FLAP
- AL_RN_SECONDARY_WAN_TUNNEL_DOWN
- AL_RN_SECONDARY_WAN_TUNNEL_FLAP
- AL_RN_SITE_DOWN
- AL_RN_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_RN_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- AL_RN_SPN_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_SC_PRIMARY_WAN_BGP_DOWN
- AL_SC_PRIMARY_WAN_BGP_FLAP
- AL_SC_PRIMARY_WAN_TUNNEL_DOWN
- AL_SC_PRIMARY_WAN_TUNNEL_FLAP
- AL_SC_SECONDARY_WAN_BGP_DOWN
- AL_SC_SECONDARY_WAN_BGP_FLAP
- AL_SC_SECONDARY_WAN_TUNNEL_DOWN
- AL_SC_SECONDARY_WAN_TUNNEL_FLAP
- AL_SC_SITE_DOWN
- AL_SC_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_SC_SITE_LONG_DURATION_EXCEEDED_CAPACITY
- AL_ZTNA_CONNECTOR_APP_STATUS_DOWN
- AL_ZTNA_CONNECTOR_APP_STATUS_DOWN_PARTIAL
- AL_ZTNA_CONNECTOR_CPU_HIGH
- AL_ZTNA_CONNECTOR_MEMORY_HIGH
- AL_ZTNA_CONNECTOR_TUNNEL_DOWN
- New Features in Incidents and Alerts
- Known Issues
Integrate Prisma Access with Riverbed SteelConnect SD-WAN
Where Can I Use This? | What Do I Need? |
---|---|
|
|
Use this workflow to configure three sites to use a ClassicVPN tunnel to establish
VPN connectivity with Prisma Access. Match the configuration in SCM with the
configuration in Prisma Access. Each management interface has its own default
settings, so we recommend that you confirm each setting between SCM and
Panorama.
This workflow assumes that you have already configured the remote network tunnel
for the tunnels you want to create. You need the IP address of the Prisma Access
side of the tunnel to complete this configuration. To find this address in
Panorama, select PanoramaCloud ServicesStatusNetwork Details and find the Service IP Address in the
Remote Networks area.
The following figure shows a total of six RouteVPN tunnels. They are identified by
solid orange lines. SteelConnect automatically forms these tunnels over the internet
WAN between SteelConnect appliances. Three of these tunnels use the internet between
sites, and the other three use the MPLS cloud between sites. These tunnels form the
overlay network. This term is an abstraction of the internet and WAN in
which the gateways communicate with each other. The communication for the overlay
network takes place on an underlay network. The underlay network is the
series of network devices owned by a provider or customer making up a network
infrastructure.

The organizational networking defaults you set in SCM determine how the SD-WAN
processes traffic. For traffic going to the internet breakout, the traffic uses the
internet uplink. For traffic between sites, the SD-WAN prefers the RouteVPN over the
internet uplink over the RouteVPN over the MPLS WAN. Based on organizational
defaults, SCM automates the creation of a full-mesh RouteVPN over the internet
uplink and establishes encrypted tunnels over the MPLS network.
The following figure shows the internet breakout preferences as defined in SCM.

The following diagram illustrates the logical traffic flow. The traffic between
ThousandOaks and New York, HQ and New York, and HQ and ThousandOaks takes the
RouteVPN over the MPLS overlay by default, while traffic from each branch to the
internet takes the internet uplink by default. The workflow in this section
configures ClassicVPN tunnels and defines traffic rules in SCM so that traffic from
the SD-WAN to the internet takes the ClassicVPN tunnels to Prisma Access.

You can override organizational defaults by Traffic Path rules. The following figure
shows an SCM configuration that directs traffic between the New York site
172.16.3.0/24 subnet to the HQ 172.16.1.0/24 subnet or the ThousandOaks
172.16.2.0/24 subnet to use the RouteVPN tunnel instead of the ClassicVPN tunnels
used for internet traffic. The settings in SCM specify these tunnels to use the MPLS
WAN.

Internet traffic uses the ClassicVPN tunnel at each site. Traffic from the New York
LAN to the internet uses the ClassicVPN tunnel in New York. Traffic from
ThousandOaks to the internet uses the ClassicVPN tunnel in ThousandOaks, and traffic
from HQ to the internet uses the ClassicVPN tunnel in HQ.
This workflow creates and configures ClassicVPN tunnels between the SteelConnect
SD-WAN and Prisma Access.
- In SCM, select Network DesignClassicVPN.
- Create the ClassicVPN connection by completing the following steps:
- Click New ClassicVPN connection.
- Enter a Name for the connection.
- Enter the Remote Gateway address.The remote gateway address is the Service IP Address for the remote network in Prisma Access. To find this IP address in Panorama, select PanoramaCloud ServicesStatusNetwork Details and note the Service IP Address for the remote network. You must create a remote network tunnel in Prisma Access before you complete this workflow.
- Enter the Remote IPv4 network.In this case, the remote network is 0.0.0.0/0, because SCM should route all traffic that does not have a more specific route (that is, internet-bound traffic) over the ClassicVPN.
- Select the source Site.
- Select the source Zones.In this example, traffic from LAN1 at HQ is sent over the ClassicVPN connection if a more specific route does not exist in the routing table of the gateway. For additional details on how packets are processed by the SteelConnect network, see How a Packet Traverses a SteelConnect Network in the SteelConnect SD-WAN Deployment Guide.There is an additional zone listed in the following figure: NY-LAN2. In the workflow inConfigure Internet Breakout from a Single Site to Prisma Access, internet traffic from the New York office is backhauled through the HQ site. Create this zone to establish the VPN tunnel. If you remove the NY-LAN2 zone from the configuration, the tunnel will go down.In addition, you must match any zones you create here, including any subnets, on the Prisma Access side. For example, this tunnel includes the 172.16.1.0/24 subnet (for the HQ site) and the 172.16.4.0/24 subnet (for the NY-LAN2 site). You also specified these subnets in Prisma Access for each remote network you created. To view these subnets in Panorama, select PanoramaCloud ServicesConfigurationRemote Networks and view the information in the Branch IP Subnets field.There are default values that SCM creates for you when you deploy a ClassicVPN. If you use the default values in SCM, you will need to edit the configuration in Panorama. If you use the defaults in Panorama, you will need to edit the configuration in SCM. Both sides must match. Our HQ configuration will match the Panorama configuration.
- Adjust the configuration in SCM by completing the following steps:
- Select the Authentication tab.
- Enter the Pre-shared Key to match what is configured in Panorama.
- Click Submit.
- Configure advanced tunnel settings by completing the following steps:
- Click the Advanced tab.
- Enter the Local ID.The Local-ID is the proxy-ID seen in the IPSec tunnel negotiation. If the Proxy-ID isn't known on both ends, the tunnel will fail. This configuration was tested using the IP address as the endpoint ID instead of FQDN.
- Enter the Remote ID.The remote ID is the tunnel endpoint IP address in Prisma Access.
- Click Submit.
- Configure IKE settings (Phase 1) and IPSec (Phase 2) encryption settings by completing the following steps.IPSec VPNs establish in two phases, IKE phase 1 and IPSec phase 2. Phase 1 is used to create a secure channel in which parameters that apply to the data being encrypted are negotiated. In SCM, the IKE settings are for the phase 1 tunnel. The phase 2 tunnel negotiation defines how the user traffic is encrypted from the SteelConnect gateway to Prisma Access.The example used in this workflow creates an IKE tunnel with AES128 encryption, SHA1 hashing, and a lifetime of 28,800 seconds (8 hours).
- Scroll down in the Advanced tab and select IKEv1.IKEv1 uses the phase 1 and phase 2 method of negotiation, while IKEv2 creates parent and child security associations.
- Select AES128.
- Select SHA1.
- Enter 28800 in the IKE lifetime field.This setting specifies the length of time that the IKE phase 1 tunnel remains up before it renegotiates.
- Select AES256 as the IPSec encryption cipher
- . Select SHA1 in the IPSec has algorithm field.
- Select DH Group 2 (1024 bit) in the IPSec DH Group field.
- Enter an IPSec lifetime of 2600 seconds.
- Click Submit.
After submitting this configuration, the tunnel begins to establish. Once the tunnel establishes, you receive an event notification in SCM and the tunnel status displays as Online, as seen in the following figure. - Repeat the steps in this workflow to add additional sites.
Configure the SteelConnect Tunnels
Since the configuration steps are the same for additional branches, this workflow
does not document the workflow for all tunnels. However, you must complete the
following tasks after you add the two branch sites:
- If you use the SCM default values to create the tunnel in SCM, the Local ID is set as the FQDN. If the remote end supports FQDN (as Prisma Access does), you don't need to change this setting. If the remote end does not support FQDN, you must change this setting.
- SteelConnect creates a randomly generated pre-shared key. If you choose to use this key, you need to copy it and enter it in Prisma Access.
- Copy the autogenerated pre-shared key by completing the following steps:
- In SCM, click Authentication.
- Click Reveal to the right of the Preshared Key field.
- Copy the pre-shared key.
- (Optional) Modify the Local ID, if required, by completing the following steps:
- Click Advanced.
- Enter the Local ID.
- Enter the Remote ID.
- Click Submit.There are now three established ClassicVPN sessions from each site to Prisma Access.
- Either modify the default rule, or disable it and add a new rule.The default outbound rule allows user traffic on the ClassicVPN. Since a 0.0.0.0/0 remote network is defined in the ClassicVPN configuration, the SD-WAN sends all traffic that does not have a more specific route in the routing table over the ClassicVPN to Prisma Access.The following SCM output shows the default outbound rules using internet Access as the target.
- Modify the default outbound rule, or add a new one as shown in the following figure, to allow sites to communicate over the RouteVPN.
- (Optional) Add traffic rules to direct specific traffic over selected links.
Configure the Tunnel in Prisma Access
After you configure the tunnel in SCM, configure the tunnel settings in Prisma
Access to match the SCM settings.
- Select NetworkRemote_Network_TemplateNetwork ProfilesIPSec Crypto.
- Click Add and create an IPSec cryptographic profile with settings that match the settings you made for the ClassicVPN tunnel in SCM.These settings are for the Phase 2 tunnel establishment.
- Select NetworkRemote_Network_TemplateNetwork ProfilesIKE Crypto.
- Click Add and create an IKE cryptographic profile with settings that match the settings you made for the ClassicVPN tunnel in SCM.These settings are for the Phase 1 tunnel establishment.The encryption, authentication, and timer policy rules don't need to be identical between the IPSec and IKE crypto policy rules; however, whatever policy rules you configure must be identical on the SteelConnect gateways and Prisma Access. If the IKE Profile uses AES-128-CBC on the gateway, then you must configure the IKE Crypto profile in Prisma Access to match. If the IPSec settings on the gateway are set to use AES-256, then you must configure the IPSec Crypto Profile in Prisma Access to match.
Configure Internet Breakout from a Single Site to Prisma Access
This workflow configures SCM to backhaul internet traffic from the NY office over
the RouteVPN and then send it to the internet over the ClassicVPN by way of
Prisma Access, as shown in the following figure.

Complete the following to set up a backhauled internet configuration.
- Create a traffic rule that forces traffic between sites to use RouteVPN tunnels.
- Edit the traffic rule so that the tunnel the NY-LAN2 and HQ-LAN1 uses the MPLS tunnel by default.This configuration ensures that traffic from the NY site to the internet is first backhauled to HQ using the MPLS connection.
Troubleshoot the Riverbed SteelConnect Remote Network
Prisma Access provides logs that provide you with the status of remote tunnels
and the status of each tunnel. To view these logs in Panorama, select MonitorLogsSystem.
To debug tunnel issues, you can filter for tunnel-specific logs by using the
object identifier corresponding to that tunnel. The following figures show
errors related to tunnel misconfiguration and negotiation issues.





