OCI Network Firewall - Securing the Private LBaaS traffic

Prerequisites:

OCI Network Firewall - Concepts and Deployment

OCI Network Firewall - NAT Gateway use case

OCI Network Firewall - Hub and Spoke traffic inspection

OCI Network Firewall - Securing the LBaaS traffic

From the routing and security perspective, the networking architectures containing the NFW and the private LBaaS are very interesting to be deployed. As in the public LBaaS case, it will offer the same degree of security with the difference related to the private resources used.

The routing configuration that needs to be in place for the NFW to inspect the traffic from/to different part of network will be explained in the next section, it forms the core of the networking architecture with the NFW acting as a bump-in-the-wire. Some of the concepts are already exposed in the previous NFW blogs, but now, let's integrate the NFW with the private OCI LBaaS.

Below is the networking topology proposed, a very simple one but offering all the relevant routing and security details that needs to be in place:

The App VM1 and VM2 sits behind the private LBaaS, the traffic originated from On-premises host at 10.114.187.184 and from Consumer VM1 needs to be analyzed by the NFW prior to be sent to the private LBaaS.

The routing configuration

a) The traffic originated from On-premises host at 10.114.187.184 to the private LBaaS

The route table attached to the IPSec or FC VC DRG attachment contains the following static route:

The next hop attachment name called HUB is the Shared and Internet VCN from the above networking diagram. The 192.168.0.0/28 subnet, where the private LBaaS sits, will the advertised to On-premises CPE for IP reachability to private LBaaS floating private IP address at 192.168.0.12.

We need to make sure the traffic is making the path through the NFW prior to reach the private LBaaS, so, in the HUB attachment VCN route table we will configure the following route:

The DRG will forward all the traffic for subnet 192.168.0.0/28 to the private IP at 192.168.0.20 which essentially is the NFW.

Note1: At the subnet level, all the routing and security needs to be in place to allow the traffic and routing accordingly.

After the traffic is inspected by the NFW, it is forwarded to the private LBaaS, where at this point needs to be sent to one of the two backend servers configured.

Note2: The user traffic originated by the private LBaaS (after performing the SNAT) together with the health-check performed by the private LBaaS to the backend servers, needs to be inspected by the NFW.

The private LBaaS subnet route table contains the following route entries:

As we can see, the next hop is the NFW and all the traffic to the red squared destinations will be inspected by the NFW.

The private NFW subnet route table contains the following route entries:

After the traffic is inspected by the NFW, it is forwarded to the DRG and the DRG based on the HUB VCN attachment route table, will use the dynamic learned route to perform the forwarding to the backend servers:

Once the backend servers responds, the DRG will receive the traffic and will use the static default route configured in the Backend DRG VCN attachment route table, as follow:

The LBaaS receives the response and will send the traffic back to the On-premises host using the NFW -> DRG -> CPE path, with the DRG having a dynamic route learned in the HUB DRG VCN attachment route table:

b) The traffic originated from Consumer VM at 192.168.2.4 to the private LBaaS

Consumer DRG VCN attachment route table contains the static configured default route to send all the traffic to the HUB VCN where the NFW is located:

The traffic will follow the path: Consumer VM -> DRG -> NFW -> LBaaS -> NFW -> DRG -> Backend Servers -> DRG -> NFW -> LBaaS -> NFW -> DRG -> Consumer VM.

The NFW security configuration

The four IP Addrees Lists in the NFW policy:

One HTTP application:

Two Security Rules:

Note that the second security rule will allow the user traffic together with the LBaaS health-check.

The entire routing and security configuration is in place, let's verify if the traffic is flowing correctly and analyze the NFW traffic log:

We have the confirmation that the traffic is working as expected. Let's analyze the NFW logs and make sure the NFW has intercepted the traffic:

The above NFW traffic logs confirms the expected behavior.