Mastering OCI Networking - Scenario 1 (Hub and Spoke with OCI Firewall)- Part B

Summary

This video demonstrates the setup of an urban topology with an OC FI wall deployed in a hub-and-spoke network. It covers the creation of three VCNs, side-to-side VPN configuration, and network routing validation using the network visualizer. The presenter explains DRG route table configurations for on-prem and spoke VCNs, dynamic routing, and firewall inspections. It also includes details on the use of load balancers, web servers, and how to validate traffic through trace paths and log checks, ensuring proper firewall routing and traffic flow across the network.

Takeaways

• 😀 Overview of the setup involving Urban Spook topology with an OCFI wall deployed in a Hub.
• 🌐 Explanation of three VCNS (VCNA as Hub, VCNB, and VCNC as spokes) and a Site-to-Site VPN connected to an on-prem CP.
• 🔄 Network validation is done using the Network Visualizer tool to check the connections between the on-prem network and the VCNS.
• 🛠 Detailed configuration of DRG (Dynamic Routing Gateway) route tables for on-prem, spoke VCNS, and the Hub VCN.
• 🔗 Static route configuration for future VCNs to connect through the Hub VCN.
• 🚧 Import route distribution helps automatically download routes learned from IPsec and VCN attachments.
• 📶 Traffic inspection is done via firewalls, routing traffic between on-prem networks and spoke VCNS through the Hub.
• 🚦 Configuration of private and public subnets in Hub VCN with default routes pointing to the firewall and internet gateway.
• 🖥 Load balancer setup in the public subnet for the web server, which is accessed through Oracle Cloud Infrastructure.
• 📊 Logs and TracePath are used to verify that traffic is being routed through the firewall correctly.

Q & A

What is the purpose of the setup shown in the video?

The purpose of the setup is to demonstrate an urban spook topology using an OCI (Oracle Cloud Infrastructure) firewall, with a hub-and-spoke VCN (Virtual Cloud Network) model, side-to-side VPN, and DRG (Dynamic Routing Gateway) configuration for secure routing between on-premise and cloud environments.

What are the roles of the VCNA, VCNB, and VCNC in the topology?

In the topology, VCNA acts as the Hub VCN, while VCNB and VCNC are spoke VCNs. Traffic from the spoke VCNs is directed to the Hub VCN for centralized routing and inspection.

How does the routing between on-prem and cloud networks work in this setup?

Traffic from the on-prem network, which is in the 100.x.x.x range, is routed through a side-to-side VPN connection to the Hub VCN. The Hub VCN inspects the traffic and then forwards it to the spoke VCNs, ensuring secure and controlled routing.

How is the DRG configured in this setup?

The DRG (Dynamic Routing Gateway) is configured with multiple route tables: one for the on-prem network, another for the spoke VCNs, and a third for the Hub VCN. The DRG uses static and dynamic routes to forward traffic between the different components of the network.

What is the significance of the 'import route distribution' feature?

The 'import route distribution' feature allows automatic downloading of routes learned by the DRG. It simplifies routing configuration by dynamically importing routes from IPsec, virtual circuit attachments, and VCN attachments, and applying them to the route tables.

What is the purpose of creating a static route for the 172.16.0.0/16 CIDR range?

The static route for the 172.16.0.0/16 CIDR range is created to ensure that any future VCNs spun up within this CIDR range are properly routed to the Hub VCN, facilitating centralized traffic control.

Why are separate route tables used for the public and private subnets in the Hub VCN?

Separate route tables are used for the public and private subnets to ensure proper traffic segmentation. The public subnet routes to the internet gateway, while the private subnet routes traffic through a firewall and the dynamic routing gateway (DRG) for secure internal communication.

What is the role of the firewall in this setup?

The firewall, deployed in the private subnet of the Hub VCN, inspects incoming and outgoing traffic between the on-prem network, the internet, and the spoke VCNs. It ensures that only authorized traffic is allowed through the network.

How is traffic inspection validated in this setup?

Traffic inspection is validated by reviewing the DRG transit routing tables, performing trace paths to check if traffic flows through the firewall, and checking the firewall logs for details on source, destination, ports, and actions.

How is East-West traffic (traffic between spokes) handled?

East-West traffic between spoke VCNs is routed through the Hub VCN, where it is inspected by the firewall before being sent to its destination. The trace path and firewall logs can be used to verify this flow.

Outlines

00:00

🔧 Overview of Hub and Spoke Topology Setup

