Configure a Service Connection in Prisma Access
Focus
Focus
Prisma Access

Configure a Service Connection in Prisma Access

Table of Contents

Configure a Service Connection in
Prisma Access

Start configuring your service connections for Prisma Access.
Where Can I Use This?
What Do I Need?
  • Prisma Access (Cloud Management)
  • Prisma Access (Panorama Managed)
Create service connections to allow
Prisma Access
to perform the following tasks:
  • Allow access to the resources in your HQ or data center.
    If you have corporate resources that your remote networks and mobile users need to access, you must enable
    Prisma Access
    to access the corresponding corporate network. Before you begin to configure a service connection, gather the following information for each of your HQ or data centers to which you want
    Prisma Access
    to be able to connect.
    • IPSec-capable firewall, router, or SD-WAN device connection at your corporate site.
    • IPSec settings for terminating the primary VPN tunnel from
      Prisma Access
      to the IPSec-capable device on your corporate network.
    • IPSec settings for terminating the secondary VPN tunnel from Prisma Access to the IPSec-capable device on your corporate network.
      If you have an existing template that contains IPSec tunnel, Tunnel Monitoring, and IPSec Crypto Profile configurations, you can add that template to the template stack to simplify the process of creating the IPSec tunnels. Or, you can edit the Service_Conn_Template that gets created automatically and create the IPSec configurations required to create the IPSec tunnel back to the corporate site.
      Prisma Access
      also provides you with a set of predefined IPSec templates for some commonly-used network devices, and a generic template for any device that is not included in the predefined templates.
    • List of IP subnetworks at the site.
    • List of internal domains that
      Prisma Access
      must be able to resolve.
    • IP address of a corporate access node at your network’s site 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.
    • Network reachability settings for the service infrastructure subnet.
      Make the entire service infrastructure subnet reachable from the HQ or data center.
      Prisma Access
      uses IP addresses for all control plane traffic from this subnet.
    • (For
      Prisma Access (Panorama Managed)
      only) The service account for your authentication, if required for access.
    • (For
      Prisma Access (Panorama Managed)
      only) The routing type (either static or dynamic (BGP)) to use with service connections.
    • (For
      Prisma Access (Panorama Managed)
      only) To route users to the resources they need, you must provide the routes to the resources. You can do this in one or more of the following ways:
      • Define a static route to each subnetwork or specific resource that you want your users to be able to access.
      • Configure BGP between your service connection locations and
        Prisma Access
        .
      • Use a combination of both methods
  • Allow remote networks and mobile users to communicate with each other.
    Even if you do not need your
    Prisma Access
    users to connect to your HQ or data center, you might need to allow your mobile users to access your remote network sites. Service connections are required for this use case because, while all remote network sites are fully meshed, the mobile user infrastructure is not. Minimally configuring a service connection establishes the hub-and-spoke network mobile users need to access a branch network.
    To improve network efficiency, place service connections close to the remote network or networks that mobile users access most frequently.

Cloud Management

