OCI DMZ common architectures - part 1 - concepts

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

One of the biggest challenges is securing your environment, regardless of the architecture and deployment location. In this blog series, we will take a look at exposing to the Internet services deployed inside the Oracle Cloud Infrastructure. This entry will focus on concepts and high-level diagrams and then we will take each proposed architecture and do a demo on implementing them across multiple other entries.

The DMZ

Exposing services to the Internet carries risks. To try to mitigate those risks we usually create a super-secure buffer zone between the Internet and our internal infrastructure which holds the apps. We refer to this zone as a DMZ or demilitarized zone. This DMZ can consist of multiple layers of security checks but it’s usually built around a security appliance, mainly a firewall. While other components can be there, such as load balancers or proxies, the gatekeeper will be the firewall.

DMZ components in OCI

When we bring OCI into the picture we need to understand what tools we can leverage to create our DMZ. While this is not a complete list, most of the options would include some of the following:
- Virtual Firewall Appliances -   these are virtual instances of well-known firewalls such as Palo Alto, Fortigate, Juniper vSRX, Cisco vASA; I will refer to these as NVAs (network virtual appliances) in the diagrams.
- OCI’s Firewall service – this highly available firewall service can be used in some of the architectures
- OCI’s Web Application Firewall service – as with the Firewall service, the WAF can be added to enhance some of the architectures which rely on HTTP(S) services
- Load balancers – either LB services (LBaaS or NLB) or appliances running dedicated software can be used; the architectures I will present will be focused on OCI’s Load balancer services
- Public DNS systems – you can use your own DNS system but OCI’s Public DNS service had built-in DDOS capabilities which can stop some of the attacks before even reaching the first node

NVA High Availability

Before we get started with the architectures, let’s discuss HA. In OCI, for Virtual Appliances, you can achieve High Availability in two ways:
- Vendor-provided HA mechanism – some of the firewall vendors have created an HA mechanism that leverages OCI’s APIs to make two NVAs act as a cluster. The cluster works in the active-passive mode where the active node has a number of secondary OCI IPs on its VNICs and the passive constantly monitors the active node. Whenever the active node fails health checks, the passive node will do API calls to move all secondary IPs from the primary NVA VNICs to itself. Some of the vendors that implemented this are Palo Alto and Fortinet.
- Vendor agnostic HA (Load balancer HA) – if there is no vendor-implemented mechanism we can leverage OCI’s Load Balancer services (either the Network Load Balancer or the Load Balancer as a Service) to provide the much-needed HA. In this scenario, the NVAs will act as independent nodes, unaware of each other, so you have to configure them individually. Another downside is that all traffic leaving the NVAs towards the internal network must be translated to the NVA IP address using Source NAT (SNAT). The upside is you get twice the throughput.

DMZ architectures

Now let’s move to the core of the blog, the DMZ architectures. We will split the architectures into three distinct parts, each providing some features but missing others. The idea is that there is not a single architecture that fits all use cases, instead, you have to choose which architecture matches your security requirements. Furthermore, you can combine the architectures inside the same deployment.

DMZ type 1 – direct exposure of the NVA to the Internet

The simplest architecture revolves around assigning public IPs to the NVA. All the Internet traffic will hit the NVA on the Untrust/Public interface. The NVA will then do a Destination NAT (DNAT) to forward the traffic to a backend server that is hosting the service, through the trust interface.
As discussed above, we have two base diagrams for this architecture.

A) The Vendor HA:

vha2

If we choose the Vendor HA mechanism, the active NVA will have 1 or more secondary IPs on the Untrust/Public VNIC. Each secondary private IP will have a Public IP assigned to it. Note that you can have up to 31 secondary IPs which translates to 31 Public IPs on which you can expose services. The architecture works on exposing these services by configuring Destination NAT on the NVAs. While you can map a whole Public IP to a backend server through the DNAT, the usual configuration uses a mapping of Ports to backend servers (ex: Public IP 8800/TCP goes to internal APP server 1 on port 443/TCP).
One interesting thing we can achieve with this design is preserving the original source IP of the Internet user throughout the whole path, right up to the last node, provided the routing inside OCI is configured to accommodate this.  Alternatively, you can Source NAT the packet leaving the firewall towards the internal service with the NVA’s IP from the Trust/Private Subnet which will make the routing easier.

B) The LB HA:

lbha

In this scenario, the NVAs are independent and we use a Network Load Balancer to ensure High Availability. The usual configuration involves creating a single listener with a wildcard port in the NLB which will forward all traffic to the NVAs (TCP and UDP only, ICMP is not supported). We will configure the NVAs as the backend for the NLB.
The NLB can be configured to preserve the initial source IP of the packet so the NVAs will be able to see it. However, when the NVAs forward the packet to the internal servers they must do Source NAT with the IP of the internal interface to ensure packets are returned to the correct NVA.
As opposed to the Vendor HA, in this case, we have a single Public IP to expose services, which sits on the NLB. If we need to scale, we can deploy a second NLB.

Some considerations, true for both scenarios:
- The target of the DNAT can be an APP server or a Load Balancer or any other IP reachable service.
- The target of the DNAT can be inside the same VCN as the NVA Cluster or inside other VCNs, reachable via a Local Peering Gateway or a Dynamic Routing Gateway.
- You can use OCI’s unique feature where you can put a vNIC of a Compute (NVA) in a different VCN than the other vNICs, this way you don’t need an LPG or a DRG. Also, the number of vNICs an NVA can have is directly proportional to the number of OCPUs so if you have many APP VCNs you will need an NVA with many OCPUs which increases the cost.
- The exposed service can run on either TCP or UDP protocols.
- This architecture works well for non-HTTP services and is great for corner cases that use UDP-based services.
- If you want to expose HTTPS applications then you should look at the other designs or configure the NVA to do TLS/SSL inspection. Otherwise, the traffic passing through the NVA will be encrypted which limits its detection capabilities.