This paragraph introduces the video, where the creator provides a demonstration of a hub and spoke topology setup using Oracle Cloud Infrastructure (OCI) with a wall deployed in the hub. The explanation covers the creation of three Virtual Cloud Networks (VCNs) – a hub (VCN A) and two spokes (VCN B and C). The presenter sets up a site-to-site VPN with an on-premise network, where the on-prem network is in the 100.x range and the VCNs are in a different range. The network visualizer is used to verify routing, showing that the hub acts as the central point of connection for all spokes and the on-premise network.

05:00

🚦 DRG Configuration and Route Tables Explanation

This section delves into the configuration of the Dynamic Routing Gateway (DRG) and its route tables. The presenter explains the creation of three route tables: one for on-premise networks, one for spoke VCNs, and one for the hub VCN. They also explain the need for specific routing rules to manage traffic between on-prem and VCNs. Additionally, a static route is set up for future VCNs in a predefined CIDR range. Import route distribution is discussed, showing how routes are learned dynamically and applied to the route table, making the routing system efficient.

10:04

🔄 Hub VCN Routing and Firewall Configuration

The third paragraph focuses on the routing configuration for the hub VCN, which includes private and public subnets. Two route tables are created—one for the private subnet pointing to the NAT gateway and another for the public subnet pointing to the internet gateway. The presenter discusses the importance of including specific routes for public subnets and how implicit routing in OCI might bypass the firewall if not explicitly configured. The explanation covers common routing mistakes, especially regarding traffic inspection by the firewall, and stresses the need to ensure proper route overrides.

🌐 Load Balancer Setup and Traffic Inspection

Here, the speaker explains the deployment of a load balancer in the public subnet with a backend server. They show that both internet and on-premise servers can access the application hosted behind the firewall. East-West (internal) traffic flow is verified using tools like curl and trace path, showing how traffic passes through the firewall. They also demonstrate traffic inspection logs in the firewall for validation, providing detailed filtering options to check the source, destination, port, and action of inspected traffic.

Keywords

💡VCN (Virtual Cloud Network)

A Virtual Cloud Network (VCN) is a customizable private network within the Oracle Cloud Infrastructure (OCI). In the video, the speaker discusses setting up three VCNs, where VCNA serves as the hub, and VCNB and VCNC are the spokes. The VCNs allow the speaker to manage network communication between different cloud resources, with the Hub VCN acting as a central connection point.

💡Hub-and-Spoke Topology

Hub-and-Spoke topology is a network design where multiple 'spoke' networks connect to a central 'hub' network. In the video, the speaker explains this topology with VCNA being the hub and VCNB and VCNC as the spokes. All traffic from the spoke networks is routed through the hub VCN, facilitating centralized network control and security management.

💡DRG (Dynamic Routing Gateway)

A Dynamic Routing Gateway (DRG) allows traffic between a VCN and networks outside the cloud, such as on-premises networks. In the video, the speaker details the configuration of DRG route tables to manage traffic between on-premise networks and VCNs. The DRG plays a crucial role in routing traffic efficiently and ensuring connectivity between cloud and on-prem resources.

💡Route Tables

Route tables define the rules for directing network traffic within the cloud infrastructure. The video discusses creating several route tables to manage traffic between different VCNs, subnets, and on-prem networks. For instance, specific route tables handle traffic for public and private subnets, while others are used for the DRG and its connections to the spokes and the hub.

💡IPsec VPN

An IPsec VPN provides a secure connection between a Virtual Cloud Network (VCN) and an on-premises network. In the video, the speaker mentions setting up an IPsec VPN to connect an on-prem server to the OCI environment, showing how it allows secure communication between the cloud and physical infrastructure.

💡Network Visualizer

The Network Visualizer is a tool that allows users to view and validate their network topology and configuration in a visual format. The speaker uses this tool in the video to verify the connections between the hub, spokes, and the on-prem network, ensuring that the routing is functioning correctly. It visually confirms that traffic is properly routed through the hub VCN.

💡Firewall

A firewall is a security system that monitors and controls incoming and outgoing network traffic. In the video, the speaker describes deploying a firewall in the private subnet of the hub VCN. All traffic, whether from the internet or the on-premises network, is inspected by the firewall to ensure security, before being forwarded to its destination.

💡Subnet

A subnet is a segmented part of a VCN that can be used to isolate different resources within the network. In the video, the speaker sets up both public and private subnets in the hub VCN, with specific routing tables for each. The public subnet routes traffic to the internet gateway, while the private subnet routes internal traffic to a firewall.

💡Load Balancer

A load balancer distributes traffic across multiple servers to ensure availability and performance. In the video, the speaker configures a load balancer in the public subnet of the hub VCN to distribute traffic to a web server. This setup ensures that the application is accessible from the internet and that the traffic is managed efficiently.

💡Route Distribution

Route distribution refers to the process of propagating routes dynamically across a network. In the video, the speaker discusses creating import route distributions to automatically download and apply learned routes. This is used to ensure that the routing tables within the DRG are updated with the latest information, facilitating efficient network traffic management.

Highlights

Overview of the Urban Spook topology setup with an ocfi wall deployed in the hub.

Explanation of the three virtual cloud networks (VCNs) and their configuration: VCNA as the hub and VCNB/C as the spokes.

Demo of the site-to-site VPN configuration, showcasing a working tunnel between on-prem and VCN.

Validation of the network setup using the network visualizer tool to inspect routing correctness.

Detailed breakdown of the Dynamic Routing Gateway (DRG) route table setup for on-prem, spoke VCNs, and the hub VCN.

Step-by-step creation of static and dynamic routes, including IPsec virtual circuit attachments.

Configuration of DRG import route distribution to automatically download routes and create route tables.

Routing configuration for public and private subnets in the hub VCN, highlighting the use of firewalls for inspection.

Discussion on avoiding routing mistakes with OCI implicit route tables by overriding with specific routes.

Configuration of the NAT gateway and association with DRG transit routing tables to enable reverse traffic flow inspection.

Load balancer configuration in the public subnet, demonstrating backend server access via public IP address.

Demonstration of East-West traffic flow and inspection between spoke VCNs and on-prem network.

Validation of routing paths using trace path and logs to ensure traffic inspection through the firewall.

Analysis of firewall logs and filtering traffic by source, destination, and port to validate network traffic inspection.

Concluding demo showing successful access to the web server from both on-prem and internet environments.

Transcripts

hello all welcome back to my channel

and

in this video I'm going to just quickly

show you uh give you a video demo of my

setup that I've created for this Urban

spook topology with an ocfi wall

deployed in the hub

and if you are you are looking at the

three vcns that I've created vcna will

be the Hub mbnc are the spokes

and I've also set up a side to side VPN

with my on-prem CP which is this

if I click on that you'd see one of the

tunnels will be up just I've just

configured one for the demo purpose

and um

that on on-prem network will be in 100

range

while the vcns are

in this this range and a good way of

validating your network setup and

routing is done right is by going to the

network visualizer

and if you

so I let the

uh the map populate there you go so now

if you see

um you have an on-prem Network and three

um

recents and one of them is the Hub so if

you select this link you'd see it was

able to make a connection it has linked

towards every Network point which is

this you can see B and the on-prem

network

whereas if you select any other vcn or

even the on-prem ipsec VPN it would be

able to connect only to the hub vcn

which means that the Hub vcn is the

central Connecting Point for all these

so any traffic that's going to come off

this on-prem will be directed to the hub

vcn and the Hub Vision will be able to

send it after inspecting will be able to

send it back to the spoke vcns so this

is a good way of validating if your

routing is right

now let me quickly show you how the drg

is configured let me show you the show

you around the drg and its route tables

so the first thing is the drg route

table you will see route table number

one which is meant for on-prem Route

table number two which is meant for

spoke vcns Android number three which is

meant for the Hub vcn and the routable

number one which is meant for uh

the on-prem networks we are essentially

advertising a static route of 170 to 16

0.0 16 which is your OC C8 let's assume

that you're going to any future vcns

that are put you're going to spin up

will be of this cidr range you will have

to enter that range and then point it uh

to your vcn hub

uh which is vcna attachment

and create a route table

and Route table number two will be

any traffic that's going to come out of

these uh in Spoke vcns your oci vcns the

be it uh internet or on-prem anything

that any traffic that's going to come

out of it will be down forwarded to your

uh Hub vcn attachment

and uh that's again a static of the

nuclear create and for the Hub vcn you

create a dynamic routing that is you

create an import route distribution and

how do you do it is by if you go to the

drg and go to import route distribution

you create a new import or distribution

and add a similar policy where you

include all IP second virtual circuit

attachments you can also include your

RPC attachments for those such few use

cases um

where you want to inspect traffic coming

from your other region

with the with the firewall and you also

include the vcn attachments here

um and use this what does import route

distribution does is it automatically

downloads all those routes that it

learns and um you then create a route

table using that

uh

so when you create it

it would let you choose an import route

distribution so you will just enable

import or distribution and use of import

and then say the changes now if you

click on get all roads

all those routes would appear

automatically

so this is my on-prem route and this is

my workload server in which I've

deployed a web server behind a load

balancer

excuse me so

um so that's the drg route tables that

