Scenario C: Public and Private Subnets with a VPN

This topic explains how to set up Scenario C, which is a simple example of a multi-tier setup. It consists of a Virtual Cloud Network (VCN) with a regional public subnet  to hold public servers (such as web servers), and a regional private subnet  to hold private servers (such as database servers). 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. Instances in the public subnet have direct access to the internet by way of an internet gateway . Instances in the private subnet can initiate internet connections by way of a NAT gateway  (for example, to get software updates), but cannot receive inbound connections from the internet through that gateway.

Each 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.

Tip

Security lists are one way to control traffic in and out of the VCN's resources. You can also use network security groups

This scenario can use a legacy or upgraded DRG.

Each subnet also has its own custom security list and custom route table with rules specific to the needs of the subnet's instances. In this scenario, the VCN's default route table (which is always empty to start with) is not used.

See the following figure.

This image shows Scenario C: a VCN with both a public and private subnet, an internet gateway, NAT gateway, and a VPN IPSec connection.
Callout 1: Regional private subnet route table
Destination CIDR Route target
0.0.0.0/0 NAT Gateway
10.0.0.0/16 DRG
Callout 2: Regional public subnet route table
Destination CIDR Route target
0.0.0.0/0 Internet Gateway
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 needs to configure the on-premises router 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 C. Otherwise, you need access to Networking, and you need the ability to launch instances. See IAM Policies for Networking.

Setting Up Scenario C

Setup is easy in the Console. Alternatively, you can use the Oracle Cloud Infrastructure API, which lets you implement 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 required Networking components. There's also a critical step that requires a network administrator in your organization to take information you receive while 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. Take a break while the network administrator completes the configuration and then 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:

  • CreateVcn: Always include a DNS label if you want the VCN to use the VCN Resolver (see DNS in Your Virtual Cloud Network).
  • CreateInternetGateway
  • CreateNatGateway
  • CreateRouteTable: Call it to create the Public Subnet Route Table. To enable communication by way of the internet gateway, add a route rule with destination = 0.0.0.0/0, and destination target = the internet gateway you created earlier.
  • CreateRouteTable: Call it again to create the Private Subnet Route Table. To enable communication by way of the NAT gateway, add a route rule with destination = 0.0.0.0/0, and destination target = the NAT gateway you created earlier.
  • First call GetSecurityList to get the default security list, and then call UpdateSecurityList:

    • Change the existing stateful ingress rules to use your on-premises network's CIDR as the source CIDR, instead of 0.0.0.0/0.
    • If you plan to launch Windows instances, add this stateful ingress rule: Source type = CIDR, source CIDR = your on-premises network on TCP, source port = all, destination port = 3389 (for RDP).
  • CreateSecurityList: Call it to create the Public Subnet Security List with these rules:

    • Stateful ingress: Source type = CIDR, source 0.0.0.0/0 on TCP, source port = all, destination port = 80 (HTTP)
    • Stateful ingress: Source type = CIDR, source 0.0.0.0/0 on TCP, source port = all, destination port = 443 (HTTPS)
    • Stateful egress: Destination type = CIDR, destination CIDR blocks of private subnets on TCP, source port = all, destination port = 1521 (for Oracle databases)
  • CreateSecurityList: Call it again to create the Private Subnet Security List with these rules:

    • Stateful ingress: Source type = CIDR, source CIDR blocks of public subnets on TCP, source port = all, destination port = 1521 (for Oracle databases)
    • Stateful ingress: Source type = CIDR, source CIDR blocks of private subnets on TCP, source port = all, destination port = 1521 (for Oracle databases)
    • Stateful egress: Destination type = CIDR, destination CIDR blocks of private subnets on TCP, source port = all, destination port = 1521 (for Oracle databases)
  • CreateSubnet: Call it to create regional public subnet. Include a DNS label for the subnet if you want the VCN Resolver to resolve hostnames for VNICs in the subnet. Use the Public Subnet Route Table you created earlier. Use both the default security list and the Public Subnet Security List that you created earlier. Use the default set of DHCP options.
  • CreateSubnet: Call it again to create regional private subnet. Include a DNS label for the subnet if you want the VCN Resolver to resolve hostnames for VNICs in the subnet. Use the Private Subnet Route Table you created earlier. Use both the default security list and the Private Subnet Security List that you created earlier. Use the default set of DHCP options.
  • CreateDrg: Creates a dynamic routing gateway (DRG).
  • CreateDrgAttachment: Attaches the DRG to the VCN.
  • CreateCpe: Here you provide the IP address of the router at your end of the VPN (see Prerequisites).
  • CreateIPSecConnection: Here you provide the static routes for your on-premises network (see Prerequisites). In return, you receive the configuration information your network administrator needs to configure your router. If you need that information later, you can get it with GetIPSecConnectionDeviceConfig. For more information about the configuration, see CPE Configuration.
  • First call GetRouteTable to get the Private Subnet Route Table. Then call UpdateRouteTable to add a route rule with destination = the on-premises network CIDR (10.0.0.0/16 in this example), and destination target = the DRG you created earlier.
  • LaunchInstance: Launch at least one instance in each subnet. By default, the instances in the public subnets are assigned public IP addresses. For more information, see Creating an Instance.

You can now communicate from your on-premises network with the instances in the public subnet over the internet gateway.

Important

Although you can launch instances into the private subnets, you can't communicate with them from your on-premises network until your network administrator configures your on-premises router (see CPE Configuration). After that, your IPSec connection is 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.