Set Up an IPSec Tunnel (Tunnel Mode)
Focus
Focus
Network Security

Set Up an IPSec Tunnel (Tunnel Mode)

Table of Contents

Set Up an IPSec Tunnel (Tunnel Mode)

Set up an IPSec tunnel for authentication and encryption of data. Define proxy IDs for policy-based VPN peers and ensure successful IKE and IPSec negotiations.
Where Can I Use This?What Do I Need?
  • Prisma Access (Managed by Panorama or Strata Cloud Manager)
  • PAN-OS
  • No license required
  • PAN-OS 10.1 and Later
The IPSec tunnel configuration allows you to authenticate and/or encrypt the data (IP packet) as it traverses the tunnel.
IPSec tunnel mode is the default mode. IPSec tunnel mode creates a secure connection between two endpoints by encapsulating packets in an additional IP header. This means, in tunnel mode, the IPSec wraps the original packet, encrypts it, adds a new IP header and sends it to the other side of the VPN tunnel (IPSec peer). Hence, tunnel mode provides better security by encrypting the entire original packet. Tunnel mode is commonly used for site-to-site communications.
If you’re setting up the firewall to work with a peer that supports policy-based VPN, you must define Proxy IDs. Devices that support policy-based VPN use specific security rules/policies or access-lists (source addresses, destination addresses, and ports) for permitting interesting traffic through an IPSec tunnel. These rules are referenced during quick mode or IKE phase 2 negotiation, and are exchanged as proxy IDs in the first or the second message of the process. So, if you’re configuring the firewall to work with a policy-based VPN peer, for a successful phase 2 negotiation you must define the proxy ID so that the setting on both peers is identical. If the proxy ID isn’t configured, because the firewall supports route-based VPN, the default values used as proxy ID are source ip: 0.0.0.0/0, destination ip: 0.0.0.0/0 and application: any; and when these values are exchanged with the peer, it results in a failure to set up the VPN connection.
To establish an IPSec tunnel successfully, both IKE and IPSec negotiations should be successful:
  • The IKE negotiation will be successful only when both VPN peers exchange compatible IKE parameters.
  • The IKE Phase 2 (IPSec) negotiation will be successful only when both VPN peers exchange compatible IPSec parameters.

Set Up an IPSec Tunnel (Tunnel Mode) (PAN-OS 10.1 and Later)

