AZ-104 Lab Journey (Day 6): Connecting Segmented Networks with VNet Peering and Custom Routing

Today, with DiSEP5.0 X Teknowledge, we moved from isolated networking into something much closer to enterprise reality: segmented networks that still need controlled communication.

The environment now mirrors a classic hub-and-spoke style design where core services and manufacturing workloads live in separate virtual networks but must communicate securely.

At every point, I thought of the possibility of a misconfiguration or things that could go wrong despite doing everything right. How does one troubleshoot incase of an incident?

The scenario

The organization separates core IT services (DNS, security tooling, shared services) from manufacturing services. This segmentation helps with security and blast-radius control, but it introduces a practical challenge: some workloads in manufacturing still need to communicate with services in the core network.

This lab focused on enabling that communication intentionally and securely, instead of flattening the network.

Task 1 & 2: Building isolated networks with intent

I started by creating:

• A Core Services virtual network, hosting a virtual machine
• A Manufacturing Services virtual network, hosting a separate virtual machine

At this stage, the networks were completely isolated — no implicit trust, no connectivity, no shortcuts.

Task 3: Verifying connectivity with Network Watcher

Before configuring any peering, I used Azure Network Watcher to test connectivity between the two virtual machines.

As expected:

• Communication failed
• The test confirmed that isolation was enforced at the network level

This step was subtle but important: instead of assuming how Azure behaves, I validated it. Network Watcher makes invisible networking decisions observable — which is just as useful for defenders as it is for attackers.

Task 4: Enabling communication with virtual network peering

Next, I configured virtual network peering between the Core Services VNet and the Manufacturing VNet.

Once peered:

• Resources in both networks could communicate using private IP addresses
• No public internet exposure was required
• The networks remained logically separate but operationally connected

This pattern is common in real-world Azure environments, especially when separating:

• Production vs development
• Shared services vs business units
• Parent companies vs subsidiaries

Task 5: Retesting connectivity with Azure PowerShell

After peering, I re-tested connectivity using Azure PowerShell.

This confirmed:

• End-to-end communication was now possible
• Changes were effective and predictable
• Connectivity could be validated programmatically, not just through the portal

Out of curiosity, I also tested the connectivity with Network Watcher to observe the difference. That being done, I learned that Network changes should always be verified, not assumed.

Task 6: Controlling traffic with a custom route

The final task introduced custom routing, which is where architecture and security start to overlap heavily.

The requirement was clear:

• All traffic between the perimeter subnet and internal core services subnet must flow through a virtual network appliance
• Direct communication should not be allowed

To achieve this, I created a user-defined route (UDR) that redirected traffic from the perimeter subnet to a Network Virtual Appliance (NVA). I was curious to observe the routing behaviour in action and understand what happens behind the scenes, but that visibility wasn’t available in the lab.

That limitation made me reflect on how fragile this setup can be in real environments — what happens if the route is applied to the wrong subnet, if the appliance becomes a single point of failure, or if traffic fails open when the appliance goes down?

The biggest takeaway from this lab for me is that every new connection expands the attack surface. Designing connectivity is easy; designing secure connectivity is the real challenge. This is exactly the kind of thinking I want to keep sharpening as I continue this journey.