X

Tutorial: Automatically Setup a NAT instance in Oracle Cloud Infrastructure with Terraform

Changbin Gong
Principal Product Manager and Cloud Advisor

This post describes how to automatically setup network address translation (NAT) instance with Terraform in your virtual cloud network (VCN) on Oracle Cloud Infrastructure (OCI) and configure your private instances to route Internet requests through the NAT instance.  

A NAT instance can be used in a public subnet of your VCN to enable instances in the private subnet to initiate outbound IPv4 traffic to the Internet or other Oracle Cloud Infrastructure services. You could use this, for example, to enable instances to access to the Internet for specific purposes like software updates., but prohibit the instances from being accessible from Internet.

Four different deployment scenarios are provided in this post to meet various POC and production requirements. You can use this blog post and Terraform code to facilitate your POC or production deployment. The Terraform code is open source so that you can use as-is or update based upon your needs. 

Scenario #1

In this deployment, the NAT instance only has a single virtual network interface (aka vNIC) with one primary private IP address.  This deployment can be used for POC environments with very limited resources.

The high level deployment architecture is illustrated as below:

VCN with two subnets:

·      public (10.0.0.0/24), with access to Internet through an Internet Gateway

  • NATInstance is an instance in the frontend subnet which providing NAT for private subnet.

·      private (10.0.1.0/24), a private subnet with no access to Internet.

  • PrivateInstance is an instance in the private subnet.

Public subnet configuration

The route table Public Route has a Route rule, where the Internet gateway is configured as the route target for all traffic (0.0.0.0/0).

Its security list has an egress rule to allow traffic to all destinations. Ingress rules allow traffic from the backend subnet (and any other address ranges in the VCN) only.

Private subnet configuration

The private subnet's route table Private Route has a routing rule, where NATInstance (10.0.0.2) is configured as the route target for all traffic 0.0.0.0/0.

Its security list has an egress rule to allow traffic to all destinations. Ingress rules allow only specific address ranges (like on-premises network or any other backend subnets in the VCN)

There is only one network interface and one primary private IP address for the NAT instance.  You need to get the OCID of this private IP address and include it as a route target in the route table of the private subnet. 

The following Terraform code shows how to get OCID of the primary private IP address.

data "oci_core_private_ips" "myPrivateIPs" {

    ip_address = "${data.oci_core_vnic.NatInstanceVnic.private_ip_address}"

    subnet_id = "${oci_core_subnet.MgmtSubnet.id}"

}

Private_IP_ocid = "${lookup(data.oci_core_private_ips.myPrivateIPs.private_ips[0],"id")}"

You can download the Terraform code for this deployment at https://github.com/cgong-github/oci/tree/nat/example01

Scenario#2

In this deployment, the NAT instance only has a single network interface (aka vNIC),  but with one primary and one secondary private IP addresses.  This deployment is recommended for POC environments with high availability (HA) requirements.  You can failover the NAT functionality, by moving the secondary private IP to the backup NAT instance.

The high level deployment architecture is illustrated as below:

VCN with two subnets:

·      public (10.0.0.0/24), with access to Internet through an Internet Gateway

  • NATInstance is an instance in the frontend subnet which providing NAT for private subnet.

·      private (10.0.1.0/24), a private subnet with no access to Internet.

  • PrivateInstance is an instance in the private subnet.

Public subnet configuration

The route table Public Route has a Route rule, where the Internet gateway is configured as the route target for all traffic (0.0.0.0/0).

Its security list has an egress rule to allow traffic to all destinations. Ingress rules allow traffic from the backend subnet (and any other address ranges in the VCN).

Private subnet configuration

Private subnet's route table Private Route has a routing rule, where NATInstance secondary private IP address (10.0.0.3) configured as the route target for all traffic 0.0.0.0/0.

Its security list has an egress rule to allow traffic to all destinations. Ingress rules allow only specific address ranges (like on-premises network or any other backend subnets in the VCN)

You can download the Terraform code for this deployment at https://github.com/cgong-github/oci/tree/nat/example02

Scenario #3

In this deployment, the NAT instance has two network interfaces (aka vNIC).  One vNIC is deployed in the public subnet.  The other vNIC is deployed in the private subnet. This deployment is recommended for POC environments with network isolation and segmentation requirements.   For instance,  you may want to totally separate front end subnet traffic from backend private subnet. 

The high level deployment architecture is illustrated as below:

VCN with two subnets:

·      public (10.0.0.0/24), with access to Internet through an Internet Gateway

  • NATInstance is an instance in the frontend subnet which providing NAT for private subnet.

·      private (10.0.1.0/24), a private subnet with no access to Internet.

  • PrivateInstance is an instance in the private subnet.