Configure service connections for
Prisma Access (Cloud Management)
.
To configure a service connection for
Prisma Access (Cloud Management)
to allow access to private apps or internal corporate resources, complete the following steps.
  1. Select
    Manage
    Service Connections
    Service Connections Setup
    .
    If you're using Strata Cloud Manager, go to
    Workflows
    Prisma Access
    Setup
    Service Connections
    and
    Add Service Connection
    .
  2. Give the service connection a descriptive
    Name
    .
  3. Select the
    Prisma Access
    Location
    where your HQ or data center is located.
  4. (
    Optional
    ) Enable source NAT for Mobile Users—GlobalProtect IP pool addresses, IP addresses in the Infrastructure subnet, or both.
    You can specify a subnet at one or more service connections that are used to NAT traffic between
    Prisma Access
    GlobalProtect mobile users and private applications and resources at a data center.
    • Data Traffic source NAT
      —Performs NAT on Mobile User IP address pool addresses so that they are not advertised to the data center, and only the subnets you specify at the service connections are advertised and routed in the data center.
    • Infrastructure Traffic source NAT
      —Performs NAT on addresses from the Infrastructure subnet so that they are not advertised to the data center, and only those subnets you specify at the service connections are advertised and routed in the data center.
    • User-ID
      —When selected,
      Prisma Access
      uses this service connection for identity redistribution.
      User-ID Redistribution Management
      —Sometimes, granular controls are needed for user-ID redistribution in particularly large scale Prisma Access deployments. User-ID Redistribution Management lets you manually disable the default identity redistribution behavior for certain service connections by removing the check mark in the
      User ID
      column, and then select specific service connections to be used for identity redistribution. It's not necessary to do this for most configurations. Contact Palo Alto Networks support to activate this functionality.
    • Source NAT Pool
      —Specify the IP address pool used to perform NAT on the mobile user IP address pool, Infrastructure subnet, or both.
      • Use a private IP (RFC 1918) subnet or a suitable subnet that is routable in your routing domain.
      • Make sure that the subnet does not overlap with the Mobile Users—GlobalProtect IP address pool, the Infrastructure subnet, or any other source NAT addresses used for this tenant.
      • Enter a subnet between /25 and /32.
  5. Select an
    IPSec Tunnel
    . If you have not yet set up a primary or secondary IPSec Tunnel, select
    Set Up
    and follow the steps below.
    1. Give the tunnel a descriptive
      Name
      .
    2. Select the
      Branch Device Type
      for the IPSec device and the HQ or data center that you’re using to establish the tunnel with
      Prisma Access
      .
    3. For the
      Branch Device IP Address
      , choose to use either a
      Static IP
      address that identifies the tunnel endpoint or a
      Dynamic
      IP address.
      If you set the
      Branch Device IP Address
      to
      Dynamic
      , you must also add the IKE ID for the HQ or data center (
      IKE Local Identification
      ) or for
      Prisma Access
      (
      IKE Peer Identification
      ) to enable the IPSec peers to authenticate.
      Because you don't have the values to use for the
      Prisma Access
      IKE ID (
      IKE Peer Identification
      ) until the service connection is fully deployed, you would typically want to set the IKE ID for the HQ or data center (
      IKE Local Identification
      ) rather than the
      Prisma Access
      IKE ID.
  6. Turn on
    Tunnel Monitoring
    .
    Enter a Tunnel Monitoring
    Destination IP
    address on the HQ or data center network for
    Prisma Access
    to determine whether the tunnel is up and, if your branch IPSec device uses a policy-based, enter the associated
    Proxy ID
    .
    The tunnel monitoring IP address you enter is automatically added to the list of branch subnetworks.
  7. Save
    the tunnel settings.
  8. To add or adjust routing and Quality of Service settings, go to
    Manage
    Service Connections
    Service Connections Setup
    Routing and QoS
    .
    If you're using Strata Cloud Manager, go to
    Workflows
    Prisma Access
    Setup
    Service Connections
    and
    Add Service Connection
    .
    Set Up
    or
    Edit
    the
    Routing
    or
    QoS
    settings.
  9. Configure static routes.
    1. For static routes to route traffic to and from your HQ or data center,
      Add
      the IP subnets or IP addresses that you want to secure at the branch.
      If you make any changes to the IP subnets on your HQ or data center network, you must manually update the static routes.
  10. Configure dynamic routing.
    1. For dynamic routing to advertise HQ or data center subnets,
      Enable BGP for Dynamic Routing
      .
    2. (
      Optional
      ) Select an
      MRAI Timer
      value.
      BGP routing offers a timer you can use to tailor BGP routing convergence in your network called the
      Minimum Route Advertisement Interval (MRAI)
      . MRAI acts to rate-limit updates on a per-destination basis, and the BGP routers wait for at least the configured MRAI time before sending an advertisement for the same prefix. A smaller number gives you faster convergence time but creates more advertisements in your network. A larger number decreases the number of advertisements that can be sent, but can also make routing convergence slower. You decide the number to put in your network for the best balance between faster routing convergence and fewer advertisements.
      Configure an MRAI range of between 1 and 600 seconds, with a default value of 30 seconds.
    3. To reduce the number of mobile user IP subnet advertisements over BGP to your customer premises equipment (CPE), specify
      Prisma Access
      to summarize the subnets before it advertises them by selecting
      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.
    4. (
      Optional
      ) to have
      Prisma Access
      originate a default route advertisement for the remote network using eBGP, select
      Advertise the 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.
    5. (
      Optional
      ) If you configured a secondary WAN and you need to change the peer address for the secondary (backup) BGP peer, select
      Use different BGP Peer for Secondary Tunnel
      and enter a unique Peer and, optionally, Local IP address for the secondary WAN.
    6. To add a community for service connections) to the outbound prefixes from the eBGP peers at the customer premises equipment (CPE), set
      Add no-export community
      to
      Enabled Out
      . This capability is
      Disabled
      by default.
    7. (
      Optional
      ) Select
      Do Not Export Routes
      to prevent
      Prisma Access
      from forwarding routes into the HQ or data center.
      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.
      Because
      Prisma Access
      does not send BGP advertisements, if you select this option you must configure static routes on your on-premises equipment to establish routes back to Prisma Access.
    8. Enter the
      Peer IP Address
      assigned as the Router ID of the eBGP router on the HQ or data center network.
    9. Enter the
      Peer AS
      , the autonomous system (AS) for your network.
      Use and RFC 6996-compliant BGP Private AS number.
    10. Enter the
      Local IP Address
      that
      Prisma Access
      uses as its Local IP address for BGP.
      A local address is only required if your HQ or data center device requires it for BGP peering to be successful. Make sure the address you specify does not conflict or overlap with IP addresses in the infrastructure subnet or subnets in the remote network.
    11. Enter a
      Secret
      password to authenticate BGP peer communications.
    12. Select
      Confirm Secret
      .
  11. (
    Optional
    ) Configure QoS.
    To start, add a QoS Profile to define the QoS classes that will shape traffic between the HQ or data center and
    Prisma Access
    . You’ll then create a QoS policy rule and add the profile to the rule, to enforce QoS on matching HQ or data center traffic.
    1. Enter a name for your
      QoS Profile
      .
    2. Select
      Create New
      .
    3. Set the maximum throughput (in Mbps) for traffic leaving the HQ or data center service connection as the
      Egress Max
      .
      You can specify a value up to the maximum licensed bandwidth of your HQ or data center.
    4. Set the guaranteed bandwidth as the
      Egress Guaranteed
      (in Mbps).
      Any traffic that exceeds the Egress Guaranteed value is best effort but not guaranteed. Any bandwidth that is guaranteed but unused remains available to all traffic.
    5. Define each QoS
      Class
      and attach it to a policy rule.
      A QoS class determines the priority and bandwidth for traffic matching a QoS policy rule. There are up to eight definable QoS classes in a single QoS Profile. Unless otherwise configured, traffic that does not match a QoS class is assigned a class of 4.
    6. Configure the
      Priority
      of a QoS Class.
      Priorities include real-time, high, medium, or low.
    7. Configure the
      Egress Max
      value.
      The egress max value for a QoS class, or the combined egress max values for multiple QoS classes, must not exceed the egress max value for the QoS Profile.
    8. Configure the
      Egress Guaranteed
      value.
      The guaranteed bandwidth assigned to the QoS class isn't reserved for that class; unused bandwidth remains available to all traffic. Any class traffic that exceeds the egress-guaranteed value is best effort but not guaranteed.

