Enabling flexible security architectures with symmetric hashing on the OCI network load balancers

March 26, 2024 | 7 minute read
Jody Davis
Principal Member of the Technical Staff
Text Size 100%:

Customers want to deploy familiar security architectures in the cloud, which includes firewalls, network virtual appliances (NVAs), intrusion detection systems (IDSs), intrusion prevention systems (IPSs), and SDWAN appliances. All these architectures are available today on Oracle Cloud Marketplace. Best practices require that customers deploy at least two of these devices for resiliency and scalability and then place the device behind a load balancer to route incoming traffic.

Before today, however, customers had to make a choice: An active-active design that enables scalability but lost visibility into the source of the traffic, or active-standby, which preserves the source details of the traffic but limits the throughput to a single security device.

Today, we’re pleased to announce the general availability of symmetric hashing support on Oracle Cloud Infrastructure (OCI) flexible network load balancers. Now, you can choose an active-active design for scalability and automatically provide that the source of all traffic is preserved and passed to the security devices bidirectionally. Traffic flows through the network load balancer to your security devices and then back along the same path, avoiding dropped network flows that can occur with asymmetric routing. This feature is available across all OCI realms.

Active-active security appliance designs: Before symmetric hashing

For applications that require more flows or greater bandwidth to be processed through your security appliances, you deploy an active-active security appliance design. For any stateful security appliance, you need the same security appliance that processes the incoming traffic flow and processes the outgoing traffic flow, or traffic is dropped.

Before the symmetric hashing feature was available, customers had to configure their security appliances with configurations (source NAT) on their firewalls, which helped to prevent asymmetric routing. The application backends then receives traffic that arrived with the source IP of the firewall, which processed the incoming traffic flow, not the true client’s address. The downside for this design meant that the true source IP of the client was gone. If you needed this information for compliance or other purposes, you were generally out of luck.

Maximum visibility, seeing the true client IP address: Before symmetric hashing

Sometimes, you need to know who ordered one of your widgets. Maybe you use the source IP address data to determine where they are in the world, or you have security compliance requirements that mandate you log the true source of the incoming traffic flows. Before symmetric hashing, you generally had to design your security architecture in a way that didn’t offer the same flexibility (active-standby). If your application design required bandwidth or connections per second that exceeded the security appliance, your only option was to upgrade to a bigger security appliance to achieve higher throughput.

How symmetric hashing works on the OCI network load balancer

You can configure OCI private network load balancers to operate in source and destination IP header preservation (transparent) mode*. In this mode, you can insert a private network load balancer transparently as a next-hop route target to which packets are forwarded along the traffic path to their destination. Combined with our new symmetric hashing feature, this feature enables use cases, such as scaling of firewall appliances, IPS, and IDS, where the network load balancer acts as the bump-in-the-wire in the path that preserves incoming client packet and sends it to the next hop network virtualization appliance to apply security policies before forwarding the packet to its ultimate destination of the application servers. The following diagrams show the high-level traffic flow for both north-south traffic and east-west traffic through the network load balancer and NVAs when using this design.

North to South traffic flow  East to West traffic flow

In source and destination preservation (transparent) mode, the OCI network load balancer doesn’t modify any information in the packet and forwards it to the backend, effectively operating as a route target. This setup requires the traffic to be directed through the network load balancer through a virtual cloud network (VCN) routing table entry. See the following example packet flow.

* Are you interested in learning more about OCI's NLB and it's different modes of operation? Check out the docs here to learn more!

What network designs can be enabled with symmetric hashing?

For private network load balancers configured in transparent (source and destination header preservation) mode, you can now enable symmetric hashing on the network load balancer. This method helps ensure that traffic is forwarded to the same network virtual appliance in both directions, without the need for source NAT on the NVA. Enabling symmetric hashing on the network load balancer enables the following network designs:

  • Single network load balancer front-ends firewall appliances and handles both forward and reverse traffic.

  • Enable symmetric egress traffic through SD-WAN appliances

