1. Concepts Guide
  2. Virtual Networking Overview
  3. Networking Scenarios

Networking Scenarios

This section describes a number of basic networking scenarios to help you understand the networking service and how networking components operate together.

Caution:

Regardless of the selected networking scenario, always ensure that the IP address ranges configured as Private Cloud Appliance public IPs DO NOT conflict with IP addresses used within the data center network.

When configuring virtual cloud networks (VCNs) with a dynamic routing gateway (DRG), ensure that the VCN IP address ranges DO NOT overlap with each other or with the on-premises network.

Private Subnet with Data Center Ingress and Egress Traffic

This section describes a setup consisting of a VCN and a private subnet. Instances in the subnet can reach and be reached from the on-premises network. For connectivity to and from your on-premises network, the VCN needs a dynamic routing gateway (DRG).

The subnet uses the default security list, which has default rules that are designed to make it easy to get started. 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 implicitly 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.

The subnet uses the default route table, which contains no rules when the VCN is created. In this scenario, the table has only a single rule: to route traffic intended for all destinations (0.0.0.0/0) through the DRG.

The VCN CIDR must not overlap with any IP address range in the data center, or in any other VCN that uses a DRG. The VCN CIDR also must not overlap with the IP addresses configured as Private Cloud Appliance public IPs. Overlap with VCNs using a NAT gateway or internet gateway is allowed.

To set up this networking scenario, you perform the following steps:

  1. Create the VCN.

    Choose a compartment you have permission to work in. Specify a CIDR block for the VCN; for example: 172.16.0.0/16. Optionally, enable DNS and specify a DNS label for the VCN.

  2. Create the private subnet.

    Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 172.16.10.0/24. Make the subnet private; the instances you create cannot obtain a public IP address. Select the default route table. If you enabled DNS at the VCN level, you can choose to assign host names in the subnet and specify a subnet DNS label as well.

  3. Update the default security list.

    You set up the subnet to use the VCN's default security list. Now you add security list rules that allow the types of connections that the instances in the VCN will need.

    For example, if your subnet contains Microsoft Windows instances and you intend to access them using RDP, add an ingress rule to the default security list using these parameters:

    • Source Type: CIDR

    • Source CIDR: 0.0.0.0/0

    • IP Protocol: TCP

    • Source Port Range: All

    • Destination Port Range: 3389

  4. Create a dynamic routing gateway (DRG) and attach it to your VCN.

    When you create the DRG, it is in "Provisioning" state for a short period. Ensure that provisioning is done before continuing. Next, attach the DRG you just created to your VCN. For this scenario you can ignore the advanced attachment options. The DRG attachment will be in "Attaching" state for a short period before it is ready.

    To allow traffic to flow to the DRG, you must add a route rule.

  5. Update the default route table to use the DRG.

    The default route table starts out with no rules. No route rule is required in order to route traffic within the VCN itself. You must add a rule that routes all traffic destined for addresses in your on-premises network to the DRG. Enter these parameters:

    • Target Type: Dynamic Routing Gateway.

      The VCN's attached DRG is automatically selected as the target.

    • Destination CIDR block: 0.0.0.0/0

      This means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.

    Because the subnet was set up to use the default route table, the DRG now enables traffic between the resources in the subnet and in your on-premises network.

  6. Create instances.

    Your next step is to create one or more instances in the subnet. Each instance automatically gets a private IP address. With the network setup in this scenario, no additional configuration is required in order to access the instances from your on-premises network.

Private Subnet with Data Center Egress Traffic Only

This section describes a setup consisting of a VCN and a private subnet. Instances in the subnet can reach the on-premises network, but cannot be reached from outside the VCN. For connectivity to your on-premises network, the VCN needs a NAT gateway.

The subnet uses the default security list, which has default rules that are designed to make it easy to get started. Remember that security list rules only allow traffic. Any traffic not explicitly covered by a security list rule is implicitly denied. In this scenario, no additional rules need to be added to the default security list.