More IKE Options

Based on the IPSec device type you selected,
Prisma Access
provides a recommended set of ciphers and a key lifetime for the IKE Phase 1 key exchange process between the device at your HQ/DC and
Prisma Access
. You can use the recommended settings, or customize the settings as needed for your environment.
  • Select an
    IKE Protocol Version
    for your IPSec device and
    Prisma Access
    to use for IKE negotiation.
    If you select
    IKEv1 Only Mode
    ,
    Prisma Access
    can use only the IKEv1 protocol for the negotiation. If you select
    IKEv2 Only Mode
    ,
    Prisma Access
    can use only the IKEv2 protocol for the negotiation. If you select
    IKEv2 Preferred Mode
    ,
    Prisma Access
    uses the IKEv2 protocol only if your IPSec device also supports IKEv2. If your IPSec device does not support IKEv2,
    Prisma Access
    falls back to using the IKEv1 protocol.
  • Add an
    IKEv1 Crypto Profile
    to customize the IKE crypto settings that define the encryption and authentication algorithms used for the key exchange process in IKE Phase 1.
    Prisma Access
    automatically uses a default IKE Crypto profile based on the
    Branch Device Type
    that’s being used to establish this tunnel.
    • Encryption
      —Specify the encryption algorithm used in the IKE SA negotiation.
      Prisma Access
      supports the following encryption algorithms: 3des (168 bits), aes-128-cbc (128 bits), aes-192-cbc (192 bits), aes-256-cbc (256 bits), and DES (56 bits). You can also select null (no encryption).
    • Authentication
      —Specify the authentication algorithm used in the IKE SA negotiation.
      Prisma Access
      supports the following authentication algorithms: sha1 (160 bits), sha256 (256 bits), sha384 (384 bits), sha512 (512 bits), and md5 (128 bits). You can also select null (no authentication).
    • DH Group
      —Specify the Diffie-Hellman (DH) groups used to generate symmetrical keys for IKE in the IKE SA negotiation. The Diffie-Hellman algorithm uses the private key of one party and the public key of the other to create a shared secret, which is an encrypted key that both VPN tunnel peers share.
      Prisma Access
      supports the following DH groups: Group 1 (768 bits), Group 2 (1,024 bits—default), Group 5 (1,536 bits), Group 14 (2,048 bits), Group 19 (256-bit elliptic curve group), and Group 20 (384-bit elliptic curve group). For the strongest security, select the group with the highest number.
    • Lifetime
      —Specify the unit and amount of time for which the IKE Phase 1 key is valid (default is 8 hours). For IKEv1, the security association (SA) isn't actively re-keyed before the key lifetime expires. The IKEv1 Phase 1 re-key triggers only when the SA expires. For IKEv2, the SA must be re-keyed before the key lifetime expires. If the SA isn't re-keyed upon expiration, the SA must begin a new Phase 1 key.
    • IKEv2 Authentication Multiple
      —Specify the value that is multiplied by the key lifetime to determine the authentication count (range is 0-50; default is 0). The authentication count is the number of times that the security processing node can perform IKEv2 IKE SA re-key before it must start over with IKEv2 reauthentication. The default value of 0 disables the reauthentication feature.
  • Enable
    IKE Passive Mode
    so that
    Prisma Access
    only response to IKE connections and does not initiate them.
  • IKE NAT Traversal
    is turned on by default.
    This means that UDP encapsulation is used on IKE and UDP protocols, enabling them to pass-through network address translation (NAT) devices that are between the IPSec VPN tunnel endpoints.

