Protect Your Cloud Resources Using a Virtual Firewall

Although Oracle Cloud Infrastructure offers network security controls through security lists and network security groups, in some scenarios different types of network security are required. For those scenarios, Oracle Cloud Infrastructure uses virtual cloud networks (VCN) and subnets to lay the different segments of the network, and the firewall to handle the security controls.

Deploying a firewall to control the network flow gives you the following benefits:
  • Centralized access controls
  • Content filtering
  • Inbound and outbound Network Address Translation (NAT) and Port Address Translation (PAT)
  • Advanced traffic policies
  • Consistency of procedures through different environments (on-premises and other cloud providers), which also simplifies migration and expansion to the cloud because the same tools are being used
  • Extended design capabilities for complex scenarios

Architecture

In this architecture, a virtual firewall controls north-south traffic and east-west traffic. The architecture shows how to design the network and where to place the firewall.

North-south traffic is the traffic that comes from the internet (through the internet gateway) or the on-premises environment (through the dynamic routing gateway) to the VCNs. East-west traffic is the traffic between VCNs in your tenancy.

The following diagram illustrates this reference architecture.

Description of firewall-oci.png follows
Description of the illustration firewall-oci.png

firewall-oci-oracle.zip

In the diagram, the VNICs connect the subnets to a virtual firewall (such as a Palo Alto Networks VM-Series firewall). The subnets assume the following roles in the architecture:
  1. The Management Public Subnet in VCN1 (CIDR 10.0.1.0/24) provides the network administrator access to the virtual firewall's console through SSH and HTTPS.
  2. The Untrusted Public Subnet in VCN1 (CIDR 10.0.2.0/24) enables customers to access private subnets from the Internet with the control of Palo Alto Firewall.
  3. The Trusted Private Subnet in VCN1 (CIDR 10.0.3.0/24) acts as the DMZ.
  4. The Trusted Private Subnet in VCN2 (CDIR 10.1.1.0/24) allows for hidden private resources.

The architecture has the following components:

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domains

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Fault domains

    A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

  • Virtual cloud network (VCN) and subnets

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Internet gateway

    The internet gateway allows traffic between the public subnets in a VCN and the public internet.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.

  • Route table

    Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

  • Security lists

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

  • Virtual network interface card (VNIC)

    A VNIC enables an instance to connect to a VCN and determines how the instance connects with endpoints inside and outside the VCN. Each instance automatically comes with a primary VNIC, and you can add secondary ones.

  • Firewall

    The firewall controls the flow between the segments in your environment. Advanced features vary among providers.

Recommendations

Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.

  • VCN

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select an address range that doesn’t overlap with your on-premises network, so that you can set up a connection between the VCN and your on-premises network, if necessary.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your functionality and security requirements. Attach all the compute instances within the same tier or role to the same subnet.

    Use regional subnets.

  • Security lists

    Although all the traffic is flowing through the firewall, security lists are still required for traffic within and among subnets.

  • Firewall

    If your environment is mission-critical, ensure that the firewall you implement supports a highly available deployment to avoid unexpected outages.

    When using a standby firewall, deploy it on a different fault domain.

    Because the firewall isn’t managed as part of Oracle Cloud Infrastructure, ensure that its patches are always applied.

    The firewall requires multiple VNICs to connect the different segments in your environment. Choose an instance shape that provides enough VNICs.

Considerations

  • Performance

    As the central point of communication, the firewall instance should have enough VNICs to connect the existing segments. For most cases, CPU is not a limiting factor. In Oracle Cloud Infrastructure, the number of VNICs and the associated bandwidth scale up with the number of OCPUs of the instance’s shape.

  • Security

    The firewall isn’t managed as part of Oracle Cloud Infrastructure. Implement secure procedures to ensure secure management access and a good patching policy.

  • Availability

    The firewall is the central point where all the communications flows. The firewall that you choose must be able to work in a high-availability mode to avoid impacts if an unplanned outage occurs.

  • Cost

    The cost of using this architecture is based on the size of the instance shape used for the firewall. If you choose a paid firewall solution, the licensing costs should also be considered.

Deploy

The Terraform code for this reference architecture is available as a sample stack in Oracle Cloud Infrastructure Resource Manager. You can also download the code from GitHub, and customize it to suit your specific requirements.

  • Deploy by using Oracle Cloud Infrastructure Resource Manager:
    1. Click Deploy to Oracle Cloud

      If you aren't already signed in, enter the tenancy and user credentials.

    2. Review and accept the terms and conditions.
    3. Select the region where you want to deploy the stack.
    4. Follow the on-screen prompts and instructions to create the stack.
    5. After creating the stack, click Terraform Actions, and select Plan.
    6. Wait for the job to be completed, and review the plan.

      To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.

    7. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
  • Deploy using the Terraform code in GitHub:
    1. Go to GitHub.
    2. Clone or download the repository to your local computer.
    3. Follow the instructions in the README document.

Change Log

This log lists significant changes: