DEV Community: Abhishek Kadlii

Shifting to IaC: Writing the 183-Line Central Firewall Engine in Bicep When the Portal Hits a Wall | Day 9 & 10

Abhishek Kadlii — Wed, 27 May 2026 06:45:25 +0000

In my Day 8 lab, we successfully executed a classic data-plane traffic hijack. By forging a User Defined Route (UDR) for 0.0.0.0/0 on our Spoke network (Sec_Spoke_SEA_VNet), we successfully ripped traffic away from its default internet path and funneled it straight into a virtual appliance placeholder IP at 10.0.1.4 inside our Hub. As my terminal verification tests proved, outbound internet transit hit a hard 100% packet hole.

For Days 9 & 10, the mission was clear: replace that placeholder IP with a live, stateful Azure Native Firewall (Basic SKU) to intercept, inspect, and enforce rule collections on those hijacked packets.

Then, reality hit. Mid-sprint, my active 30-day promotional credit pool hit its expiration safety boundary. My portal dashboard flagged a paused state with an absolute balance of ₹0.00.

In a production enterprise environment, infrastructure blockers like this happen all the time. Budgets freeze, subscription terms shift, or portal access gets locked down. As a Network Security Engineer transitioning into DevSecOps, you don’t stop the roadmap; you change your delivery mechanism. Instead of manually clicking buttons inside the billing-active Azure Portal GUI, I pivoted immediately. I abstracted our entire physical network, routing states, peering hooks, and stateful security rules into a single, declarative Infrastructure-as-Code (IaC) deployment blueprint using Azure Bicep.

By moving from the GUI to local code, I built and validated the complete security engine architecture entirely for free inside Visual Studio Code with zero out-of-pocket financial risk.

The Network Logic: What Are We Architecting?

Before looking at the codebase, let’s map out exactly how data packets traverse this topology during runtime:

[ Private Spoke Subnet: 10.1.1.0/24 ]
│
▼ (User Defined Route: 0.0.0.0/0 ➔ Next Hop: 10.0.2.4)
[ AzureFirewallSubnet: 10.0.2.0/24 ] ──► Stateful Inspection Engine
│
├──► Matched Rule (UDP Port 53) ──► Allowed ──► Source NAT (SNAT) ➔ Internet
└──► Unmatched Rule (TCP 80/443) ──► Dropped ➔ Implicit Deny Posture

If you are coming from a traditional Network Security TAC background (like managing Palo Alto Prisma Access service connections or security zones), this setup mimics a centralized Next-Generation Firewall (NGFW) deployment.

The private Spoke VM does not have a public interface or an internet gateway. When it tries to talk to the outside world, our UDR acts as a mandatory signpost forcing the packet across the VNet Peering highway into the Hub's AzureFirewallSubnet at coordinate 10.0.2.4. The firewall then parses the packet from Layer 3 up to Layer 7, cross-references it with our rule policy, and decides whether to let it transit or drop it on the floor.

Complete Enterprise-Grade Bicep Security Blueprint

Below is the complete, unedited 183-line Bicep file that builds the entire baseline network fabric and trains the central firewall's inspection engine:

param location string = 'southeastasia'

// ===================================================================
// 1. CENTRAL ROUTE TABLE (THE TRAFFIC HIJACK SIGNPOST)
// ===================================================================
resource spokeRouteTable 'Microsoft.Network/routeTables@2023-09-01' = {
  name: 'Spoke_To_Hub_RT'
  location: location
  properties: {
    routes: [
      {
        name: 'Route_To_Hub'
        properties: {
          addressPrefix: '0.0.0.0/0'         // Intercepts all outbound internet traffic
          nextHopType: 'VirtualAppliance'     // Overrides default system provider routing
          nextHopIpAddress: '10.0.2.4'       // Core internal private IP of our Azure Firewall
        }
      }
    ]
  }
}

// ===================================================================
// 2. CORE HUB NETWORK (MANAGEMENT, FIREWALL, AND GATEWAY SEGMENTS)
// ===================================================================
resource hubVnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
  name: 'Sec_Hub_SEA_VNet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [ '10.0.0.0/16' ]
    }
    subnets: [
      {
        name: 'Management_SEA_Subnet'
        properties: {
          addressPrefix: '10.0.1.0/24'
        }
      }
      {
        name: 'AzureFirewallSubnet'         // Mandated structural name for native engine binding
        properties: {
          addressPrefix: '10.0.2.0/24'
        }
      }
      {
        name: 'GatewaySubnet'               // Reserved segment for future VPN/ExpressRoute Gateways
        properties: {
          addressPrefix: '10.0.3.0/24'
        }
      }
    ]
  }
}

// ===================================================================
// 3. SPOKE PRODUCTION NETWORK (BOUND TO TRAFFIC HIJACK UDR)
// ===================================================================
resource spokeVnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
  name: 'Sec_Spoke_SEA_VNet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [ '10.1.0.0/16' ]
    }
    subnets: [
      {
        name: 'App_Prod_Subnet'
        properties: {
          addressPrefix: '10.1.1.0/24'
          routeTable: {
            id: spokeRouteTable.id           // Associates the traffic-hijacking UDR table
          }
        }
      }
    ]
  }
}

// ===================================================================
// 4. BIDIRECTIONAL NETWORK PEERING: HUB TO SPOKE
// ===================================================================
resource hubToSpokePeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
  parent: hubVnet
  name: 'Hub_To_Spoke_Peer'
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: false
    remoteVirtualNetwork: {
      id: spokeVnet.id
    }
  }
}

// ===================================================================
// 5. BIDIRECTIONAL NETWORK PEERING: SPOKE TO HUB
// ===================================================================
resource spokeToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
  parent: spokeVnet
  name: 'Spoke_To_Hub_Peer'
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: false
    remoteVirtualNetwork: {
      id: hubVnet.id
    }
  }
}

// ===================================================================
// 6. CENTRAL FIREWALL PUBLIC EGRESS INTERFACE (PUBLIC IP)
// ===================================================================
resource firewallPublicIP 'Microsoft.Network/publicIPAddresses@2023-09-01' = {
  name: 'Sec_Hub_FW_PIP'
  location: location
  sku: {
    name: 'Standard'
  }
  properties: {
    publicIPAllocationMethod: 'Static'
  }
}

// ===================================================================
// 7. CENTRAL FIREWALL POLICY CONTAINER (THE SECURITY RULEBOOK)
// ===================================================================
resource firewallPolicy 'Microsoft.Network/firewallPolicies@2023-09-01' = {
  name: 'Hub_Central_FW_Policy'
  location: location
  properties: {
    sku: {
      tier: 'Basic'
    }
  }
}

// ===================================================================
// 8. CENTRAL NATIVE FIREWALL ENGINE PROVISIONING
// ===================================================================
resource azureFirewall 'Microsoft.Network/azureFirewalls@2023-09-01' = {
  name: 'Central-Security-Engine'
  location: location
  properties: {
    sku: {
      name: 'AZFW_VNet'
      tier: 'Basic'
    }
    firewallPolicy: {
      id: firewallPolicy.id
    }
    ipConfigurations: [
      {
        name: 'fw-ip-config'
        properties: {
          publicIPAddress: {
            id: firewallPublicIP.id
          }
          subnet: {
            id: '${hubVnet.id}/subnets/AzureFirewallSubnet' // Drops interface into reserved subnet
          }
        }
      }
    ]
  }
}

// ===================================================================
// 9. STATEFUL RULE COLLECTION GROUP (LAYER 4 NETWORK FILTER RULES)
// ===================================================================
resource ruleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2023-09-01' = {
  parent: firewallPolicy
  name: 'Outbound_Traffic_RCG'
  properties: {
    priority: 1000
    ruleCollections: [
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'Allow_Core_Network'
        priority: 1100
        action: {
          type: 'Allow'
        }
        rules: [
          {
            ruleType: 'NetworkRule'
            name: 'Allow_DNS'
            ipProtocols: [
              'UDP'
            ]
            sourceAddresses: [
              '10.1.1.0/24'                  // Permits packets originating from Spoke Prod Subnet
            ]
            destinationAddresses: [
              '8.8.8.8'                      // Target: Google Primary DNS
              '8.8.4.4'                      // Target: Google Secondary DNS
            ]
            destinationPorts: [
              '53'                           // Limits traffic strictly to DNS query protocols
            ]
          }
        ]
      }
    ]
  }
}

Deep-Dive: Code Logic & Packet Inspection Mechanics

When discussing this topology in enterprise cloud security interviews, you must be able to trace how this specific code handles packet state:

The UDR Override Mechanics (Resource 1): By declaring a custom route for 0.0.0.0/0 with a nextHopType of VirtualAppliance, we explicitly override default systemic routing. The infrastructure forces the next-hop IP mapping to match 10.0.2.4, which is the exact internal interface of our upcoming firewall engine.
The API Subnet Constraint (Resource 2): The Azure resource provider imposes a strict naming policy. A native firewall cannot attach to an arbitrarily named subnet profile. It searches exclusively for a subnet token string labeled AzureFirewallSubnet. We carved out a dedicated /24 block (10.0.2.0/24) to handle the private clustering interfaces of the engine.
Stateful Layer 4 Filtering (Resource 9): This section defines our firewall policy rulebook. The engine operates on an Implicit Deny architecture—if a packet parameter profile does not explicitly match an allowed rule entry, it drops dead at the gate.
- The Allowed Execution Flow: A workload inside our Spoke network (10.1.1.0/24) generates a standard domain name lookup request toward external DNS resolver 8.8.8.8 over UDP Port 53. The firewall parses the packet headers, finds an exact match inside our Allow_DNS rule matrix, permits the transit, and executes Source NAT (SNAT) using our public IP (Sec_Hub_FW_PIP) to preserve private topology boundaries.
- The Implicit Deny Flow: A background process or a user inside that same Spoke network attempts to establish an outbound web session over HTTP (Port 80) or HTTPS (Port 443). The packet hit the firewall interface. The stateful inspector reviews the policy definitions, encounters an absolute absence of any rule mapping ports 80/443, and silently drops the connection instantly.

Code Logic & Traffic Processing Deep-Dive

To demonstrate absolute operational mastery during cloud engineering interviews, we must break down how this file behaves during active network runtime:

Resource 1 (spokeRouteTable): This object overrides default routing behavior. By creating a custom route entry for 0.0.0.0/0 (all internet traffic) with a nextHopType parameter explicitly declared as VirtualAppliance, we disrupt standard network isolation. Any server on this subnet that tries to reach an external resource is automatically pointed directly to 10.0.2.4.
Resource 2 (hubVnet) Subnet Naming Constraint: The Azure API dictates that a native firewall appliance cannot bind to an arbitrary subnet profile. It requires an exact structural string identifier named AzureFirewallSubnet. We carved out a dedicated /24 block (10.0.2.0/24) to handle the clustering interfaces of the underlying infrastructure.
Resource 9 (ruleCollectionGroup) Layer 4 Parsing: This is where our packet filtering criteria are established. The firewall runs a stateful inspection engine, matching source vectors against destination coordinates.
- The Evaluated Match: When a compute host inside our Spoke network (10.1.1.0/24) generates an upstream lookup request toward 8.8.8.8 on UDP Port 53, the firewall validates an exact parameter match in its rule collection and permits egress traffic while executing Source NAT (SNAT).
- The Implicit Deny Enforcement: If an active process on that same workload attempts to create an outbound HTTP web session on port 80 or an HTTPS connection on port 443, the data packet hits the firewall interface. The engine reviews the policy rules, encounters a total absence of any rule covering ports 80/443, and instantly drops the connection with zero response back to the client.

Compilation Verification & Local Quality Control

To ensure the technical validity, reference bindings, and compliance of this 183-line enterprise design without launching live, billing-active resources, I leveraged the built-in Microsoft Bicep language compilation workspace inside Visual Studio Code.

The compiler ran an extensive static validation analysis across our declared topography configurations, network peering structures, and rule groups, verifying a completely flawless design layout:

The local IDE output officially confirmed: No problems have been detected in the workspace.

The Live Traffic Intercept: Bringing the Cloud Fortress to Life (Day 8)

Abhishek Kadlii — Mon, 25 May 2026 06:49:22 +0000

As I was curious after reading and implementing the User-Defined Routing (UDR) and subnet-slicing concepts previously, I couldn't wait to test this out under live traffic conditions. Theory is fine on paper, but as an infrastructure engineer, I don't truly trust a network design until I break it, throw live packets at it, and look at the raw terminal logs.

Tonight, I stepped completely out of the textbooks and moved assets onto the cloud field. I deployed two live virtual servers inside my Singapore network sandbox, faced down strict regional quota walls, bypassed local internet restrictions, and operationally proved that my traffic hijacking detour rule works perfectly under real production conditions.

Here is the step-by-step engineering log of how I did it, the real-world troubleshooting steps I took, and the underlying mechanics explained so simply that anyone can understand it.

🏛️The Day 8 Deployment Strategy: Setting the Field

To safely test our custom detour signpost without opening our network to the public internet, I had to deploy two distinct virtual machines into my sandbox environment. To keep my billing running at exactly ₹0/hour, I utilized Microsoft's newer, high-performance AMD free-tier eligible engine size (Standard_B2ats_v2).

💡The Analogy: The Front Security Lobby vs. The Locked Back Vault

Hub-Mgmt-VM (The Front Lobby Desk): This machine sits right inside the public entryway of our network (Management_SEA_Subnet). It is given an official, fixed public street address (Static Public IP) so that administrators can find it and log into it from the outside world.
Spoke-App-VM (The Hidden Back Vault): This machine sits deep inside the isolated production floor (App_Prod_Subnet) within the Spoke VNet. To maintain strict security, this machine is given absolutely no public front door. It has no public IP address, making it completely invisible to the internet and dependent on our hub-and-spoke bridge to talk to the world.

🛠️The Step-by-Step Command-Line Execution

Instead of clicking through the graphics of the Azure Portal GUI, I typed the deployment scripts manually into the Azure Cloud Shell to burn the syntax directly into my muscle memory.

Generating the Golden Cryptographic Login Keys

Before spinning up the servers, I generated a pair of secure cryptographic keys. In professional enterprise security, we completely ban weak, guessable text passwords. Instead, we use advanced mathematics to generate an interconnected Private Golden Key (kept in our pocket) and a matching Public Lock (bolted onto the server door).

`bash

ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N ""
`

🚙Code Decoder (Line-by-Line):

ssh-keygen - Starts the security engine tool to manufacture secure digital keys and locks.

-t rsa - Tells the computer to use the industry-standard RSA math algorithm for maximum security.

-b 2048 - Makes the lock 2,048 bits thick, which would take supercomputers billions of years to crack.

-f ~/.ssh/id_rsa - Saves your private golden key as id_rsa and your public lock as id_rsa.pub in a hidden folder.

-N "" - Assigns a blank passphrase so our automation code can read the keys instantly without annoying prompts.

Provisioning the Entryway Jump Box (Hub Machine)

I launched the administrative entryway machine directly inside the Singapore network layout using our AMD free-tier compute profile:

`bash 

az vm create -g Marathahalli_Lab_RG -n Hub-Mgmt-VM --location southeastasia --vnet-name Sec_Hub_SEA_VNet --subnet Management_SEA_Subnet --image Ubuntu2204 --size Standard_B2ats_v2 --admin-username abhishek --ssh-key-values ~/.ssh/id_rsa.pub --public-ip-address-allocation static
`

🚙Code Decoder (Line-by-Line):

az vm create - Orders Azure to go to its physical hardware racks and carve out a new virtual server.

-g Marathahalli_Lab_RG - Groups all the server assets (disks, cards) inside my regional resource folder.

-n Hub-Mgmt-VM - Labels this machine "Hub-Mgmt-VM" so we can easily track it in logs.

--location southeastasia - Bypasses local data center hardware shortages by building the machine straight in Singapore.

--vnet-name Sec_Hub_SEA_VNet - Plugs this machine's network card directly into our central Hub network.

--subnet Management_SEA_Subnet - Drops the machine into the dedicated room reserved for administrative management desks.

--image Ubuntu2204 - Installs a clean, production-ready version of the Ubuntu Linux 22.04 operating system.

--size Standard_B2ats_v2 - Our Zero-Cost Safeguard; chooses a dual-core AMD size that is 100% free-tier eligible.

--admin-username abhishek - Creates the master administrator user profile inside the Linux operating system.

--ssh-key-values ~/.ssh/id_rsa.pub - Takes the public lock file we created earlier and bolts it onto the server login gate.

--public-ip-address-allocation static - Gives this lobby desk a fixed, unchanging internet address so we can always connect from home.

Provisioning the Completely Private Workload (Spoke Machine)

Next, I launched our isolated application instance. Notice the empty quotes at the very end of the script—this explicitly commands Azure to deny this machine a public IP door, keeping it completely private:

`bash

az vm create -g Marathahalli_Lab_RG -n Spoke-App-VM --location southeastasia --vnet-name Sec_Spoke_SEA_VNet --subnet App_Prod_Subnet --image Ubuntu2204 --size Standard_B2ats_v2 --admin-username abhishek --ssh-key-values ~/.ssh/id_rsa.pub --public-ip-address ""
`

🚙Code Decoder (Line-by-Line):

--vnet-name Sec_Spoke_SEA_VNet - Targets our Spoke Network instead of our Hub network.

--subnet App_Prod_Subnet - Drops this machine onto our isolated production factory floor block.

--public-ip-address "" - The Isolation Shield; passing empty quotes forbids Azure from giving this server a public IP address.

📊 The Routing Validation Blueprint: The Live Tests

Once both servers were live, it was time to run our live validation test plan. We need to mathematically and operationally prove that our traffic hijacking detour rules are working.

`    ===================================================================================
    =                         THE LIVE TRAFFIC FLOW DIAGRAM                           =
    ===================================================================================

     [ Home/Cloud Terminal ] --(Passes Through)--> [ Hub Lobby Jump Box: 10.0.1.4 ]



                                                            |
                                                   (VNet Peering Bridge)
                                                            |
                                                            v
     [ Internet: 8.8.8.8 ] <---(100% PACKET LOSS!)--- [ Private Spoke VM: 10.1.1.4 ]
          ^                                                 |



          |                                        (User-Defined Route)
          |                                                 |
          +=========== (HIJACKED TO BLACK HOLE!) ===========+
`

Test 1: The Master Itinerary Manifest Audit (Effective Routes Query)

Before sending a packet, I queried Azure’s network routing engine directly to show me what map the Spoke network interface was using under the hood:

`bash

az network nic show-effective-route-table -g Marathahalli_Lab_RG -n Spoke-App-VMVMNic -o table
`

🚙Code Decoder (Line-by-Line):

az network nic - Targets the virtual Network Interface Card attached to our private Spoke server.

show-effective-route-table - Interrogates Azure's live routing processor to show the active traffic map.

-n Spoke-App-VMVMNic - Targets the specific system name of our Spoke machine's network adapter card.

-o table - Orders the output messy code to cleanly rearrange itself into a beautiful grid with headers.

The result was an absolute architectural victory! The table showed our manual detour route for 0.0.0.0/0 sitting as Active, while Azure’s native, unmonitored default highway to the internet was marked as completely Invalid.

Test 2: The Inner Private Walkway Check (The Peering Bridge Jump)

I used secure SSH Agent Forwarding (ssh -A) to pass through my public entryway lobby box and jump straight onto the internal private IP of our isolated Spoke machine (10.1.1.4).

Once inside the Spoke machine's shell prompt, I executed an internal connectivity check back to the Hub:

`bash

ping -c 4 10.0.1.4
`

🚙Code Decoder (Line-by-Line):

ping - Sends small network test packets to an IP address to see if it is awake.

-c 4 - Sets a count limit flag; stops sending test packets automatically after 4 attempts.

10.0.1.4 - Targets the private internal IP coordinate of our Hub management desk room.

The packets zoomed across the private VNet Peering footbridge instantly, returning a perfect 0% packet loss statistic. This proved that our internal private communication lines were completely healthy and operational.

Test 3: The Black Hole Validation Check (The Ultimate Hijack Proof)

Now, the grand finale. While standing inside the private Spoke machine, I attempted to send a packet out to Google's public internet server:

`bash

ping -c 4 8.8.8.8
`

🚙Code Decoder (Line-by-Line):

