OCI DMZ common architectures - part 2 - type 1 demo

May 26, 2023 | 9 minute read
Radu Nistor
Principal Cloud Solution Architect
Text Size 100%:

This blog is the second part of the DMZ series which was started with the main architecture blog. In this entry, we will do a demo on implementing a “type 1” DMZ architecture.

Demo Type 1 DMZ

As discussed in the main blog, there are various ways to expose services to the Internet. For type 1, the NVA will be the entry point into OCI. Also, as there are two types of high availability, depending on the NVA Vendor, we will have two implementation scenarios.

For the demo, I will use Palo Alto firewalls, deployed in both Active-Passive and Active-Active modes, depending on the scenario. 

Scenario 1 – Vendor HA

The high-level diagram for type 1 looks like this:


For the demo part, I will implement the green flow, where the APP sits behind a Load Balancer, in a different VCN than the NVA cluster, reachable via the Dynamic Routing Gateway.

Turning that high-level diagram, with a focus on the green flow, into a detailed implementation diagram would look like this:


As this blog cannot be very long, we will not go into detail about the implementation of each item in the diagram above.
1) OCI DNS (Optional) – the first part of any flow is DNS resolution. When implementing a DMZ in OCI you can use OCI’s Public DNS service which provides additional DDOS capabilities out-of-the-box. However, you can use any DNS system you like as long as you point to the FW’s Public IP.


2) VCNs – we will deploy 2 VCNs, one dedicated for the DMZ which will hold the NVA Cluster and one dedicated for the APP tier.


3) Subnets – the DMZ VCN will have two subnets, one facing the Internet (public) and one facing the internal network (private). The APP VCN will have a single subnet (private) holding the internal resources, LB and VM. Note that the DMZ VCN will also have a Management and an HA subnet, dedicated to Palo Alto management, which are not active in the data path.

4) VCN Route tables – the VCN route tables will need to be adjusted according to the diagram so traffic can flow as desired.

DMZ VCN Public Subnet:


DMZ VCN Private Subnet:


APP VCN Private Subnet:


5) Security Lists – even though NSGs are the recommended security construct, for the purpose of this demo I will use Security Lists which will have the same functionality.
6) DRG – both VCNs will be attached to the DRG to enable communication between them.
7) Load balancer – the Load Balancer will be configured to do SSL Offloading; I will also add a “hostname” option to the listener so only requests for dmz-demo.oci-lab.cloud are served; communication to the backend Web Server will be on 80/TCP (HTTP) thus unencrypted.
8) Web server – a simple Oracle Linux system will provide an Apache Splash Page
9) The Palo Alto Cluster – deploying the Palo Alto firewalls in active-passive mode requires some work. Please follow this link and this link.

After the PA Cluster is done, you should have:
a) A private secondary IP on the Untrust/Public interface of the primary Palo Alto, with a Public IP assigned; configure that private IP on the interface, inside PAN OS.


b) A private secondary IP on the Trust/Private interface of the primary Palo Alto; configure that private IP on the interface, inside PAN OS.



c) Correct route rules inside PAN OS, according to the diagram:


d) Correct DNAT and SNAT rules:


e) Correct Firewall policies to allow the traffic. For the demo, I will create an “Allow All” policy.

Once everything is in place, we can test the reachability to the Apache Web server:


As we can see, everything seems to work well. Let’s see some logs from the Palo Alto and the LBaaS.


The Palo “sees” the original IP coming from the Internet. The request is hitting the Public Interface ( and then the PA performs both DNAT and SNAT:


The Palo FW will take the packet destined for, 443/TCP, and forward it to (LBaaS in the other VCN) on the same port. Also, the PA will perform SNAT so the packet leaving the FW will have the source of (Private Interface IP). Let's see an LBaaS log:


And this concludes the demo for the Vendor HA scenario.

The Vendor agnostic HA (LB HA)

Moving to the other scenario, where we switch to a Network Load Balancer assisted high availability, the diagram transforms to:


Most of the configuration items remain the same so I will only highlight the differences:
a) The Palo Alto Firewalls are now independent, each having its own configuration, interfaces and so on.
b) The Palo Alto firewalls will need to allow TCP 80 polls from the Network LB, on the Untrust/Public interfaces. This configuration is vendor specific and, in the case of Palo Alto, it means we have to add “management profiles” to those interfaces.



c) The NLB will have a single listener that forwards all traffic to the PA firewalls. Of course, the NLB listener can be created with restriction to port 443/TCP but the usual way is to create the wildcard listener.


d) The Public DNS entry will now point to the NLB’s Public IP and the Palo Alto firewalls will no longer require Public IPs at all.



After all of this is in place, we are ready to test the reachability to the web server.


Doing multiple requests, we can see the traffic is load balanced across both firewalls.





And this concludes our demo for the Type 1 DMZ. Check the main blog for the other types of DMZ architectures.

Radu Nistor

Principal Cloud Solution Architect

Previous Post

Fusion Analytics Connector - Making the Best of Your Shopify Data

Matthieu Lombard | 5 min read

Next Post

OCI DMZ common architectures - part 1 - concepts

Radu Nistor | 10 min read