Onboard and Configure Remote Networks
Table of Contents
Expand All
|
Collapse All
Prisma Access Docs
-
- Prisma Access China
- 4.0 & Later
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
-
-
-
- 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
Onboard and Configure Remote Networks
Onboard your remote network connections, including determining
the compute regions to use when you allocate remote network bandwidth
by region.
For each remote network that you want to secure
using Prisma Access for networks, you must use the following workflow
to push the required policy configuration to Prisma Access and onboard
each remote network so that you can start sending traffic from the
remote site through the IPSec tunnel to Prisma Access.
Use
one of the following workflows to onboard your remote networks:
- If you have a new deployment, or if you have an existing deployment that wants to migrate to allocating bandwidth by compute location, use the workflow to allocate bandwidth by compute location, also known as the bandwidth allocation model.Not all existing deployments can upgrade to the bandwidth allocation model. See Plan to Deploy Remote Networks for details.
- If you have an existing deployment with onboarded remote networks and you want to continue to allocate bandwidth per remote network location, or if you have a deployment that cannot migrate to the bandwidth allocation model, use the workflow to allocate bandwidth by remote network location.
Before
you begin onboarding your remote networks, be sure you go through
the steps to Plan to Deploy Remote Networks.
Configure Prisma Access for Networks—Configure Bandwidth by Compute Location
If you need to onboard many remote network
locations, onboard a remote network using this workflow and then import
the remote network configuration.
- Select PanoramaCloud ServicesConfigurationRemote Networks and edit the
settings by clicking the gear icon in the Settings area.
- In the Templates section, Add any
templates that contain configuration you want to push to Prisma
Access for networks. For example, if you have existing templates
that contain your zone configurations, or IPSec tunnel, IKE Gateway,
or crypto profile settings, you can add them to the predefined Remote_Network_Template_Stack
to simplify the onboarding process.You can Add more than one template to the stack and then order them appropriately using Move Up and Move Down. This is important because Panorama evaluates in the stack from top to bottom, with settings in templates higher in the stack taking priority over the same settings specified in templates lower in the stack. Note that you cannot move the default template from the top of the stack.Although you can add existing templates to the stack from the plugin, you cannot create a new template from the plugin. Instead, use the workflow to add a new template.
- Select the Parent Device Group for
Prisma Access for remote networks. You can select an existing device
group or use Shared.You will push all of the configuration—including the security policy, security profiles, and other policy objects (such as application groups and objects, and address groups), HIP objects and profiles and authentication policy—that Prisma Access for networks needs to enforce consistent policy to your remote network users using the device group hierarchy you specify here.You don’t need to define all of the policy that you will push to the remote network yet. Instead, configure the settings to onboard the remote site. You can then go back and add the templates and device groups with the complete configurations to push consistent policy out to your remote networks.
- If you will be configuring remote networks that have
overlapping subnets, select the Overlapped Subnets check
box to enable outbound internet access for those locations.While configuring Remote Network Locations with Overlapping Subnets introduces some limitations, it is acceptable in some cases (for example, if you want to add a guest network at a retail store location).
- In the Templates section, Add any
templates that contain configuration you want to push to Prisma
Access for networks. For example, if you have existing templates
that contain your zone configurations, or IPSec tunnel, IKE Gateway,
or crypto profile settings, you can add them to the predefined Remote_Network_Template_Stack
to simplify the onboarding process.
- (Optional) Configure DNS Proxy settings
for your remote network.Prisma Access allows you to specify DNS servers to resolve both domains that are internal to your organization and external domains. If you do not specify any settings, Prisma Access does not proxy DNS requests for remote networks.
- In the Remote_Network_Device_Group device
group, select PoliciesSecurity and Add a
security policy rule with an Application of DNS and
an Action of Allow to
allow DNS traffic. Without a security policy rule to allow DNS traffic, DNS resolution does not occur.
- If you configure Prisma Access to proxy the DNS requests from your remote networks, update the DNS settings on all the endpoints in that network to use the Prisma Access Remote Network DNS Proxy IP Address as the primary DNS server and use your DNS server as secondary DNS server. You can get this DNS proxy IP from PanoramaCloud ServicesStatus Network DetailsService Infrastructure.
- Add one or more DNS
Proxy settings, entering the following values:
- Select a Region from the drop-down at the top of the window.Select a specific region, or select Worldwide to apply the DNS settings globally. If you specify multiple proxy settings with a mix of regional and Worldwide regions, Prisma Access uses the regional settings for the Locations in the region or regions you specify and uses the worldwide settings elsewhere. Prisma Access evaluates the rules from top to bottom in the list.
- Add one or more rules to configure the DNS settings for Internal Domains.
- Enter a unique Rule Name for the rule.
- you want your internal DNS server to only resolve the domains you specify, enter the domains to resolve in the Domain List. Specify an asterisk in front of the domain; for example, *.acme.com. You can specify a maximum of 1,024 domain entries.
- If you have a Custom DNS server that can access your internal domains, specify the Primary DNS and Secondary DNS server IP addresses, or select Use Cloud Default to use the default Prisma Access DNS server.
- Specify the DNS settings for Public Domains.
- Use Cloud Default—Use the default Prisma Access DNS server.
- Same as Internal Domains—Use the same server that you use to resolve internal domains. When you select this option, the DNS Server used to resolve public domains is same as the server configured for the first rule in the Internal Domains section.
- Custom DNS server—If you have a DNS server that can access your public (external) domains, enter the Primary DNS server address in that field.
(Optional) You can Add a DNS Suffix to specify the suffix that the client should use locally when an unqualified hostname is entered that it cannot resolve, for example, acme.local. Do not enter a wildcard (*) character in front of the domain suffix (for example, acme.com). You can add multiple suffixes. - If you want Prisma Access to proxy DNS requests, configure Configure values for the use for UDP queries (the Interval to retry the query in seconds and the number of retry Attempts to perform).If you want Prisma Access to proxy DNS requests for your GlobalProtect users, You must update your endpoints to use the Remote Network DNS Proxy IP Address as the primary DNS server (PanoramaCloud ServicesStatusNetwork DetailsService Infrastructure).
- In the Remote_Network_Device_Group device
group, select PoliciesSecurity and Add a
security policy rule with an Application of DNS and
an Action of Allow to
allow DNS traffic.
- (Optional) Configure Prisma Access to use the
Directory Sync service to retrieve user and group information.You must configure Directory Sync to retrieve user and group information from your Active Directory (AD) before you enable and configure Directory Sync integration in Prisma Access using the settings in the Group Mapping Settings tab. See Get User and Group Information Using the Cloud Identity Engine for details.
- Create new zones in the one of the templates in the stack
(Network > Zones> Add) or map the zones referenced
in existing templates you added to the stack as trusted or untrusted.
On Panorama, policy rules are defined in device groups, and zones
are defined in templates. Therefore, you need to make sure that
you add the templates that reference the zones included in your
policy rules to the template stack.On a Palo Alto Networks® next-generation firewall, security policy is enforced between zones, which map to physical or virtual interfaces on the firewall. But as Prisma Access for networks has only two zones, trust and untrust, you need to map any zone with traffic bound to the Internet (including your sanctioned SaaS applications) as untrust and all internal zones as trust.
- (Optional) Edit the zone
mapping settings.By default, all of the zones in Prisma Access for networks template stack a are classified as Untrusted Zones. If you have not yet defined zones or if the templates in the Remote_Network_Template_Stack do not have zone configurations, you can come back and add them when you push policy to Prisma Access for networks.
- For each zone you want to designate as trusted, select it and click Add to move it to the list of Trusted Zones.
- Click OK to save the mappings.
- (Optional) Edit the zone
mapping settings.
- Allocate bandwidth for the locations that you want to
onboard by clicking the gear icon in the Bandwidth Allocation area.You allocate bandwidth at an aggregate level per compute location. See Plan to Deploy Remote Networks for details.If you have an existing remote networks deployment that currently onboards remote networks by location, a pop-up window displays, asking if you want to migrate to the bandwidth allocation model. Click Migrate to continue, or Cancel to cancel the migration. The Service IP Address addresses (the public IP addresses used on the Prisma Access side of the IPSec tunnel for the remote network connection) do not change when you migrate your deployment.The migration to the aggregate bandwidth model is permanent and not reversible. Before you migrate, review the migration checklist. You must Commit and Push your changes for them to take effect.
- Enter the Bandwidth Allocation you
want for each Compute Location that is associated
with the Prisma Access Locations you want
to onboard.To verify the bandwidth amount you entered, select the check mark next to the bandwidth amount; to cancel the amount, select x.Specify a minimum bandwidth of 50 Mbps and a maximum bandwidth of the maximum remaining licensed bandwidth.
- Wait for the bandwidth to be reflected in the Allocated Total field at the top of the page; then, click OK.
- Click Add in the Onboarding settings,
and specify a Name to identify the infrastructure
that will secure the remote network location you are onboarding.You cannot change the name of the remote network location after you enter it. Make sure you know your naming scheme for your remote networks before you begin onboarding.
- (BGP
deployments only) Create a configuration so that your remote
network connection can use up to four IPSec tunnels for its traffic
(ECMP Load Balancing). QoS is not supported with ECMP load balancing, and static routes are not supported (BGP is required). If your deployment uses one IPSec tunnel for its remote network connection or uses static routes, select None for ECMP Load Balancing and continue to Step 12.
- Select one of the choices to enable or disable
ECMP load balancing.
- None—Do not use ECMP load balancing (use a single remote network tunnel for this remote network connection). This is the only choice you can make for static routes; BGP is required for ECMP load balancing.
- Enabled with Symmetric Return—Specify up to four IPSec tunnels for this remote network connection and force Prisma Access to use the same link for the return traffic as it used to send the traffic.Select this option if you use one or more tunnels as a backup tunnel to be used only if one of the primary tunnels go down. If a link fails, Prisma Access uses one of the other tunnels to send and receive traffic symmetrically.
- Add an IPSec tunnel for the
remote network connection and specify the following values:
- Enable—Enables BGP for the IPSec tunnel.This selection is not configurable; you must enable BGP to configure ECMP.
- Summarize Mobile User Routes before advertising—Reduces the number of mobile user IP subnet advertisements over BGP to your customer premises equipment (CPE) by summarizing them.By default, Prisma Access advertises the mobile users IP address pools in blocks of /24 subnets; if you summarize them, Prisma Access advertises the pool based on the subnet you specified. For example, Prisma Access advertises a public user mobile IP pool of 10.8.0.0/20 using the /20 subnet, rather than dividing the pool into subnets of 10.8.1.0/24, 10.8.2.0/24, 10.8.3.0/24, and so on before advertising them. Summarizing these advertisements can reduce the number of routes stored in CPE routing tables. For example, you can use IP pool summarization with cloud VPN gateways (Virtual Private Gateways (VGWs) or Transit Gateways (TGWs)) that can accept a limited number of routes.If you enable route summarization for a location that uses ECMP, you must enable route summarization on all links to that location, or you will receive an error during commit.Prisma Access sets the community string for aggregated mobile user routes to 0xFFFE:0xFFF0.
- Advertise Default Route—Prisma Access originates a default route advertisement for the remote network using eBGP.Be sure that your network does not have another default route being advertised by BGP, or you could introduce routing issues in your network.
- Don’t Advertise Prisma Access Routes—Prevents the Prisma Access BGP peer from forwarding routes into your organization’s network.By default, Prisma Access advertises all BGP routing information, including local routes and all prefixes it receives from other service connections, remote networks, and mobile user subnets. Select this check box to prevent Prisma Access from sending any BGP advertisements, but still use the BGP information it receives to learn routes from other BGP neighbors.Since Prisma Access does not send BGP advertisements if you select this option, you must configure static routes on the on-premises equipment to establish routes back to Prisma Access.
- Peer AS—Specify the autonomous system (AS) to which the firewall, virtual router, or BGP router at your remote network belongs.
- Peer IP Address—Enter the IP address assigned as the Router ID of the eBGP router on the remote network for which you are configuring this connection.
- Local IP Address (Optional)—Enter an address that Prisma Access uses as its Local IP address for BGP.Specify the IP address to use on the Prisma Access side of the tunnel.Specifying a Local Address is useful where the device on the other side of the connection (such as an Amazon Web Service (AWS) Virtual Private Gateway) requires a specific local IP address for BGP peering to be successful. 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.
- Secret and Confirm Secret (Optional)—Enter and confirm a passphrase to authenticate BGP peer communications.
- Repeat the previous step to add up to four tunnels to use with the remote network connection.
- Select one of the choices to enable or disable
ECMP load balancing.
- Select the Location in which Prisma
Access will deploy the infrastructure required to secure your remote
network location. This region should be geographically located close
to your remote network location.See this table for a list of Prisma Access locations.If you have not yet allocated bandwidth for the compute location to which the location maps, Prisma Access prompts you to enter bandwidth for that compute location.
- 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.
- (Static routing or single-tunnel
deployments only) Select or add a new IPSec Tunnel configuration
to access the firewall, router, or SD-WAN device at the corporate
location:
- Select one of the predefined IPSec templates in the Remote_Network_Template, or, if you have added a template to the Remote_Network_Template_Stack (or modified the predefined Remote_Network_Template) that includes an IPSec Tunnel configuration, select that IPSec Tunnel from the drop-down. Note that the tunnel you are creating for each remote network connection connects Prisma Access to the IPSec-capable device at each branch location.Use the following guidelines when configuring an IPSec tunnel:
- The peer addresses in the IKE Gateway configuration must be unique for each tunnel. You can, however, re-use some of the other common configuration elements, such as crypto profiles.
- The IPSec Tunnel you select from a template must use Auto Key exchange and IPv4 only.
- The IPSec tunnel, IKE gateway, and crypto profile names cannot be longer than 31 characters.
- If you onboard multiple remote networks to the same location with dynamic IKE peers, you must use the same IKE crypto profile for all remote network configurations.
- To create a new IPSec Tunnel configuration,
click New IPSec Tunnel, give it a Name and
configure the IKE Gateway, IPSec Crypto Profile, and Tunnel Monitoring settings.
- If the IPSec-capable device at your branch location uses policy-based VPN, on the Proxy IDs tab, Add a proxy ID that matches the settings configured on your local IPSec device to ensure that Prisma Access can successfully establish an IPSec tunnel with your local device.
- Leave Enable Replay Protection selected to detect and neutralize against replay attacks.
- Select Copy TOS Header to copy the Type of Service (TOS) header from the inner IP header to the outer IP header of the encapsulated packets in order to preserve the original TOS information.
- To enable tunnel monitoring for the service connection, select Tunnel Monitor.
- Enter a Destination IP address.Specify an IP address at your branch location to which Prisma Access can send ICMP ping requests for IPSec tunnel monitoring. Make sure that this address is reachable by ICMP from the entire Prisma Access infrastructure subnet.
- If you use tunnel monitoring with a peer device that uses multiple proxy IDs, specify a Proxy ID or add a New Proxy ID that allows access from the infrastructure subnet to your branch location.The following figure shows a proxy ID with the service infrastructure subnet (172.16.55.0/24 in this example) as the Local IP subnet and the branch location’s subnet (10.1.1.0/24 in this example) as the Remote subnet.The following figure shows the Proxy ID you created being applied to the tunnel monitor configuration by specifying it in the Proxy ID field.
You must configure a static route on your CPE to the Tunnel Monitor IP Address for tunnel monitoring to function. To find the destination IP address to use for tunnel monitoring from your branch location to Prisma Access, select PanoramaCloud ServicesStatusNetwork Details, click the Service Infrastructure radio button, and find the Tunnel Monitor IP Address.
- If you have a secondary WAN link at this location, select Enable Secondary
WAN.Be sure to create a unique IPSec tunnel for each remote network’s secondary WAN; Prisma Access does not support reusing the same IPSec tunnel for secondary WANs in multiple remote networks.Configuring a Secondary WAN is not supported in the following deployments:
- If your secondary WAN is set up in active-active mode with the Primary IPSec tunnel.
- If your customer premises equipment (CPE) is set up in an Equal Cost Multipath (ECMP) configuration with the Primary and Secondary IPSec tunnel.
If you use static routes, tunnel failover time is less than 15 seconds from the time of detection, depending on your WAN provider.If you configure BGP routing and have enabled tunnel monitoring, the shortest default hold time to determine that a security parameter index (SPI) is failing is the tunnel monitor, which removes all routes to a peer when it detects a tunnel failure for 15 consecutive seconds. In this way, the tunnel monitor determines the behavior of the BGP routes. If you do not configure tunnel monitoring, the hold timer determines the amount of time that the tunnel is down before removing the route. Prisma Access uses the default BGP HoldTime value of 90 seconds as defined by RFC 4271, which is the maximum wait time before Prisma Access removes a route for an inactive SPI. If the peer BGP device has a shorter configured hold time, the BGP hold timer uses the lower value.When the secondary tunnel is successfully installed, the secondary route takes precedence until the primary tunnel comes back up. If the primary and secondary are both up, the primary route takes priority.If you use a different BGP peer for the secondary (backup) connection, Prisma Access does not honor the Multi-Exit Discriminator (MED) attributes advertised by the CPE. This caveat applies if you use multiple BGP peers on either remote network connections or service connections. - Enable routing to the subnetworks or individual IP addresses
at the remote network site that your users will need access to.Prisma Access uses this information to route requests to the appropriate site. The networks at each site cannot overlap with each other or with IP address pools that you designated for the service infrastructure or for the Prisma Access for users IP pools. You can configure Static Routes, BGP, or a combination of both.
- To configure Static Routes:
- On the Static Routes tab, click Add and enter the subnetwork address (for example, 172.168.10.0/24) or individual IP address of a resource, such as a DNS server (for example, 10.32.5.1/32) that your remote users will need access to.
- Repeat for all subnets or IP addresses that Prisma Access will need access to at this location.
- To configure BGP:
- Select the BGP tab.
- (Optional) Select the ECMP Load Balancing choices. See Step 9.
- If you select None for ECMP Load Balancing, enter the BGP choices.
- To enable BGP for the remote network connection, select Enable.When you enable BGP, Prisma Access sets the time to live (TTL) value for external BGP (eBGP) to 8 to accommodate any extra hops that might occur between the Prisma Access infrastructure and your customer premises equipment (CPE) that terminates the eBGP connection.
- To reduce the number of mobile user IP subnet advertisements over BGP to your customer premises equipment (CPE) by summarizing them, select Summarize Mobile User Routes before advertising.By default, Prisma Access advertises the mobile users IP address pools in blocks of /24 subnets; if you summarize them, Prisma Access advertises the pool based on the subnet you specified. For example, Prisma Access advertises a public user mobile IP pool of 10.8.0.0/20 using the /20 subnet, rather than dividing the pool into subnets of 10.8.1.0/24, 10.8.2.0/24, 10.8.3.0/24, and so on before advertising them. Summarizing these advertisements can reduce the number of routes stored in CPE routing tables. For example, you can use IP pool summarization with cloud VPN gateways (Virtual Private Gateways (VGWs) or Transit Gateways (TGWs)) that can accept a limited number of routes.Prisma Access sets the community string for aggregated mobile user routes to 0xFFFE:0xFFF0.
- To allow Prisma Access to advertise a default route for the remote network using eBGP, select Advertise Default Route.If you select Advertise Default Route, be sure that your network does not have another default route being advertised by BGP, or you could introduce routing issues in your network.You must publish your default routes before you make this selection to advertise them. In addition, be sure that your network does not have another default route being advertised by BGP, or you could introduce routing issues in your network.
- To prevent the BGP peer on the Prisma Access firewall from forwarding routes into your organization’s network, select Don’t Advertise Prisma Access Routes.By default, Prisma Access advertises all BGP routing information, including local routes and all prefixes it receives from other service connections, remote networks, and mobile user subnets. Select this check box to prevent Prisma Access from sending any BGP advertisements, but still use the BGP information it receives to learn routes from other BGP neighbors.Since Prisma Access does not send BGP advertisements if you select this option, you must configure static routes on the on-premises equipment to establish routes back to Prisma Access.
- Enter the Peer AS, which is the autonomous system (AS) to which the firewall, virtual router, or BGP router at your remote network belongs.
- Enter the IP address assigned as the Router ID of the eBGP router on the remote network for which you are configuring this connection as the Peer Address.
- (Optional) Enter an address that Prisma Access uses as its Local IP address for BGP.Specifying a Local Address is useful where the device on the other side of the connection (such as an Amazon Web Service (AWS) Virtual Private Gateway) requires a specific local IP address for BGP peering to be successful. 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.
- (Optional) Enter and confirm a passphrase to authenticate BGP peer communications.
- (Optional) If you configured a Secondary WAN and you need to change the Peer Address or Local Address for the secondary (backup) BGP peer, deselect Same as Primary WAN and enter a unique Peer and, optionally, Local IP address for the secondary WAN.In some deployments (for example, when using BGP to peer with an AWS VPN gateway), the BGP peer for the primary and secondary WAN might be different. In those scenarios, you can choose to set a different BGP peer for the secondary WAN.For BGP deployments with secondary WANs, Prisma Access sets both the primary and secondary tunnels in an UP state, but follows normal BGP active-backup behavior for network traffic. Prisma Access sets the primary tunnel as active and sends and receives traffic through that tunnel only; if the primary tunnel fails, Prisma Access detects the failure using BGP rules, sets the secondary tunnel as active, and uses only the secondary tunnel to send and receive traffic.
- (Optional) Configure Inbound Access options.This choice only applies if you want to configure your remote network for remote network inbound access. See Provide Secure Inbound Access to Remote Network Locations for an overview and configuration details.
- Commit the configuration changes to Panorama and push
the configuration out to Prisma Access for networks.
- Click CommitCommit to Panorama.
- Click CommitCommit and Push. Click Edit SelectionsPrisma Access, and select both Prisma Access for networks and Prisma Access for service setup to push the configuration out to the service.
- Click OK and Push.
- Configure the IPSec-capable device at the remote network
location to set up an IPSec connection with Prisma Access for networks.
- Find the Service IP Address for this remote network connection by selecting PanoramaCloud ServicesStatusNetwork Details, clicking the Remote Networks radio button, and viewing the Service IP Address field. Prisma Access for networks infrastructure has assigned this IP address for the Prisma Access remote network connection, and you must configure this as the peer IP address to set up the IPSec tunnel between the remote network location and Prisma Access for networks.
- Check the Local IP address for the device at the remote network location on the PanoramaCloud ServicesStatusNetwork DetailsRemote Networks page. If you are performing NAT at the remote network location, the Local IP address displays the IP address of the device after NAT.
- To secure traffic at the remote network location you
must create security policy rules.
- Select Policies.
- Select the Device Group in which to add policy rules. You can select the Remote_Network_Device_Group or the parent device group that you selected for defining policies to secure the remote network location.
- Create security policy rules.
Make sure that you do not define security policy rules to allow
traffic from any zone to any zone. In the security policy rules,
use the zones that you defined in your template.If a user on your network is denied access to a website, report website access issues before you open a ticket with Palo Alto Networks.
- Enable logging to Strata Logging Service. You must create and
attach a log forwarding profile to each policy rule for which you
want to forward logs.
- Select Objects > Log Forwarding.
- Select the Device Group in which you added the policy rules, for example, Remote_Network_Device_Group.
- Add a Log Forwarding profile. In the log forwarding profile match list, Add each Log Type that you want to forward.
- Select Panorama/Strata Logging Service as
the Forward Method to enable Prisma Access to forward the logs to
Strata Logging Service. You will be able to monitor the logs and generate
reports from Panorama. Strata Logging Service provides a seamless integration
to store logs without backhauling them to your Panorama at the corporate
headquarters, and Panorama can query Strata Logging Service as needed.The following example enables forwarding of Traffic, Threat Prevention, WildFire Submission, URL Filtering, Data Filtering, and Authentication logs to Strata Logging Service.
- Select Policies > Security and edit the policy rule. In Actions, select the Log Forwarding profile you created.
- Commit all your changes to Panorama and push the configuration
changes to Prisma Access.
- Click CommitCommit to Panorama.
- Click CommitPush to Devices and click Edit Selections.
- On the Prisma Access tab, make sure Prisma Access for networks is selected and then click OK.
- Click Push.
- Check the remote network status.See Verify Remote Network Connection Status for details.
Configure Prisma Access for Networks Allocating Bandwidth by Location
If you have deployed remote networks using
the Cloud Services plugin 1.7 or earlier, you can continue to allocate
bandwidth by location by completing the following steps.
Before
you begin onboarding your remote networks, be sure you go through
the steps to Plan to Deploy Remote Networks.
If
you need to onboard many remote network locations, onboard a remote
network using this workflow and then import
the remote network configuration.
- Select PanoramaCloud ServicesConfigurationRemote Networks and edit the
settings by clicking the gear icon in the Settings area.
- In the Templates section, Add any
templates that contain configuration you want to push to Prisma
Access for networks. For example, if you have existing templates
that contain your zone configurations, or IPSec tunnel, IKE Gateway,
or crypto profile settings, you can add them to the predefined Remote_Network_Template_Stack
to simplify the onboarding process.You can Add more than one template to the stack and then order them appropriately using Move Up and Move Down. This is important because Panorama evaluates in the stack from top to bottom, with settings in templates higher in the stack taking priority over the same settings specified in templates lower in the stack. Note that you cannot move the default template from the top of the stack.Although you can add existing templates to the stack from the plugin, you cannot create a new template from the plugin. Instead, use the workflow to add a new template.
- Select the Parent Device Group for
Prisma Access for remote networks. You can select an existing device
group or use Shared.You will push all of the configuration—including the security policy, security profiles, and other policy objects (such as application groups and objects, and address groups), HIP objects and profiles and authentication policy—that Prisma Access for networks needs to enforce consistent policy to your remote network users using the device group hierarchy you specify here.You don’t need to define all of the policy that you will push to the remote network yet. Instead, configure the settings to onboard the remote site. You can then go back and add the templates and device groups with the complete configurations to push consistent policy out to your remote networks.
- (Optional) If you have configured an on-premises
next-generation firewall as a master device,
select the Master Device you configured.When you select the Master Device, Prisma Access auto-populates user and group information in the security policy rules in Panorama for mobile user and remote network device groups.
- If you will be configuring remote networks that have
overlapping subnets, select the Overlapped Subnets check
box to enable outbound internet access for those locations.While configuring Remote Network Locations with Overlapping Subnets introduces some limitations, it is acceptable in some cases (for example, if you want to add a guest network at a retail store location).
- In the Templates section, Add any
templates that contain configuration you want to push to Prisma
Access for networks. For example, if you have existing templates
that contain your zone configurations, or IPSec tunnel, IKE Gateway,
or crypto profile settings, you can add them to the predefined Remote_Network_Template_Stack
to simplify the onboarding process.
- (Optional) Configure DNS Proxy settings
for your remote network.Prisma Access allows you to specify DNS servers to resolve both domains that are internal to your organization and external domains. If you do not specify any settings, Prisma Access does not proxy DNS requests for remote networks.
- In the Remote_Network_Device_Group device
group, select PoliciesSecurity and Add a
security policy rule with an Application of DNS and
an Action of Allow to
allow DNS traffic. Without a security policy rule to allow DNS traffic, DNS resolution does not occur.
- If you configure Prisma Access to proxy the DNS requests from your remote networks, update the DNS settings on all the endpoints in that network to use the Prisma Access Remote Network DNS Proxy IP Address as the primary DNS server and use your DNS server as secondary DNS server. You can get this DNS proxy IP from PanoramaCloud ServicesStatus Network DetailsService Infrastructure.
- Add one or more DNS proxy settings,
entering the following values:
- For Internal Domains:
- Select a Region (North America & South America, Africa, Europe & Middle East, or Asia, Australia & Japan), or specify Worldwide to apply the DNS settings globally.You can add multiple region-specific DNS proxy settings, or specify a DNS proxy for one or more regions and specify another worldwide DNS proxy for the rest of the world. If you specify only a regional setting and onboard remote networks in that region only, Prisma Access does not proxy the DNS requests, and the source IP address of the DNS request is the remote network’s EBGP Router IP address. If you specify multiple proxy settings with a mix of regional and worldwide regions, Prisma Access uses the regional settings for the Locations in the region you specify; otherwise, Prisma Access uses the worldwide settings.
- Specify the IP addresses of the Primary DNS and Secondary DNS servers that your remote network should use to resolve internal domains.
- (Optional) If you want your internal DNS server to only resolve the domains you specify, enter the domains to resolve in the Domain List.You can use a wildcard (*) in front of the domains in the domain list, for example *.acme.local or .acme.com. You can specify a maximum of 1,024 domain entries.
- For External Domains:
- Enter a Primary DNS choice.To use the default Prisma Access DNS server, select Use Cloud Default. To use the same server that you use to resolve internal domains, select Same as Internal Domains. To use third-party or public DNS server, select Custom DNS Server, then specify the IP address of the DNS server.
- Enter a Secondary DNS choice, choosing from the same options you chose for the Prisma DNS.
- In the Remote_Network_Device_Group device
group, select PoliciesSecurity and Add a
security policy rule with an Application of DNS and
an Action of Allow to
allow DNS traffic.
- (Optional) Configure Prisma Access to use the
Directory Sync service to retrieve user and group information.You must configure Directory Sync to retrieve user and group information from your Active Directory (AD) before you enable and configure Directory Sync integration in Prisma Access using the settings in the Group Mapping Settings tab. See Get User and Group Information Using the Cloud Identity Engine for details.
- Create new zones in the one of the templates in the stack
(Network > Zones> Add) or map the zones referenced
in existing templates you added to the stack as trusted or untrusted.
On Panorama, policy rules are defined in device groups, and zones
are defined in templates. Therefore, you need to make sure that
you add the templates that reference the zones included in your
policy rules to the template stack.On a Palo Alto Networks® next-generation firewall, security policy is enforced between zones, which map to physical or virtual interfaces on the firewall. But as Prisma Access for networks has only two zones, trust and untrust, you need to map any zone with traffic bound to the Internet (including your sanctioned SaaS applications) as untrust and all internal zones as trust.
- (Optional) Edit the zone
mapping settings.By default, all of the zones in Prisma Access for networks template stack a are classified as Untrusted Zones. If you have not yet defined zones or if the templates in the Remote_Network_Template_Stack do not have zone configurations, you can come back and add them when you push policy to Prisma Access for networks.
- For each zone you want to designate as trusted, select it and click Add to move it to the list of Trusted Zones.
- Click OK to save the mappings.
- (Optional) Edit the zone
mapping settings.
- Click Add in the Onboarding settings,
and specify a Name to identify the infrastructure
that will secure the remote network location you are onboarding.You cannot change the name of the remote network location after you enter it. Make sure you know your naming scheme for your remote networks before you begin onboarding.
- (BGP
deployments only) Create a configuration so that your remote
network connection can use up to four IPSec tunnels for its traffic
(ECMP Load Balancing). QoS is not supported with ECMP load balancing, and static routes are not supported (BGP is required). If your deployment uses one IPSec tunnel for its remote network connection or uses static routes, select None for ECMP Load Balancing and continue to Step 9.Specify a minimum Bandwidth of 50 Mbps.Prisma Access divides the bandwidth you select by the number of tunnels; for example, if you specify 300 Mbps and add four tunnels, each tunnel carries 75 Mbps. If one of the tunnels goes down, your network connection will now carry 225 Mbps instead of 300 Mbps.
- Select one of the choices to enable or disable
ECMP load balancing.
- None—Do not use ECMP load balancing (use a single remote network tunnel for this remote network connection). This is the only choice you can make for static routes; BGP is required for ECMP load balancing.
- Enabled with Symmetric Return—Specify up to four IPSec tunnels for this remote network connection and force Prisma Access to use the same link for the return traffic as it used to send the traffic.Select this option if you use one or more tunnels as a backup tunnel to be used only if one of the primary tunnels go down. If a link fails, Prisma Access uses one of the other tunnels to send and receive traffic symmetrically.
- Add an IPSec tunnel for the
remote network connection and specify the following values:
- Enable—Enables BGP for the IPSec tunnel.This selection is not configurable; you must enable BGP to configure ECMP.
- Summarize Mobile User Routes before advertising—Reduces the number of mobile user IP subnet advertisements over BGP to your customer premises equipment (CPE) by summarizing them.By default, Prisma Access advertises the mobile users IP address pools in blocks of /24 subnets; if you summarize them, Prisma Access advertises the pool based on the subnet you specified. For example, Prisma Access advertises a public user mobile IP pool of 10.8.0.0/20 using the /20 subnet, rather than dividing the pool into subnets of 10.8.1.0/24, 10.8.2.0/24, 10.8.3.0/24, and so on before advertising them. Summarizing these advertisements can reduce the number of routes stored in CPE routing tables. For example, you can use IP pool summarization with cloud VPN gateways (Virtual Private Gateways (VGWs) or Transit Gateways (TGWs)) that can accept a limited number of routes.If you enable route summarization for a location that uses ECMP, you must enable route summarization on all links to that location, or you will receive an error during commit.Prisma Access sets the community string for aggregated mobile user routes to 0xFFFE:0xFFF0.
- Advertise Default Route—Allows Prisma Access to advertise a default route for the remote network using eBGP.You must publish your default routes before you make this selection to advertise them. In addition, be sure that your network does not have another default route being advertised by BGP, or you could introduce routing issues in your network.
- Don’t Advertise Prisma Access Routes—Prevents the Prisma Access BGP peer from forwarding routes into your organization’s network.By default, Prisma Access advertises all BGP routing information, including local routes and all prefixes it receives from other service connections, remote networks, and mobile user subnets. Select this check box to prevent Prisma Access from sending any BGP advertisements, but still use the BGP information it receives to learn routes from other BGP neighbors.Since Prisma Access does not send BGP advertisements if you select this option, you must configure static routes on the on-premises equipment to establish routes back to Prisma Access.
- Peer AS—Specify the autonomous system (AS) to which the firewall, virtual router, or BGP router at your remote network belongs.
- Peer IP Address—Enter the IP address assigned as the Router ID of the eBGP router on the remote network for which you are configuring this connection.
- Local IP Address (Optional)—Enter an address that Prisma Access uses as its Local IP address for BGP.Specify the IP address to use on the Prisma Access side of the tunnel.Specifying a Local Address is useful where the device on the other side of the connection (such as an Amazon Web Service (AWS) Virtual Private Gateway) requires a specific local IP address for BGP peering to be successful. 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.
- Secret and Confirm Secret (Optional)—Enter and confirm a passphrase to authenticate BGP peer communications.
- Repeat the previous step to add up to four tunnels to use with the remote network connection.
- Select one of the choices to enable or disable
ECMP load balancing.
- Select the Location in which Prisma
Access will deploy the infrastructure required to secure your remote
network location. This region should be geographically located close
to your remote network location.See this table for a list of Prisma Access locations.
- Select the Bandwidth you want
to allocate to this remote network location. The bandwidth you select
cannot exceed the total amount of bandwidth you have licensed. Use
this setting to define the amount of the total licensed bandwidth
you want to allocate to this location.To help you determine how much bandwidth a specific site needs, consider the bandwidth available from your ISP at each location. See How to Calculate Remote Network Bandwidth for more details and suggestions. If you enable ECMP Load Balancing, you must specify a minimum of 50 Mbps.You can change the bandwidth of a remote network connection after you onboard it, with the exception of the 500 Mbps (w/o SSL Decryption) or 1000 Mbps (Preview) bandwidth choices. If you select either of these preview choices and then need to change the bandwidth, you must first add an identical network with the only change being the lower, non-Preview bandwidth choice, commit your changes, make a note of the Service IP address and reconfigure your IPSec tunnel to use that address, then delete the existing remote network with the preview bandwidth choice.
- (Static
routing or single-tunnel deployments only) Select or add a
new IPSec Tunnel configuration to access
the firewall, router, or SD-WAN device at the corporate location:
- If you have added a template to the Remote_Network_Template_Stack (or modified the predefined Remote_Network_Template) that includes an IPSec Tunnel configuration, select that IPSec Tunnel from the drop-down. Note that the tunnel you are creating for each remote network connection connects Prisma Access to the IPSec-capable device at each branch location.Use the following guidelines when configuring an IPSec tunnel:
- The peer addresses in the IKE Gateway configuration must be unique for each tunnel. You can, however, re-use some of the other common configuration elements, such as crypto profiles.
- The IPSec Tunnel you select from a template must use Auto Key exchange and IPv4 only.
- If you onboard multiple remote networks to the same location with dynamic IKE peers, you must use the same IKE crypto profile for all remote network configurations.
- To create a new IPSec Tunnel configuration,
click New IPSec Tunnel, give it a Name and
configure the IKE Gateway, IPSec Crypto Profile, and Tunnel Monitoring settings.
- If the IPSec-capable device at your branch location uses policy-based VPN, on the Proxy IDs tab, Add a proxy ID that matches the settings configured on your local IPSec device to ensure that Prisma Access can successfully establish an IPSec tunnel with your local device.
- Leave Enable Replay Protection selected to detect and neutralize against replay attacks.
- Select Copy TOS Header to copy the Type of Service (TOS) header from the inner IP header to the outer IP header of the encapsulated packets in order to preserve the original TOS information.
- To enable tunnel monitoring for the service connection, select Tunnel Monitor.
- Enter a Destination IP address.Specify an IP address at your branch location to which Prisma Access can send ICMP ping requests for IPSec tunnel monitoring. Make sure that this address is reachable by ICMP from the entire Prisma Access infrastructure subnet.
- If you use tunnel monitoring with a peer device that uses multiple proxy IDs, specify a Proxy ID or add a New Proxy ID that allows access from the infrastructure subnet to your branch location.The following figure shows a proxy ID with the service infrastructure subnet (172.16.55.0/24 in this example) as the Local IP subnet and the branch location’s subnet (10.1.1.0/24 in this example) as the Remote subnet.The following figure shows the Proxy ID you created being applied to the tunnel monitor configuration by specifying it in the Proxy ID field.
You must configure a static route on your CPE to the Tunnel Monitor IP Address for tunnel monitoring to function. To find the destination IP address to use for tunnel monitoring from your branch location to Prisma Access, select PanoramaCloud ServicesStatusNetwork Details, click the Service Infrastructure radio button, and find the Tunnel Monitor IP Address.
- If you have a secondary WAN link at this location, select Enable Secondary
WAN.Be sure to create a unique IPSec tunnel for each remote network’s secondary WAN; Prisma Access does not support reusing the same IPSec tunnel for secondary WANs in multiple remote networks.If you use static routes, tunnel failover time is less than 15 seconds from the time of detection, depending on your WAN provider.If you configure BGP routing and have enabled tunnel monitoring, the shortest default hold time to determine that a security parameter index (SPI) is failing is the tunnel monitor, which removes all routes to a peer when it detects a tunnel failure for 15 consecutive seconds. In this way, the tunnel monitor determines the behavior of the BGP routes. If you do not configure tunnel monitoring, the hold timer determines the amount of time that the tunnel is down before removing the route. Prisma Access uses the default BGP HoldTime value of 90 seconds as defined by RFC 4271, which is the maximum wait time before Prisma Access removes a route for an inactive SPI. If the peer BGP device has a shorter configured hold time, the BGP hold timer uses the lower value.When the secondary tunnel is successfully installed, the secondary route takes precedence until the primary tunnel comes back up. If the primary and secondary are both up, the primary route takes priority.If you use a different BGP peer for the secondary (backup) connection, Prisma Access does not honor the Multi-Exit Discriminator (MED) attributes advertised by the CPE. This caveat applies if you use multiple BGP peers on either remote network connections or service connections.
- Enable routing to the subnetworks or individual IP addresses
at the remote network site that your users will need access to.Prisma Access uses this information to route requests to the appropriate site. The networks at each site cannot overlap with each other or with IP address pools that you designated for the service infrastructure or for the Prisma Access for users IP pools. You can configure Static Routes, BGP, or a combination of both.
- To configure Static Routes:
- On the Static Routes tab, click Add and enter the subnetwork address (for example, 172.168.10.0/24) or individual IP address of a resource, such as a DNS server (for example, 10.32.5.1/32) that your remote users will need access to.
- Repeat for all subnets or IP addresses that Prisma Access will need access to at this location.
- To configure BGP:
- Select the BGP tab.
- Select the ECMP Load Balancing choices. See Step 6.
- If you select None for ECMP Load Balancing, enter the BGP choices.
- To enable BGP for the remote network connection, select Enable.When you enable BGP, Prisma Access sets the time to live (TTL) value for external BGP (eBGP) to 8 to accommodate any extra hops that might occur between the Prisma Access infrastructure and your customer premises equipment (CPE) that terminates the eBGP connection.
- To reduce the number of mobile user IP subnet advertisements over BGP to your customer premises equipment (CPE) by summarizing them, select Summarize Mobile User Routes before advertising.By default, Prisma Access advertises the mobile users IP address pools in blocks of /24 subnets; if you summarize them, Prisma Access advertises the pool based on the subnet you specified. For example, Prisma Access advertises a public user mobile IP pool of 10.8.0.0/20 using the /20 subnet, rather than dividing the pool into subnets of 10.8.1.0/24, 10.8.2.0/24, 10.8.3.0/24, and so on before advertising them. Summarizing these advertisements can reduce the number of routes stored in CPE routing tables. For example, you can use IP pool summarization with cloud VPN gateways (Virtual Private Gateways (VGWs) or Transit Gateways (TGWs)) that can accept a limited number of routes.Prisma Access sets the community string for aggregated mobile user routes to 0xFFFE:0xFFF0.
- To allow Prisma Access to advertise a default route for the remote network using eBGP, select Advertise Default Route.If you select Advertise Default Route, be sure that your network does not have another default route being advertised by BGP, or you could introduce routing issues in your network.You must publish your default routes before you make this selection to advertise them. In addition, be sure that your network does not have another default route being advertised by BGP, or you could introduce routing issues in your network.
- To prevent the BGP peer on the Prisma Access firewall from forwarding routes into your organization’s network, select Don’t Advertise Prisma Access Routes.By default, Prisma Access advertises all BGP routing information, including local routes and all prefixes it receives from other service connections, remote networks, and mobile user subnets. Select this check box to prevent Prisma Access from sending any BGP advertisements, but still use the BGP information it receives to learn routes from other BGP neighbors.Since Prisma Access does not send BGP advertisements if you select this option, you must configure static routes on the on-premises equipment to establish routes back to Prisma Access.
- Enter the Peer AS, which is the autonomous system (AS) to which the firewall, virtual router, or BGP router at your remote network belongs.
- Enter the IP address assigned as the Router ID of the eBGP router on the remote network for which you are configuring this connection as the Peer Address.
- (Optional) Enter an address that Prisma Access uses as its Local IP address for BGP.Specifying a Local Address is useful where the device on the other side of the connection (such as an Amazon Web Service (AWS) Virtual Private Gateway) requires a specific local IP address for BGP peering to be successful. 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.
- (Optional) Enter and confirm a passphrase to authenticate BGP peer communications.
- (Optional) If you configured a Secondary WAN and you need to change the Peer Address or Local Address for the secondary (backup) BGP peer, deselect Same as Primary WAN and enter a unique Peer and, optionally, Local IP address for the secondary WAN.In some deployments (for example, when using BGP to peer with an AWS VPN gateway), the BGP peer for the primary and secondary WAN might be different. In those scenarios, you can choose to set a different BGP peer for the secondary WAN.For BGP deployments with secondary WANs, Prisma Access sets both the primary and secondary tunnels in an UP state, but follows normal BGP active-backup behavior for network traffic. Prisma Access sets the primary tunnel as active and sends and receives traffic through that tunnel only; if the primary tunnel fails, Prisma Access detects the failure using BGP rules, sets the secondary tunnel as active, and uses only the secondary tunnel to send and receive traffic.
- If required, enable Quality of Service for
the remote network connection and specify a QoS profile or add a New
QoS Profile.You can create QoS profiles to shape QoS traffic for remote network and service connections and apply those profiles to traffic that you marked with PAN-OS security policies, traffic that you marked with an on-premises device, or both PAN-OS-marked and on-premise-marked traffic. See Configure Quality of Service in Prisma Access for details.
- (Optional) Configure Inbound Access options.This choice only applies if you want to configure your remote network for remote network inbound access. See Provide Secure Inbound Access to Remote Network Locations for an overview and configuration details.
- Commit the configuration changes to Panorama and push
the configuration out to Prisma Access for networks.
- Click CommitCommit to Panorama.
- Click CommitCommit and Push. Click Edit SelectionsPrisma Access, and select both Prisma Access for networks and Prisma Access for service setup to push the configuration out to the service.
- Click OK and Push.
- Configure the IPSec-capable device at the remote network
location to set up an IPSec connection with Prisma Access for networks.
- Find the Service IP Address for this remote network connection by selecting PanoramaCloud ServicesStatusNetwork Details, clicking the Remote Networks radio button, and viewing the Service IP Address field. Prisma Access for networks infrastructure has assigned this IP address for the Prisma Access remote network connection, and you must configure this as the peer IP address to set up the IPSec tunnel between the remote network location and Prisma Access for networks.
- Check the Local IP address for the device at the remote network location on the PanoramaCloud ServicesStatusNetwork DetailsRemote Networks page. If you are performing NAT at the remote network location, the Local IP address displays the IP address of the device after NAT.
- To secure traffic at the remote network location you
must create security policy rules.
- Select Policies.
- Select the Device Group in which to add policy rules. You can select the Remote_Network_Device_Group or the parent device group that you selected for defining policies to secure the remote network location.
- Create security policy rules.
Make sure that you do not define security policy rules to allow
traffic from any zone to any zone. In the security policy rules,
use the zones that you defined in your template.If a user on your network is denied access to a website, report website access issues before you open a ticket with Palo Alto Networks.
- Enable logging to Strata Logging Service. You must create and
attach a log forwarding profile to each policy rule for which you
want to forward logs.
- Select Objects > Log Forwarding.
- Select the Device Group in which you added the policy rules, for example, Remote_Network_Device_Group.
- Add a Log Forwarding profile. In the log forwarding profile match list, Add each Log Type that you want to forward.
- Select Panorama/Strata Logging Service as
the Forward Method to enable Prisma Access to forward the logs to
Strata Logging Service. You will be able to monitor the logs and generate
reports from Panorama. Strata Logging Service provides a seamless integration
to store logs without backhauling them to your Panorama at the corporate
headquarters, and Panorama can query Strata Logging Service as needed.The following example enables forwarding of Traffic, Threat Prevention, WildFire Submission, URL Filtering, Data Filtering, and Authentication logs to Strata Logging Service.
- Select Policies > Security and edit the policy rule. In Actions, select the Log Forwarding profile you created.
- Commit all your changes to Panorama and push the configuration
changes to Prisma Access.
- Click CommitCommit to Panorama.
- Click CommitPush to Devices and click Edit Selections.
- On the Prisma Access tab, make sure Prisma Access for networks is selected and then click OK.
- Click Push.
- Check the remote network status.See Verify Remote Network Connection Status for details.
Verify Remote Network Connection Status
Select PanoramaCloud ServicesStatusStatus to verify that the remote
network connections have been successfully deployed.
The Deployment
Status area allows you to view the progress of onboarding and
deployment jobs before they complete, as well as see more information
about the status of completed jobs. See Deployment Progress and Status for details.
To display
a map that shows the locations of the remote networks in the regions
you have selected, select PanoramaCloud ServicesStatusMonitor and click the Remote Networks tab.
Select
a region to get more detail about that region.
Click the tabs
below the map to see additional remote network statistics.
Status tab:
- Location—The location where your remote network is deployed.
- Remote Peer—The peer to which the remote network has an IPSec tunnel connection.
- IPSec Termination Node—The IPSec termination node associated with the remote network. This field only displays if you allocate bandwidth by compute location.
- ECMP—Whether you have enabled ECMP Load Balancing on this remote network connection.
- Config Status—The status of your last configuration push to the service. If you have made a change locally, and not yet pushed the configuration to the cloud, the status shows Out of sync. Hover over the status indicator for more detailed information. After committing and pushing the configuration to Prisma Access, the Config Status changes to In sync.
- BGP Status—Displays information about the BGP state between the firewall or router at the remote network location and Prisma Access. Although you might temporarily see the status pass through the various BGP states (idle, active, open send, open pend, open confirm, most commonly, the BGP status shows:
- Connect—The router at the remote network location is trying to establish the BGP peer relationship with Prisma Access.
- Established—The BGP peer relationship has been established.This field will also show if the BGP connection is in an error state:
- Warning—There has not been a BGP status update in more than eight minutes. This may indicate an outage on the firewall.
- Error—The BGP status is unknown.
- Tunnel Status—The operational status of the connection between Prisma Access and the remote network.
Statistics tab:
- Location—The location where your remote network is deployed.
- Remote Peer—The corporate location to which this remote network is setting up an IPSec tunnel.
- Ingress Bandwidth (Mbps)—The bandwidth from the remote network location to Prisma Access.For the Ingress Bandwidth, Ingress Peak Bandwidth, Egress Bandwidth, and Egress Peak Bandwidth fields, when the bandwidth consumption on a remote network goes beyond 80% of the allocated bandwidth, the numbers display in a red color.
- Ingress Peak Bandwidth (Mbps)—The peak load from the remote network location into the cloud service.
- Egress Bandwidth (Mbps)—The bandwidth from Prisma Access into the remote network location.
- Egress Peak Bandwidth (Mbps)—The peak load from Prisma Access into the remote network location.
To
find statistics about locations in the region, select Bandwidth
Usage.
Select
the check mark for a location to see detailed bandwidth usage. For
deployments that allocate bandwidth by compute location, select
an IPSec termination node to view statistics for that node. Prisma Access
uses the 95th percentile standard to gather statistics, which tracks
bandwidth at peak utilization and ignores the top 5 percent of utilization
peaks and large bursts.
Verify Remote Connection BGP Status
If you configured BGP, you can check its status
by selecting PanoramaCloud
ServicesStatusNetwork
DetailsRemote NetworksBGP
Status.
The
BGP Status dialog displays. This table provides you with the following
information:
- Peer—Routing information for the BGP peer, including status, total number of routes, configuration, and runtime statistics and counters. The total number of routes display in the bgpAfiIpv4-unicast Counters area, in the Incoming Total and Outgoing Total fields.
- Local RIB—Routing information that has been received from different peers and is stored in the Routing Information Base (RIB).
- RIB Out—Routing information that Prisma Access advertises to its peers through BGP update messages. See How BGP Advertises Mobile User IP Address Pools for Service Connections and Remote Network Connections for an example of this table and for information about how BGP utilizes the IP address pool you create for mobile users.