The "Aha!" Moment That Changed Everything
I'll never forget the moment I ran Test-NetConnection after setting up VNet peering and saw TcpTestSucceeded: True - after hours of failed connections, everything finally worked! Here's my real journey through Azure networking, complete with screenshots of every step.
Step 1: Setting Up My Test Environment (The Manual Way)
Why I Ditched the Templates:
The lab provided ARM templates, but I chose manual creation to really understand what was happening behind the scenes.
What I Actually Did:
Created TestVM in ManufacturingVnet:
Resource Group: ContosoResourceGroup
Location: UK West (to match my VNet)
Virtual Network: ManufacturingVnet
Subnet: default (10.30.0.0/24)
Verified TestVM1 in CoreServicesVnet:
Already existed from previous lab
Step 2: The RDP Struggle & Finding Better Solutions
The Problem Every Azure Admin Faces:
RDP connections failed repeatedly with that frustrating "can't connect" message.
My Workaround That Actually Worked Better:
Discovered Azure Run Command:
TestVM → Operations → Run command → RunPowerShellScript
Used Serial Console as Backup:
Perfect for when RDP fails
Direct command-line access
Step 3: The Baseline Test - Proving Isolation
Getting TestVM1's IP:
powershell
ipconfig
The Expected Failure:
powershell
Test-NetConnection 10.20.20.4 -port 3389
This proved the networks were completely isolated - which was exactly what we expected at this stage.
Step 4: Building the Network Bridge - VNet Peering
The Magic Configuration:
CoreServicesVnet → Peerings → + Add:
Peering link name: ManufacturingVnet-to-CoreServicesVnet
Virtual network: ManufacturingVnet
Allow access: Enabled
Automatic Reverse Peering Created:
CoreServicesVnet-to-ManufacturingVnet
Clicked "Sync" and Watched the Status Change:
From "Initiated" to "Connected"
Step 5: The Moment of Truth - Testing Connectivity
Running the Exact Same Command:
powershell
Test-NetConnection 10.20.20.4 -port 3389
The Beautiful Result:
text
TcpTestSucceeded: True
ComputerName: 10.20.20.4
RemotePort: 3389
Step 6: Cleanup & Cost Management
Removing Resources Properly:
powershell
Remove-AzResourceGroup -Name 'ContosoResourceGroup' -Force -AsJob
Key Lessons That Made Me a Better Cloud Engineer
Technical Insights:
Manual configuration > templates for learning
Run Command is incredibly powerful for administration
Peering must be bidirectional to work properly
Business Value Realized:
Cost savings by eliminating VPN gateways
Performance boost through Azure backbone
Security enhancement with private connectivity
Why This Matters for Your Organization
If you're managing multiple Azure environments, VNet peering isn't just technical - it's business-critical for:
Application integration between different teams
Hybrid cloud strategies
Compliance and security requirements
Ready to Help Others Succeed
I'm passionate about making cloud networking accessible. If your organization is facing similar challenges, I'd love to:
Share more detailed configurations
Help troubleshoot specific scenarios
Collaborate on Azure networking projects
What networking challenges are you facing? Share your experiences below!
Top comments (0)