Scenario B: Private Subnet with a VPN

This topic explains how to set up Scenario B, which consists of a virtual cloud network (VCN) with a regional private subnet . There are servers in separate availability domains  for redundancy. The VCN has a dynamic routing gateway  (DRG) and IPSec VPN  for connectivity to your on-premises network. The VCN has no direct connection to the internet. Any connection to the internet would need to come indirectly by way of the on-premises network.

The subnet uses the default security list, which has default rules that are designed to make it easy to get started with Oracle Cloud Infrastructure. The rules enable typical required access (for example, inbound SSH connections and any type of outbound connections). Remember that security list rules only allow traffic. Any traffic not explicitly covered by a security list rule is denied.

In this scenario, you add additional rules to the default security list. You could instead create a custom security list for those rules. You would then set up the subnet to use both the default security list and the custom security list.

Tip

Security lists are one way to control traffic in and out of the VCN's resources. You can also use network security groups, which let you apply a set of security rules to a set of resources that all have the same security posture.

The subnet uses the default route table, which starts out with no rules when the VCN is created. In this scenario, the table has only a single rule for the DRG. No route rule is required in order to route traffic within the VCN itself.

See the following figure.

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

Tip

The scenario 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:

  • Public IP address of the customer-premises equipment  (CPE) at your end of the VPN
  • Static routes for your on-premises network (this scenario uses static routing for the VPN tunnels, but you could instead use BGP dynamic routing)

You will provide Oracle this information and in return receive the information your network administrator must have to configure the CPE at your end of the VPN.

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be granted security access in a policy  by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment  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.

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 CPE 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

Task 1: Set up the VCN and subnet
  1. Create the VCN:

    1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
    2. Choose a compartment you have permission to work in (on the left side of the page). The page updates to display only the resources in that compartment. If you're not sure which compartment to use, contact an administrator. For more information, see Access Control.
    3. Click Create Virtual Cloud Network.
    4. Enter the following:

      • Name: A descriptive name for the VCN. It doesn't have to be unique, and it cannot be changed later in the Console (but you can change it with the API). Avoid entering confidential information.
      • Create in Compartment: Leave as is.
      • CIDR Block: One or more non-overlapping CIDR blocks for the VCN. For example: 172.16.0.0/16. You can add or remove CIDR blocks later. See Allowed VCN Size and Address Ranges. For reference, here's a CIDR calculator.
      • Enable IPv6 Address Assignment: This option is available only if the VCN is in the US Government Cloud. For more information, see IPv6 Addresses.
      • Use DNS Hostnames in this VCN: Required for assignment of DNS hostnames to hosts in the VCN, and required if you plan to use the VCN's default DNS feature (called the Internet and VCN Resolver). If the check box is selected, you can specify a DNS label for the VCN, or the Console will generate one for you. The dialog box automatically displays the corresponding DNS Domain Name for the VCN (<VCN DNS label>.oraclevcn.com). For more information, see DNS in Your Virtual Cloud Network.
      • Tags: Leave as is. You can add tags later if you want. For more information, see Resource Tags.
    5. Click Create Virtual Cloud Network.

      The VCN is then created and displayed on the Virtual Cloud Networks page in the compartment you chose.

  2. Create the regional private subnet:

    1. While still viewing the VCN, click Create Subnet.
    2. Enter the following:

      • Name: A friendly name for the subnet (for example, Regional Private Subnet). It doesn't have to be unique, and it cannot be changed later in the Console (but you can change it with the API). Avoid entering confidential information.
      • Regional or Availability Domain-Specific: Select Regional (recommended), which means the subnet spans all availability domains in the region. Later when you launch an instance, you can create it any availability domain in the region. For more information, see Overview of VCNs and Subnets.
      • CIDR Block: A single, contiguous CIDR block within the VCN's CIDR block. For example: 172.16.0.0/24. You cannot change this value later. For reference, here's a CIDR calculator.
      • Enable IPv6 Address Assignment: This option is available only if the VCN is in the US Government Cloud. For more information, see IPv6 Addresses.
      • Route Table: Select the default route table.
      • Private or public subnet: Select Private Subnet, which means instances in the subnet cannot have public IP addresses. For more information, see Access to the Internet.
      • Use DNS Hostnames in this Subnet: This option is available only if you provided a DNS label for the VCN during creation. The option is required for assignment of DNS hostnames to hosts in the subnet, and required if you plan to use the VCN's default DNS feature (called the Internet and VCN Resolver). If the check box is selected, you can specify a DNS label for the subnet, or the Console will generate one for you. The dialog box automatically displays the corresponding DNS Domain Name for the subnet (<subnet_DNS_label>.<VCN_DNS_label>.oraclevcn.com). For more information, see DNS in Your Virtual Cloud Network.
      • DHCP Options: Select the default set of DHCP options.
      • Security Lists: Select the default security list.
      • Tags: Leave as is. You can add tags later if you want. For more information, see Resource Tags.
    3. Click Create Subnet.

      The subnet is then created and displayed on the Subnets page.

  3. Update the default security list to include rules to allow the types of connections that your instances in the VCN will need:

    1. While still on the page displaying your VCN's subnets, click Security Lists, and then click the default security list.
    2. Under Resources, click either Ingress Rules or Egress Rules depending on the type of rule you want to work with. You can add one rule at a time by clicking either Add Ingress Rule or Add Egress Rule.
    3. Add your desired rules. Here are suggested ones to add to the default ones already in the default security list:

      Example: Ingress HTTP access
      • Type: Ingress
      • Stateless: Unselected (this is a stateful rule)
      • Source Type: CIDR
      • Source CIDR: 0.0.0.0/0
      • IP Protocol: TCP
      • Source Port Range: All
      • Destination Port Range: 80
      • Description: An optional description of the rule.
      Example: Ingress HTTPS access
      • Type: Ingress
      • Stateless: Unselected (this is a stateful rule)
      • Source Type: CIDR
      • Source CIDR: 0.0.0.0/0
      • IP Protocol: TCP
      • Source Port Range: All
      • Destination Port Range: 443
      • Description: An optional description of the rule.
      Example: Ingress SQL*Net access for Oracle databases
      • Type: Ingress
      • Stateless: Unselected (this is a stateful rule)
      • Source Type: CIDR
      • Source CIDR: 0.0.0.0/0
      • IP Protocol: TCP
      • Source Port Range: All
      • Destination Port Range: 1521
      • Description: An optional description of the rule.
      Example: Ingress RDP access required for Windows instances
      • Type: Ingress
      • Stateless: Unselected (this is a stateful rule)
      • Source Type: CIDR
      • Source CIDR: 0.0.0.0/0
      • IP Protocol: TCP
      • Source Port Range: All
      • Destination Port Range: 3389
      • Description: An optional description of the rule.
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.

