Prisma Access
Onboard an Azure Virtual Network
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)
- Enable Dynamic Privilege Access 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
-
- Onboard Prisma Access
-
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 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
- 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
- Configure Proxy Chaining with Blue Coat 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
-
-
- 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_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_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_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
Onboard an Azure Virtual Network
Onboard an Azure virtual network (VNet) to Prisma Access and secure access to it for
mobile users and remote networks.
Where Can I Use This? | What Do I Need? |
---|---|
|
|
When you deploy your organization’s resources using a Microsoft Azure virtual network
(VNet), you can secure these resources with Prisma Access. To do so, you onboard an
existing or new VNet to Prisma Access as a remote network. You also configure
settings for a remote network tunnel (a site-to-site tunnel between Prisma Access
and the Azure VNet) and use BGP to dynamically route traffic between them.
The following diagram shows the topology used to secure an Azure instance with Prisma
Access.

For Azure-specific information about creating a site-to-site connection, see the
Microsoft Azure document Create a Site-to-Site connection in the Azure
portal.
Onboard an Azure Virtual Network (Strata Cloud Manager)
Onboard an Azure virtual network (VNet) to Prisma Access and secure access to it for
mobile users and remote networks.
Configure a Virtual Network and Virtual Network Gateway on Azure
The Azure virtual network uses a virtual network gateway for its side of the VPN
tunnel to Prisma Access. This gateway uses a subnet called GatewaySubnet. The
GatewaySubnet contains IP addresses used for virtual network gateway resources
and services and is part of the virtual network IP address range that you
specify when you configure your virtual network on Azure.
Each Azure VPN gateway incorporates high availability by having two instances per
gateway in an active-standby configuration. If an active instance goes down for
planned maintenance or an unplanned outage, the instance automatically fails
over to the standby instance and resumes the site-to-site VPN connections. For a
planned maintenance, Azure restores the connectivity in approximately 10 to 15
seconds. For an unplanned outage, Azure restores the connectivity in
approximately 1 minute to 90 seconds.
Create the virtual network and virtual network gateway using the following
task.
By default, Azure will not direct internet traffic to the VPN tunnel you
create in this task. To
secure internet-bound traffic
with Prisma Access
, enable forced tunneling on Azure using
PowerShell commands. - In Azure, create your virtual network, if you have not already created it. See the Microsoft Azure documentation for details.
- Create a subnet for the gateway.You must name the subnet GatewaySubnet to let Azure deploy its gateway resources and Azure does not allow the use of another subnet name. Without a subnet named GatewaySubnet, gateway creation fails.
- In the Azure portal, navigate to the virtual network where you want to create a virtual network gateway.
- On your virtual network page, click Subnets to expand the Subnets page for the virtual network you created.
- Click +Gateway subnet at the top to open the Add subnet page.
- Add the address and click OK.
- Add a virtual network gateway.
- On the left side of the portal page, click +Create a resource and type Virtual Network Gateway in the search box, then press Enter.
- In Results, locate and click Virtual network gateways.
- At the bottom of the Virtual network gateway page, click Create virtual network gateway.
- Enter values similar to the values on the following screenshot and click Create.It may take up to 30 minutes to create the virtual network gateway.
- After Azure creates the virtual network gateway, select the virtual network gateway you created, click Overview, and make a note of the Public IP address assigned to the virtual network gateway.
- Click Configuration and make a note of the BGP ASN and BGP peer IP address(es) fields.
Configure IKE, IPSec, and BGP and Onboard the Azure VNet in Prisma Access
After you perform the initial configuration on Azure, create IKE and IPSec
security profiles and policies and a remote network connection in Prisma
Access.
For assistance with configuring security parameters on Azure, see the Microsoft
Azure documents About VPN devices and IPsec/IKE parameters
for Site-to-Site VPN Gateway connections and About cryptographic requirements and Azure
VPN gateways.
- In Strata Cloud Manager, select WorkflowsPrisma Access SetupRemote Networks.
- (Optional) If you have not already, allocate bandwidth for the remote network under Bandwidth Management.You allocate bandwidth by selecting bandwidth for the remote network’s compute location. Select an Assigned Bandwidth for the remote network’s compute location.
- Go to Remote Networks and Add Remote Networks.
- Give the remote network a descriptive Site Name.
- Select the Prisma Access Location that is closest to your Azure VNet.
- Select the IPSec Termination Node to use for the remote network.
- Enable ECMP Load Balancing.
- Set up the IPSec tunnel for the Azure gateway.
- Set Up the primary tunnel.
- Select an existing tunnel, or select Create New to create a new tunnel.
- Give the tunnel a descriptive Name.
- Select the Branch Device Type for the IPSec device at the remote network site that you’re using to establish the tunnel with Prisma Access.
- Specify a Pre-Shared Key.
- Specify a Branch Device IP Address of either Static IP or Dynamic IP.Setting up an IKE Peer Identification is required if you use a dynamic IP address. If you select Static IP, enter a static IP address.
- Select IKE Advanced Options, create an IPSec crypto profile for the IPSec tunnel, and Save the changes.The IPSec crypto settings you specify here must match the settings you specify on Azure. To set IKE and IPSec policies in Azure, see the Microsoft Azure documentation.
- Select IPSec Advanced Options, create an IKEv1 crypto profile for the gateway, and Save the changes.
- Set Up BGP routing.
- Enable BGP for Dynamic Routing.
- Enter the Peer Address value from Azure in the Peer IP address field and enter the Autonomous system number (ASN) value from Azure in the Peer AS field.
- (Optional) Enter an address that Prisma Access uses as its Local IP Address for BGP.Make sure that the address you specify does not conflict or overlap with IP addresses in the Infrastructure Subnet or subnets in the remote network.You must configure a static route on your CPE to the BGP local address.
- Save the changes.
- Commit and Push your configuration.
- After the onboarding process completes, and make a note of the value in the Service IP field.
Set up Network Connectivity from your Azure Virtual Network
After you configure the remote network in Prisma Access, complete the
configuration on Azure by performing the following task.
For additional information about configuring BGP on Azure, see the Microsoft
Azure document Overview of BGP with Azure VPN
Gateways.
- In Azure, create a local network gateway.
- In the Search resources, services, and docs search box, type local network gateways.
- Click +Add.
- Enter the following values in the text box that displays.
- Enter a Name for the gateway.
- Enter an IP address. Use the Service IP Address from the remote network in Prisma Access in step7.
- Check Configure BGP settings and enter a unique Autonomous system number (ASN) and BGP peer IP address.
- Enter a Subscription, Resource group, and Location for the gateway.
- Click Create.
- Create a virtual network connection.
- Navigate to and open the page for the virtual network gateway you created when youconfigured a virtual network and virtual network gateway on Azure.See the Microsoft Azure documentation for details.
- On the page for the virtual network gateway, click Connections. At the top of the Connections page, click +Add to open the Add connection page.
- Enter values for the new connection, then click OK.In the Shared key (PSK) field, use the same Pre-shared Key that you used when you created the IKE gateway in Prisma Access.
- Click OK.
- Add a new route table to use for BGP routing.
- Select +Create a resource on the upper left corner of the Azure portal.
- Select Networking, then select Route table.
- Add a Name, Subscription, Resource Group, and Location.
- Set BGP route propagation to Enabled.
- Click Create.
- Associate a subnet to the route table you created.
- Open the route table you created.
- Select SettingsSubnets.
- Click Associate to add a subnet.
- In the Associate subnet column, click Virtual network.
- Select the virtual network you created when youconfigured a virtual network and virtual network gateway on Azure.
- Click OK.
Verify Remote Network Connectivity
To verify that the IPSec tunnel between Azure and Prisma Access is operational,
perform the following steps:
- In Azure, select the Connection you created and click Overview.The tunnel should show a status of Connected.
- Verify that the BGP routes are being advertised on Azure.
- Open the route table you just created.
- Select NetworkingSettings.
- Select the name of a network interface.
- Select Support + troubleshootingEffective routes.
- Verify that the BGP routes are being advertised.
- Check the remote network and BGP status in Prisma Access.In Strata Cloud Manager, select WorkflowsPrisma Access SetupRemote Networks.The Config Status should be In Sync and verify the BGP Status in Routing Information.
Secure Internet-Bound Traffic with Prisma Access
If you enable BGP, the virtual network gateway does not use static routes and
uses only the routes it learns from BGP advertisements.
To secure all traffic to and from Azure, you must force traffic to pass through
Prisma Access. You do this by enabling the forced tunneling feature on
Azure.
Enabling forced tunneling may result in a loss of connectivity to virtual
network instances over the internet. Make sure that you use another
connection method (for example, a bastion host) to connect to instances over
the internet.
You configure forced tunneling by using PowerShell CLI commands in your Azure
account as described in the following task. For more details about forced
tunneling, see the Microsoft Azure document Configure forced tunneling using the Azure
Resource Manager deployment model.
To enable the feature, complete the following workflow.
These commands are examples. If you use different variables for your route
tables, virtual network gateways, subnets, or resource groups, substitute
those values in the commands provided in this task.
- Log into your PowerShell console with elevated privileges, and connect to your account.
- Create a new route table by entering the following commands:
> New-AzureRmRouteTable -Name "DefRouteTable" -ResourceGroupName "GPCS-PM-TME" -Location "WEST US"
> $rt = Get-AzureRmRouteTable -Name "DefRouteTable" -ResourceGroupName "GPCS-PM-TME"
> Add-AzureRmRouteConfig -Name "DefaultRoute" -AddressPrefix "0.0.0.0/0" -NextHopType VirtualNetworkGateway -RouteTable $rt
> Set-AzureRmRouteTable -RouteTable $rt
- Modify the subnet configuration by entering the following commands:
> $vnet = Get-AzureRmVirtualNetwork -Name "GPCS-Onboarding-VMNET" -ResourceGroupName "GPCS-PM-TME"
> Set-AzureRmVirtualNetworkSubnetConfig -Name "GPCS-O-Subnet-1" -VirtualNetwork $vnet -AddressPrefix "10.200.1.0/24" -RouteTable $rt
> Set-AzureRmVirtualNetwork -VirtualNetwork $vnet
- Enable the default route for the network gateway default site by entering the following commands.
> $LocalGateway = Get-AzureRmLocalNetworkGateway -Name "GPCS-Gateway-US-WEST" -ResourceGroupName "GPCS-PM-TME"
> $VirtualGateway = Get-AzureRmVirtualNetworkGateway -Name "GPCS-Onboarding-Gateway" -ResourceGroupName "GPCS-PM-TME"
> Set-AzureRmVirtualNetworkGatewayDefaultSite -GatewayDefaultSite $LocalGateway -VirtualNetworkGateway $VirtualGateway
Onboard an Azure Virtual Network (Panorama)
Onboard an Azure virtual network (VNet) to Prisma Access and secure access to it for
mobile users and remote networks.
Configure a Virtual Network and Virtual Network Gateway on Azure
The Azure virtual network uses a virtual network gateway for its side of the VPN
tunnel to Prisma Access. This gateway uses a subnet called GatewaySubnet. The
GatewaySubnet contains IP addresses used for virtual network gateway resources
and services and is part of the virtual network IP address range that you
specify when you configure your virtual network on Azure.
Each Azure VPN gateway incorporates high availability by having two instances per
gateway in an active-standby configuration. If an active instance goes down for
planned maintenance or an unplanned outage, the instance automatically fails
over to the standby instance and resumes the site-to-site VPN connections. For a
planned maintenance, Azure restores the connectivity in approximately 10 to 15
seconds. For an unplanned outage, Azure restores the connectivity in
approximately 1 minute to 90 seconds.
Create the virtual network and virtual network gateway using the following
task.
By default, Azure will not direct internet traffic to the VPN tunnel you
create in this task. To
secure internet-bound traffic
with Prisma Access
, enable forced tunneling on Azure using
PowerShell commands. - In Azure, create your virtual network, if you have not already created it. See the Microsoft Azure documentation for details.
- Create a subnet for the gateway.You must name the subnet GatewaySubnet to let Azure deploy its gateway resources and Azure does not allow the use of another subnet name. Without a subnet named GatewaySubnet, gateway creation fails.
- In the Azure portal, navigate to the virtual network where you want to create a virtual network gateway.
- On your virtual network page, click Subnets to expand the Subnets page for the virtual network you created.
- Click +Gateway subnet at the top to open the Add subnet page.
- Add the address and click OK.
- Add a virtual network gateway.
- On the left side of the portal page, click +Create a resource and type Virtual Network Gateway in the search box, then press Enter.
- In Results, locate and click Virtual network gateways.
- At the bottom of the Virtual network gateway page, click Create virtual network gateway.
- Enter values similar to the values on the following screenshot and click Create.It may take up to 30 minutes to create the virtual network gateway.
- After Azure creates the virtual network gateway, select the virtual network gateway you created, click Overview, and make a note of the Public IP address assigned to the virtual network gateway.
- Click Configuration and make a note of the BGP ASN and BGP peer IP address(es) fields.
Configure IKE, IPSec, and BGP and Onboard the Azure VNet in Prisma Access
After you perform the initial configuration on Azure, create IKE and IPSec
security profiles and policies and then create a remote network connection in
Prisma Access using Panorama.
For assistance with configuring security parameters on Azure, see the Microsoft
Azure documents About VPN devices and IPsec/IKE parameters
for Site-to-Site VPN Gateway connections and About cryptographic requirements and Azure
VPN gateways.
- In Panorama, select Remote_Network_Template from the Template drop-down.
- Select NetworkNetwork ProfilesIKE Crypto and Add an IKE crypto profile for the gateway.Make a note of these settings; the IKE crypto settings you specify here must match the settings you specify on Azure. To set IKE and IPSec policies in Azure, see the Microsoft Azure documentation. The screenshot in the following figure uses the following settings:
- DH Group: group2
- Encryption: aes-256-cbc
- Authentication: sha1
- Key Lifetime: 8 Hours
- Select NetworkNetwork ProfilesIPSec Crypto and Add an IPSec crypto profile for the IPSec tunnel.The IPSec crypto settings you specify here must match the settings you specify on Azure; to set IKE and IPSec policies in Azure, see the Microsoft Azure documentation. The screenshot in the following figure uses the following settings:
- IPSec Protocol: ESP
- DH Group: no-pfs
- Lifetime: 8 Hours
- Encryption: aes-256-gcm
- Authentication: none
- Select NetworkNetwork ProfilesIKE Gateways and Add an IKE gateway.
- In the General tab, change the Peer ID Address Type to IP.
- In the Peer Address field, enter the Public IP address from the Overview screen on Azure.
- Enter a Pre-shared Key.Make a note of this key. You use it later when youSet up Network Connectivity from your Azure Virtual Network.
- Click OK.
- Select NetworkIPSec Tunnels and Add an IPSec tunnel for the Azure gateway, specifying the IKE gateway and IPSec Crypto Profile that you created earlier in this task.
- Select PanoramaCloud ServicesConfigurationRemote Networks and Add the Azure VPN as a remote network.Specify the following choices:
- Select a Location that is closest to your Azure VNet.
- Select the IPSec Termination Node that you want to use for this remote network.Prisma Access uses this node to associate remote network locations with compute locations.
- Specify the IPSec primary tunnel that you just created in the IPSec Tunnel field.
- Configure BGP routing.
- Click the BGP tab.
- Enter the Autonomous system number (ASN) value from Azure in the Peer AS field and enter the Peer Address value from Azure in the BGP peer IP address(es) field.
- (Optional) Enter an address that Prisma Access uses as its Local Address for BGP.Make sure that the address you specify does not conflict or overlap with IP addresses in the Infrastructure Subnet or subnets in the remote network.You must configure a static route on your CPE to the BGP Local Address.
- Click OK.
- Commit and Push your configuration.
- After the onboarding process completes, select PanoramaCloud ServiceStatusNetwork DetailsRemote Networks and make a note of the value in the Service IP Address field.
Set up Network Connectivity from your Azure Virtual Network
After you configure the remote network in Prisma Access, complete the
configuration on Azure by performing the following task.
For additional information about configuring BGP on Azure, see the Microsoft
Azure document Overview of BGP with Azure VPN
Gateways.
- In Azure, create a local network gateway.
- In the Search resources, services, and docs search box, type local network gateways.
- Click +Add.
- Enter the following values in the text box that displays.
- Enter a Name for the gateway.
- Enter an IP address. Use the Service IP Address from the remote network in Prisma Access (PanoramaCloud ServiceStatusNetwork DetailsRemote Networks).
- Check Configure BGP settings and enter a unique Autonomous system number (ASN) and BGP peer IP address.
- Enter a Subscription, Resource group, and Location for the gateway.
- Click Create.
- Create a virtual network connection.
- Navigate to and open the page for the virtual network gateway you created when youconfigured a virtual network and virtual network gateway on Azure.See the Microsoft Azure documentation for details.
- On the page for the virtual network gateway, click Connections. At the top of the Connections page, click +Add to open the Add connection page.
- Enter values for the new connection, then click OK.In the Shared key (PSK) field, use the same Pre-shared Key that you used when you created the IKE gateway in Prisma Access.
- Click OK.
- Add a new route table to use for BGP routing.
- Select +Create a resource on the upper left corner of the Azure portal.
- Select Networking, then select Route table.
- Add a Name, Subscription, Resource Group, and Location.
- Set BGP route propagation to Enabled.
- Click Create.
- Associate a subnet to the route table you created.
- Open the route table you created.
- Select SettingsSubnets.
- Click Associate to add a subnet.
- In the Associate subnet column, click Virtual network.
- Select the virtual network you created when youconfigured a virtual network and virtual network gateway on Azure.
- Click OK.
Verify Remote Network Connectivity
To verify that the IPSec tunnel between Azure and Prisma Access is operational,
perform the following steps:
- In Azure, select the Connection you created and click Overview.The tunnel should show a status of Connected.
- Verify that the BGP routes are being advertised on Azure.
- Open the route table you just created.
- Select NetworkingSettings.
- Select the name of a network interface.
- Select Support + troubleshootingEffective routes.
- Verify that the BGP routes are being advertised.
- Check the remote network and BGP status in Prisma Access.In Panorama, select PanoramaCloud ServicesStatusMonitorRemote NetworksStatus.The Config Status should be In Sync and the BGP Status should be Established.
Secure Internet-Bound Traffic with Prisma Access
If you enable BGP, the virtual network gateway does not use static routes and
uses only the routes it learns from BGP advertisements.
To secure all traffic to and from Azure, you must force traffic to pass through
Prisma Access. You do this by enabling the forced tunneling feature on
Azure.
Enabling forced tunneling may result in a loss of connectivity to virtual
network instances over the internet. Make sure that you use another
connection method (for example, a bastion host) to connect to instances over
the internet.
You configure forced tunneling by using PowerShell CLI commands in your Azure
account as described in the following task. For more details about forced
tunneling, see the Microsoft Azure document Configure forced tunneling using the Azure
Resource Manager deployment model.
To enable the feature, complete the following workflow.
These commands are examples. If you use different variables for your route
tables, virtual network gateways, subnets, or resource groups, substitute
those values in the commands provided in this task.
- Log into your PowerShell console with elevated privileges, and connect to your account.
- Create a new route table by entering the following commands:
> New-AzureRmRouteTable -Name "DefRouteTable" -ResourceGroupName "GPCS-PM-TME" -Location "WEST US"
> $rt = Get-AzureRmRouteTable -Name "DefRouteTable" -ResourceGroupName "GPCS-PM-TME"
> Add-AzureRmRouteConfig -Name "DefaultRoute" -AddressPrefix "0.0.0.0/0" -NextHopType VirtualNetworkGateway -RouteTable $rt
> Set-AzureRmRouteTable -RouteTable $rt
- Modify the subnet configuration by entering the following commands:
> $vnet = Get-AzureRmVirtualNetwork -Name "GPCS-Onboarding-VMNET" -ResourceGroupName "GPCS-PM-TME"
> Set-AzureRmVirtualNetworkSubnetConfig -Name "GPCS-O-Subnet-1" -VirtualNetwork $vnet -AddressPrefix "10.200.1.0/24" -RouteTable $rt
> Set-AzureRmVirtualNetwork -VirtualNetwork $vnet
- Enable the default route for the network gateway default site by entering the following commands.
> $LocalGateway = Get-AzureRmLocalNetworkGateway -Name "GPCS-Gateway-US-WEST" -ResourceGroupName "GPCS-PM-TME"
> $VirtualGateway = Get-AzureRmVirtualNetworkGateway -Name "GPCS-Onboarding-Gateway" -ResourceGroupName "GPCS-PM-TME"
> Set-AzureRmVirtualNetworkGatewayDefaultSite -GatewayDefaultSite $LocalGateway -VirtualNetworkGateway $VirtualGateway
Troubleshoot the Site-to-Site Connection
Use the procedures in this section to troubleshoot any issues you have with
tunnel creation.
- To troubleshoot the site-to-site connection in Prisma Access, log in to Panorama and select LogsSystem, then enter (subtype eq vpn) in the Filter field to view messages related to VPN tunnel creation.
- To troubleshoot the site-to-site connection on Azure, you can download the VPN gateway configuration on Azure by selecting NetworkingSettings, selecting the name of a network interface. selecting Support + troubleshootingEffective routes, and clicking Download.