More IPSec Options

Based on the IPSec device type you selected,
Prisma Access
provides a recommended set of IPSec protocol and key lifetime settings to secure data within the IPSec tunnel between your IPSec device and
Prisma Access
in IKE Phase 2 for the security association (SA). You can use the recommended settings, or customize the settings as needed for your environment.
  • Customize the
    IPSec Crypto Profile
    to define how data is secured within the tunnel when Auto Key IKE automatically generates keys for the IKE SAs during IKE Phase 2.
    Prisma Access
    automatically configures a default IPSec Crypto profile based on the
    Branch Device Type
    vendor. You can either use the default profile or create a custom profile.
    • IPSec Protocol
      —Secure the data that traverses the VPN tunnel. The Encapsulating Security Payload (
      ESP
      ) protocol encrypts the data, authenticates the source, and verifies the data integrity. The Authentication Header (
      AH
      ) protocol authenticates the source and verifies the data integrity.
      If you use
      ESP
      as the IPSec protocol, also specify the
      Encryption
      algorithm used in the IPSec SA negotiation.
      Prisma Access
      supports the following encryption algorithms: aes-256-gcm (256 bits), aes-256-cbc (256 bits), aes-192-cbc (192 bits), aes-128-gcm (128 bits), aes-128-cbc (128 bits), 3des (168 bits), and DES (56 bits). You can also select null (no encryption).
  • Authentication
    —Specify the authentication algorithm used in the IPSec SA negotiation.
    Prisma Access
    supports the following authentication algorithms: sha1 (160 bits), sha256 (256 bits), sha384 (384 bits), sha512 (512 bits), and md5 (128 bits). If you set the IPSec Protocol to ESP, you can also select none (no authentication).
  • DH Group
    —Specify the Diffie-Hellman (DH) groups for IKE in the IPSec security association (SA) negotiation.
    Prisma Access
    supports the following DH groups: Group 1 (768 bits), Group 2 (1,024 bits—default), Group 5 (1,536 bits), Group 14 (2,048 bits), Group 19 (256-bit elliptic curve group), and Group 20 (384-bit elliptic curve group). For the strongest security, select the group with the highest number. If you don’t want to renew the key that
    Prisma Access
    creates during IKE phase 1, select
    no-pfs
    (no perfect forward secrecy). If you select this option,
    Prisma Access
    reuses the current key for the IPSec SA negotiation.
  • Lifetime
    —Specify the unit and amount of time during which the negotiated key is valid (default is 1 hour).
  • Lifesize
    —Specify the unit and amount of data that the key can use for encryption.