If you want to see a demo on this architecture, take a look at this blog post.

DMZ type 2 – Adding a Web Load balancer in front of the NVAs

More than 80% of Internet-related traffic is HTTPS so it makes sense to introduce an Application Load Balancer into the mix. This LB, called LBaaS in OCI, adds very interesting features such as SSL offloading and HTTP services (path routing, header manipulation, and many more) and can employ an OCI WAF policy which will greatly increase your security posture.
For the Vendor HA, the diagram would look like this:

lbass3

 

The usual architecture works by configuring the backend of the LBaaS as one of the secondary IPs on the NVA Untrust/Public interface. If we do this we must ensure the NVA answers to health checks on that interface. The usual health check targets a well-known service (https, ssh) which the NVA must allow. This configuration is Vendor specific.
Another option is to configure the LBaaS backend with the IP of the actual server holding the service, which can reside in another VCN. If we do this then we need to add static routes in the Public Subnet to tell the LBaaS it can reach its backends via the NVA’s VIP (secondary IP) on the Untrust interface. In this scenario, the NVA will see the health checks going to the backend servers so expect o lot of noise in the traffic.

If we move to the LB HA, it looks like this:

lbnovendor

In this case, the backend of the LBaaS must be the NVAs.
Some considerations, true for both scenarios:
- The target of the DNAT can be an APP server or a Load Balancer or any other IP reachable service.
- The target of the DNAT can be inside the same VCN as the NVA Cluster or inside other VCNs, reachable via a Local Peering Gateway or a Dynamic Routing Gateway.
- You can use OCI’s unique feature where you can put a vNIC of a Compute (NVA) in a different VCN than the other vNICs, this way you don’t need an LPG or a DRG.  Also, the number of vNICs an NVA can have is directly proportional to the number of OCPUs so if you have many APP VCNs you will need an NVA with many OCPUs which increases the cost.
- The exposed service can only run on TCP; this architecture is best suited for HTTP(S) services.
- You can leverage the hostname option in the LBaaS Listener to create multiple 443 listeners, each dedicated to one or more hostnames (more info here). Those listeners will have the NVAs as the backend, but you can configure a different backend on different ports for each listener (ex: Listener1 has the NVAs as the backend on port 4000, Listener 2 has the NVAs as the backend on port 4001 and so on). The DNAT in the NVAs will control where the traffic goes on the trusted side.
- You can also use multiple secondary IPs in the NVAs to increase the number of possible exposed ports or if you want to simply use 443 every time.
- The LBaaS should have the certificates and do SSL offloading so the NVAs can “look” at unencrypted traffic.
- A WAF policy on the LBaaS is optional but highly recommended for any HTTP(S) services that you expose.
Note that in this architecture the NVA will only see traffic originated with the LBaaS IP as the LB always does SNAT towards its backends. After that, the NVAs will again do Source NAT when sending the packets to their final destination.
If you want to see a demo on this architecture, take a look at this blog post.

DMZ type 3 – Gateway routing

OCI introduced a cool feature called Gateway Routing. With this feature, you can attach a VCN Route table to a Gateway (Internet Gateway, Service Gateway) and force the traffic to go through a private IP of your choosing. In the case of the DMZ discussion, this opens the possibility to reroute traffic destined for a Public LBaaS or a Public Compute through a firewall, for inspection. The only limiting factor is that the firewall and the original target must be in the same VCN and be served by the same Internet Gateway.
Let’s take a look at a diagram, for vendor-specific HA:

gwroutevendor


While this looks similar to the “type 1” architecture, the implementation is quite different.  The Public IPs are assigned to the Public LBaaS or the APP Server (which are in the same VCN as the NVA cluster) but the VCN route table attached to Internet Gateway is forcing the traffic through the secondary IP of the NVA cluster primary node. That way, you can inspect the traffic before it reaches the LB.
In this architecture, you do not need to SNAT the traffic leaving the NVA cluster but you do need to make sure the target Public Subnets (where the LBaaS or the APP server live) have return routes to 0.0.0.0/0 through the NVA cluster VIP.


OCI’s NGFW Service relies on this model to expose services to the Internet. Here is how it looks:

gwocifw

In the case of OCI’s NGFW service, you can configure an SSL Decryption Policy which will allow you to inspect SSL traffic before sending it to the Public Load Balancer. Note that the FW service allows only one interface which will be used for all traffic. For a demo on implementing the above scenario please take a look at this blog.

Final note

The architectures presented in this blog are not the only possible ways to create a DMZ but they are the most used. OCI offers a great deal of flexibility for the network setup so these architectures can be tuned to your needs or even combined, to offer the best solution that exposes services to the Internet as securely as possible.

As stated at the beginning of this blog entry, these are high-level architectures designed to introduce you to the many possibilities. For detailed implementation steps please follow the embedded links throughout the blog.

 

 

Radu Nistor

Principal Cloud Solution Architect


Previous Post

OCI DMZ common architectures - part 2 - type 1 demo

Radu Nistor | 9 min read

Next Post


Handling Overlapping CIDRs in OCI

Mohsin Kamal | 3 min read