Step-by-step procedure to configure IPSec tunnel in tunnel mode which is the default mode.
  1. Select NetworkIPSec Tunnels and then Add a new tunnel configuration.
  2. On the General tab, enter a Name for the tunnel.
  3. Select the Tunnel interface on which to set up the IPSec tunnel.
    To create a new tunnel interface:
    1. Select Tunnel InterfaceNew Tunnel Interface. (You can also select NetworkInterfacesTunnel and click Add.)
    2. In the Interface Name field, specify a numeric suffix, such as .2.
    3. On the Config tab, select the Security Zone list to define the zone as follows:
    Use your trust zone as the termination point for the tunnel—Select the zone. Associating the tunnel interface with the same zone (and virtual router) as the external-facing interface on which the packets enter the firewall mitigates the need to create inter-zone routing.
    Or:
    Create a separate zone for VPN tunnel termination (Recommended)—Select New Zone, define a Name for the new zone (for example vpn-corp), and click OK.
    1. For Virtual Router, select default.
    2. (Optional) If you want to assign an IPv4 address to the tunnel interface, select the IPv4 tab, and Add the IP address and network mask, for example 10.31.32.1/32.
    3. Click OK.
  4. (Optional) Enable IPv6 on the tunnel interface.
    1. Select the IPv6 tab on NetworkInterfacesTunnelIPv6.
    2. Select Enable IPv6 on the interface.
      This option allows you to route IPv6 traffic over an IPv4 IPSec tunnel and will provide confidentiality between IPv6 networks. The IPv6 traffic is encapsulated by IPv4 and then ESP. To route IPv6 traffic to the tunnel, you can use a static route to the tunnel, or use OSPFv3, or use a policy-based forwarding (PBF) rule.
    3. Enter the 64-bit extended unique Interface ID in hexadecimal format, for example, 00:26:08:FF:FE:DE:4E:29. By default, the firewall will use the EUI-64 generated from the physical interface’s MAC address.
    4. To assign an IPv6 Address to the tunnel interface, Add the IPv6 address and prefix length, for example 2001:400:f00::1/64. If Prefix isn’t selected, the IPv6 address assigned to the interface will be wholly specified in the address text box.
      1. Select Use interface ID as host portion to assign an IPv6 address to the interface that will use the interface ID as the host portion of the address.
      2. Select Anycast to include routing through the nearest node.
  5. Set up key exchange.
    On the General tab, configure one of the following types of key exchange:
    Set up Auto Key exchange
    1. Select the IKE Gateway. To set up an IKE gateway, see Set Up an IKE Gateway.
    2. (Optional) Select the default IPSec Crypto profile. To create a new IPSec Profile, see Define IPSec Crypto Profiles.
    Set up Manual Key exchange
    1. Specify the Local SPI for the local firewall. SPI is a 32-bit hexadecimal index that is added to the header for IPSec tunneling to assist in differentiating between IPSec traffic flows; it’s used to create the SA required for establishing a VPN tunnel.
    2. Select the Interface that will be the tunnel endpoint, and optionally select the IP address for the local interface that is the endpoint of the tunnel.
    3. Select the protocol to be used—AH or ESP.
    4. For AH, select the Authentication method and enter a Key and then Confirm Key.
    5. For ESP, select the Authentication method and enter a Key and then Confirm Key. Then, select the Encryption method and enter a Key and then Confirm Key, if needed.
    6. Specify the Remote SPI for the remote peer.
    7. Enter the Remote Address, the IP address of the remote peer.
  6. Protect against a replay attack.
    Anti-replay is a sub-protocol of IPSec and is part of the Internet Engineering Task Force (IETF) Request for Comments (RFC) 6479. The anti-replay protocol is used to prevent hackers from injecting or making changes in packets that travel from a source to a destination and uses a unidirectional security association in order to establish a secure connection between two nodes in the network.
    After a secure connection is established, the anti-replay protocol uses packet sequence numbers to defeat replay attacks. When the source sends a message, it adds a sequence number to its packet; the sequence number starts at 0 and is incremented by 1 for each subsequent packet. The destination maintains the sequence of numbers in a sliding window format, maintains a record of the sequence numbers of validated received packets, and rejects all packets that have a sequence number that is lower than the lowest in the sliding window (packets that are too old) or packets that already appear in the sliding window (duplicate or replayed packets). Accepted packets, after they’re validated, update the sliding window, displacing the lowest sequence number out of the window if it was already full.
    1. On the General tab, select Show Advanced Options and select Enable Replay Protection to detect and neutralize against replay attacks.
    2. Select the Anti Replay Window to use. You can select an anti-replay window size of 64, 128, 256, 512, 1024, 2048, or 4096. The default is 1024.
  7. (Optional) Preserve the Type of Service header for the priority or treatment of IP packets.
    In the Show Advanced Options section, select Copy TOS Header. This copies 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.
    If there are multiple sessions inside the tunnel (each with a different ToS value), copying the ToS header can cause the IPSec packets to arrive out of order.
  8. By default, IPSec tunnels come up in Tunnel mode if you don’t configure IPSec mode. You can also select IPSec Mode as Tunnel in the Show Advanced Options section to establish an IPSec in tunnel mode.
  9. (Optional) Select Add GRE Encapsulation to enable GRE over IPSec.
    Add GRE encapsulation in cases where the remote endpoint requires traffic to be encapsulated within a GRE tunnel before IPSec encrypts the traffic. For example, some implementations require multicast traffic to be encapsulated before IPSec encrypts it. Add GRE Encapsulation when the GRE packet encapsulated in IPSec has the same source IP address and destination IP address as the encapsulating IPSec tunnel.
  10. Enable Tunnel Monitoring.
    You must assign an IP address to the tunnel interface for monitoring.
    To alert the device administrator to tunnel failures and to provide an automatic failover to another tunnel interface:
    1. Select Tunnel Monitor.
    2. Specify a Destination IP address on the other side of the tunnel to determine if the tunnel is working properly.
    3. Select a Profile to determine the action upon tunnel failure. To create a new profile, see Define a Tunnel Monitoring Profile.
  11. Create a Proxy ID to identify the VPN peers.
    This step is required only if the VPN peer uses a policy-based VPN.
    1. Select NetworkIPSec Tunnels and click Add.
    2. Select the Proxy IDs tab.
    3. Select the IPv4 or IPv6 tab.
    4. Click Add and enter the Proxy ID name.
    5. Enter the Local IP address or subnet for the VPN gateway.
    6. Enter the Remote address for the VPN gateway.
    7. Select the Protocol:
      • Number—Specify the protocol number (used for interoperability with third-party devices).
      • Any—Allows TCP and/or UDP traffic.
      • TCP—Specify the local port and remote port numbers.
      • UDP—Specify the local port and remote port numbers.
    8. Click OK.
  12. Commit your changes.
    Click OK and Commit.

