Palo Alto

This topic provides configuration for a Palo Alto device. The configuration was validated using PAN-OS version 8.0.0.

Palo Alto experience is required.


Oracle provides configuration instructions for a set of vendors and devices. Make sure to use the configuration for the correct vendor.

If the device or software version that Oracle used to verify the configuration does not exactly match your device or software, the configuration might still work for you. Consult your vendor's documentation and make any necessary adjustments.

If your device is for a vendor not in the list of verified vendors and devices, or if you're already familiar with configuring your device for IPSec, see the list of supported IPSec parameters and consult your vendor's documentation for assistance.

VPN Connect is the IPSec VPN that Oracle Cloud Infrastructure offers for connecting your on-premises network to a virtual cloud network (VCN).

The following diagram shows a basic IPSec connection to Oracle Cloud Infrastructure with redundant tunnels. IP addresses used in this diagram are only examples.

This image summarizes the general layout of your on-premises network, VPN Connect tunnels, and VCN.

Best Practices

This section covers general best practices and considerations for using VPN Connect.

Configure All Tunnels for Every IPSec Connection

Oracle deploys two IPSec headends for each of your connections to provide high availability for your mission-critical workloads. On the Oracle side, these two headends are on different routers for redundancy purposes. Oracle recommends configuring all available tunnels for maximum redundancy. This is a key part of the "Design for Failure" philosophy.

Have Redundant CPEs in Your On-Premises Network Locations

Each of your sites that connects with IPSec to Oracle Cloud Infrastructure should have redundant edge devices (also known as customer-premises equipment (CPE)). You add each CPE to the Oracle Console and create a separate IPSec connection between your dynamic routing gateway (DRG)  and each CPE. For each IPSec connection, Oracle provisions two tunnels on geographically redundant IPSec headends. For more information, see the Connectivity Redundancy Guide (PDF).

Routing Protocol Considerations

When you create an IPSec VPN, it has two redundant IPSec tunnels. Oracle encourages you to configure your CPE to use both tunnels (if your CPE supports it). Note that in the past, Oracle created IPSec VPNs that had up to four IPSec tunnels.

The following two routing types are available, and you choose the routing type separately for each tunnel in the IPSec VPN:

  • BGP dynamic routing: The available routes are learned dynamically through BGP. The DRG dynamically learns the routes from your on-premises network. On the Oracle side, the DRG advertises the VCN's subnets.
  • Static routing: When you set up the IPSec connection to the DRG, you specify the particular routes to your on-premises network that you want the VCN to know about. You also must configure your CPE device with static routes to the VCN's subnets. These routes are not learned dynamically.

For more information about routing with VPN Connect, including Oracle recommendations on how to manipulate the BGP best path selection algorithm, see Routing for the Oracle IPSec VPN.

Other Important CPE Configurations

Ensure access lists on your CPE are configured correctly to not block necessary traffic from or to Oracle Cloud Infrastructure.

If you have multiple tunnels up simultaneously, ensure that your CPE is configured to handle traffic coming from your VCN on any of the tunnels. For example, you need to disable ICMP inspection, configure TCP state bypass, and so on. For more details about the appropriate configuration, contact your CPE vendor's support.

Caveats and Limitations

This section covers general important characteristics and limitations of VPN Connect to be aware of.

Asymmetric Routing

Oracle uses asymmetric routing across the multiple tunnels that make up the IPSec connection. Configure your firewalls accordingly. Otherwise, ping tests or application traffic across the connection will not reliably work.

When you use multiple tunnels to Oracle Cloud Infrastructure, Oracle recommends that you configure your routing to deterministically route traffic through the preferred tunnel. If you want to use one IPSec tunnel as primary and another as backup, configure more-specific routes for the primary tunnel (BGP) and less-specific routes (summary or default route) for the backup tunnel (BGP/static). Otherwise, if you advertise the same route (for example, a default route) through all tunnels, return traffic from your VCN to your on-premises network will route to any of the available tunnels (because Oracle uses asymmetric routing).

For specific Oracle routing recommendations about how to force symmetric routing, see Preferring a Specific Tunnel in the IPSec VPN.

Route-Based or Policy-Based IPSec VPN

The IPSec protocol uses Security Associations (SAs) to determine how to encrypt packets. Within each SA, you define encryption domains to map a packet's source and destination IP address and protocol type to an entry in the SA database to define how to encrypt or decrypt a packet.


Other vendors or industry documentation might use the term proxy ID, security parameter index (SPI), or traffic selector when referring to SAs or encryption domains.

There are two general methods for implementing IPSec tunnels:

  • Route-based tunnels: Also called next-hop-based tunnels. A route table lookup is performed on a packet's destination IP address. If that route’s egress interface is an IPSec tunnel, the packet is encrypted and sent to the other end of the tunnel.
  • Policy-based tunnels: The packet's source and destination IP address and protocol are matched against a list of policy statements. If a match is found, the packet is encrypted based on the rules in that policy statement.

The Oracle VPN headends use route-based tunnels but can work with policy-based tunnels with some caveats listed in the following sections.


The Oracle VPN headend supports only a single encryption domain. If your policy includes multiple entries, the tunnel will flap or there will be connectivity problems in which only a single policy works at any one time.

Encryption domain for route-based tunnels
Encryption domain for policy-based tunnels

If Your CPE Is Behind a NAT Device