The subnet uses the default route table, which contains no rules when the VCN is created. In this scenario, the table has only a single rule: to route traffic intended for all destinations (0.0.0.0/0) through the NAT gateway.

There are no overlap restrictions for the VCN CIDR in this configuration.

To set up this networking scenario, you perform the following steps:

  1. Create the VCN.

    Choose a compartment you have permission to work in. Specify a CIDR block for the VCN; for example: 172.16.0.0/16. Optionally, enable DNS and specify a DNS label for the VCN.

  2. Create the private subnet.

    Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 172.16.10.0/24. Make the subnet private; the instances you create cannot obtain a public IP address. Select the default route table. If you enabled DNS at the VCN level, you can choose to assign host names in the subnet and specify a subnet DNS label as well.

  3. Create a NAT gateway and attach it to your VCN.

    When you create the NAT gateway, it is enabled immediately. However, you must add a route rule to allow traffic to flow to the gateway.

  4. Update the default route table to use the NAT gateway.

    The default route table starts out with no rules. No route rule is required in order to route traffic within the VCN itself. You must add a rule that routes all traffic destined for addresses in your on-premises network to the NAT gateway. Enter these parameters:

    • Target Type: NAT gateway.

      The VCN's attached NAT gateway is automatically selected as the target.

    • Destination CIDR block: 0.0.0.0/0

      This means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.

    Because the subnet was set up to use the default route table, the NAT gateway now enables traffic from the resources in the subnet to your on-premises network.

  5. Create instances.

    Your next step is to create one or more instances in the subnet. Each instance automatically gets a private IP address. With the network setup in this scenario, instances can reach resources in your on-premises network, but your on-premises network has no direct access to these instances.

Public Subnet with Data Center Ingress and Egress Traffic

This section describes a setup consisting of a VCN and a public subnet. Instances in the subnet can reach and be reached from the on-premises network. For connectivity to and from your on-premises network, the VCN needs an internet gateway. The IP addresses used in this scenario must be public from the appliance perspective. In a private cloud context, this means a unique address directly reachable from 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. 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 implicitly 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.

The subnet uses the default route table, which contains no rules when the VCN is created. In this scenario, the table has only a single rule: to route traffic intended for all destinations (0.0.0.0/0) through the internet gateway.

There are no overlap restrictions for the VCN CIDR in this configuration.

To set up this networking scenario, you perform the following steps:

  1. Create the VCN.

    Choose a compartment you have permission to work in. Specify a CIDR block for the VCN; for example: 172.16.0.0/16. Optionally, enable DNS and specify a DNS label for the VCN.

  2. Create the public subnet.

    Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 172.16.10.0/24. Select the default route table. Make the subnet public, so that instances can obtain public IP addresses. If you enabled DNS at the VCN level, you can choose to assign host names in the subnet and specify a subnet DNS label as well.

  3. Create the internet gateway.

    When you create the internet gateway, it is enabled immediately. However, you must add a route rule to allow traffic to flow to the gateway.

  4. Update the default route table to use the internet gateway.

    The default route table starts out with no rules. No route rule is required in order to route traffic within the VCN itself. You must add a rule that routes all traffic destined for addresses outside the VCN to the internet gateway. Enter these parameters:

    • Target Type: Internet Gateway

    • Destination CIDR block: 0.0.0.0/0

      This means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.

    • Target: The internet gateway you created.

    Because the subnet was set up to use the default route table, the resources in the subnet can now use the internet gateway. The existence of this rule also enables inbound connections to the subnet, through the internet gateway. The next step is to specify the types of traffic you want to allow into and out of the instances you later create in the subnet.

  5. Update the default security list.

    You set up the subnet to use the VCN's default security list. Now you add security list rules that allow the types of connections that the instances in the VCN will need.

    For example, if the instances in your subnet are web servers, they likely need to receive inbound HTTPS connections. To enable that traffic, add an ingress rule to the default security list using these parameters:

    • Source Type: CIDR

    • Source CIDR: 0.0.0.0/0

    • IP Protocol: TCP

    • Source Port Range: All

    • Destination Port Range: 443

  6. Create instances.

    Your next step is to create one or more instances in the subnet. Each instance automatically gets a private IP address. With the network setup in this scenario, you must give each instance a public IP address, otherwise you cannot access them through the internet gateway.