I've created and after creating the dr0

out tables I had to go and attach them

to the

vcns so the spoke vcns are going to have

route table number two if you click on

the vcn attachment click on edit

Advanced options you will it will give

you an option to choose the route table

so you go change the route table here

the one that you created do that for all

these attachments and also for the ipsec

attachment

click open the attachment click on edit

choose the drg route table and then we

are good

so you should be able so now so you've

created those route tables attach it to

the to associated with the attachments

and any traffic that's going to come in

hit the drg will use those respective

route tables and Route those traffic to

the destination

and now let's go to the hub Vision

routing configuration let me show you

around

what routes were required in the hub vcn

and in the hub vcn you've got private

and public subnet so you're going to

need two route tables one for private

and one for public

in the public route table you will have

a default route pointing to the internet

gateway

and the internal vcn will be pointed to

the firewall

whereas in the firewall is deployed in

the private subnet so the private

routing table will have the default

route pointing to the nand Gateway and

the on-prem and internal network will be

pointed to the dynamic routing gateways

and if you go to uh the drg transit

routing table in which will be used to

Route the traffic

to the firewall incoming traffic from

the drg to the firewall you had

a default route pointing uh to your

firewall and you also add another uh

specific route for your 100 to 160.128

which is your public subnet so

you may ask why why would I write

another route on when I already have a

default route pointing to the firewall

which is a valid question but then when

an incoming traffic hits the drg

incoming traffic from the drg hits the

transit

or the bcn attachment the vcn already

knows that Monster energy 16

0.128 uh it's it's part of an implicit

route table that is already available

with the oci so you writing a 0.0.0

route finding the firewall does not mean

that gets overwritten so it would still

be able to send the traffic bypassing

the firewall so it is it becomes

important for you to

um

write that route

[Music]

um

also pointing to the firewall so that

you kind of override the implicit

routing that oci does so this is a

common

um mistake or people miss doing this and

they say that routing is not working so

so this is an important aspect so don't

forget don't forget to get this routing

also added in your route table so after

that is done

um

then the remaining is the not transit

route table this is for the reverse

traffic from other spoke vcns to go back

to the firewall

you use this and then associate it with

the NAT gateways

so you will see that routing table

Associated here

and the drg attachment has the drg

transit routing table associated

how do I associate It Is by clicking the

clicking on edit

the vcn attachment click on edit so go

to Advanced options we have vcn route

table

second tab you'd be able to see

that you we've Associated the drg

transit routing table like like this

here

and you can also do the same

for the NAD gateways

um so if you click three and click you

can associate a different route table

that you've created so all these dot

tables are created and Associated to

make sure this uh the inspection Works

in all four directions

and let me also show you the load

balancer that I've created

the load balance uh is deployed in the

public subnet

and has the back end

100 to 16 159 being the configured as

the back end so uh if I use the public

IP address

and try to do browse that website from

my home

there you go the page opens up this is

my web server running on the Oracle

Cloud infrastructure I'm able to access

this traffic I'm in the sub web

application which is deployed inside the

loaded bands behind the the workload vcn

and I can also

um so this is the the web server

which is behind

the firewall in a spoke vcn and I'm able

to also go out to the internet using

this all of this traffic are being

inspected by the firewall

and I can also reach to an on-prem

server

which is

10.0.1.91 which is deployed which is

behind my VPN ipsec VPN so

so let's say you have a use case where

your on-prem server which is this guy

he's trying to access your application

and OCA

and I'm just trying to do a curl so that

to show you that I'm able to browse the

website and I'm able to see the same

content that I'm seeing from the

internet

with the private IP address but then

here over the private arbitrus I'm able

to access the website just fine so the

East West access is also working both

ways

so and now how do I you can also do a

trace path

you can do a trace Pro path

to see if the traffic is going through

the firewall

so I'm trying to do a trace path from

yeah see look at this so this is going

to the

I'm just going to the firewall and that

gets getting routed to the drg and then

obviously the the liver span VPN server

that I have and the other tenancy does

not have IC and pay allowed so that's

why it's not completing but then you

should be able to validate with the

trace path if the traffic is going

through the firewall that's one good way

of checking it

and the other way the most reliable way

of checking it is going through the logs

so I go to identity security firewall

policies firewalls

and then

let's go check the logs

so the log should up you and will should

tell you what are the

traffic is going through and if you want

it to be more readable you go to explore

with Log search

and

you can filter it or or

arrange it in with

this way source

destination

port

in action

so you should see all the traffic with

different between different Source

destination destination port and action

here yeah that's how you validate if

your configuration is working

thank you so much I hope it helps