Oracle Cloud Infrastructure Documentation

Cisco ASA: Policy-Based

This topic provides a policy-based configuration for a Cisco ASA that is running software version 8.5 to 9.7.0.

As a reminder, Oracle provides different configurations based on the ASA software:

  • 9.7.1 or newer: Route-based configuration
  • 8.5 to 9.7.0: Policy-based configuration (this topic)
  • Older than 8.5: Not supported by the Oracle configuration instructions. Consider upgrading to a newer version.

Oracle recommends using a route-based configuration to avoid interoperability issues and to achieve tunnel redundancy with a single Cisco ASA device.

The Cisco ASA does not support route-based configuration for software versions older than 9.7.1. For the best results, if your device allows it, Oracle recommends that you upgrade to a software version that supports route-based configuration.

With policy-based configuration, you can configure only a single tunnel between your Cisco ASA and your dynamic routing gateway (DRG).

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. The IP addresses in this diagram are examples only and not for literal use.

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


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.

Best Practices

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

Specific to Cisco ASA: VPN filters

VPN filters let you further filter traffic either before it enters or after it exits a tunnel. Use VPN filters if you need additional granularity for filtering different traffic types or source/destination flows. For more information, see Cisco's VPN Filter documentation.

VPN filter configuration is not included in the configuration template that appears in the CPE Configuration section. To use VPN filters, add the following configuration items manually.

  • Access control list (ACL): Create an ACL that the VPN filter can use to restrict the traffic permitted through the tunnels. If you have an ACL already used for a VPN filter, do not also use it for an interface access group.

    access-list ${vpnFilterAclName} extended permit ip ${VcnCidrNetwork} ${VcnCidrNetmask} ${onPremCidrNetwork} ${onPremCidrNetmask}
  • Group policy: Apply the VPN filter to your group policy.

    group-policy oracle-vcn-vpn-policy attributes
     vpn-filter value ${vpnFilterAclName}
  • Tunnel group: Apply the group policy to your tunnel group.

    tunnel-group ${oracleHeadend1} general-attributes
     default-group-policy oracle-vcn-vpn-policy

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 An optional virtual router that you can add to your VCN to provide a path for private network traffic between your VCN and on-premises network. 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 NAT Traversal (NAT-T) is disabled for VPN Connect traffic. NAT-T is not supported with Oracle Cloud Infrastructure.

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.

Specific to Cisco ASA: Caveats and Limitations

This section covers important characteristics and limitations that are specific to Cisco ASA.

Tunnel MTU and Path MTU Discovery

You have two options for addressing tunnel MTU and path MTU discovery with Cisco ASA:

Option 1: TCP MSS adjustment

The maximum transmission unit (packet size) through the IPSec tunnel is less than 1500 bytes. You can fragment packets that are too large to fit through the tunnel. Or, you can signal back to the hosts that are communicating through the tunnel that they need to send smaller packets.

You can configure the Cisco ASA to change the maximum segment size (MSS) for any new TCP flows through the tunnel. The ASA looks at any TCP packets where the SYN flag is set and changes the MSS value to the configured value. This configuration might help new TCP flows avoid using path maximum transmission unit discovery (PMTUD).

Use the following command to change the MSS. This command is not part of the sample configuration in the CPE Configuration section of this topic. Apply the TCP MSS adjustment command manually, if needed.

sysopt connection tcpmss 1387

Option 2: Clear/set the Don't Fragment bit

Path MTU discovery requires that all TCP packets have the Don't Fragment (DF) bit set. If the DF bit is set and a packet is too large to go through the tunnel, the ASA drops the packet when it arrives. The ASA sends an ICMP packet back to the sender indicating that the received packet was too large for the tunnel. The ASA offers three options for handling the DF bit. Choose one of the options and apply it to the configuration:

  • Set the DF bit (recommended): Packets have the DF bit set in their IP header. The ASA may still fragment the packet if the original received packet cleared the DF bit.

    crypto ipsec df-bit set-df ${outsideInterface}
  • Clear the DF bit: The DF bit is cleared in the packet's IP header. Allows the packet to be fragmented and sent to the end host in Oracle Cloud Infrastructure for reassembly.

    crypto ipsec df-bit clear-df ${outsideInterface}
  • Ignore (copy) the DF bit: The ASA looks at the original packet's IP header information and copies the DF bit setting.

    crypto ipsec df-bit copy-df ${outsideInterface}