Public Subnet with Mixed Data Center Connectivity

This section describes a setup consisting of a VCN and a public subnet. It contains a mix of instances with and without a public IP address. Instances with a public IP address can reach and be reached from the on-premises network through an internet gateway. Instances with only a private IP address cannot be reached from outside the VCN, but have access to selected resources, for example software repositories, in the on-premises network through a NAT gateway. In a private cloud context, the public IP addresses in this scenario are unique and directly reachable within 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. 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 implicitly 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.

The subnet uses the default route table, which contains no rules when the VCN is created. In this scenario, the table has two rules:

  • to route traffic intended for a particular data center address range (for example 10.25.4.0/24) through the NAT gateway

  • to route traffic intended for all other destinations (0.0.0.0/0) through the internet gateway

There are no overlap restrictions for the VCN CIDR in this configuration.

To set up this networking scenario, you perform the following steps:

  1. Create the VCN.

    Choose a compartment you have permission to work in. Specify a CIDR block for the VCN; for example: 172.16.0.0/16. Optionally, enable DNS and specify a DNS label for the VCN.

  2. Create the public subnet.

    Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 172.16.10.0/24. Select the default route table. Make the subnet public, so that instances can obtain public IP addresses. If you enabled DNS at the VCN level, you can choose to assign host names in the subnet and specify a subnet DNS label as well.

  3. Create an internet gateway and a NAT gateway.

    When you create these gateways, they are enabled immediately. However, you must add route rules to allow traffic to flow to the gateways.

  4. Update the default route table to use the two gateways.

    The default route table starts out with no rules. No route rule is required in order to route traffic within the VCN itself. You must add rules that route traffic destined for addresses outside the VCN to the gateways.

    1. Add a routing rule for the NAT gateway using these parameters, and replace the example destination as required:

      • Target Type: NAT Gateway

      • Destination CIDR block: 10.25.4.0/24

        This means that all non-intra-VCN traffic intended for that particular subnet in the data center goes to the target specified in this rule.

      • Target: The NAT gateway you created.

    2. Add a routing rule for the internet gateway using these parameters:

      • Target Type: Internet Gateway

      • Destination CIDR block: 0.0.0.0/0

        This means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.

      • Target: The internet gateway you created.

    Because the subnet was set up to use the default route table, the resources in the subnet can now use the internet gateway or NAT gateway.

    • Instances with only a private IP address can reach resources in the data center IP range 10.25.4.0/24. In this example we assume that software repositories exist in that range, and instances access them to update the operating system and applications they run. Other traffic outside the VCN is not allowed.

    • Instances with a public IP address also use the NAT gateway when connecting to resources in that specific data center IP range. For all other outbound traffic, as well as inbound connections, the internet gateway is used.

    The next step is to specify the types of traffic you want to allow into and out of the instances you later create in the subnet.

  5. Update the default security list.

    You set up the subnet to use the VCN's default security list. Now you add security list rules that allow the types of connections that the instances in the VCN will need.

    For example, if the instances with a public IP address in your subnet are web servers, they likely need to receive inbound HTTPS connections. To enable that traffic, add an ingress rule to the default security list using these parameters:

    • Source Type: CIDR

    • Source CIDR: 0.0.0.0/0

    • IP Protocol: TCP

    • Source Port Range: All

    • Destination Port Range: 443

  6. Create instances.

    Your next step is to create instances in the subnet. Each instance automatically gets a private IP address. With the network setup in this scenario, you must give an instance a public IP address if it requires external connectivity through the internet gateway.

Public and Private Subnet with Separate Routing

