Azure VNet Subnet Design + Network Security (NSG + UDR Basics)

As an upcoming DevOps engineer still learning the trade through Hagital Cloud Academy, I was assigned a group project by our instructor. I have concluded the project and want to use this opportunity to showcase what i built.

Firstly, let me show you what the project entailed.

Group five Fintech project:

Azure VNet Subnet Design + Network Security (NSG + UDR Basics)

A Nigerian fintech company wants to improve the structure of its application within a virtual network. They need proper segmentation between frontend and backend systems, with controlled traffic flow for security.

Tasks

Create a Virtual Network (VNet) in Azure with these subnets: Frontend-subnet (for web servers) Backend-subnet (for application servers) Database-subnet (no public access allowed)

Deploy resources:

1 Linux VM in Frontend-subnet

1 Linux VM in Backend-subnet

Configure Network Security Groups (NSGs)

Allow HTTP/HTTPS traffic only to Frontend VM.

Allow Backend VM to accept traffic only from Frontend subnet.

Block all direct access from the Internet to the backend subnet.

Test connectivity:

Frontend VM should be reachable via public IP Backend

VM should NOT be publicly reachable

Frontend VM should be able to ping Backend VM

Configure a simple User Defined Route (UDR): Ensure traffic from Frontend → Backend follows internal routing (no internet bypass)

Document your setup with Screenshots of the following:

Subnet creation

NSG rules

Successful/failed ping tests

VM connectivity tests

When Mr Chris gave us the assignment, I won't lie, I was a bit scared and was like whoaaahhhh. However, I later calmed myself, reread the project instructions, understood them, and got to work.

I'll explain how I did the project with screenshots so anyone who wants to follow my lead can recreate it and get the same result, even if you don't know much about Microsoft Azure.

The solution

Step 1. To create the architecture shown above, start by creating your resource group. Use the search bar to search for resource group and create one. The one I created was g5-fintech.

Step 2. Create a virtual network for all your assets. Again, use the search bar to search for VNet, then select virtual networks.

Choose your subscription, select the resource group you created for the project, give your VNet a suitable name, choose a region and proceed to the next page. Skip the security page and move to the address space area.

Delete the default subnet created for you, since you'll create your own later. After deleting, review and create your Vnet.

After creating your Vnet, go to the resource.

In the far-left corner, click on subnets. Once you click it, a pop-up will appear that you need to fill.

The areas you need to touch are the name area where you'll add your subnet name, like I added frontend-subnet. Then the starting address should be 10.0.1.0, not 10.0.0.0, because you don't want the subnet IP address to overlap with the VNet at 10.0.0.0.

Once you're done, you click the add button at the bottom.

Repeat the process for the remaining two subnets. Ensure the backend IP doesn't overlap with the frontend, and the database IP doesn't overlap with the backend IP.

From the image above, I gave my backend a starting address of 10.0.2.0 and the database 10.0.3.0, so everything appears different.

Step 3. Time to create virtual machines. Use the search bar to search for virtual machines.

Choose your subscription, resource group, give your virtual machine (VM) a name, and choose a region (same region as your subnets). Availability options and security type should match my images.

Your chosen image should be Ubuntu Server 24.04 LTS - X64 Gen2, with a x64 VM architecture. The VM size should be standard B1 or B2ts, which are among the cheapest.

We're using SSH public key authentication. Choose your username and ensure you allow selected ports in the public inbound ports area.

Once you're done, click on the next button twice to get to networking.

Under virtual network, select the vnet you created. Under subnet, because this VM is for your frontend, select the frontend subnet you already created. The frontend-vm-ip will be created automatically for you.

Review, create, download the key and go to resources.

On the resources page for your frontend-vm, in the right-hand corner, you'll find your VM's public IP address. Take note of it because it will come in handy.

Time to create your backend-vm. This backend VM will be private, so there will be some slight changes.

The public inbound port should be set to none because we don't want to allow SSH access. Click on next twice to go to networking

Public IP beneath the subnet should be set to none, since we don't want this backend VM to be public. Therefore, no public IP. Public inbound ports should also be set to none.

Review, create, and download the public key, then go to the resource.

Scroll to the bottom to find the private IP of the private backend VM. Note it down because you will need it later.

Here are the two vm's running. One is public with a visible IP address, while the other is a private VM.

