End-to-End Setup: Create Azure Local Virtual Network, Gateway, SLB, and NSGs from Scratch

Introduction

Azure Local, formerly known as Azure Stack HCI, has evolved into a robust hybrid cloud platform that brings Azure capabilities to your datacenter. With its Software Defined Networking (SDN) features, administrators can deploy secure, scalable, and automated network infrastructures that mirror Azure’s public cloud constructs—right on-premises.

This guide provides an end-to-end walkthrough of how to build a full Azure Local SDN stack: Virtual Network (VNet), Gateway, Software Load Balancer (SLB), and Network Security Groups (NSGs). You’ll walk away with practical steps, code examples, diagrams, and production-ready validation tips.

Architecture Overview

Azure Local SDN enables isolation, segmentation, and optimized traffic flow within your on-prem cloud environment. Below is an overview of the key components:

SDN Topology Diagram

Component Table

Prerequisites

Before we dive into the deployment, ensure the following:

• Azure Local Cluster: Deployed and joined to Active Directory
• SDN Express or Manual SDN Setup completed
• Certificates: Valid and trusted by all nodes
• PowerShell Modules:
  • NetworkController
  • SdnDiagnostics
• WAC: Installed and configured

Optional: Have Bicep installed if using IaC-based automation.

Step-by-Step Network Setup

A. Create Virtual Network and Logical Subnets

New-SdnLogicalNetwork -Name "TenantVNet" -SubnetPrefix "10.1.0.0/16" -LogicalSubnet @(
    @{Name="AppSubnet"; Prefix="10.1.1.0/24"},
    @{Name="WebSubnet"; Prefix="10.1.2.0/24"},
    @{Name="GatewaySubnet"; Prefix="10.1.3.0/24"}
)

You may alternatively use Windows Admin Center (WAC) to visualize and validate VNet creation.

B. Register and Configure Network Controller

Install-NetworkController -NodeNames @("NC1","NC2","NC3") -Cluster -ClientAuthentication Kerberos -Credential $cred
Register-SdnProvider -Name "NC01" -RestIPAddress "10.0.0.10"

Verify REST API:

Invoke-WebRequest -Uri https://10.0.0.10 -UseBasicParsing

C. Deploy Gateway

New-SdnGatewayPool -Name "S2SGateway" -InstanceCount 2 -Credential $cred
New-SdnVpnConnection -Name "ToAzure" -LocalAddress "PublicIP" -RemoteAddress "AzureGatewayIP" -SharedKey "SuperSecure123"

D. Deploy Software Load Balancer (SLB)

New-SdnLoadBalancerMux -Name "SLBMUX01"
New-SdnLoadBalancer -Name "WebLB" -FrontendIPAddress "10.1.2.5" -BackendPool @("10.1.2.10","10.1.2.11") -Protocol TCP -Port 443

You can also define SLB settings using a JSON configuration and push it via REST to the NC endpoint.

E. Create and Apply Network Security Groups (NSGs)

New-SdnAccessControlList -Name "WebNSG"
Add-SdnAccessControlEntry -ACLName "WebNSG" -Name "Allow-HTTPS" -Protocol TCP -LocalPort 443 -RemoteAddress * -Action Allow -Priority 100
Add-SdnAccessControlEntry -ACLName "WebNSG" -Name "Deny-All" -Protocol * -LocalPort * -RemoteAddress * -Action Deny -Priority 200

Example NSG Rule Table

Validation and Troubleshooting

Run the following PowerShell commands to confirm component health:

Get-SdnLogicalNetwork
Get-SdnGatewayStatus
Get-SdnLoadBalancer

Test connectivity:

Test-NetConnection -ComputerName 10.1.2.10 -Port 443

Use SdnDiag for deeper diagnostics:

Invoke-SdnDiag -All

Troubleshooting Table

Best Practices for Production

• Use infrastructure-as-code with Bicep to deploy SDN consistently
• Separate control and data planes
• Use scoped delegation and RBAC
• Monitor traffic using NSG flow logs
• Store configuration in source control (e.g., Git)

Conclusion

With this guide, you’ve stood up a full Azure Local SDN environment, including VNets, Gateways, Load Balancing, and Network Security Groups. This mirrors the architectural patterns of Azure public cloud, enabling a consistent, secure, and high-performing hybrid infrastructure.

Resources

• Microsoft Docs – Azure Stack HCI + SDN
• PowerShell SDN Toolkit – GitHub

Disclaimer

This post reflects the author’s testing and implementation experience. Always validate compatibility with your specific infrastructure and consult official Microsoft documentation before applying changes to production