Day-7 | Azure Networking Demo | Azure VNet, Firewall, NSG and Bastion

1. Why Do We Need This? (Problem Statement & Status Quo)

Throughout the earlier modules of the Azure Zero to Hero series, fundamental and advanced theoretical concepts of Azure networking were established—including Virtual Networks (VNets), subnets, route tables, Network Security Groups (NSGs), and Azure Firewalls. However, moving straight into interview questions without practical execution leaves a vital gap in engineering intuition.

• The Gap: Theoretical understanding alone fails to clarify how traffic flows across a multi-layered cloud topology (from an external user, through a centralized perimeter firewall, down to a hardened private subnet running a web server).
• The Solution: Swap the planned interview session with a complete, end-to-end Hands-On Demonstration. By building an isolated architecture from scratch, learners experience firsthand how packets are filtered, translated via Network Address Translation (NAT), and securely managed via Bastion hosts.

2. Core Mental Model & Architecture Analogy

To visualize this cloud environment without relying on clumsy wireframes, think of an enterprise office building:

• The Perimeter Guard (Azure Firewall): Acts as the strict gatekeeper facing the public internet. External users cannot talk directly to internal servers; they must present themselves at the firewall's designated public IP and port.
• The Private Server Room (Private Subnet & VM): The virtual machine holding the application code possesses only a private IP address. It is completely invisible and unreachable directly from the public internet.
• The Employee Elevator (Azure Bastion): Authorized internal engineers (developers/sysadmins) who need to SSH into private machines for maintenance cannot jump straight through the firewall. Instead, they use a managed, secure proxy service (Bastion) that handles authentication and relays terminal sessions safely.

3. Step-by-Step Architectural Blueprint

Before executing the configuration, the target topology must be fully mapped out. The deployment bundles all resources under a single dedicated Resource Group to ensure clean lifecycle management and easy tear-down.

4. Step 1: Resource Group & Virtual Network Provisioning

Every Azure deployment requires an organizational container (Resource Group) and an isolated private network space (VNet) configured with proper CIDR block sizing.

Creating the Resource Group

1. Navigate to Resource Groups in the Azure Portal.
2. Click Create, select your subscription, and name the group abishek.
3. Choose a region close to your location (e.g., East US) and finalize creation.

Creating the Virtual Network & Subnets

1. Search for and select Virtual Networks, then click Create.
2. Assign it to the abishek Resource Group and name the VNet abishek.
3. Configure the address space using the default IPv4 CIDR block: 10.0.0.0/16 (which provides 16,384 assignable IP addresses).
4. Enable Built-in Security Services:
   • Azure Bastion: Enable and provision a standard public IP address.
   • Azure Firewall: Enable, select standard tier, and create a new firewall policy named abishek-firewall-policy.
5. Review the auto-generated subnets: Azure automatically carves out dedicated system subnets (AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet) alongside a default user subnet for application workloads.

5. Step 2: Deploying the Private Virtual Machine

To simulate a realistic production tier, the web server must reside in a private subnet without a public IP address.

1. Navigate to Virtual Machines and click Create -> Azure Virtual Machine.
2. Basics Configuration:
   • Resource Group: abishek
   • Virtual Machine Name: nginx-web-1
   • Region: Match the VNet region (East US)
   • Image: Ubuntu Server 22.04 LTS (Eligible for free tier services)
   • Authentication Type: SSH Public Key (generate and download the .pem private key file).
3. Networking Configuration:
   • Virtual Network: Select abishek VNet.
   • Subnet: Select the default web application subnet (not the firewall or bastion subnets).
   • Public IP: Select None (ensuring the VM gets only a private IP address).
   • NIC Network Security Group (NSG): Keep inbound port 22 open temporarily for initial administrative setup via Bastion.
4. Click Review + create and download the private key file.

Note on Cloud-Init vs. User Data:

• Custom Data: Scripts executed once during the initial creation phase of the VM. Ideal for installing packages and bootstrapping web servers immediately upon boot (heavily utilized in Auto-Scaling Groups).
• User Data: Files passed to the VM that persist throughout its lifetime, retrievable across restarts without re-executing scripts on boot.

6. Step 3: Installing Nginx and Hosting a Static HTML Page

Because the VM lacks a public IP, direct SSH access from a local terminal is impossible. Azure Bastion bridges this gap securely.

Connecting via Azure Bastion

1. In the Azure Portal, navigate to your virtual machine nginx-web-1.
2. Scroll down the left menu to Operations and click Bastion.
3. Select SSH Private Key from Local File, upload your downloaded .pem key, enter the username (azure user), and click Connect.

Installing Nginx and Deploying Content

Once inside the interactive browser-based shell, execute the following commands to install Nginx and deploy a static webpage:

# Switch to root user
sudo su -

# Update local APT package repositories
apt update

# Install Nginx web server
apt install nginx -y

# Navigate to the default Nginx web root directory
cd /var/www/html

# Create and write a custom index.html file
cat << 'EOF' > index.html
<h1>I learned Azure networking today</h1>
EOF

# Restart Nginx service to apply changes
systemctl restart nginx

Local Verification Test

Verify that Nginx is running correctly inside the private instance by issuing a local loopback curl request:

curl http://localhost:80

Expected Output: <h1>I learned Azure networking today</h1>

7. Step 4: Configuring Azure Firewall & DNAT Rules

With Nginx running privately, external users cannot access it directly. An incoming request must hit the Azure Firewall's public IP address, which then translates and forwards the traffic inward using Destination Network Address Translation (DNAT).

Creating a DNAT Rule Collection

1. Search for and open your Azure Firewall instance (abishek), then click on Firewall Policy.
2. Under Settings on the left menu, select NAT rules (Network Address Translation rules).
3. Click Add rule collection:
   • Name: firewall-nginx-rule
   • Rule collection type: DNAT
   • Priority: 100 (Lower numbers execute with higher priority; valid range: 100 to 65,355).
4. Click Add to create the collection, then add a specific rule inside it:
   • Rule Name: engine-rule
   • Source Type: IP Address
   • Source IP: Enter your personal laptop's public IP address (found by searching "what is my IP" on a browser). Restricting this prevents unauthorized public traffic.
   • Protocol: TCP
   • Destination Ports: 4000 (The external listening port exposed on the firewall).
   • Destination IP: The Public IP address of the Azure Firewall.
   • Translated Address: The Private IP address of your nginx-web-1 virtual machine.
   • Translated Port: 80 (The internal port where Nginx is listening).
5. Click Save and wait for the firewall policy update to deploy across Azure.

8. Step 5: End-to-End Flow Walkthrough & Testing

With the DNAT rule active, test the complete workflow from an external web browser.

Traffic Flow Mechanics

Your Local Laptop (Public IP: 203.0.113.50)
   |
   | sends HTTP GET request to http://<Firewall-Public-IP>:4000
   v
Azure Firewall Public IP (Port 4000)
   |
   | evaluates DNAT Rule (Matches source IP & destination port 4000)
   v
Azure Firewall translates destination to Private IP (10.0.0.4:80)
   |
   | forwards packet across VNet to Web Application Subnet
   v
Nginx Web Server inside Private VM (nginx-web-1)
   |
   | processes request and returns "I learned Azure networking today"
   v
Azure Firewall relays response back to Your Local Laptop

Verification in Browser

Open any web browser outside the private network and navigate to:

http://<AZURE_FIREWALL_PUBLIC_IP>:4000

Result: The browser successfully renders: "I learned Azure networking today".

9. Industry Reality, Debugging & Cleanup

Production Pitfalls & Debugging Mindset

• Asymmetric Routing & NSG Blocks: If web traffic fails to load, verify that Network Security Groups (NSGs) attached to the subnet or NIC allow inbound traffic on port 80 or that the DNAT translated port matches.
• Firewall Propagation Delays: Azure Firewall rule updates can take several minutes to propagate globally across underlying backend clusters. Patience is required after clicking save.
• IP Restrictions: Hardcoding personal IP addresses in firewall rules works for testing, but production environments require robust security groups, Web Application Firewalls (WAF), or VPN gateways.

Mandatory Resource Cleanup

To prevent unexpected cloud billing charges on free trial or pay-as-you-go subscriptions, delete the entire Resource Group once testing is complete:

1. Navigate to Resource Groups -> select abishek.
2. Click Delete resource group.
3. Type the resource group name to confirm and click Delete. All associated VNets, firewalls, subnets, and VMs will be purged automatically.

10. Summary and Key Takeaways

• Resource Group Organization: Bundling all networking, compute, and security resources under a single Resource Group ensures clean management and effortless tear-down.
• VNet and Subnet Sizing: CIDR blocks (e.g., 10.0.0.0/16) determine the total pool of available IP addresses within a virtual network.
• Dedicated System Subnets: Azure automatically provisions dedicated subnets for core infrastructure components like Azure Firewall (AzureFirewallSubnet) and Azure Bastion (AzureBastionSubnet).
• Zero Public IP Workloads: Production-grade virtual machines are placed in private subnets with only private IP addresses, shielding them from direct internet exposure.
• Secure Management via Bastion: Azure Bastion acts as a secure, managed proxy, eliminating the need to expose SSH (Port 22) directly to the public internet while providing complete audit logging.
• Perimeter Defense with Azure Firewall: Centralized firewalls inspect inbound traffic, filtering out malicious or unauthorized requests before they ever reach internal subnets.
• Destination Network Address Translation (DNAT): DNAT rules map an external public IP and custom port (e.g., Port 4000) to an internal private IP and application port (e.g., Port 80).
• Strict Source IP Filtering: Restricting firewall policies to trusted administrative or user IP addresses prevents unauthorized public scanning and attacks.