Set Up an IPSec Tunnel (Tunnel Mode) (Strata Cloud Manager)

Set up a Strata Cloud Manager Managed Prisma Access IPSec tunnel for your service connection or a remote network site.
Use the following steps to set up an IPSec tunnel for your service connection or a remote network site.
The first tunnel you create is the primary tunnel for the service connection or a remote network site. You can then repeat this workflow to optionally set up a secondary tunnel. When both tunnels are up, the primary tunnel takes priority over the secondary tunnel. If the primary tunnel for a service connection or a remote network site goes down, the connection falls back to the secondary tunnel until the primary tunnel comes back up.
Based on the IPSec device you use to establish the tunnel for your service connection or a remote network site, Prisma Access provides built-in, recommended IKE and IPSec security settings. You can use the recommended settings to get started quickly, or customize them as needed for your environment.

Add Primary and Secondary IPSec VPN Tunnels

  1. Launch Prisma Access Cloud Management.
  2. For a service connection, go to SettingsPrisma Access SetupService Connections and Set Up the primary tunnel. For a remote network site, go to SettingsPrisma Access SetupRemote Networks and Set Up the primary tunnel. If you’ve already set up a primary tunnel, you can continue here to also add a secondary tunnel.
    1. Give the tunnel a descriptive Name.
    2. Select the Branch Device Type for the IPSec device at the HQ/DC (for a service connection) or at the remote network site 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.
      (For a service connection) If you set the Branch Device IP Address to Dynamic, you must also add the IKE ID for the HQ/DC (IKE Local Identification) or for Prisma Access (IKE Peer Identification) to enable the IPSec peers to authenticate.
      Because you do not 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/DC (IKE Local Identification) rather than the Prisma Access IKE ID.
      (For a remote network site) If you set the Branch Device IP Address to Dynamic, you must also add the IKE ID for the remote network site (IKE Local Identification) or for Prisma Access (IKE Peer Identification) to enable the IPSec peers to authenticate.
      Because you do not have the values to use for the Prisma Access IKE ID (IKE Peer Identification) until the remote network is fully deployed, you would typically want to set the IKE ID for the remote network site (IKE Local Identification) rather than the Prisma Access IKE ID.
  3. Turn on Tunnel Monitoring.
    Enter a Tunnel Monitoring Destination IP address on the HQ/DC network for Prisma Access to use determine whether the tunnel is up and, if your IPSec device uses policy-based VPN, enter the associated Proxy ID.
    The tunnel monitoring IP address you enter is automatically added to the list of branch subnetworks.
  4. Save the tunnel settings.
    To continue:

Set Up an IPSec Tunnel (Tunnel Mode) ()