Public subnet configuration

The route table Public Route has a Route rule, where the Internet gateway is configured as the route target for all traffic (0.0.0.0/0).

Its security list has an egress rule to allow traffic to all destinations. Ingress rules allow traffic from the backend subnet (and any other address ranges in the VCN).

Private subnet configuration

Private subnet's route table Private Route has a routing rule, where NATInstance second vNIC’s  private IP address (10.0.1.3) configured as the route target for all traffic 0.0.0.0/0.

Its security list has an egress rule to allow traffic to all destinations. Ingress rules allow only specific address ranges (like on-premises network or any other backend subnets in the VCN)

After attaching the second vNIC to the NAT instance, this network interface is not automatically recognized by the operating system of the NAT instance.  So you need to run a provided script after launching the NAT instance.  You can download this script fom https://docs.us-phoenix-1.oraclecloud.com/Content/Network/Tasks/managingVNICs.htm#Linux.  This can be done via Terraform.

After the second network interface of the NAT instance is up and running, the Terraform code needs to run additional command to enable NAT functionality is

firewall-offline-cmd --direct --add-rule ipv4 filter FORWARD 0 -i ens4 -j ACCEPT

You can download the Terraform code for this deployment at https://github.com/cgong-github/oci/tree/nat/example03

Please note, the current version of the Terraform provider for Oracle Cloud Infrastructure (2.0.5) does not support updating route rules after a subnet is created.   This creates a cyclic dependency issue for this Terraform deployment because getting the OCID of the private IP address of a second vNIC depends on the creation of a private subnet.  And the creation of a private subnet depends on populating the route table with a route rule with the OCID of the private IP address of the second vNIC of the NAT instance as routing target.   

To work around this issue, you can look at the next deployment scenario (Scenario#4) or you can manually add the route rule to the route table of the private subnet after you run the Terraform code.

Scenario #4

In this deployment, the NAT instance only has two network interfaces (aka vNIC).  One vNIC is deployed in the public subnet.  The other vNIC is deployed in the private subnet. This deployment is recommended for POC environments with network isolation and segmentation requirements.   As mentioned in Scenario#3,  this deployment creates one additional private subnet to host the second vNIC of the NAT instance to work around limitation of the current version of the Terraform provider for OCI.

The high level deployment architecture is illustrated as below:

VCN with three subnets:

·      public (10.0.0.0/24), with access to Internet through an Internet Gateway

  • NATInstance is an instance in the frontend subnet which providing NAT for private subnet.

·      private (10.0.1.0/24), a private subnet with no access to Internet and host the second vNIC of the NAT instance.

·      private (10.0.2.0/24), a private subnet with no access to Internet.

  • PrivateInstance is an instance in this private subnet.

Public subnet configuration

The route table Public Route has a Route rule, where the Internet gateway is configured as the route target for all traffic (0.0.0.0/0).

Its security list has an egress rule to allow traffic to all destinations. Ingress rules allow traffic from the backend subnet (and any other address ranges in the VCN).

Private subnet configuration

For the first private subnet (10.0.1.0/24),  the private route table is kept empty. Its security list has an egress rule to allow traffic to all destinations. Ingress rules allow only specific address ranges (like on-premises network or any other backend subnets in the VCN)

For the second private subnet (10.0.2.0/24),  the route table Private Route has a routing rule, where NATInstance second vNIC’s  private IP address (10.0.1.3) configured as the route target for all traffic 0.0.0.0/0.

Its security list has an egress rule to allow traffic to all destinations. Ingress rules allow only specific address ranges (like on-premises network or any other backend subnets in the VCN)

Please note that you need to disable reverse path filtering in the Linux kernel of the NAT instance for this deployment.   The following Terraform code shows how to disable reverse path filtering in the Linux kernel:

      net.ipv4.conf.all.rp_filter = 0

      net.ipv4.conf.ens3.rp_filter = 0

      net.ipv4.conf.ens4.rp_filter = 0

You can download the Terraform code for this deployment at https://github.com/cgong-github/oci/tree/nat/example04

Conclusion

With Terraform code, you can easily automate the deployment of NAT instance to protect important resources in your cloud datacenter and provide services for the hosts located on private subnets. In this post, four different deployment scenarios are provided for different POC or production requirements.

Appendix

Terraform

Terraform is infrastructure-as-code software that enables users to define a datacenter infrastructure in a high-level configuration language. It generates an execution plan describing what it will do to reach the desired state, and then executes it to build the described infrastructure.

Terraform provides a flexible abstraction of resources and providers.  Terraform provider for Oracle Cloud Infrastructure can be found at https://github.com/oracle/terraform-provider-oci

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha
Oracle

Integrated Cloud Applications & Platform Services