OCI DMZ common architectures - part 3 - type 2 demo

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

This blog is part of the DMZ series which was started with the main architecture blog. Now, we will do a demo on implementing a “type 2” DMZ architecture.

Demo Type 2 DMZ

As discussed in the main blog, there are various ways to expose services to the Internet. For type 2, we will use an OCI Load Balancer service as the entry into the environment. 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 2 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 LBaaS Public IP.



2) Load Balancer Service (LBaaS) – there are a wide variety of options on configuring the LB. For the demo, I chose to create a single listener on HTTPS (443/TCP) with an added certificate for SSL offloading and a “hostname” for dmz-demo.oci-lab.cloud which helps if we plan to serve multiple services/sites with the same LB.


The backend of the LBaaS will be the Palo Alto Cluster VIP (the secondary private IP on the primary NVA, untrust/public interface). Communication with the backend will be plain HTTP, port 8888. This will allow us to scale for new services by simply using a different backend port for another service.


Note that even though the backend communication is on port 8888/TCP, the health check will be on port 80/TCP.


3) WAF Policy – creating a WAF policy is very easy. Just select the type of protection you want and apply the policy directly to the LBaaS.


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


5) 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.
6) 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:


7) 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. For this demo, the rules are a little relaxed but the actual rules should be strengthened in a production environment.
8) DRG – both VCNs will be attached to the DRG to enable communication between them.
9) Private Load balancer – the Private Load Balancer is only added to the mix to allow for multiple backend servers even though for this demo we have a single Apache server. The Private LBaaS does not have any fancy configuration, a single listener on HTTP and backend communication to web servers on TCP/80.
10) Web server – a simple Oracle Linux system will provide an HTTP running service.
11) 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; 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.



Notice that the Untrust interface needs a “Management profile” to respond to the LBaaS health checks on 80/TCP.

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 Public LBaaS ,the Palo Alto and the private LBaaS.

Public LBaaS:


The source of the request is my Public IP and the backend server responding is the Palo Alto cluster VIP on port 8888/TCP.
Palo Alto Cluster:


The Palo “sees” the source as the Public LB internal IP ( 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, 8888/TCP, and forward it to (LBaaS in the other VCN) on port 80/TCP. Also, the PA will perform SNAT so the packet leaving the FW will have the source of (Private Interface VIP).
The private LB has this log:


The private LB sees the request coming from the Palo Cluster VIP ( but will also report the original source IP (taken from the HTTP header).
And this concludes the demo for the Vendor HA scenario.


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


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.





So both firewalls will need the correct routing, firewall policies and NAT rules as explained in the first scenario.
b) The LBaaS will have the same configuration as in the Vendor HA scenario with the exception that it will now have 2 backends, both Palo Alto firewalls.


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 2 DMZ. Check the main blog for the other types of DMZ architectures.

Radu Nistor

Principal Cloud Solution Architect

Previous Post

Upload the DNS zone when the zonefile is over the accepted limit

Catalin Andrei | 5 min read

Next Post

Use Case: Null (black hole) Routing in OCI

Raffi Shahabazian | 3 min read