Set up a Panorama Managed Prisma Access IPSec tunnel for your service connection or a remote network site.
With Prisma Access, Palo Alto Networks deploys and manages the security infrastructure globally to secure your remote networks and mobile users.
  • Service Connections—If your Prisma Access license includes it, you have the option to establish IPSec tunnels to allow communication between internal resources in your network and mobile users and users in your remote network locations. You could, for example, create a service connection to an authentication server in your organization’s HQ or data center.
    Even if you don’t require a service connection for your HQ or data center, we recommend that you create one to allow network communication between mobile users and remote network locations, and between mobile users in different geographical locations.
  • Remote Networks—Use remote networks to secure remote network locations, such as branches, and users in those branches with cloud-based next-generation firewalls. You can enable access to the subnetworks at each remote network location using either static routes, dynamic routing using BGP, or a combination of static and dynamic routes. All remote network locations that you onboard are fully meshed.
See how to set up an IPSec tunnel for a service connection and a remote network.

Set up an IPSec Tunnel (Service Connection)

  1. Select or add a new IPSec Tunnel configuration to access the private apps at your data center or headquarters 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.
  2. 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.
  3. 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.

Set up an IPSec Tunnel (Remote Network)

  1. (Static routing or single-tunnel deployments only) Select or add a new IPSec Tunnel configuration to access the firewall, router, or SD-WAN device at the corporate location:
    • Select one of the predefined IPSec templates in the Remote_Network_Template, or, if you have added a template to the Remote_Network_Template_Stack (or modified the predefined Remote_Network_Template) that includes an IPSec Tunnel configuration, select that IPSec Tunnel from the drop-down. Note that the tunnel you are creating for each remote network connection connects Prisma Access to the IPSec-capable device at each branch location.
      Use the following guidelines when configuring an IPSec tunnel:
      • The peer addresses in the IKE Gateway configuration must be unique for each tunnel. You can, however, re-use some of the other common configuration elements, such as crypto profiles.
      • The IPSec Tunnel you select from a template must use Auto Key exchange and IPv4 only.
      • The IPSec tunnel, IKE gateway, and crypto profile names cannot be longer than 31 characters.
      • If you onboard multiple remote networks to the same location with dynamic IKE peers, you must use the same IKE crypto profile for all remote network configurations.
    • To create a new IPSec Tunnel configuration, click New IPSec Tunnel, give it a Name and configure the IKE Gateway, IPSec Crypto Profile, and Tunnel Monitoring settings.
      • If the IPSec-capable device at your branch location uses policy-based VPN, on the Proxy IDs tab, Add a proxy ID that matches the settings configured on your local IPSec device to ensure that Prisma Access can successfully establish an IPSec tunnel with your local device.
    • Leave Enable Replay Protection selected to detect and neutralize against replay attacks.
    • Select Copy TOS Header to copy the Type of Service (TOS) header from the inner IP header to the outer IP header of the encapsulated packets in order to preserve the original TOS information.
    • To enable tunnel monitoring for the service connection, select Tunnel Monitor.
      • Enter a Destination IP address.
        Specify an IP address at your branch location to which Prisma Access can send ICMP ping requests for IPSec tunnel monitoring. Make sure that this address is reachable by ICMP from the entire Prisma Access infrastructure subnet.  
      • If you use tunnel monitoring with a peer device that uses multiple proxy IDs, specify a Proxy ID or add a New Proxy ID that allows access from the infrastructure subnet to your branch location.
        The following figure shows a proxy ID with the service infrastructure subnet (172.16.55.0/24 in this example) as the Local IP subnet and the branch location’s subnet (10.1.1.0/24 in this example) as the Remote subnet.
        The following figure shows the Proxy ID you created being applied to the tunnel monitor configuration by specifying it in the Proxy ID field.
      You must configure a static route on your CPE to the Tunnel Monitor IP Address for tunnel monitoring to function. To find the destination IP address to use for tunnel monitoring from your branch location to Prisma Access, select PanoramaCloud ServicesStatusNetwork Details, click the Service Infrastructure radio button, and find the Tunnel Monitor IP Address.
  2. 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.