Single network load balancer frontends firewall appliances and handles both forward and reverse traffic

In the following diagram, we have a scenario in which you have a transparent network load balancer acting as a bump in the wire in front of your firewalls to load balance flows through all your active firewalls before the traffic arrives at the applications located in the spoke subnets. In transparent mode, you don’t send traffic to the vIP of the network load balancer, but instead send it to the application IP itself. This application can be another load balancer frontending the application backends or, in our case, a virtual machine (VM) instance running a webserver.

To redirect traffic through the transparent network load balancer and our firewalls, we use intraVCN routing to redirect incoming traffic coming in from your on-premises data center to the network load balancer using a private IP route rule contained within the dynamic routing gateway (DRG) route table. The transparent network load balancer then loadbalances the forward traffic to one of the active firewalls, configured as backends, which in turn forward the traffic to the actual servers. This traffic is forwarded without performing any NAT on the packet.

In the return path, we utilize route rules on the VCN route table associated with the local peering gateway (LPG) to help ensure that traffic from the backend servers is routed through the network load balancer. The transparent network load balancer is expected to loadbalance the return traffic to the same firewall device to which the forward traffic was loadbalanced. This return is the result of having symmetric hashing enabled on the NLB. The firewall then forwards the return traffic directly back to the customer on-premises data center network through the DRG. The main requirement here for the transparent network load balancer is to forward both forward and reverse traffic to the same firewall device.

This whole process is done without changing the source or destination IP header along the way, ensuring that applications on the backend see the true source IP address of the client and not that of the network load balancer or the firewall.

Single network load balancer frontends firewall appliances and handles both forward and reverse traffic

Enable symmetric egress traffic through SD-WAN appliances

In the following diagram, we have a private transparent-mode network load balancer, which is frontending SD-WAN devices for traffic egressing from OCI to a customer’s on-premises datacenter. The forward (ingress) traffic from the on-premises datacenter to OCI doesn’t go through a network load balancer. In this case, the network load balancer only sees the reverse direction of the traffic. So, the first packet of a TCP connection seen on the network load balancer is a SYN ACK.

We don’t have any route entries on the DRG route table redirecting traffic to the network load balancer. We only redirect the egress or return traffic through the transparent network load balancer and the SDWAN appliances. We once again take advantage of intraVCN routing to specify that all traffic from our application subnet (web ssubnet 10.0.1.0/24) destined for our on-premises environment (172.16.1.0/24) has a private IP next hop of the network load balancer vIP. This configuration allows the outbound traffic from the VCN to be loadbalanced to the SD-WAN appliances.

Enabled symmetric egress traffic through SD-WAN appliances.

Getting started with symmetric hashing for your OCI network load balancer

To get started with symmetric hashing on your network load balancer, in the Oracle Cloud Console, access the navigation menu and select Networking, Load Balancers, and then Network Load Balancer. Then, deploy a private network load balancer, enable source and destination header preservation, and then select the Enable symmetric hashing option. By default, symmetric hashing is disabled for backwards compatibility.

Configuration details for enabling symmetric hashing in the Oracle Cloud Console.

If you want to enable symmetric hashing on an existing network load balancer, proceed to your network load balancer and select Edit. Then, you can enable source and destination header preservation and symmetric hashing. Having source and festination header preservation enabled at the network load balancer level is required before you enable symmetric hashing.

Editing network load balancer details to enabling symmetric hashing.

Conclusion

With the new possibilities enabled by our network load balancer with symmetric hashing feature, OCI provides the flexibility to help you simplify your application deployments on OCI. On behalf of the virtual networking product team, we encourage you to share any product feedback that you have in the comments. Keep watching the Oracle Cloud Infrastructure space for updates as we add more exciting capabilities.

For more information, see the following resources:

Jody Davis

Principal Member of the Technical Staff


Previous Post

Behind the Scenes: Transforming cloud security with MLOps

Yuting Sun | 13 min read

Next Post


Oracle Access Governance: Securing the identity posture for enterprise and cloud applications

Sandeep Khedekar | 5 min read