Verify Service Connection Status

To verify that the service connection has been successfully set up, select
Manage > Service Setup > Service Connections > Sites
and check that the
Status
is
OK
.
If you're using Strata Cloud Manager, go to
Workflows
Prisma Access
Setup
Service Connections
.
If the status isn't
OK
, hover over the Status icon to view any errors.
The
Sites
area allows you to view all onboarded service connections, along with their status and other details about them.
Site
  • Name
    —The name of the service connection.
  • Active/Backup
    —The active and backup locations of the service connection.
  • Subnets
    —The assigned infrastructure subnets of the service connection.
Status
  • Tunnel
    —The operational status of the connection between
    Prisma Access
    and your service connection.
  • Config
    —The status of your last configuration push to service. If the local configuration and the configuration in the cloud match, the Config Status is
    In sync
    . If you have made a change locally, and not yet pushed the configuration to the cloud, this may display the status
    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
    .
Prisma Access
  • Location
    —The location where the service connection is deployed.
  • Service IP
    —The IP address of the service connection.
  • EBGP Router
    —The IP address of the EBGP Router in the service connection.
Links
  • BGP IPv4
    —The status of the BGP IPv4 routing in the service connection.
  • BGP IPv6
    —The status of the BGP IPv6 routing in the service connection.
  • IPSec Tunnel
    —The IPSec tunnel of your service connection. The first IPSec tunnel you establish will be the
    (Primary)
    tunnel. If you established a second IPSec tunnel it will be the
    (Secondary)
    tunnel.
  • Peer IP Address
    —The gateway IP address of the service connection.

Panorama

