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 . Other servers are in separate availability domains  for redundancy. The VCN has a dynamic routing gateway  (DRG) and Site-to-Site 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.

This scenario can use a legacy or upgraded DRG.

In this scenario, you add 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

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 to route traffic within the VCN itself. The subnet uses the default security list. See the following figure.

This image shows Scenario B: a VCN with a regional private subnet and a VPN IPSec connection.
Callout 1: Regional private subnet route table
Destination CIDR Route target
0.0.0.0/0 DRG
Tip

The scenario uses Site-to-Site 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 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, an administrator must be a member of a group granted security access in a policy  by a tenancy 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 the tenancy administrator what type of access you have and which compartment  your access works in.

If you're a member of the Administrators group, you already have the required access to implement 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 perform 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 necessary 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. Plan to take a break while the network administrator completes the configuration and return afterward to confirm communication with your instances over the VPN.

Using the Console

Using the API

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.

Use the following operations:

  1. CreateVcn: Always 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: Creates a dynamic routing gateway (DRG)
  4. CreateDrgAttachment: Attaches the DRG to the VCN.
  5. CreateCpe: Provide the public IP address of the CPE at your end of the VPN (see Prerequisites).
  6. CreateIPSecConnection: Provide the static routes for your on-premises network (see Prerequisites). The command returns the configuration information that your network administrator needs 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 through 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 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 more security, you could modify all the stateful ingress rules to allow traffic only from within your VCN and your on-premises network. 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 can't communicate with them from your on-premises network until your network administrator configures your CPE (see CPE Configuration). After that, Site-to-Site VPN should be up and running. You can confirm its status by using GetIPSecConnectionDeviceStatus. You can also confirm Site-to-Site VPN is up by connecting to the instances from your on-premises network.