VPN Traffic Might Enter One Tunnel and Exit Another

If VPN traffic enters an interface with the same security level as an interface toward the packet's next hop, you must allow that traffic. By default, the packets between interfaces that have identical security levels on your ASA are dropped.

Add the following command manually if you need to permit traffic between interfaces with the same security levels. This command is not part of the sample configuration in the CPE Configuration section.

same-security-traffic permit inter-interface

General Caveats and Limitations

This section covers general characteristics and limitations of VPN Connect.

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 the 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.

The configuration template provided is for a Cisco ASA running version 8.5 software (or later).


Cisco ASA versions 9.7.1 and newer support route-based configuration, which is the recommended method to avoid interoperability issues.

If you want tunnel redundancy with a single Cisco ASA device, you must use the route-based configuration. With policy-based configuration, you can configure only a single tunnel between your Cisco ASA and your dynamic routing gateway (DRG).

The configuration template refers to these items that you must provide:

  • CPE public IP address: The internet-routable IP address that is assigned to the external interface on the CPE. You or your Oracle administrator provides this value to Oracle when creating the CPE object in the Oracle Console.
  • Inside tunnel interface (required if using BGP): The IP addresses for the CPE and Oracle ends of the inside tunnel interface. You provide these values when creating the IPSec connection in the Oracle Console.
  • BGP ASN (required if using BGP): Your BGP ASN.

In addition, you must:

  • Configure internal routing that routes traffic between the CPE and your local network.
  • Ensure that you permit traffic between your ASA and your Oracle VCN (the following configuration template references this access list with the variable ${outboundAclName}).
  • Identify the internal VPN group policy (the following configuration template references this group policy as oracle-vcn-vpn-policy).
  • Identify the transform set used for your crypto map (the following configuration template references this transform set as oracle-vcn-transform).
  • Identify the crypto map name and sequence number (the following configuration template references the map name as oracle-vpn-map-v1 and sequence number 1).
  • Identify the operation number for IP SLA continuous ping (the following configuration template uses operation number 1).

This following configuration template from Oracle Cloud Infrastructure is a starting point for what you need to apply to your CPE. The syntax for each CPE device configuration may be different and depends on the model and software versions. Be sure to compare your CPE model and version to the appropriate configuration template.

Some of the parameters referenced in the template must be unique on the CPE, and the uniqueness can only be determined by accessing the CPE. Ensure that the parameters are valid on your CPE and do not overwrite any previously configured values. In particular, ensure that the following values are unique:

  • Policy names or numbers
  • Crypto map names and sequence numbers

  • Interface names
  • Access list names or numbers (if applicable)

View the configuration template in full screen for easier reading.

Configuration Template

! Configuration Template
! The configuration consists of a single IPSec tunnel.
! The configuration template involves setting up the following:
! Access Lists
! ISAKMP Policy
! Base VPN Policy
! IPSec Configuration
! IPSec Tunnel Group Configuration
! IP Routing (BGP or Static)
! Optional: Disable NAT for VPN Traffic
! The configuration template has various parameters that you must define before applying the configuration.
! ${OracleInsideTunnelIpAddress1} = Inside tunnel IP address of Oracle-side for the first tunnel. You provide these values when creating the IPSec connection in the Oracle Console.
! ${bgpASN} = Your BGP ASN
! ${cpePublicIpAddress} = The public IP address for the CPE. This is the IP address of your outside interface
! ${outboundAclName} = ACL used to control traffic out of your inside and outside interfaces
! ${oracleHeadend1} = Oracle public IP endpoint obtained from the Oracle Console.
! ${sharedSecret1} = You provide when you set up the IPSec connection in the Oracle Console, or you can use the default Oracle-provided value.
! ${outsideInterface} = The public interface or outside of tunnel interface which is configured with the CPE public IP address.
! ${vcnCidrNetwork} = VCN IP range
! ${vcnCidrNetmask} = Subnet mask for VCN
! ${onPremCidrNetwork} = On-premises IP range
! ${onPremCidrNetmask} = ON-premises subnet mask
! ${cryptoMapAclName} = Name of ACL which will be associated with the IPSec security association.
! ${vcnHostIp} = IP address of a VCN host. Used for IP SLA continuous ping to maintain tunnel UP state.
! Access Lists
! Permit Traffic Between Your ASA and Your Oracle VCN
! Assuming there is an access-list controlling traffic in and out of your Internet facing interface, you will need to permit traffic between your CPE and the Oracle VPN Headend
! WARNING: The new ACL entry you add to permit the traffic between your ASA and VPN headend needs to be above any deny statements you might have in your existing access-list
access-list ${outboundAclName} extended permit ip host ${oracleHeadend1} host ${cpePublicIpAddress}
! Crypto ACL
! Create an ACL named ${cryptoMapAclName} which will later be associated with the IPSec security association using the 'crypto-map' command. This will define which source/destination traffic needs to be encrypted and sent across the VPN tunnel.
! Keep this ACL to a single entry. In a policy based configuration each ACL line will establish a separate encryption domain.
! The single encryption domain used in this configuration sample will have a source/destination of any/VCN CIDR. Refer to the 'Encryption domain for policy-based tunnels' subsection for supported alternatives.
access-list ${cryptoMapAclName} extended permit ip any ${vcnCidrNetwork} ${vcnCidrNetmask}
! ISAKMP Policy
! ISAKMP Phase 1 configuration.
! IKEv1 is enabled on the outside interface.
! IKEv1 policy is created for Phase 1 which specifies to use a Pre-Shared Key, AES256, SHA1, Diffie-Hellman Group 5, and a Phase 1 lifetime of 28800 seconds (8 hours).
! If different parameters are required, modify this template before applying the configuration.
! WARNING: The IKEv1 group policy is created with a priority of 10. Make sure this doesn't conflict with any pre-existing configuration on your ASA.
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 5
 lifetime 28800
! Base VPN Policy
! An internal VPN group policy named 'oracle-vcn-vpn-policy' is created to define some basic VPN tunnel settings
! Idle and session timeouts are disabled to maintain the tunnel UP state and tunnel protocol is set to IKEv1
group-policy oracle-vcn-vpn-policy internal
group-policy oracle-vcn-vpn-policy attributes
 vpn-idle-timeout none
 vpn-session-timeout none
 vpn-tunnel-protocol ikev1
! IPSec Configuration
! Create an IKEv1 transform set named 'oracle-vcn-transform' which defines a combination of IPSec (Phase 2) policy options. Specifically, AES256 for encryption and SHA1 for authentication.
! If different parameters are required, modify this template before applying the configuration.
crypto ipsec ikev1 transform-set oracle-vcn-transform esp-aes-256 esp-sha-hmac
! A crypto map is used to tie together the important traffic that needs encryption (via crypto map ACL) with defined security policies (from the transform set along with other crypto map statements), and the destination of the traffic to a specific crypto peer.
! In this configuration example, a single crypto map is created named 'oracle-vpn-map-v1' This crypto map references the previously created crypto map ACL, the 'oracle-vcn-transform' transform set and further defines PFS Group 5 and the security association lifetime to 3600 seconds (1 hour).
! WARNING: Make sure your crypto map name and sequence numbers do not overlap with existing crypto maps.
! WARNING: DO NOT use the 'originate-only' option with an Oracle IPSec VPN tunnel. It causes the tunnel's traffic to be inconsistently blackholed. The command is only for tunnels between two Cisco devices. Here's an example of the command that you should NOT use for the Oracle IPSec VPN tunnels: crypto map <map name> <sequence number> set connection-type originate-only
crypto map oracle-vpn-map-v1 1 match address ${cryptoMapAclName}
crypto map oracle-vpn-map-v1 1 set pfs group5
crypto map oracle-vpn-map-v1 1 set peer ${oracleHeadend1}
crypto map oracle-vpn-map-v1 1 set ikev1 transform-set oracle-vcn-transform
crypto map oracle-vpn-map-v1 1 set security-association lifetime seconds 3600
! WARNING: The below command will apply the 'oracle-vpn-map-v1' crypto map to the outside interface. The Cisco ASA supports a single crypto map per interface. Make sure no other crypto map is applied to the outside interface before using this command.
crypto map oracle-vpn-map-v1 interface outside
! IPSec Tunnel Group Configuration
! This configuration matches the group policy 'oracle-vcn-vpn-policy' with an Oracle VPN headend endpoint.
! The pre-shared key for each Oracle VPN headend is defined in the corresponding tunnel group.
tunnel-group ${oracleHeadend1} type ipsec-l2l
tunnel-group ${oracleHeadend1} general-attributes
 default-group-policy oracle-vcn-vpn-policy
tunnel-group ${oracleHeadend1} ipsec-attributes
 ikev1 pre-shared-key ${sharedSecret1}
! IP SLA Configuration
! The Cisco ASA doesn't establish a tunnel if there's no interesting traffic trying to pass through the tunnel.
! You must configure IP SLA on your device for a continuous ping so that the tunnel remains up at all times.
! You must allow ICMP on the outside interface.
! Make sure that the SLA monitor number used is unique.
sla monitor 1
 type echo protocol ipIcmpEcho ${vcnHostIp} interface outside
 frequency 5
sla monitor schedule 1 life forever start-time now
icmp permit any ${outsideInterface}
! IP Routing
! Pick either dynamic (BGP) or static routing. Uncomment the corresponding commands prior to applying configuration.
! Border Gateway Protocol (BGP) Configuration
! Uncomment below lines if you want to use BGP.
! router bgp ${bgpASN}
!  address-family ipv4 unicast
!   neighbor ${OracleInsideTunnelIpAddress1} remote-as 31898
!   neighbor ${OracleInsideTunnelIpAddress1} activate
!   network ${onPremCidrNetwork} mask ${onPremCidrNetmask}
!   no auto-summary
!   no synchronization
!  exit-address-family
! Static Route Configuration
! Uncomment below line if you want to use static routing.
! route outside ${VcnCidrNetwork} ${VcnCidrNetmask} ${OracleInsideTunnelIpAddress1}
! Disable NAT for VPN Traffic
! If you are using NAT for traffic between your inside and outside interfaces, you might need to disable NAT for traffic between your on-premises network and the Oracle VCN.
! Two objects are created for this NAT exemption. 'obj-OnPrem' represents the on-premises network as a default route, and 'obj-oracle-vcn-1' represents the VCN CIDR block used in Oracle Cloud Infrastructure.
! If different address ranges are required, modify this template before applying the configuration.
! object network obj-onprem
!  subnet
! object network obj-oracle-vcn-1
!  subnet ${vcnCidrNetwork} ${vcnCidrNetmask}
! nat (inside,outside) source static obj-onprem obj-onprem destination static obj-oracle-vcn-1 obj-oracle-vcn-1


The following ASA commands are included for basic troubleshooting. For more exhaustive information, refer to Cisco's IPSec Troubleshooting document.

Use the following command to verify that ISAKMP security associations are being built between the two peers.

show crypto isakmp sa

Use the following command to verify the status of all your BGP connections.

show bgp summary

Use the following command to verify the ASA's route table.

show 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.