Create a Service Connection to Allow Access to Private Apps

1. Select PanoramaCloud ServicesConfigurationService 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.
5. 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 Service_Conn_Template_Stack (or modified the predefined Service_Conn_Template) that includes an IPSec Tunnel configuration, select that IPSec Tunnel from the drop-down. Note that the tunnel you are 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, 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. 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.
   • 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 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 PanoramaCloud ServicesStatusNetwork 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 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.
8. (Optional, 3.2 Innovation Deployments Only) 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.
   • 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 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:

   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.
        Do not 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. Enter the IP address assigned as the Router ID of the eBGP router on the data center/HQ network for which you are configuring this service connection as the Peer Address.
   4. 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.
   5. (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 networking 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.
      If you do not specify a local address, Prisma Access uses an IP address from the Infrastructure Subnet. After you Commit and Push your changes, you can find the Local Address used under the EBGP Router Address (PanoramaCloud ServicesStatusNetwork DetailsService ConnectionEBGP Router).
   6. (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. If required, 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-premise-marked traffic. See Quality of Service in Prisma Access 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 Strata Logging Service logging storage. If your deployment does not have asymmetric flows via the service connections, you do not need to disable logging.

13. Commit your changes to Panorama and push the configuration changes to Prisma Access.

    1. Click CommitCommit 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 13.
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 PanoramaCloud ServicesStatusNetwork 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.