Oracle Cloud Infrastructure Documentation
Try Free Tier

Working with Site-to-Site VPN

This topic contains some details about working with Site-to-Site VPN and the related components. Also see these topics:

Migrating to Policy-Based VPN

Oracle Cloud Infrastructure's Site-to-Site VPN v2 service fully supports policy-based IPSec VPNs with up to 50 encryption domains per tunnel.

To prevent potential traffic disruptions, if you have been migrated from the Site-to-Site VPN v1 service to Site-to-Site VPN v2, and have configured a CPE with several encryption domains, change the tunnel configurations on the OCI side of the connection to match the CPE configuration. This article explains why this modification is so important, and the required steps to configure OCI to use policy-based IPSec VPNs.

Why migrate to the Policy-Based VPN feature

The Site-to-Site VPN v1 service is always configured as a route-based VPN and uses an any/any encryption domain for both BGP and static routing types. For policy-based VPN interoperability, Site-to-Site VPN v1 supports a CPE configured for policy-based VPNs if the CPE acts as the initiator, and only a single encryption domain is sent to OCI. Configuring multiple encryption domains in this scenario results in instability of the tunnel where you might observe the tunnel flapping or that the traffic traversing the tunnel has unsteady reachability.

The Site-to-Site VPN v2 service uses a policy-based routing type option in addition to BGP and static routing types. Site-to-Site VPN v2's BGP and static routing types remain route-based and support a single any/any encryption domain. These options work with a single encryption domain policy-based CPE configuration, however this isn't recommended and sending more than one encryption domain results in tunnel instability.

The policy-based routing type available for Site-to-Site VPN v2 is a fully featured policy-based VPN that lets you configure the OCI side to fully match a CPE's policy-based configuration and accept all the individual security associations (SAs) required for a stable IPSec VPN tunnel.

For more information on encryption domains and the different IPSec VPN tunnel types, see Supported Encryption Domain or Proxy ID.

After the tunnels have been migrated from Site-to-Site VPN v1 to v2, they continue to use the same routing type (BGP or static) as configured before migration. This section details the step-by-step process to change existing route-based tunnels to use policy-based routing.

  1. Sign-in to the OCI Console.
  2. Open the navigation menu  and select Networking. Under Customer connectivity, select Site-to-Site VPN.
  3. Select the IPSec connection whose tunnels need to be changed to use policy-based routing.
  4. The tunnels are listed in the details for the IPSec connection, and the routing type for each tunnel is shown. The routing type is listed as either BGP dynamic routing or static routing. Select the tunnel name to view its details.
  5. Select Edit to change the settings of the tunnel you're viewing.
  6. Under Routing type check the box for policy based routing. This presents an extra configuration option for Associations.
  7. Under Associations configure all relevant encryption domains. Each entry under On-premises CIDR blocks generates an encryption domain with all possible entries configured under Oracle Cloud CIDR blocks.

    For more information see Encryption domains for policy-based tunnels.

    1. For On-premises CIDR blocks add all on-premises CIDR blocks that require connectivity to OCI over the IPSec tunnel.
    2. For Oracle Cloud CIDR blocks add all OCI CIDR blocks that must be reachable from the on-premises network.
  8. The values for IPv4 inside tunnel interface - CPE and IPv4 inside tunnel interface - Oracle can be retained as you changed the tunnel's routing type. No changes are required for these values.
  9. Select Save Changes.
  10. Navigate back to the parent IPSec connection and repeat the process for the other IPSec tunnel.

Viewing Tunnel Status and Configuration

When you successfully create the IPSec connection, Oracle produces important configuration information for each of the resulting IPSec tunnels. For an example, see task 2h in the overall setup process. You can view that information and the status of the tunnels at any time. This includes the BGP status if the tunnel is configured to use BGP dynamic routing.

Using the CPE Configuration Helper

After you set up Site-to-Site VPN, a network engineer must configure the customer-premises equipment (CPE) at the on-premises end of the connection. The configuration includes details about the Virtual Cloud Network (VCN) and the IPSec tunnels in the Site-to-Site VPN. The CPE Configuration Helper generates the information for the network engineer. For more information, see Using the CPE Configuration Helper.

Changing the Static Routes

You can change the static routes for an existing IPSec connection. You can provide up to 10 static routes.

Remember that an IPSec connection can use either static routing or BGP dynamic routing. You associate the static routes with the overall IPSec connection and not the individual tunnels. If an IPSec connection has static routes associated with it, Oracle uses them for routing a tunnel's traffic only if the tunnel itself is configured to use static routing. If it's configured to use BGP dynamic routing, the IPSec connection's static routes are ignored.

Important

The IPSec connection goes down while it's reprovisioned with the static route changes.

Changing the CPE IKE Identifier That Oracle Uses

If the CPE is behind a NAT device, you might need to give Oracle the CPE IKE identifier. You can either specify it when you create the IPSec connection, or later edit the IPSec connection and change the value. Oracle expects the value to be an IP address or fully qualified domain name (FQDN). When you specify the value, you also specify which type it is.

Important

The IPSec connection goes down while it's reprovisioned to use the CPE IKE identifier.

Using IKEv2

Oracle supports Internet Key Exchange (IKE) version 1 and version 2 (IKEv2).

To use IKEv2 with a CPE that supports it, you must:

  • Configure each IPSec tunnel to use IKEv2 in the Oracle Console. See the following procedures.
  • Configure the CPE to use IKEv2 encryption parameters that the CPE supports. For a list of parameters that Oracle supports, see Supported IPSec Parameters.

Changing the Shared Secret That an IPSec Tunnel Uses

When you set up Site-to-Site VPN, by default Oracle provides each tunnel's shared secret (also called the pre-shared key). You might have a particular shared secret that you want to use instead. You can specify each tunnel's shared secret when you create the IPSec connection, or you can edit the tunnels and provide each new shared secret then. For the shared secret, only numbers, letters, and spaces are allowed. We recommend using a different shared secret for each tunnel.

Important

When you change a tunnel's shared secret, both the overall IPSec connection and the tunnel go into the Provisioning state while the tunnel is reprovisioned with the new shared secret. The other tunnel in the IPSec connection remains in the Available state. However, while the first tunnel is being reprovisioned, you can't change the second tunnel's configuration.

Changing from Static Routing to BGP Dynamic Routing

To change an existing Site-to-Site VPN from using static routing to using BGP dynamic routing, follow the process in this section.

Caution

When you change a tunnel's routing type, the tunnel's IPSec status doesn't change during reprovisioning. However, routing through the tunnel is affected. Traffic is temporarily disrupted until a network engineer configures the CPE device in accordance with the routing type change. If an existing Site-to-Site VPN is configured to only use a single tunnel, this process disrupts the connection to Oracle. If a Site-to-Site VPN instead uses several tunnels, we recommend reconfiguring one tunnel at a time to avoid disrupting the connection to Oracle.

Monitoring Site-to-Site VPN

You can monitor the health, capacity, and performance of Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications. For more information, see Monitoring and Notifications.

For information about monitoring a connection, see Site-to-Site VPN Metrics.

Viewing Site-to-Site VPN Log Messages

You can view the log messages generated for various operational aspects of Site-to-Site VPN such as the negotations that occur in bringing an IPSec tunnel UP. Enabling and accessing the Site-to-Site VPN log messages can be done by using Site-to-Site VPN or the Logging Service.

  • For an overview of the Logging service in general, see Logging Overview.
  • For details on enabling and accessing the Site-to-Site VPN log messages by using the Logging service, see Service Logs.

  • For details on the Site-to-Site VPN log message schema, see Details for Site-to-Site VPN.

Disabling or Terminating Site-to-Site VPN

To disable Site-to-Site VPN between an on-premises network and VCN, you can detach the DRG from the VCN instead of deleting the IPSec connection. If you're also using the DRG with FastConnect, detaching the DRG would also interrupt the flow of traffic over FastConnect.

You can delete the IPSec connection. However, if you later want to reestablish it, a network engineer must configure the CPE device again with a new set of tunnel configuration information from Oracle.

To permanently delete Site-to-Site VPN, you must first terminate the IPSec connection. Then you can delete the CPE object. If you're not using the DRG for another connection to an on-premises network, you can detach it from the VCN and then delete it.

Managing Tags for an IPSec Connection or CPE Object

Apply tags to resources to help organize them according to business needs. Apply tags at the time you create a resource, or update the resource later with the wanted tags. For general information about applying tags, see Resource Tags.

Moving an IPSec Connection or CPE Object to a Different Compartment

You can move resources from one compartment to another. After you move the resource to the new compartment, inherent policies apply immediately and affect access to the resource through the Console. Moving the CPE object to a different compartment doesn't affect the connection between an on-premises data center and Oracle Cloud Infrastructure. For more information, see Working with Compartments.

Maintaining IPSec Tunnels

To ensure the security, stability, and performance of our system, Oracle regularly updates software across the OCI platform. These updates include critical fixes such as vulnerability patches, new features, and bug fixes, which improves the overall functionality and reliability. During the update process, an IPSec tunnel is moved from one VPN headend to another headend, which leads to the IPSec connection getting reset when only one tunnel is used. Only one IPSec tunnel in an IPSec connection is moved. While we can't prevent this brief interruption to the tunnel, we have optimized the update mechanism to minimize the downtime. When the Customer Premise Equipment (CPE) continuously tries to reestablish the connection, normal IPSec tunnel downtime is under a minute. This design lets Oracle maintain a balance between keeping the system secure and reliable while minimizing the disruption to connectivity. Sometimes restoring the IPSec tunnel can take up to 10 minutes:

  • When the tunnel is set as a responder only on the OCI side and the CPE isn't trying to bring the tunnel up immediately
  • When the CPE fails to respond to the IKE negotiation started by the OCI side

While the IPSec tunnel flap during software updates is unavoidable, OCI provides redundant tunnels. These redundant tunnels are designed to maintain continuous traffic flow, even during the brief period when one tunnel experiences downtime. If redundancy has been set up correctly, all traffic routed through the primary tunnel seamlessly switches to the redundant tunnel during a tunnel flap. This failover mechanism ensures that services remain uninterrupted, and the traffic flow is preserved without significant delays. OCI ensures that the redundant tunnels land on two distinct VPN headends. During our software updates only one tunnel is impacted at a time.

We recommend and expect that you test redundancy by taking down the primary VPN tunnel, both during the initial setup and on a regular cadence thereafter. Confirm that VCN instances remain reachable while the primary tunnel is offline, and the traffic is shifting to the redundant tunnel. The VPN Redundancy section in this Redundancy Guide provides more insight into setting up the redundancy for VPN tunnels in different use cases.

You can use the following steps to temporarily disable a tunnel yourself to test redundancy failover from a primary IPSec tunnel to a secondary IPSec tunnel:

  1. Open the navigation menu  and select Networking. Under Customer connectivity, select Site-to-Site VPN.

    A list of the IPSec connections in the compartment that you're viewing is displayed. If you don't see the policy you're looking for, verify that you're viewing the correct compartment. To view policies attached to a different compartment, under List scope, select that compartment from the list.

  2. Select the name of the IPSec connection you're interested in.
    Each tunnel's details are displayed, including the IPSec status, the BGP status (if the tunnel uses BGP dynamic routing), and the Oracle VPN IP address (the VPN headend).
  3. Select the name of the primary (or secondary) IPSec tunnel.
  4. To temporarily disable a tunnel:
    1. In the displayed Tunnel information tab, next to the Shared Secret field, select Edit.
    2. Cut the text in the shared secret field, and replace it with a few random letters or numbers. This causes the BGP session to go down and traffic can failover to the other tunnel. This field can't be empty.
      Paste the original string in the shared secret field into a text file. You need this to reestablish the BGP session after confirming redundancy is working as expected.
    3. Select Save changes.
    4. Confirm that traffic is still flowing on the secondary IPSec tunnel in the connection.
  5. To restore a temporarily disabled tunnel:
    1. In the displayed Tunnel information tab, next to the Shared Secret field, select Edit.
    2. Paste in the original text in the shared secret field.
    3. Select Save changes.
    4. Wait for the BGP session to reestablish.

Using the API for Site-to-Site VPN

These are the Networking service API operations for managing Site-to-Site VPN components.

For information about using the API and signing requests, see REST API documentation and Security Credentials. For information about SDKs, see SDKs and the CLI.

To manage your VCN and subnets, use these operations:

To manage your DRG, use these operations:

To manage routing for your VCN, use these operations:

To manage security lists for your VCN, use these operations:

To manage CPEs, use these operations:

To manage IPSec connections, use these operations:

Was this article helpful?