This section describes a simple multi-tier setup consisting of a VCN with a public and a private subnet. The public subnet holds public instances such as web servers, and the private subnet holds private instances such as database servers. The VCN has a NAT gateway for connectivity from the private subnet to your on-premises network. Instances in the public subnet have external access through an internet gateway.

Note:

In Private Cloud Appliance the public IP addresses are reserved address ranges within the boundaries of the on-premises network; not actual unique internet addresses. The internet gateway in the VCN allows access from the on-premises network to the public subnet. From an instance in the public subnet you can then access resources in the private subnet.

Each subnet uses the default security list, which has default rules that are designed to make it easy to get started. 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 implicitly denied.

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.

To set up this networking scenario, you perform the following steps:

  1. Create the VCN.

    Choose a compartment you have permission to work in. Specify a CIDR block for the VCN; for example: 172.16.0.0/16. Optionally, enable DNS and specify a DNS label for the VCN.

  2. Add the necessary gateways to the VCN.

    The instances in the public subnet need an internet gateway for incoming and outgoing public traffic. The instances in the private subnet need a NAT gateway to be able to reach the data center network. These gateways are enabled immediately upon creation, but you must add route rules to allow traffic to flow to them.

  3. Create custom route tables for the subnets you will create later.

    1. For the public subnet, create a route table and add a rule that routes all traffic destined for addresses outside the VCN to the internet gateway. Enter these parameters:

      • Target Type: Internet Gateway

      • Destination CIDR block: 0.0.0.0/0

        This means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.

      • Target: The internet gateway you created.

    2. For the private subnet, create a route table and add a rule that routes all traffic destined for addresses in your on-premises network to the NAT gateway. Enter these parameters:

      • Target Type: NAT Gateway

      • Destination CIDR block: 0.0.0.0/0

        This means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.

      • Target: The NAT gateway you created.

  4. Update the default security list.

    Add security list rules that allow the types of connections that the instances in the VCN will need.

    Edit each of the existing stateful ingress rules so that the Source CIDR is not 0.0.0.0/0, but the CIDR for your on-premises network; in this example: 10.25.0.0/16.

  5. Create custom security lists for the subnets you will create later.

    1. Create a custom security list for the public subnet and add rules to allow the types of connections that the public instances will need. For example, web servers likely need to receive HTTP and HTTPS ingress traffic. For HTTP, use the settings below. For HTTPS, add another similar rule for TCP port 443.

      • Source Type: CIDR

      • Source CIDR: 0.0.0.0/0

      • IP Protocol: TCP

      • Source Port Range: All

      • Destination Port Range: 80

    2. Create a custom security list for the private subnet and add rules to allow the types of connections that the private instances will need. For example, database servers likely need to receive SQL*Net (TCP port 1521) ingress traffic from clients in the private and the public subnet. For clients in the public subnet, use the settings below. For clients in the private subnet, add another similar rule for the CIDR of the private subnet (172.16.1.0/24).

      • Source Type: CIDR

      • Source CIDR: 172.16.2.0/24

      • IP Protocol: TCP

      • Source Port Range: All

      • Destination Port Range: 1521

  6. Create the subnets in the VCN.

    • Public subnet:

      Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 172.16.2.0/24. Make the subnet public, so that instances can obtain public IP addresses. Select the custom public subnet route table you created earlier.

      Select two security lists: both the default security list and the public subnet security list you created earlier. If you enabled DNS at the VCN level, you can choose to assign host names in the subnet and specify a subnet DNS label as well.

    • Private subnet:

      Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 172.16.1.0/24. Make the subnet private; the instances you create in this subnet cannot obtain a public IP address. Select the custom private subnet route table you created earlier.

      Select two security lists: both the default security list and the private subnet security list you created earlier. If you enabled DNS at the VCN level, you can choose to assign host names in the subnet and specify a subnet DNS label as well.

  7. Create instances.

    Your next step is to create instances in the subnets. Each instance automatically gets a private IP address. In the public subnet, assign a public IP address to each instance. Otherwise, you won't be able to reach the instance from your on-premises network.