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:

vendor

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:

type2

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.

ocidns

dnslb

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.

listener

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.

backends

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

lbhc

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.

waf

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.

vcns

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:

dmzrt

DMZ VCN Private Subnet:

dmzrt2

APP VCN Private Subnet:

apprt

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.

untrustpa

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.

trustpa

panosnic

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:

panosrouting

d) Correct DNAT and SNAT rules:

dnatsant

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:

httpcheck


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:

lbaaslog

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

palog

The Palo “sees” the source as the Public LB internal IP (10.0.0.34). The request is hitting the Public Interface (10.0.0.53) and then the PA performs both DNAT and SNAT:

palog2


The Palo FW will take the packet destined for 10.0.0.53, 8888/TCP, and forward it to 172.16.0.71 (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 10.0.0.87 (Private Interface VIP).
The private LB has this log:

internallb

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

The LB HA

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

bla

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.

PA1:

blaaa

PA2:

fgh

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.

dgdf

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

newtest

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

PA1:

pa1

PA2:

pa2

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