Oracle Cloud Infrastructure Documentation

Cisco ASA: Policy-Based Without VPN Filters

Important

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 route-based configuration. With policy-based configuration, you can configure only a single tunnel between your Cisco ASA and your dynamic routing gateway (DRG), even though Oracle provides configuration information for two tunnels.

Supported Encryption Domain or Proxy ID

The values for the encryption domain (also known as a proxy ID, security parameter index (SPI), or traffic selector) depend on whether your CPE supports route-based tunnels or policy-based tunnels. For more information about the correct encryption domain values to use, see Supported Encryption Domain or Proxy ID.

Parameters from API or Console

Get the following parameters from the Oracle Cloud Infrastructure Console or API.

${ipAddress#}

  • Oracle VPN headend IPSec tunnel endpoints. There is one value for each tunnel.
  • Example value: 129.146.12.52

${sharedSecret#}

  • The IPSec IKE pre-shared-key. There is one value for each tunnel.
  • Example value: EXAMPLEDPfAMkD7nTH3SWr6OFabdT6exXn6enSlsKbE

${cpePublicIpAddress}

  • The public IP address for the CPE (previously made available to Oracle via the Console). This is the IP address of your outside interface.
  • Example Value: 1.2.3.4

Additional Configuration Parameters

The Cisco ASA config requires the following additional variables:

${vcnID}

  • A UUID string used to uniquely name some access-lists and object-groups (can also use any other string that does not create a name that conflicts with an existing object-group or access-list).
  • Example: oracle-vcn-1

${VcnCidrBlock}

  • When creating the VCN, your company selected this CIDR to represent the IP aggregate network for all VCN hosts.
  • Example Value: 10.0.0.0/20

${VcnCidrNetwork} and ${VcnCidrNetmask}

  • These are the base address and netmask for the ${VcnCidrBlock}
  • For more information, see: Wikipedia reference for finding CidrNetmask
  • Values based on the example ${VcnCidrBlock} shown above:
    • ${VcnCidrNetwork}: 10.0.0.0
    • ${VcnCidrNetmask}: 255.255.0.0

${custCIDR} and ${custMask}

  • To disable NAT between your VCN and your on-premises network, you must define the source IP addresses for packets going through your CPE into the IPSec tunnels.
  • Example values:
    • ${custCIDR}: 0.0.0.0
    • ${custMask}: 0.0.0.0

Parameters Discovered from CPE Configuration

The following parameters are based on your current CPE Configuration.

Sample Router Config:

interface Vlan100
nameif outside
ip address 192.0.2.1 255.255.255.0
!
interface Vlan101
nameif inside
access-group outbound-acl out interface Vlan101
access-group inbound-acl in interface Vlan100

${insideInterface} and ${outsideInterface}

  • These are the interfaces that face the inside and outside of your CPE.
  • The outside interface should be able to ping the Oracle VPN headend IPs.
  • The inside interface is the one facing your customer premise infrastructure.
  • Values based on Sample Router Config above:
    • ${outsideInterface}: Vlan100
    • ${insideInterface}: Vlan101

${insideInterfaceName} and ${outsideInterfaceName}

  • These are the "nameif" values for the inside and outside interfaces.
  • Values based on Sample Router Config above:
    • ${insideInterfaceName}: inside
    • ${outsideInterfaceName}: outside

${inboundAclName} and ${outboundAclName}

  • You likely also have access-lists configured to control traffic in and out of your inside and outside interfaces.
  • Values based on Sample Router Config above:
    • ${inboundAclName}: inbound-acl
    • ${outboundAclName}: outbound-acl

Config Template Parameter Summary

Each region has multiple Oracle IPSec headends. The template below will allow setting up multiple tunnels on your CPE, each to a corresponding headend. In the table below, "User" is you/your company.

Parameter Source Example Value
${ipAddress1} Console/API 129.146.12.52
${sharedSecret1} Console/API (long string)
${ipAddress2} Console/API 129.146.13.52
${sharedSecret2} Console/API (long string)
${cpePublicIpAddress} User 1.2.3.4
${vcnID} Console/API/User 1
${VcnCidrBlock} User 10.0.0.0/16
${VcnCidrNetwork} User 10.0.0.0
${VcnCidrNetmask} User 255.255.0.0
${VcnHostIp} User IP address of a host inside your VCN. Preferably this host can reply to ICMP Echo requests. Example: 10.0.2.7
${custCIDR} User 0.0.0.0
${custMask} User 0.0.0.0
${insideInterface} User CPE Vlan101
${outsideInterface} User CPE Vlan100
${insideInterfaceName} User CPE inside
${outsideInterfaceName} User CPE outside
${inboundAclName} User CPE inbound-acl
${outboundAclName} User CPE outbound-acl
${cryptoMapAclName} User CPE orcl-acl

Important

The following ISAKMP and IPSec policy parameter values are applicable to VPN Connect in the commercial cloud. For the Government Cloud, you must use the values listed in Required VPN Connect Parameters for the Government Cloud.

Commercial Cloud: ISAKMP Policy Options

Commercial Cloud: IPSec Policy Options

CPE Configuration

Network Object Definition

The ASA uses configuration objects to identify IP networks that are used in multiple locations.

Define Object that Represents Your Oracle VCN

This object group is used by the IPSec policies to understand what IP addresses belong to your Oracle VCN, so that they can be encrypted and sent inside the correct IPSec tunnel.

object network oracle-vcn-${vcnID}
subnet ${VcnCidrNetwork} ${VcnCidrNetmask}

Define Object that Represents Your Customer Premise Network

This object may already be present on your ASA. A common name would match the interface name of your "inside" interface. You might have multiple "subnet" entries in this object-group. One for each aggregate subnet you want to allow this IPSec tunnel to be used for traffic to and from your Oracle VCN.

object network ${insideInterfaceName}
subnet ${custCIDR} ${custMask}

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.

nat (${insideInterfaceName},${outsideInterfaceName}) source static ${insideInterfaceName} ${insideInterfaceName} destination static oracle-vcn-${vcnID} oracle-vcn-${vcnID}

Permit Traffic Between Your CPE 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 CPE 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 ${ipAddress1} host ${cpePublicIpAddress}
access-list ${outboundAclName} extended permit ip host ${ipAddress2} host ${cpePublicIpAddress}

NOTE: You can be more restrictive in your ACL if you wish by only permitting the following:

  • udp port 500 : isakmp
  • esp : ipsec encapsulated secure payload

Crypto Map ACL Configuration

The following access list "orcl-acl" will be associated with the IPSec security association using the "crypto-map" command.

access-list ${cryptoMapAclName} extended permit ip any ${VcnCidrNetwork} ${VcnCidrNetmask} 

Important

You must initiate the tunnel. If the Oracle IPSec gateway initiates the tunnel, it only supports sending the crypto map equivalent of "ip any any". As the responder, it accepts only a single entry in the crypto map: ip any ${VcnCidrNetwork} ${VcnCidrNetmask} as shown in the preceding command.

ISAKMP Policy Configuration

See the ASA Command Reference.

crypto ikev1 enable ${outsideInterfaceName}
crypto ikev1 policy 1
authentication pre-share
encryption aes-256
hash sha
group 5
lifetime 28800

Base VPN Policy Configuration

This configuration sets the base values for the IPSec tunnels.

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

See the relevant Cisco documentation:

IPSec Configuration

See the relevant Cisco reference documentation.

Warning

Make sure your crypto map sequence numbers do not overlap with existing crypto maps.

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 ipsec ikev1 transform-set oracle-vcn-transform esp-aes-256 esp-sha-hmac
crypto map oracle-${ipAddress1}-map-v1 1 match address ${cryptoMapAclName}
crypto map oracle-${ipAddress1}-map-v1 1 set pfs group5
crypto map oracle-${ipAddress1}-map-v1 1 set peer ${ipAddress1} crypto map oracle-${ipAddress1}-map-v1 1 set ikev1 transform-set oracle-vcn-transform crypto map oracle-${ipAddress1}-map-v1 1 set security-association lifetime seconds 3600 crypto map oracle-${ipAddress1}-map-v1 interface outside crypto map oracle-${ipAddress2}-map-v1 2 match address ${cryptoMapAclName} crypto map oracle-${ipAddress2}-map-v1 2 set pfs group5
crypto map oracle-${ipAddress2}-map-v1 2 set peer ${ipAddress2} crypto map oracle-${ipAddress2}-map-v1 2 set ikev1 transform-set oracle-vcn-transform crypto map oracle-${ipAddress2}-map-v1 2 set security-association lifetime seconds 3600 crypto map oracle-${ipAddress2}-map-v1 interface outside

Per Tunnel IPSec Configuration

This configuration matches the group policy with an Oracle VPN headend endpoint.

tunnel-group ${ipAddress1} type ipsec-l2l
tunnel-group ${ipAddress1} general-attributes
default-group-policy oracle-vcn-vpn-policy
tunnel-group ${ipAddress1} ipsec-attributes
ikev1 pre-shared-key ${sharedSecret1}

tunnel-group ${ipAddress2} type ipsec-l2l
tunnel-group ${ipAddress2} general-attributes
default-group-policy oracle-vcn-vpn-policy
tunnel-group ${ipAddress2} ipsec-attributes
ikev1 pre-shared-key ${sharedSecret2}		

SLA Monitoring Configuration

The Cisco ASA device doesn't establish a tunnel if there's no interesting traffic trying to pass through the tunnel. You must configure SLA monitoring on your device so that the tunnel remains up at all times. You must allow ICMP on the outside interface. Make sure that the SLA monitor number 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}		

Optional Config Where VPN Traffic Might Enter One Tunnel and Exit Another

If the VPN traffic enters an interface with the same security level as an interface towards the packets next-hop, you will need to allow that traffic. By default, the packets between interfaces with identical security levels on your ASA will be dropped.

See the relevant Cisco reference documentation.

same-security-traffic permit inter-interface

Dealing with Tunnel MTU and Path MTU Discovery

Option 1 - TCP MSS Adjust

Because the maximum transmission unit (packet size) through the IPSec tunnel is less than 1500 bytes, we need to either fragment packets that are too big to fit through the tunnel or we need to signal back to the hosts 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 will look at any TCP packets where the SYN flag is set and change the MSS value to the configured value. This might help new TCP flows avoid having to use path maximum transmission unit discovery (pmtud).

sysopt connection tcpmss 1387 

References:

Option 2 - Clear/Set Don't Fragment Bit

Path MTU Discovery requires that all TCP packets have the Don't Fragment (DF) bit set. When the packet arrives on the ASA, if it is too big to go through the tunnel and the DF bit is set, the ASA will drop the packet and send an ICMP packet back to the sender indicating that the packet was too big to fit through the tunnel. There are three options on the ASA for how to handle the DF bit (pick one of the options):

  • Set the DF bit: If the DF bit is not already set and the packet is too big, will set the DF bit, causing the ASA to drop the the packet and send an ICMP error message back to the sender. (Recommended)

    crypto ipsec df-bit set-df ${outsideInterfaceName}
  • Clear the DF bit: Will allow the ASA to fragment the packet and send it to the end host in Oracle Cloud Infrastructure to reassemble the packet.

    crypto ipsec df-bit clear-df ${outsideInterfaceName}
  • Ignore (copy) the DF bit: If the packet is too big, and the DF bit is set, will drop the packet and send error message to sender, if the DF bit is not set, will fragment the packet and send to Oracle Cloud Infrastructure.

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

References: