Oracle Cloud Infrastructure Documentation

Scenario B: Private Subnets with a VPN

This topic explains how to set up Scenario B, which consists of a virtual cloud network (VCN) with two private subnets in different availability domains (to illustrate redundancy) and an IPSec VPN. See the following figure. For more information, see Typical Networking Scenarios.

This image shows Scenario B: a VCN with private subnets and a VPN IPSec connection.

Tip

The scenarios uses an IPSec VPN for connectivity; however, you could instead use Oracle Cloud Infrastructure FastConnect.

Prerequisites

To set up the VPN in this scenario, you need to get the following information from a network administrator:

  • IP address of the on-premises router at your end of the VPN
  • Static routes for your on-premises network

You will provide Oracle this information and in return receive the information your network administrator needs in order to configure the on-premises router at your end of the VPN.

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be given the required type of access in a An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. you should work in.

If you're a member of the Administrators group, you already have the required access to execute Scenario B. Otherwise, you need access to Networking, and you need the ability to launch instances. See IAM Policies for Networking.

Setting Up Scenario B

Setup is easy in the Console. Alternatively, you can use the Oracle Cloud Infrastructure API, which lets you execute the individual operations yourself.

Warning

Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

Important

Most of this process involves working with the Console or API (whichever you choose) for a short period to set up the desired Networking components. But there's also a critical step that requires a network administrator in your organization to take information you receive from setting up the components and use it to configure the on-premises router at your end of the VPN. Therefore you can't complete this process in one short session. You'll need to break for an unknown period of time while the network administrator completes the configuration and then return afterward to confirm communication with your instances over the VPN.

Using the Console

To create the cloud network and subnets
To add a VPN to your cloud network
To configure your on-premises router

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use the following operations:

  1. CreateVcn: Make sure to include a DNS label if you want the VCN to use the VCN Resolver (see DNS in Your Virtual Cloud Network).
  2. CreateSubnet: Call it twice, once for each subnet in the scenario. Set each subnet to be private (that is, prohibit public IP addresses on the VNICs in the subnet). Include a DNS label for each subnet if you want the VCN Resolver to resolve hostnames for VNICs in the subnet. Use the default route table, default security list, and default set of DHCP options.
  3. CreateDrg: This creates a new dynamic routing gateway (DRG)
  4. CreateDrgAttachment: This attaches the DRG to the VCN.
  5. CreateCpe: Here you'll provide the IP address of the on-premises router at your end of the VPN (see Prerequisites).
  6. CreateIPSecConnection: Here you'll provide the static routes for your on-premises network (see Prerequisites). In return, you'll receive the configuration information your network administrator needs in order to configure your on-premises router. If you need that information later, you can get it with GetIPSecConnectionDeviceConfig. For more information about the configuration, see Configuring Your CPE.
  7. UpdateRouteTable: To enable communication via the VPN, update the default route table to include this route: 0.0.0.0/0 > DRG you created earlier.
  8. First call GetSecurityList to get the default security list, and then call UpdateSecurityList to add these additional rules to that list (be aware that UpdateSecurityList overwrites the entire set of rules):

    • Stateful ingress: Source type=CIDR, source CIDR=0.0.0.0/0, protocol=TCP, source port = all, destination port=80 (for HTTP).
    • Stateful ingress: Source type=CIDR, source CIDR=0.0.0.0/0, protocol=TCP, source port = all, destination port=443 (for HTTPS).
    • Stateful ingress: Source type=CIDR, source CIDR=0.0.0.0/0, protocol=TCP, source port = all, destination port=1521 (for Oracle databases).
    • Stateful ingress: Source type=CIDR, source CIDR=0.0.0.0/0, protocol=TCP, source port=all, destination port=3389 (for RDP; required only if using Windows instances).
  9. Tip

    For additional security, you could modify all the stateful ingress rules to allow traffic only from within your VCN and your on-premises network. You would need to create separate rules for each, one with the VCN's CIDR as the source, and one with the on-premises network's CIDR as the source.

  10. LaunchInstance: Launch at least one instance in each subnet. For more information, see Launching an Instance.

Important

Although you can launch instances into your subnets, you won't be able to communicate with them from your on-premises network until your network administrator configures your on-premises router (see Configuring Your CPE). After that, your IPSec connection should be up and running. You can confirm its status by using GetIPSecConnectionDeviceStatus. You can also confirm the IPSec connection is up by pinging the instances from your on-premises network.