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! 🚀🔥
Top comments (0)