8.8.8.8 - Targets a well-known public internet server (Google's Public DNS infrastructure).

The terminal hung for a moment, and then returned exactly 100% packet loss.

In ordinary desktop computing, losing all your packets looks like a failure. But in Cloud Network Security Engineering, this is a spectacular win! It operationally proves that our custom detour sign successfully intercepted the outbound internet packet at the subnet boundary and shoved it down our secure detour corridor. Because we haven't built the actual firewall software engine at that destination endpoint yet, the traffic terminates safely at that empty boundary, confirming that our perimeter isolation is working flawlessly.

💰Financial Discipline Check: Protecting the Trial Runway

By maintaining strict enterprise resource boundaries and leveraging Azure's dual-core AMD free-tier eligible compute allocations, our active sandbox running cost sits at exactly ₹0 per hour. This leaves my full promotional credit balance safe at ~₹18,909 for our upcoming security engine deployments.

🏁Day 8 Wrap-Up

Tonight was a massive architectural leap forward. By typing out raw CLI statements, resolving core quotas, and validating data-plane packet paths step by step, I am locking in the exact hands-on engineering confidence needed for senior enterprise technical panels.

The isolated sandbox field is fully verified. Next up, we deploy our central security engine—the live Azure Native Firewall—to capture that black-holed traffic, inspect it, and safely bridge our secure fortress out to the public web!

🛠️Safe Infrastructure Resting Script

To keep our active billing runway perfectly protected while we draft our notes, I executed a master deallocation script from the Cloud Shell Control Tower to put both machines into deep freeze at zero cost:

`bash

az vm deallocate -g Marathahalli_Lab_RG --ids $(az vm list -g Marathahalli_Lab_RG --query "[].id" -o tsv) --no-wait
`

🚙Code Decoder (Line-by-Line):

az vm deallocate - Commands Azure to stop compute billing entirely by releasing our CPU/RAM chips back into the shared datacenter pool.

$(az vm list ... --query "[].id" -o tsv) - Automatically compiles a neat list of every single virtual machine ID inside our resource group folder.

--no-wait - Forces the command to process silently in the background so we can instantly turn off our computer.

Onward and upward! 🚀🔥

Sunday Double-Header: Erecting Checkpoints and Traffic Hijacking in the Cloud (Day 6 & 7)

Abhishek Kadlii — Mon, 25 May 2026 03:57:40 +0000

Continuing the weekend grind into Sunday night, I shifted my focus to a fundamental truth of enterprise cloud security: never trust a clear road. For the Day 6 and 7 double-header of my career transition blueprint, I decided to take the automatic, unmonitored highways that cloud providers build behind the scenes and completely tear them up. I moved away from simply connecting networks to executing a tactical traffic intercept—focusing on breaking down complex routing math into plain English and carving out clean, industrial-grade security checkpoints without spending a single rupee of my trial credit.

By stepping completely out of the default cloud configuration mindset, I learned how to manually intercept global network traffic patterns and carve out specialized infrastructure zones to prepare my central cloud fortress for future Next-Generation Firewalls.

Here is the technical blueprint of what I built, the real-world engineering constraints I had to solve, and the core routing mechanics broken down so simply that anyone can grasp them.

🏛️Day 6: Setting the Detour (User-Defined Routes)

Up until yesterday, our Hub VNet (the central terminal) and Spoke VNet (the application floor) were connected by a private footbridge called VNet Peering.

💡The Analogy: The Unmonitored Highway vs. The Mandatory Detour

The Default State (System Routes): By default, Azure automatically hands a GPS map to every packet traveling between networks. If a machine inside the Spoke wants to talk to the Hub, the GPS takes it across a direct highway with zero checks, zero gates, and zero security guards. If a hacker breaches an application server, they can walk right into the corporate data center.
The Secured State (User-Defined Routes / UDR): Imagine erecting a massive concrete jersey barrier across that highway and placing a giant Mandatory Detour Sign right at the exit gate of the Spoke subnet. The sign states: "You are no longer allowed to use the direct highway. All traffic leaving this building must exit down a side road and report straight to the Security Guard Post inside the Hub first."

In the cloud world, we call this Traffic Hijacking or packet interception. We are manually ripping up Azure's automatic mapping instructions and overriding them with our own strict routing rules to force data into a secure checkpoint queue.

🛠️The Day 6 Command-Line Blueprint

I cleared my terminal and typed these out manually to build the detour signpost and bolt it down to the application floor:

`bash

# 1. Create the physical wooden signpost frame (Route Table)
az network route-table create -g Marathahalli_Lab_RG -n Spoke_To_Hub_RT -l southeastasia

# 2. Paint the specific "Hijack" instruction onto the signpost
az network route-table route create -g Marathahalli_Lab_RG --route-table-name Spoke_To_Hub_RT -n Intercept_All_Traffic --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.1.4

# 3. Bolt the signpost down to the exit door of our production application road
az network vnet subnet update -g Marathahalli_Lab_RG --vnet-name Sec_Spoke_SEA_VNet -n App_Prod_Subnet --route-table Spoke_To_Hub_RT
`

🔍Deep-Dive Concept: The Rule of the Longest Prefix Match (LPM)

When an individual router handles a packet, it might look at its manual and see multiple matching instructions. Azure resolves this conflict using a strict mathematical law: The most specific rule (the one with the longest bitmask number) ALWAYS wins.

The Interview Trap to Watch Out For:

If a packet leaves our Spoke subnet heading toward an IP address like 10.0.1.5, it matches two rules:

Our custom catch-all UDR: 0.0.0.0/0 (Length: 0)
Azure's default peering route: 10.0.0.0/16 (Length: 16)

Because 16 is a longer, more precise match than 0, Azure will prioritize the default route and completely bypass our custom detour sign! To successfully force local traffic through our future firewall, we must explicitly write a highly specific UDR targeting the 10.0.0.0/16 corporate range directly.

🚀 Day 7: Carving Out the Hub Infrastructure Containment Zones

Once the detour signpost was securely bolted down, I immediately pivoted to Day 7 to prepare the landing pads inside the central Hub network (Sec_Hub_SEA_VNet). Perimeter security engines cannot simply be dropped into regular network subnets alongside administrative tools. They require completely clean, walled-off infrastructure zones.

💡The Analogy: The Airplane Cockpit and the Loading Dock

The Firewall Zone (AzureFirewallSubnet): Think of this like the Cockpit of a commercial airliner. It is a highly restricted room built for exactly one purpose: holding the pilots and the flight controls. Regular passengers are physically banned from walking inside or pulling up a desk there. If they do, they could accidentally hit a control lever and crash the plane.
The Gateway Zone (GatewaySubnet): Think of this like a heavy-duty corporate Loading Dock at the back of the facility. It is fenced off exclusively to receive massive cargo trucks coming from your physical on-premise headquarters or your home network testing labs via secure underground transit tunnels.

🛠️The Day 7 Command-Line Blueprint

I opened up my ledger book and manually carved out these two specialized rooms, making sure to use the exact case-sensitive names strictly required by Azure's background automated logic:

`bash

# 1. Carve out the restricted Cockpit zone on Page 2 of our ledger
az network vnet subnet create -g Marathahalli_Lab_RG --vnet-name Sec_Hub_SEA_VNet -n AzureFirewallSubnet --address-prefixes 10.0.2.0/24

# 2. Carve out the secure Loading Dock zone on Page 3 of our ledger
az network vnet subnet create -g Marathahalli_Lab_RG --vnet-name Sec_Hub_SEA_VNet -n GatewaySubnet --address-prefixes 10.0.3.0/24
`

📊The Evolving Network Topology Map

`       ===================================================================
       =                       MARATHAHALLI_LAB_RG                       =
       ===================================================================

         [ SEC_SPOKE_SEA_VNET ]                  [ SEC_HUB_SEA_VNET ]
             (10.1.0.0/16)                           (10.0.0.0/16)
        +-----------------------+               +-----------------------+



        |  [ App_Prod_Subnet ]  |               | [Management_SEA_Subnet|
        |     10.1.1.0/24       |               |     10.0.1.0/24       |
        +-----------+-----------+               +-----------+-----------+



                    |                                       |
                    | (Outbound Traffic)                    v
                    v                           +-----------------------+
         +---------------------+                |  AzureFirewallSubnet  |



         |  Spoke_To_Hub_RT    |                |  (The Cockpit Zone)   |
         |  (Route Table / UDR)|                |     10.0.2.0/24       |
         |   [0.0.0.0/0]------ | -----\         +-----------------------+
         +---------------------+       |                    |



                                       |                    v
             XXXXXXXXXXXXXXXXX         |         +-----------------------+
             X DEFAULT VNET  X         |         |     GatewaySubnet     |
             X PEERING ROUTE X         |         |  (The Loading Dock)   |
             X  (HIJACKED!)  X         |         |     10.0.3.0/24       |
             XXXXXXXXXXXXXXXXX         |         +-----------------------+



                    |                  |
                    \------------------+----> [ Future Firewall Appliance IP ]
                                                  (Placeholder Location: 10.0.1.4)
`

💰Financial Discipline Check: Protecting the Trial Runway

By adhering to strict enterprise resource management principles, all infrastructure components deployed over this double-header consist purely of logical network definitions, software route tables, and placeholder rule assignments.

Because no heavy virtual machine CPUs, hardware firewalls, or static public IPs were active during this configuration phase, my sandbox running cost sits at exactly ₹0 per hour. This leaves my ~₹18,909 Azure free trial credit pool 100% intact and optimized for our upcoming operational deployment labs.

🏁 Weekend Wrap-Up

This Sunday was a massive structural leap forward. By typing out raw CLI paths manually, mastering IP allocation constraints, and designing a secure perimeter architecture block by block, I am solidifying the muscle memory needed to sit across from senior infrastructure panels with real confidence.

The foundation is ready. Next week, we bring this network fortress to life by launching live testing workloads and configuring the traffic validation rules!

Onward and upward! 🚀🔥

Weekend Grind: Breaking the GUI Habit and Building a Scalable Cloud Fortress in Azure (Day 4 & 5)

Abhishek Kadlii — Sat, 23 May 2026 13:56:49 +0000

It is Saturday night in Bengaluru. While most people are out roaming around the outer ring road or chilling in cafes, I made a conscious choice to sit at my desk, open up my terminal, and grind. I want to be part of that 1% crowd—the professionals who don’t just talk about growth but are genuinely curious, willing to put in the hours, and execute.

Over this intense weekend session, I successfully shattered my dependency on the visual Azure Portal (GUI), moved completely into command-line infrastructure automation, and expanded my secure digital sandbox into an enterprise-grade network topology.

Here is exactly how I built it, the real-world bugs I encountered, and the core architectural concepts broken down so simply that even a non-technical person can understand them.

🛑Day 4: Moving from "Pointing-and-Clicking" to Code

Up until yesterday, I built my cloud infrastructure by manually clicking buttons, menus, and checkboxes inside the Azure Portal web interface.

💡The Analogy: The Hand-Carved Bakery vs. The Smart Machine

The Manual Way (Days 1–3): Imagine baking a cake where you have to manually measure flour, crack every egg, and closely watch the oven dial. This works great for one cake. But what if a major corporate company in Whitefield orders 500 identical cakes for an event? If you try to do it all by hand, it will take forever, you will get exhausted, and some cakes will inevitably taste different due to human error.
The Automation Way (Day 4): Imagine programming a digital, industrial smart-mixer. You type in the exact measurements into a script once, press a button, and the machine perfectly outputs 500 identical cakes with zero errors.

In the cloud world, we call this Infrastructure as Code (IaC). Enterprise networks are massive; we cannot scale by clicking buttons in a browser. We use text-based scripts to deploy identical, flawless environments in seconds.

🛠️ The Simplified Command-Line Blueprint

I opened up the browser-based Azure Cloud Shell and used Azure CLI to fire up my infrastructure using tight, professional shortcut flags:

-g stands for the Resource Group (our logical container).
-n stands for the Name of our resource.
-l stands for the Location (Southeast Asia/Singapore datacenters).

Here are the exact three direct commands that built my perimeter security:

BASH
# 1. Create the Security Guard Shack (Network Security Group)
az network nsg create -g Marathahalli_Lab_RG -n Sec_Hub_SEA_NSG -l southeastasia

# 2. Program the Guard to strictly allow my home ISP IP on Port 22 (SSH)
az network nsg rule create -g Marathahalli_Lab_RG --nsg-name Sec_Hub_SEA_NSG -n Allow_SSH_Home_Only --priority 100 --source-address-prefixes 205.254.163.132 --destination-port-ranges 22

# 3. Create the Private Network and bind it to the Guard Shack instantly
az network vnet create -g Marathahalli_Lab_RG -n Sec_Hub_SEA_VNet -l southeastasia --address-prefixes 10.0.0.0/16 --subnet-name Management_SEA_Subnet --subnet-prefixes 10.0.1.0/24 --nsg Sec_Hub_SEA_NSG

🔍 The Day 4 Troubleshooting Story: Defeating the Location Clash

When I first ran my script, Azure halted everything and threw a glaring red error:

[InvalidResourceLocation] The resource 'Sec_Hub_VNet' already exists in location 'centralindia' in resource group 'Marathahalli_Lab_RG'. A resource with the same name cannot be created in location 'southeastasia'

The Lesson:

During my early labs, I had manually created a network named Sec_Hub_VNet inside India. Today, my script tried to create a new network with the exact same name inside Singapore, but within the same resource group wrapper.

Azure taught me an important architectural lesson here: While a single Resource Group can hold assets from different cities around the world, it absolutely cannot hold two items that share the exact same name.

The Fix: I modified my automation script variables, changing the name to Sec_Hub_SEA_VNet. The script instantly cleared the validation check and deployed flawlessly.

🏛️Deep-Dive Concept: How Firewalls Process Cloud Traffic

As a Network Security Engineer, I had to understand exactly how Azure evaluates firewall rules when we bind them programmatically.
In Azure, you can attach Network Security Groups (NSGs) at two distinct boundaries: the Subnet level (the whole road) and the NIC level (the specific house's front door).

💡The Analogy: The High-Security Corporate Tech Park

Imagine visiting a secure corporate client office in Marathahalli:

The Subnet Gate: First, you drive up to the main outer gate of the tech park. Security checks your vehicle. If you are on the list, they let you drive onto the campus (Allow).
The NIC Gate: Next, you walk up to the glass door of Building 3 inside that campus. The security guard at that specific door checks your ID badge and says, "You don't have access to this particular building" (Deny).

Result? You get dropped right there on the floor. You cannot enter. For a packet to reach an application, both security checkpoints must say "Allow".

INBOUND PACKET FLOW:
[Public Internet] ---> ( Subnet NSG: ALLOW ) ---> ( NIC NSG: DENY ) ---> [ Packet Dropped! ]

🚀Day 5: Scaling Out to a Hub-and-Spoke Topology

Once Day 4's automation was rock solid, I immediately jumped into Day 5 to scale my lab into a production-grade architecture. Enterprise companies do not dump everything into a single network. They isolate environments using a Hub-and-Spoke Topology.

💡The Analogy: The International Airport Terminal

The Hub (Sec_Hub_SEA_VNet): Think of this like the main central airport terminal building. This is where customs officers stand, passport control happens, and bags are scanned. Everything entering or leaving the airport must go through here.
The Spoke (Sec_Spoke_SEA_VNet): Think of this like the isolated airplane boarding gates far down the hallway. Gate A houses domestic flights; Gate B houses cargo. These gates do not need their own expensive customs setups; they rely entirely on the main central terminal (The Hub) to keep them secure.

📊 The Network Topology Map (Architecture Layout)

                    [ PUBLIC INTERNET ]

                                |
                                | (Strict Port 22 Lockdown Rule)
                                v
     =================== HUB VNET (10.0.0.0/16) ===================

     |                                                            |
     |   [ Sec_Hub_SEA_NSG ] ---> Applied to Subnet Layer         |
     |            |                                               |
     |            v                                               |
     |   [ Management_SEA_Subnet ] (10.0.1.0/24)                  |
     |                                                            |
     ==============================================================

               |                                      ^
               |                                      |
               |-----> [ Hub-to-Spoke Peering ] ------|
               |       (Status: Connected)            |
               |                                      |
               |-----> [ Spoke-to-Hub Peering ] ------|
               v                                      |
     ================== SPOKE VNET (10.1.0.0/16) ==================

     |                                                            |
     |   [ App_Prod_Subnet ] (10.1.1.0/24)                        |
     |   (Production Database / App Microservices workloads)      |
     |                                                            |
     ==============================================================

💻 Day 5 Code: Line-by-Line Technical Breakdown

To build this architecture, I executed three specific commands. Here is exactly what each line does under the hood:

Creating the Spoke Network Space

`BASH
az network vnet create -g Marathahalli_Lab_RG -n Sec_Spoke_SEA_VNet -l southeastasia --address-prefixes 10.1.0.0/16 --subnet-name App_Prod_Subnet --subnet-prefixes 10.1.1.0/24
`

az network vnet create: Tells the Azure Resource Manager to carve out a new software-defined virtual network fabric.

-g Marathahalli_Lab_RG: Places this new network inside my existing resource group container.

-n Sec_Spoke_SEA_VNet: Names this specific network space our "Spoke".

--address-prefixes 10.1.0.0/16: Allocates a massive pool of over 65,000 private IPs. Critical detail: This does not overlap with our Hub network (10.0.0.0/16), completely preventing routing collisions.

--subnet-name App_Prod_Subnet --subnet-prefixes 10.1.1.0/24: Instantly slices out a subset corridor within the Spoke where our actual production application databases and web servers will live.

Building the Walkway: From Hub to Spoke

`BASH
az network vnet peering create -g Marathahalli_Lab_RG --vnet-name Sec_Hub_SEA_VNet -n Hub-to-Spoke --remote-vnet Sec_Spoke_SEA_VNet --allow-vnet-access
`

az network vnet peering create: Tells Azure to construct a low-latency, private routing bridge directly across the Microsoft backbone network.

--vnet-name Sec_Hub_SEA_VNet: Specifies the starting point of our bridge (The Hub).

-n Hub-to-Spoke: Labels this directional leg of the bridge.

--remote-vnet Sec_Spoke_SEA_VNet: Connects the other end of the bridge straight into our Spoke network asset.

--allow-vnet-access: Programmatically permits the virtual machines inside the Hub to talk across this bridge natively.

Completing the Two-Way Street: From Spoke to Hub

`BASH
az network vnet peering create -g Marathahalli_Lab_RG --vnet-name Sec_Spoke_SEA_VNet -n Spoke-to-Hub --remote-vnet Sec_Hub_SEA_VNet --allow-vnet-access
`

Why this line is mandatory: In cloud architecture, a peering connection is not automatically bidirectional. It is a one-way street until you configure the return path. This command sets the starting point at the Spoke (--vnet-name Sec_Spoke_SEA_VNet) and maps it right back to the Hub (--remote-vnet Sec_Hub_SEA_VNet), completing the secure loop.

💰Financial Discipline Check

Since I only deployed logical networking paths, subnets, and routing bridges without provisioning any heavy virtual machine CPU power today, my automated environment runs at a cost of exactly ₹0 per hour. My Azure free trial credits remain 100% optimized and safe.

🏁Weekend Wrap-Up

This weekend was a massive leap forward. By stepping completely out of the comfort zone of the graphical portal, writing raw CLI scripts, conquering real-world resource location bugs, and standing up a verified Hub-and-Spoke enterprise topology, I am actively building the real-world skills needed to command senior cloud security roles.

The grind continues, where we will start hijacking these default routing paths using User-Defined Routes (UDRs) to force all traffic through a centralized firewall!

Onward and upward!🚀🔥

🚀 My First Day in the Cloud: How I Built a Secured Digital Fortress in Azure

Abhishek Kadlii — Fri, 22 May 2026 07:41:14 +0000

Many people think learning "Cloud Computing" means watching videos and memorizing words. But to actually become a real engineer, you have to get your hands dirty.

Today was my very first day building live systems inside Microsoft's global network (Azure). I didn't just build a cloud computer; I wrapped it in high-tech security gates to protect it from hackers.

Here is exactly what I did, told in plain, simple English.

🏰 The Analogy: Building a Secret Bank Vault

To understand what I built today, imagine you want to rent a secure vault inside a giant, high-tech fortress (the Cloud Data Center) to store important data.

[ Hacker / Stranger ] ────► ❌ Main Security Guard
│
[ Abhishek's Laptop ] ────► ✅ Private Gatehouse
│
▼ (Bypassed Router Block via Secret Tunnel)
┌──────────────┐
│ Inside Vault │ ──► [ Your Ubuntu Linux Server ]
└──────────────┘
Here are the 4 steps I took to build it:

🚪 Step 1: Hiring the Ultimate Security Guard (MFA)

Before building my vault, I hired a digital security guard for my main account. I turned on a feature called Security Defaults.

What it means: Think of it like a guard at the front door who checks IDs. If anyone tries to guess my password, the guard stops them instantly and sends a verification code straight to my personal phone. This keeps the bad guys completely out of my account.

🧱 Step 2: Building a Private Gatehouse (The Firewall / NSG)Next, I built a private wall around my vault. In the tech world, this is called a Network Security Group (NSG). It acts like a smart gatehouse with a very specific rulebook.

The Rule: I told the gatehouse, "Only let someone in if they are coming from Abhishek's exact home Wi-Fi address." If a hacker from anywhere else in the world tries to knock on the door, the gatehouse completely ignores them.

💻 Step 3: Launching the Computer (The Virtual Machine)Once the security walls were up, I ordered a fresh Linux computer (called a Virtual Machine) to live inside my vault.

The Real-World Twist: At first, the local data centers in India were completely full because so many people were using them! Instead of giving up, I used the power of the cloud to instantly teleport my project across the ocean to Singapore, where there was plenty of room. It worked perfectly and cost me next to nothing from my free credits.

🛠️ Step 4: Solving a Hidden Problem (The Serial Console)This was the most exciting part of the day. When I tried to log into my new Singapore computer from my laptop, the connection kept freezing.

The Problem: It turns out my home internet router is highly restrictive. It blocks the standard pipe (called Port 22) used to connect to Linux computers.

The Fix: Instead of calling my internet provider to complain, I used a secret Azure back-door tool called the Serial Console. It allowed me to bypass my home router's restriction and open a direct command-line window to my server right inside my Google Chrome browser tab!

💰 Saving Money: Turning off the Lights

Because the cloud operates on a "pay-for-what-you-use" model, keeping the computer running when I'm not using it would waste my free credits. To practice good discipline, I hit the Stop (Deallocate) button. This completely shuts down the physical computer in Singapore, dropping my hourly cost to exactly ₹0 until I turn it back on tomorrow.

🏆 Why this matters

Today, I proved that I can:

Lock down a cloud environment so hackers can't get in.
Adapt and move my infrastructure across the globe when resources are full.
Troubleshoot tricky network blocks like a real professional.