>
    Onboard a Remote Network
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma Access
    3. Prisma Access Remote Networks
    4. Onboard a Remote Network
    Download PDF
    Prisma Access

    Onboard a Remote Network

    Table of Contents

    Onboard a Remote Network

    This section describes the prerequisites for configuring remote networks, as well as how to configure and validate remote network operations.
    Where Can I Use This?
    What Do I Need?
    • Prisma Access (Managed by Strata Cloud Manager)
    • Prisma Access (Managed by Panorama)
    Once you have planned for your remote network, you can begin the configuration process. This includes onboarding the remote network, connecting the remote network site to
    Prisma Access
    , and enabling routing and QoS for the remote network. For each remote network that you want to secure using
    Prisma Access
     for networks, you 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 procedures to onboard your remote networks depending on your bandwidth allocation type:
    Learn how to onboard a remote network.

    Cloud Management

    To onboard a remote network site to
    Prisma Access
    , specify the location and define the amount of bandwidth to allocate to the connection.
    Here’s how to add a new remote network site to Prisma Access. You’ll start by specifying the location and defining the amount of bandwidth to allocate to the connection.

    1. Launch
      Prisma Access (Managed by Strata Cloud Manager)
      .
    2. Make sure that you have allocated bandwidth to the location where you’ll deploy the remote network. See Planning Checklist for Remote Networks.
    3. Go to
      Manage
      Service Setup
      Remote Networks
      Add Remote Networks
      .
      If you're using
      Strata Cloud Manager
      , go to
      Workflows
      Prisma Access
       Setup
      Remote Networks
      Add Remote Networks
      .
    4. Give the remote network a descriptive
      Site Name
      .
    5. Select the
      Region
       in which the site is located, and the closest
      Prisma Access
      Location
      .
    6. (
      Only if you’re planning to use BGP for dynamic routing
      ) Enable
      ECMP Load Balancing
       so that the remote network site can use up to four IPSec tunnels.
      BGP is required for ECMP load balancing; QoS and static routes are not supported.
      When you enable ECMP, Remote Network traffic is load balanced over the tunnels you configure.
    7. Configure
      Advanced Settings
      .
      • (
        Optional
        ) Use
        Static Entries
         to resolve FQDNs to specific IP addresses.
        This functionality can be useful if you have guest internet services at your organization and you want your guests to safely use search engines, preventing them from searching for potentially inappropriate or offensive material that could be against company policy. To do so, enter a unique
        Name
         for the static entry rule, an
        FQDN
        , and the IP
        Address
         where the FQDN request should be directed.
      • If you want
        Prisma Access
         to proxy DNS requests, configure values for
        UDP Queries Retries
         (the
        Interval (Sec)
         to retry the query in seconds and the number of retry
        Attempts
         to perform.
    8. Connect a Remote Network Site to Prisma Access, where you’ll create an IPSec VPN tunnel to connect the remote network site to
      Prisma Access
      .
    9. Configure static routing.
      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 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. (
        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.
      7. Enter the
        Peer IP Address
         assigned as the Router ID of the eBGP router on the HQ or data center network.
      8. Enter the
        Peer AS
        , the autonomous system (AS) for your network.
        Use and RFC 6996-compliant BGP Private AS number.
      9. 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.
      10. Enter a
        Secret
         password to authenticate BGP peer communications.
      11. Select
        Confirm Secret
        .

    Panorama

    Configure a
    Prisma Access
     remote network deployment that allocates bandwidth by compute location.
    To configure a
    Prisma Access
     remote network deployment that allocates bandwidth by compute location, complete the following steps.
    If you need to onboard many remote networks (up to 1,000), you can onboard a remote network using the following procedure, then export the remote network configuration to a CSV file, add the other remote networks you want to onboard to the CSV file, then import the CSV file to save the configuration into
    Prisma Access
    .
    1. Select
      Panorama
      Cloud Services
      Configuration
      Remote Networks
       and edit the settings by clicking the gear icon in the
      Settings
       area.
      1. 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.
      2. 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.
      3. (
        Optional
        ) If you have configured a next-generation firewall as a master device or added a Cloud Identity Engine profile to make user and group information selectable in security policies, select
        User-ID Master Device
         or
        Cloud Identity Engine
        ; then, select either the Master Device or the Cloud Identity Engine profile that you created.
      4. 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).
    2. (
      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.
      1. In the
        Remote_Network_Device_Group
         device group, select
        Policies
        Security
         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.
      2. 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
        Panorama
        Cloud Services
        Status
        Network Details
        Service Infrastructure
        .
      3. 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
          Worldwide
           to apply the DNS settings globally, select a specific theater, or select settings per location group (a group of locations that is smaller than the theater). If you add multiple settings, the location group settings are used first, then the theater settings, then the worldwide settings.
          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 (
          Panorama
          Cloud Services
          Status
          Network Details
          Service Infrastructure
          ).
      4. (
        Optional
        ) Select Advanced RCODE Support to allow the primary DNS server to fail over to the secondary DNS server if an RCODE 2 (SERVFAIL) and RCODE 5 (REFUSED) DNS return code is received.
        A DNS response code of SERVFAIL refers to a communication error with the primary DNS server, and a DNS response code of REFUSED means that the primary DNS server refused to provide the requested information. In both cases, the service fails over to the secondary DNS server.
      5. (
        Optional
        ) Use
        Static IP Entries
         to resolve FQDNs to specific IP addresses.
        This functionality can be useful if you have guest internet services at your organization and you want your guests to safely use search engines, preventing them from searching for potentially inappropriate or offensive material that could be against company policy. To do so, enter a unique
        Name
         for the static entry rule, an
        FQDN
        , and the IP
        Address
         where the FQDN request should be directed.
    3. (
      Optional
      ) Enable
      QoS
       for your remote network deployment and specify a
      QoS Profile
      ,
      Guaranteed Bandwidth Ratio
      , the amount of
      Reserved for Guaranteed Bandwidth (Mbps)
       bandwidth and, optionally, customize site options per location (
      Customize Per Site
      ).
      You enable QoS at a compute location level; however, you can specify to enable or disable QoS on a per-site basis, and specify a QoS profile on a per-site basis, when you add your remote network in a later step. Before you configure QoS, you should understand how QoS works for remote networks that allocate bandwidth by compute location, including specifying the guaranteed bandwidth and customizing bandwidth per site.
    4. (
      Optional
      ) Configure
      Group Mapping Settings
       to have
      Prisma Access
       use the Directory Sync component of the Cloud Identity Engine to retrieve user and group information.
      You must configure the Cloud Identity Engine to retrieve user and group information from your Active Directory (AD) before you enable group mapping in
      Prisma Access
       using
      Group Mapping Settings
      .
    5. 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.
      1. (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.
      2. For each zone you want to designate as trusted, select it and click
        Add
         to move it to the list of
        Trusted Zones
        .
      3. Click
        OK
         to save the mappings.
    6. 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 Prisma Access Remote Networks for details.
      If you have removed Autonomous DEM as an add-on license, or if you remove Autonomous DEM for remote networks from your license, select
      Disable Autonomous DEM
      . If you remove Autonomous DEM for remote networks and do not disable Autonomous DEM, you will receive an error upon commit.
      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 aggregate bandwidth model. Click
      Migrate
       to continue, or
      Cancel
       to cancel the migration.
      The migration to the aggregate bandwidth model is permanent and not reversible. Before you migrate, review the pre-migration checklist. You must
      Commit and Push
       your changes for them to take effect.
      The
      Service IP Address
       (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 to the aggregate bandwidth model, and no reconfiguration of your IPSec tunnel is required.
    7. 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.
    8. (
      Optional, Deployments with Autonomous DEM for Remote Networks Licenses Only
      )
      Enable
      Autonomous DEM Allocation
       for the compute location for which you allocated bandwidth.
      If you enable Autonomous DEM for the compute location, the amount of bandwidth used by the Autonomous DEM license is the same as the bandwidth you specify for the compute location. The
      Autonomous DEM Allocated Total
       shows you how much bandwidth is used by Autonomous DEM and how much is remaining. See the Autonomous DEM guide for more information.
    9. Wait for the bandwidth to be reflected in the
      Allocated Total
       field at the top of the page; then, click
      OK
      .
    10. (
      Optional)
       If you want to configure your remote network to provide secure inbound access to remote network locations, click the
      Inbound Access Remote Networks
       tab and follow the workflow to configure secure inbound access for a remote network.
    11. Add
       a remote network and specify a
      Name
      .
      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.
    12. (
      Optional, 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
      ).
      Static routes are not supported (BGP is required), and, if you have QoS configured, you cannot change the Allocation Ratio for ECMP links. 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 15.
      1. 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.
      2. 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.
        • (
          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.
        • 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.
      3. Repeat the previous step to add up to four tunnels to use with the remote network connection.
    13. 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.
      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.
      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:
      • 1 Gbps remote network throughput is not supported (these locations support a maximum of 500 Gpbs).
      • Remote network and service connection node redundancy across availability zones is not available if you deploy them in the same local zone, as both nodes are provisioned in a single zone.
      • These local zones do not 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.
    14. 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.
    15. (
      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
        Panorama
        Cloud Services
        Status
        Network Details
        , click the
        Service Infrastructure
         radio button, and find the
        Tunnel Monitor IP Address
        .
    16. 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.
    17. 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
        :
        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. Select the
          BGP
           tab.
        2. (
          Optional
          ) Select the
          ECMP Load Balancing
           choices. See Step 12.
        3. If you select
          None
           for
          ECMP Load Balancing
          , enter the BGP choices.
        4. 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.
        5. 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
          .
        6. 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.
        7. 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.
        8. Enter the
          Peer AS
          , which is the autonomous system (AS) to which the firewall, virtual router, or BGP router at your remote network belongs.
        9. 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
          .
        10. (
          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
          .
        11. (
          Optional
          ) Enter and confirm a passphrase to authenticate BGP peer communications.
        12. (
          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.
          If you use IPv6 networking in your remote network deployment, 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.
          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.
    18. (
      Optional
      ) Enable
      QoS
       for the location and specify a
      QoS Profile
      .
      You specify QoS options and overall settings on a per-compute location basis in the
      Settings
      ; however, you can enable or disable QoS or change the QoS profile on a per-location basis here.
    19. Commit the configuration changes to Panorama and push the configuration out to
      Prisma Access
       for networks.
      1. Click
        Commit
        Commit to Panorama
        .
      2. Click
        Commit
        Commit and Push
        . Click
        Edit Selections
        Prisma Access
        , and select both
        Prisma Access
         for networks and Prisma Access for service setup to push the configuration out to the service.
      3. Click
        OK
         and
        Push
        .
    20. Configure the IPSec-capable device at the remote network location to set up an IPSec connection with
      Prisma Access
       for networks.
      1. Find the
        Service IP Address
         for this remote network connection by selecting
        Panorama
        Cloud Services
        Status
        Network 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.
      2. Check the
        Local IP address
         for the device at the remote network location on the
        Panorama
        Cloud Services
        Status
        Network Details
        Remote 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.
    21. To secure traffic at the remote network location you must create security policy rules.
      1. Select
        Policies
        .
      2. 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.
      3. 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.
    22. Enable logging to Cortex Data Lake. You must create and attach a log forwarding profile to each policy rule for which you want to forward logs.
      1. Select
        Objects > Log Forwarding
        .
      2. Select the
        Device Group
         in which you added the policy rules, for example, Remote_Network_Device_Group.
      3. Add
         a Log Forwarding profile. In the log forwarding profile match list,
        Add
         each
        Log Type
         that you want to forward.
      4. Select
        Panorama/Cortex Data Lake
         as the Forward Method to enable
        Prisma Access
         to forward the logs to Cortex Data Lake. You will be able to monitor the logs and generate reports from Panorama. Cortex Data Lake provides a seamless integration to store logs without backhauling them to your Panorama at the corporate headquarters, and Panorama can query Cortex Data Lake as needed.
        The following example enables forwarding of Traffic, Threat Prevention, WildFire Submission, URL Filtering, Data Filtering, and Authentication logs to Cortex Data Lake.
      5. Select
        Policies > Security
         and edit the policy rule. In
        Actions
        , select the Log Forwarding profile you created.
    23. Commit all 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
        Prisma Access
         for networks
         is selected in the
        Push Scope
        , then click
        OK
        .
      3. Commit and Push
         your changes.
    24. Check the remote network status.

    Recommended For You

    © 2024 Palo Alto Networks, Inc. All rights reserved.