In general, the CPE IKE identifier configured on your end of the connection must match the CPE IKE identifier that Oracle is using. By default, Oracle uses the CPE's public IP address, which you provide when you create the CPE object in the Oracle Console. However, if your CPE is behind a NAT device, the CPE IKE identifier configured on your end might be the CPE's private IP address, as show in the following diagram.

This image shows the CPE behind a NAT device, the public and private IP addresses, and the CPE IKE identifier.


Some CPE platforms do not allow you to change the local IKE identifier. If you cannot, you must change the remote IKE ID in the Oracle Console to match your CPE's local IKE ID. You can provide the value either when you set up the IPSec connection, or later, by editing the IPSec connection. Oracle expects the value to be either an IP address or a fully qualified domain name (FQDN) such as For instructions, see Changing the CPE IKE Identifier That Oracle Uses.

Supported IPSec Parameters

For a vendor-neutral list of supported IPSec parameters for all regions, see Supported IPSec Parameters.

The Oracle BGP ASN for the commercial cloud is 31898. If you're configuring VPN Connect for the Government Cloud, see Required VPN Connect Parameters for Government Cloud and also Oracle's BGP ASN.

CPE Configuration


The configuration instructions in this section are provided by Oracle Cloud Infrastructure for your CPE. If you need support or further assistance, contact your CPE vendor's support directly.

The following figure shows the basic layout of the IPSec connection.

This image summarizes the general layout of the IPSec connection and tunnels.

Important Details About the Configuration Instructions

  • Commits: For PAN to activate the configuration, you must perform the commit action after any configuration change.
  • Example IP addresses: The example configuration uses IP addresses from class A (RFC1918) and (RFC5735). When you perform the configuration on the CPE, use the correct IP addressing plan for your networking topology.

The example configuration uses the following variables and values:

  • Inside tunnel1 interface - CPE:
  • Inside tunnel2 interface - CPE:
  • Inside tunnel1 interface - Oracle:
  • Inside tunnel2 interface - Oracle:
  • CPE ASN: 64511
  • On-premises network:
  • VCN CIDR block:
  • CPE public IP address:
  • Oracle VPN headend (DRG) IP address 1:
  • Oracle VPN headend (DRG) IP address 2:
  • Tunnel number 1: tunnel.1
  • Tunnel number 2: tunnel.2
  • Exit interface: ethernet1/1

About Using IKEv2

Oracle supports Internet Key Exchange version 1 (IKEv1) and version 2 (IKEv2). If you configure the IPSec connection in the Console to use IKEv2, you must configure your CPE to use only IKEv2 and related IKEv2 encryption parameters that your CPE supports. For a list of parameters that Oracle supports for IKEv1 or IKEv2, see Supported IPSec Parameters.

If you want to use IKEv2, there are special variations of some steps presented in the next section. Here is a summary of the special steps:

Configuration Process

The following process includes BGP configuration for the IPSec connection. If you instead want to use static routing, perform tasks 1–5, and then skip to Configuring Static Routing.

Task 1: Configure the ISAKMP Phase 1 policy
Task 2: Define the ISAKMP peers
Task 3: Define the IPSec Phase 2 policy
Task 4: Configure the virtual tunnel interfaces
Task 5: Configure the IPSec sessions
Task 6: Configure BGP over IPSec

Configuring Static Routing

Use the instructions here if your CPE does not support BGP over IPSec, or you do not want to use BGP over IPSec.

In this task, you configure static routes to direct traffic through the tunnel interfaces to reach the DRG and finally the VCN hosts.

  1. Follow tasks 1–5 in the preceding section.
  2. Configure static routes:
    1. Go to Network, to Virtual Routers, to default, to Static Routes, and then click Add.
    2. For Route 1, configure the parameters as shown in the next image.

      This image shows the static route settings for route 1.

    3. For Route 2, configure the parameters as shown in the next image.

      This image shows the static route settings for route 2.

  3. (Recommended) Enable ECMP for traffic sent through the two tunnels. The metric for both routes is set to 10. Here are some important notes about enabling ECMP:

    • First check to see if your networking design allows for ECMP.
    • Enabling or disabling ECMP on an existing virtual router causes the system to restart the virtual router. The restart might cause existing sessions to be terminated.
    • This example uses the default virtual router. Use the correct virtual router for your network environment.

    To enable ECMP, go to Network, to Virtual Routers, to default, to Router Settings, to ECMP, and then select the check box for Enable.

    This image shows the ECMP settings.

Here are screenshots that show the final configuration after this task is complete:

This image shows the final configuration on the IPv4 tab after configuring static routes.

This image shows the final configuration after configuring static routes.

Changing the IKE Identifier

If the CPE is behind a NAT device with a private IP address on the exit interface that the tunnel interfaces use as the source, you must specify the public IP address of the NAT device as the local IKE ID. You can do this by setting the Local Identification value in the IKE Gateway configuration:

This image shows where to change the CPE's IKE identifier.


To verify the IPSec tunnel status:

This image shows where to verify the IPSec tunnel status.

Use this command to verify the IKE SA:

show vpn ike-sa

Use this command to verify the IPSec tunnel configuration:

show vpn tunnel name <tunnel_name>

To verify the BGP status, look for Established:

This image shows where to verify the BGP status.

To verify the BGP status from the command line:

show routing protocol bgp peer peer-name <name>

To verify that the routes are installed in the routing table:

show routing route

A Monitoring service is also available from Oracle Cloud Infrastructure to actively and passively monitor your cloud resources. For information about monitoring your VPN Connect, see VPN Connect Metrics.

If you have issues, see VPN Connect Troubleshooting.