For a production VCN, you typically set up one or more custom security lists for each subnet. You can edit the subnet to use different security lists if you like. If you choose not to use the default security list, do so only after carefully assessing which of its default rules you want to duplicate in your custom security list. For example: the default ICMP rules in the default security list are important for receiving connectivity messages.

Task 2: Create instances in separate availability domains

You can now create one or more instances in the subnet (see Launching an Instance). The scenario's diagram shows instances in two different availability domains. When you create the instance, you choose the AD, which VCN and subnet to use, and several other characteristics.

However, you can't yet communicate with the instances because there's no gateway connecting the VCN to your on-premises network. The next procedure walks you through creating an IPSec VPN connection to enable that communication.

Task 3: Add an IPSec VPN to your VCN
  1. Create a customer-premises equipment (CPE) object:

    1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Customer-Premises Equipment.

    2. Click Create Customer-Premises Equipment.
    3. Enter the following:
      • Create in Compartment: Leave the default value (the compartment you're currently working in).
      • Name: A friendly name for the customer-premises equipment object. It doesn't have to be unique, and it cannot be changed later in the Console (but you can change it with the API). Avoid entering confidential information.
      • IP Address: The public IP address of the CPE at your end of the VPN (see Prerequisites).
    4. Click Create.

    The CPE object will be in the "Provisioning" state for a short period.

  2. Create a dynamic routing gateway (DRG):

    1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Dynamic Routing Gateways.

    2. Click Create Dynamic Routing Gateway.
    3. For Create in Compartment: Leave the default value (the compartment you're currently working in).
    4. Enter a friendly name for the DRG. It doesn't have to be unique, and it cannot be changed later in the Console (but you can change it with the API). Avoid entering confidential information.
    5. Click Create.

    The DRG will be in the "Provisioning" state for a short period. Make sure it is done being provisioned before continuing.

  3. Attach the DRG to your VCN:

    1. Click the DRG that you just created.
    2. Under Resources, click Virtual Cloud Networks.
    3. Click Attach to Virtual Cloud Network.
    4. Select the VCN. Ignore the section for advanced options, which is only for an advanced routing scenario called transit routing, which is not relevant here.
    5. Click Attach.

    The attachment will be in the "Attaching" state for a short period before it's ready.

  4. Update the default route table (which has no rules yet):

    1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
    2. Click your VCN.
    3. Under Resources, click Route Tables, and then click the default route table.
    4. Click Add Route Rule.
    5. Enter the following:

      • Target Type: Dynamic Routing Gateway. The VCN's attached DRG is automatically selected as the target, and you don't have to specify the target yourself.
      • Destination CIDR Block: 0.0.0.0/0 (which means that all non-intra-VCN traffic that is not already covered by other rules in the route table will go to the target specified in this rule).
      • Description: An optional description of the rule.
    6. Click Add Route Rule.

      The VCN's default route table now directs outbound traffic to the DRG and ultimately to your on-premises network.

  5. Create an IPSec Connection:

    1. Open the navigation menu. Under Core Infrastructure, go to Networking and click VPN Connections.

    2. Click Create IPSec Connection.
    3. Enter the following:

      • Create in Compartment: Leave the default value (the compartment you're currently working in).
      • Name: Enter a friendly name for the IPSec connection. It doesn't have to be unique. Avoid entering confidential information.
      • Customer-Premises Equipment Compartment: Leave as is (the VCN's compartment).
      • Customer-Premises Equipment: Select the CPE object you created earlier.
      • Dynamic Routing Gateway Compartment: Leave as is (the VCN's compartment).
      • Dynamic Routing Gateway: Select the DRG that you created earlier.
      • Static Route CIDR: Enter at least one static route CIDR (see Prerequisites). If you need to add another, click Add Static Route. You can enter up to 10 static routes, and you can change the static routes later if you like.
    4. Click Show Advanced Options and optionally provide the following items:
    5. Click Create IPSec Connection.

      The IPSec connection is created and displayed on the page. It will be in the Provisioning state for a short period.

      The displayed tunnel information includes the IP address of the VPN headend and the tunnel's IPSec status (possible values are Up, Down, and Down for Maintenance). At this point, the status is Down. To view the tunnel's shared secret, click the Actions icon (three dots), and then click View Shared Secret.

    6. Copy the Oracle VPN IP address and shared secret for each of the tunnels to an email or other location so you can deliver it to the network engineer who will configure the on-premises router.

      For more information, see CPE Configuration. You can view this tunnel information here in the Console at any time.

You have now created all the components required for the IPSec VPN. But your network administrator must configure the CPE before network traffic can flow between your on-premises network and VCN.

Task 4: Configure your CPE

These instructions are for the network administrator.

  1. Make sure you have the tunnel configuration information that Oracle provided during IPSec VPN setup. See Task 3: Add an IPSec VPN to your VCN.
  2. Configure your CPE according to the information in CPE Configuration.

If there are already instances in the subnet, you can confirm the IPSec connection is up and running by connecting to the instances from your on-premises network.

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 for the VCN if you want the instances to have hostnames (see DNS in Your Virtual Cloud Network).
  2. CreateSubnet: Create one regional private subnet. Include a DNS label for the subnet if you want the instances to have hostnames. 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 public IP address of the CPE 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 that your network administrator needs in order to configure your CPE. If you need that information later, you can get it with GetIPSecConnectionDeviceConfig. For more information about the configuration, see CPE Configuration.
  7. UpdateRouteTable: To enable communication via the VPN, update the default route table to include this route: a route rule with destination = 0.0.0.0/0, and destination target = the DRG you created earlier.
  8. First call GetSecurityList to get the default security list, and then call UpdateSecurityList to add rules for the types of connections that your instances in the VCN will need. Be aware that UpdateSecurityList overwrites the entire set of rules. Here are some suggested rules to add:

    • 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 SQL*Net access to 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. LaunchInstance: Create one or more instances in the subnet. The scenario's diagram shows instances in two different availability domains. When you create the instance, you choose the AD, which VCN and subnet to use, and several other characteristics. For more information, see Creating an Instance.
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.
Important

Although you can create instances in the subnet, you won't be able to communicate with them from your on-premises network until your network administrator configures your CPE (see CPE Configuration). 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 connecting to the instances from your on-premises network.