Configure Prisma Access for Networks

For each remote network that you want to secure using Prisma Access for networks, you must use the following workflow to push the required policy configuration to the cloud service and onboard each remote network so that you can start sending traffic from the remote site through the IPSec tunnel to the firewalls in the cloud.
Before you begin onboarding your remote networks, be sure you go through the steps to Plan to Deploy Prisma Access for Networks.
If you need to onboard many remote network locations, onboard a remote network using this workflow and then import the remote network configuration.
  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. 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).
      remote-network-overlapped-subnet.png
  2. 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.
  3. Click
    Add
    in the Onboarding settings, and specify a
    Name
    to identify the infrastructure that will secure the remote network location you are onboarding.
    You cannot change the name of the remote network location after you enter it. Make sure you know your naming scheme for your remote networks before you begin onboarding.
  4. Select the
    Bandwidth
    you want to allocate to this remote network location. The bandwidth you select cannot exceed the total amount of bandwidth you have licensed. Use this setting to define the amount of the total licensed bandwidth you want to allocate to this location.
    To help you determine how much bandwidth a specific site needs, consider the bandwidth available from your ISP at each location. See How to Calculate Remote Network Bandwidth for more details and suggestions.
  5. Select the
    Location
    in which Prisma Access will deploy the infrastructure required to secure your remote network location. This region should be geographically located close to your remote network location.
    See this table for a list of Prisma Access locations.
  6. Select or add a new
    IPSec Tunnel
    configuration to access the firewall, router, or SD-WAN device at the corporate location:
    • If you have added a template to the Remote_Network_Template_Stack (or modified the predefined Remote_Network_Template) that includes an IPSec Tunnel configuration, select that
      IPSec Tunnel
      from the drop-down. Note that the tunnel you are creating for each remote network connection connects Prisma Access to the IPSec-capable device at each branch location. 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.
    • 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.
        tunnel-monitor-proxy-id.png
        The following figure shows the Proxy ID you created being applied to the tunnel monitor configuration by specifying it in the
        Proxy ID
        field.
      service-connection-tunnel-profile.png
      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
      .
  7. 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.
      remote-network-onboarding-static.png
    • To configure
      BGP
      :
      1. On the
        BGP
        tab, select
        Enable
        .
      2. (
        Optional
        ) To prevent the BGP peer on the Prisma Access firewall from forwarding routes into your remote network, select
        Don’t export 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-premise equipment to establish routes back to Prisma Access.
        remote-network-onboarding-bgp.png
      3. Enter the
        Peer AS
        , which is the autonomous system (AS) to which the firewall virtual router or BGP router at your remote network belongs.
      4. 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
        .
      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 remote network.
      6. (
        Optional
        ) Enter and confirm a passphrase to authenticate BGP peer communications.
  8. If required, enable
    Quality of Service
    for the remote network connection and specify a QoS profile or add a
    New QoS Profile
    .
    You can create QoS profiles to shape QoS traffic for remote network and service connections and apply those profiles to traffic that you marked with PAN-OS security policies, traffic that you marked with an on-premise device, or both PAN-OS-marked and on-premise-marked traffic. See Configure Quality of Service in Prisma Access for details.
    remote-network-qos.png
  9. 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 earlier.
    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.
  10. 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.
      commit-networks-scope.png
    3. Click
      OK
      and
      Push
      .
  11. 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 your Prisma Access firewall, 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.
      verify_service_ip.png
    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.
  12. 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.
  13. 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/Logging Service
      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.
      prisma-access-remote-network-log-forwarding.png
    5. Select
      Policies > Security
      and edit the policy rule. In
      Actions
      , select the Log Forwarding profile you created.
  14. Commit all your changes to Panorama and push the configuration changes to Prisma Access.
    1. Click
      Commit
      Commit to Panorama
      .
    2. Click
      Commit
      Push to Devices
      and click
      Edit Selections
      .
    3. On the
      Prisma Access
      tab, make sure
      Prisma Access for networks
      is selected and then click
      OK
      .
    4. Click
      Push
      .

Verify Remote Network Connection Status

Select
Panorama
Cloud Services
Status
Status
to verify that the remote network connections have been successfully deployed.
verify_service_status.png
To display a map that shows the locations of the remote networks in the regions you have selected, select
Panorama
Cloud Services
Status
Monitor
and click the
Remote Networks
tab.
remote-network-status-by-region.png
Select a region to get more detail about that region.
remote-network-status-by-location.png
Click the tabs below the map to see additional remote network statistics.
Status
tab:
  • Region
    —The region where your cloud service infrastructure is deployed for the remote network location.
  • Remote Peer
    —The peer to which the remote network has an IPSec tunnel connection.
  • Allocated Bandwidth (Mbps)
    —The amount of bandwidth you allocated for the remote network location.
    To enable traffic peaks, the service allows you to go 10% over the allocated bandwidth for each site; traffic overages above this peak limit is dropped.
  • Config Status
    —The status of your last configuration push to the service. If you have made a change locally, and not yet pushed the configuration to the cloud, the status shows
    Out of sync
    . Hover over the status indicator for more detailed information. After committing and pushing the configuration to Prisma Access, the Config Status changes to
    In sync
    .
  • BGP Status
    —Displays information about the BGP state between the firewall or router at the remote network location and the Prisma Access firewall. Although you might temporarily see the status pass through the various BGP states (
    idle
    ,
    active
    ,
    open send
    ,
    open pend
    ,
    open confirm
    , most commonly, the BGP status shows:
    • Connect
      —The router at the remote network location is trying to establish the BGP peer relationship with the Prisma Access firewall.
    • Established
      —The BGP peer relationship has been established.
      This field will also show if the BGP connection is in an error state:
    • Warning—There has not been a BGP status update in more than eight minutes. This may indicate an outage on the firewall.
    • Error
      —The BGP status is unknown.
  • Tunnel Status
    —The operational status of the connection between Prisma Access and the remote network.
Statistics
tab:
  • Region
    —The region where your cloud service infrastructure is deployed for the remote network location.
  • Remote Peer
    —The peer to which the remote network has an IPSec tunnel connection.
  • Allocated Bandwidth (Mbps)
    —The amount of bandwidth you allocated for the remote network location.
    To enable traffic peaks, the service allows you to go 10% over the allocated bandwidth for each site; traffic overages above this peak limit is dropped.
  • Config Status
    —The status of your last configuration push to the service. If you have made a change locally, and not yet pushed the configuration to the cloud, the status shows
    Out of sync
    . Hover over the status indicator for more detailed information. After committing and pushing the configuration to Prisma Access, the Config Status changes to
    In sync
    .
  • BGP Status
    —Displays information about the BGP state between the firewall or router at the remote network location and the Prisma Access firewall. Although you might temporarily see the status pass through the various BGP states (
    idle
    ,
    active
    ,
    open send
    ,
    open pend
    ,
    open confirm
    , most commonly, the BGP status shows:
    • Connect
      —The router at the remote network location is trying to establish the BGP peer relationship with the Prisma Access firewall.
    • Established
      —The BGP peer relationship has been established.
      This field will also show if the BGP connection is in an error state:
    • Warning—There has not been a BGP status update in more than eight minutes. This may indicate an outage on the firewall.
    • Error
      —The BGP status is unknown.
  • Tunnel Status
    —The operational status of the connection between Prisma Access and the remote network.

Verify Remote Connection BGP Status

If you configured BGP, you can check its status by selecting
Panorama
Cloud Services
Status
Network Details
Remote Networks
Show BGP Status
.
show-bgp-status-networks.png
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.
    bgp-status-peer.png
  • RIB In
    —Routing information that has been received from different peers and is stored in the Routing Information Base (RIB).
    bgp-status-rib-in.png
  • RIB Out
    —Routing information that Prisma Access advertises to its peers through BGP update messages. See How BGP Advertises Mobile User IP Address Pools for Service Connections and Remote Network Connections for an example of this table and for information about how BGP utilizes the IP address pool you create for mobile users.

Related Documentation