Step 4. Create a network security group (NSG)

Use the search bar to search for "NSG" and select "network security groups".

Click the front-end NSG that was automatically created for you.

You'll see some rules already in place. However, look at the far-left corner; you'll find inbound security rules. We need to add some of our rules. Click add and you'll get a pop-up.

Source any, which means traffic can come into this VM from any source. The * in port ranges also means traffic from any port. Same with destination (traffic from anywhere can come in).

Service is HTTP, which is served via port 80 (destination port ranges), which is a sign that the VM is open to the internet on the TCP protocol.

Action allow, priority set to 100, name set to AllowHttp, then click the add button.

New rule below.

Repeat the same process for HTTPS traffic. So the difference is the service, where you'll select HTTPS and port 443, which is the port for HTTPS communication.

You can set a priority of 310, as I did, or another number. According to Azure's system, NSGs are checked in order from lowest to highest priority. Which means the allow HTTP rule will be checked before 310. You can also decide to use 110.

The important thing is for both rules not to have the same priority number or for your important rule to have a high priority number like 4000, which means it will be looked at last.

This rule allows HTTPS traffic into the VM.

In this new rule, you're saying that any other traffic (apart from HTTP and HTTPS) from any source, port range, destination, and destination port range, with any protocol, should be denied access to the frontend VM.

Here, the priority was set to 4096, which is the final stop, because the priority number range you can choose from is between 100 and 4096. Any rule with the 4096 priority is the last thing NSG will check.

Meaning that after allowing HTTP and HTTPS traffic, it will check for any other traffic that tries to come in and deny their access.

Here are all the inbound security rules we have set on our frontend NSG. We're done with the frontend nsg.

Let's set up the backend NSG. This time, click on the backend NSG, then click on the inbound rules.

This is a new rule. Here, we want to allow the Backend VM to accept traffic only from the Frontend subnet. To do this, you will set the source (where traffic is coming from) to IP addresses, then paste the public IP of the Frontend VM into the source IP space.

Use the image above as a guide.

This new rule stipulates that every other traffic on the internet, apart from the specific frontend IP we gave access to, should be denied access to our backend VM.

These are the entire rules we set regarding our backend inbound security.

Using the image above as a reference, we need to create our database nsg. Click the create button

These are the inbound rules we set for our database. The database should receive traffic only from the backend subnet (10.0.2.0/24) on port 5432. While the second rule denies all other forms of traffic.

Step 5. Time to test if the Frontend VM is reachable via public IP

You just have to SSH into your frontend VM using your IP address.

This indicates that the frontend VM receives HTTP/HTTPS traffic.

Step 5A. Confirm whether the Frontend VM can ping the Backend VM.

You just have to SSH into your frontend VM and ping the backend VM's private IP to get your confirmation.

Step 6. Configure a simple User-Defined Route (UDR): Ensure traffic from Frontend → Backend uses internal routing (no internet bypass).

Search for Route tables via the search bar.

What we're trying to achieve here is for the frontend and the backend to communicate over a private network rather than the internet.

After associating the VNet and backend subnet with the route, SSH into your VM as shown in the image below and run the ip route command.

No external/public IP appears anywhere in the routing table. This confirms traffic is staying internal.

Bonus

Let's create a PostgreSQL database where our backend VM will store data, even though it wasn't mentioned in the project.

Next, you'll go to your private DNS zones to retrieve the database IP address.

The 10.0.3.4 I highlighted is the database IP address, and you'll need it to confirm whether the backend VM and the database are communicating.

To get this done, you have to do the following on your local machine. Copy your backend key into your backend VM as I did in the image below.

Run the command shown in the image below, and replace my frontend key with yours, my backend key with yours, and add your username and frontend IP address.

Next, you SSH into your frontend VM like i did below.

Once you log in, change the modification on the backend VM key (chmod 400 key) before you SSH into it, as I did below.

Once you're inside the backend VM, run the nc -zv 10.0.3.4 (database IP) 5432 (this is the port which allows the database and backend VM to communicate via the TCP protocol) command as I did below.

You'll see that the connection succeeded. Meaning that our database and backend VM can communicate.

This is also to confirm that the backend VM isn't open to internet traffic.

Conclusion

We have successfully completed the project we set out to accomplish. So if you want to recreate what i did, you just need to follow my footsteps via the images i shared.

Enjoy