Configure service connections for
Prisma Access (Panorama Managed)
.
To configure a service connection for Prisma Access Panorama to allow access to private apps or internal corporate resources, complete the following steps.
Do not use CLI to onboard and configure service connections. If you require the use of CLI to onboard service connections, reach out to your Palo Alto Networks team.
  1. Select
    Panorama
    Cloud Services
    Configuration
    Service Connection
    .
  2. Add
    a new service connection to one of your corporate network sites.
  3. Specify a
    Name
    for the corporate site.
  4. Select the
    Location
    closest to where the site is located.
    See this section for a list of
    Prisma Access
    locations.
    Locations denoted with two asterisks are
    Local Zones
    . These locations place compute, storage, database, and infrastructure services close to large population and industry centers. When you use these zones, keep in mind the following guidelines:
    • Remote network and service connection node redundancy across availability zones isn't available if you deploy them in the same local zone, as both nodes are provisioned in a single zone.
    • These local zones don't use Palo Alto Networks registered IPs. If you have problems accessing URLs, report the website issue using https://reportasite.gpcloudservice.com/ or reach out to Palo Alto Networks support.
  5. Select or add a new
    IPSec Tunnel
    configuration to access the firewall, router, or SD-WAN device at the corporate location:
    • If you're using an existing
      IPSec Tunnel
      configuration, select it from the drop-down. Note that the tunnel you're creating for each service connection connects
      Prisma Access
      to the IPSec-capable device at each corporate location. The peer addresses in the IKE Gateway configuration must be unique for each tunnel. You can, however, reuse some of the other common configuration elements, such as crypto profiles.
      The IPSec Tunnel you select must use Auto Key exchange and IPv4 only. In addition, make sure that the IPSec tunnel, IKE gateway, and crypto profile names are 31 characters or less.
    • 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 HQ or data center 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.
    • To detect and neutralize against reply attacks:
      Leave
      Enable Replay Protection
      .
    • To preserve the original ToS information:
      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.
    • To enable tunnel monitoring for the service connection:
      Select
      Tunnel Monitor
      :
      • Enter a
        Destination IP
        address.
        Specify an IP address at your HQ or data center site 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 HQ or data center site.
        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 HQ or data center’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 data center or HQ network to
      Prisma Access
      , select
      Panorama
      Cloud Services
      Status
      Network Details
      , click the
      Service Infrastructure
      radio button, and find the
      Tunnel Monitor IP Address
      .
  6. BGP and hot potato routing deployments only
    —Select a service connection to use as the preferred backup (
    Backup SC
    ).
    You can select any service connection that you have already added.
    Prisma Access
    uses the
    Backup SC
    you select as the preferred service connection in the event of a link failure. Selecting a backup service connection can prevent asymmetric routing issues if you have onboarded more than two service connections. This choice is available in hot potato routing mode only.
  7. If you have a secondary WAN link at this location, select
    Enable Secondary WAN
    and then select or configure an
    IPSec Tunnel
    the same way you did to set up the primary IPSec tunnel.
    If the primary WAN link goes down,
    Prisma Access
    detects the outage and establishes a tunnel to the headquarters or data center location over the secondary WAN link. If the primary WAN link becomes active, the link switches back to the primary link.
    Configuring a secondary WAN isn't 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.
  8. (
    Optional
    ) Enable source NAT for Mobile Users—GlobalProtect IP pool addresses, IP addresses in the Infrastructure subnet, or both.
    You can specify a subnet at one or more service connections that are used to NAT traffic between
    Prisma Access
    GlobalProtect mobile users and private applications and resources at a data center.
    • Enable Data Traffic source NAT
      —Performs NAT on Mobile User IP address pool addresses so that they are not advertised to the data center, and only the subnets you specify at the service connections are advertised and routed in the data center.
    • Enable Infrastructure Traffic source NAT
      —Performs NAT on addresses from the Infrastructure subnet so that they are not advertised to the data center, and only those subnets you specify at the service connections are advertised and routed in the data center.
    • User-ID
      —When selected,
      Prisma Access
      uses this service connection for identity redistribution.
      User-ID Redistribution Management
      —Sometimes, granular controls are needed for user-ID redistribution in particularly large scale Prisma Access deployments. User-ID Redistribution Management lets you manually disable the default identity redistribution behavior for certain service connections by removing the check mark in the
      User ID
      column, and then select specific service connections to be used for identity redistribution. It's not necessary to do this for most configurations. Contact Palo Alto Networks support to activate this functionality.
    • IP Pool
      —Specify the IP address pool used to perform NAT on the mobile user IP address pool, Infrastructure subnet, or both.
      Use a private IP (RFC 1918) subnet or a suitable subnet that is routable in your routing domain, and does not overlap with the Mobile Users—GlobalProtect IP address pool or the Infrastructure subnet. Enter a subnet between /25 and /32.
  9. Enable routing to the subnetworks or individual IP addresses at the corporate 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 can't 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
    :
    1. 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.
    2. Repeat for all subnets or IP addresses that
      Prisma Access
      will need access to at this location.
    To configure
    BGP
    :
    1. On the
      BGP
      tab, 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.
      Prisma Access
      does not accept BGP default route advertisements for either service connections or remote network connections.
    2. (
      Optional
      ) Select from the following choices:
      • To add a
        no-export
        community for Corporate Access Nodes (Service Connections) to the outbound prefixes from the eBGP peers at the customer premises equipment (CPE), set
        Add no-export community
        to
        Enabled Out
        . This capability is
        Disabled
        by default.
        Don't use this capability in hot potato routing mode.
      • To prevent the
        Prisma Access
        BGP peer from forwarding routes into your organization’s network.
        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
        .
      • To reduce the number of mobile user IP subnet advertisements over BGP to your customer premises equipment (CPE), specify Prisma Access to summarize the subnets before it advertises them by selecting
        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.
        If you have hot potato routing enabled and you enable route summarization,
        Prisma Access
        no longer prepends AS-PATHs, which might cause asymmetric routing. Be sure that your return traffic from the data center or headquarters location has guaranteed symmetric return before you enable route summarization with hot potato routing.
    3. (
      Optional
      ) Select an
      MRAI
      timer value.
      BGP routing offers a timer you can use to tailor BGP routing convergence in your network called the
      Minimum Route Advertisement Interval (MRAI)
      . MRAI acts to rate-limit updates on a per-destination basis, and the BGP routers wait for at least the configured MRAI time before sending an advertisement for the same prefix. A smaller number gives you faster convergence time but creates more advertisements in your network. A larger number decreases the number of advertisements that can be sent, but can also make routing convergence slower. You decide the number to put in your network for the best balance between faster routing convergence and fewer advertisements.
      Configure an MRAI range of between 1 and 600 seconds, with a default value of 30 seconds.
    4. Enter the IP address assigned as the Router ID of the eBGP router on the data center/HQ network for which you're configuring this service connection as the
      Peer Address
      .
    5. Enter the
      Peer AS
      , which is the autonomous system (AS) to which the firewall virtual router or BGP router at your data center/HQ network belongs.
    6. (
      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 service connection.
      You must configure a static route on your CPE to the BGP
      Local Address
      .
      If you use IPV6 support for your service connection, you can configure
      IPv6
      addresses as well as
      IPv4
      addresses. You also need to enable IPv6 networking globally in your
      Prisma Access
      infrastructure before you can use IPv6 addressing.
    7. (
      Optional
      ) Enter and confirm a
      Secret
      passphrase to authenticate BGP peer communications.
  10. (
    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.
  11. (
    Optional
    ) Enable
    Quality of Service
    for the service 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-premises-marked traffic. See QoS for Remote Networks for details.
  12. (
    Optional
    ) Configure
    Miscellaneous
    settings.
    1. (
      Optional
      )
      Disable Traffic Logging on Service Connections
      to disable logging on the service connections for your
      Prisma Access
      deployment.
      If the majority of the traffic flows logged by the service connections are asymmetric, disabling service connection logging might be required to reduce the consumption of Cortex Data Lake logging storage. If your deployment does not have asymmetric flows via the service connections, you don't need to disable logging.
  13. Commit your changes to Panorama and push the configuration changes to Prisma Access.
    1. Click
      Commit
      Commit and Push
      .
    2. Edit Selections
      and, in the
      Prisma Access
      tab, make sure that
      Service Setup
      is selected in the
      Push Scope
      , then click
      OK
      .
    3. Click
      Commit and Push
      .
  14. Add more service connections by repeating Step 2 through Step 11.
  15. Configure the IPSec tunnel or tunnels from your IPSec-capable device on your corporate network back to
    Prisma Access
    .
    1. To determine the IP address of the tunnel within
      Prisma Access
      , select
      Panorama
      Cloud Services
      Status
      Network Details
      , click the
      Service Connection
      radio button, and note the
      Service IP Address
      for the site.
      The Service IP Address is the public-facing address that you will need to connect to when you create the tunnel from your IPSec-capable device back to the service connection.
    2. On your IPSec-capable device at the corporate location, configure an IPSec tunnel that connects to the Service IP Address within
      Prisma Access
      and commit the change on that device so that the tunnel can be established.

Verify Service Connection Status

To verify that the service connection has been successfully set up, select
Panorama > Cloud Services > Status > Status
and check that the Status is
OK
.
If you created a service connection with placeholder values to enable communication between mobile users and users at remote networks, you do not need to verify the service connection status.
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.
If the status is not
OK
, hover over the Status icon to view any errors.
To see a graphical representation of the service connection along with status details, select
Service Connection
on the
Monitor
tab.
Select a region to get more detail about that region.
Click the tabs below the map to see additional information about the service connections.
Status
tab:
  • Location
    —The location where your service connection is deployed.
  • Remote Peer
    —The corporate location to which this s service infrastructure is setting up an IPSec tunnel.
  • Allocated Bandwidth
    —The number of service connections you have allocated multiplied by 300 Mbps.
    This number does not reflect the available service connection bandwidth.
    While each service connection provides approximately 1 Gbps of throughput, the actual throughput is dependent on several factors, including:
    • Traffic mix (for example, frame size)
    • Latency and packet loss between the service connection and the headquarters location or data center
    • Service provider performance limits
    • Customer termination device performance limits
    • Other customer data center traffic
  • ECMP
    —If you have equal cost multipath (ECMP) configured for this service connection. Since ECMP is not used for service connections, this status is
    Disabled
    .
  • Config Status
    —The status of your last configuration push to the service. If the local configuration and the configuration in the cloud match, the Config Status is
    In sync
    . If you have made a change locally, and not yet pushed the configuration to the cloud, this may display the status
    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 your corporate/headquarters location and
    Prisma Access
    where the service connection is established. 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 your data center/headquarters 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 your service connection.
Statistics
tab:
  • Location
    —The location where your service connection is deployed.
  • Remote Peer
    —The corporate location to which the service connection is setting up an IPSec tunnel.
  • Ingress Bandwidth (Mbps)
    —The bandwidth from the HQ/data center location to
    Prisma Access
    .
  • Ingress Peak Bandwidth (Mbps)
    —The peak load from the HQ/data center location into the cloud service.
  • Egress Bandwidth (Mbps)
    —The bandwidth from Prisma Access into the HQ/data center location.
  • Egress Peak Bandwidth (Mbps)
    —The peak load from
    Prisma Access
    into the HQ/data center location.
  • QoS
    —Select this button to display a graphic chart that shows a real-time and historical QoS statistics, including the number of dropped packets per class. This chart displays only for service connections or remote network connections that have QoS enabled.
If you configured BGP, you can check its status by selecting
Panorama
Cloud Services
Status
Network Details
Service Connection
Show BGP 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
    —BGP routes that
    Prisma Access
    uses locally. Prisma Access selects this information from the BGP RIB-In table, which stores the information sent by neighboring networking devices, applies local BGP import policies and routing decisions, and stores the Local RIB information in the Routing Information Base (RIB).
    Note that only the first 256 entries are shown. To view additional entries, enter a subnet or IP address in the Filter field and click Apply Filter to view a subset of the routing entries up to a maximum of 256.
  • RIB Out
    —Routing information that
    Prisma Access
    advertises to its peers through BGP update messages.

Recommended For You