SDN on Azure Local: A Deep-Dive Walkthrough From Zero to NSG

 

SDN on Azure Local: A Deep-Dive Walkthrough From Zero to NSG

Picture this: you’ve got a freshly deployed Azure Local cluster, VMs are running, and then someone in a security review asks “so how are you controlling east-west traffic between those workloads?” You open your mouth, and… nothing comes out. Been there. SDN on Azure Local is the answer to that awkward silence, and as of late 2025 it’s genuinely production-ready in a way that actually makes sense for on-prem ops teams.

This post walks through the full picture — what SDN is on Azure Local, the two paths you can take, and then a step-by-step walkthrough of the modern Arc-enabled path with real commands.

—

What SDN Actually Is on Azure Local

SDN provides a way to centrally configure and manage networks and network services such as switching, routing, and load balancing in your data center. The key word there is centrally. Instead of SSH-ing into individual switches or hand-crafting Hyper-V port ACLs on every host, you push policy from a single control plane and it propagates everywhere.

Virtual network elements such as Hyper-V Virtual Switch, Hyper-V Network Virtualization, Software Load Balancing, and RAS Gateway are designed to be integral elements of your SDN infrastructure. These aren’t bolt-ons — they’re baked into the Hyper-V stack that Azure Local already runs on.

The traffic enforcement happens at the vSwitch level via the Virtual Filtering Platform (VFP). Tenant VMs reside on logical networks managed by the Network Controller. All the traffic from these VMs is routed through the virtual switches that are Virtual Filtering Platform (VFP)-enabled.

—

Two Paths: Arc-Managed vs. On-Premises Tools

This is the first decision you need to make, and it matters because you must choose one of the modes of SDN management and cannot run in a hybrid management mode, mixing the two.

You can manage SDN on Azure Local in two ways: with Arc or with on-premises tools. SDN enabled by Arc is available with Azure Local 2506 with OS version 26100.xxxx or later. In this method, the Network Controller runs as a Failover Cluster service instead of on a virtual machine (VM).

SDN managed by on-premises tools uses Windows Admin Center or SDN Express scripts. This approach is available for Windows Server and Azure Local 2311.2 or later. This method uses three main SDN components, and you choose which to deploy: Network Controller, Software Load Balancer (SLB), and Gateway.

Here’s my take: if you’re on a fresh Azure Local 2506+ deployment and don’t need SLBs or Gateways today, go Arc-managed. It’s the direction Microsoft is clearly investing in, it hit GA with version 2510 in November 2025, and it doesn’t require you to babysit a fleet of SDN infrastructure VMs. If you need full-stack SLB and Gateway support right now, on-premises tools is your only option — some SDN features like virtual networks (vNETs), Load Balancers (SLBs), and Gateways are not yet supported in SDN enabled by Azure Arc.

The rest of this walkthrough focuses on the SDN enabled by Azure Arc path.

—

Architecture: What’s Actually Running

Before you touch a keyboard, understand what you’re deploying. The Network Controller component and its services are set as a Failover Cluster group across all the Azure Local machines in your instance. Each Network Controller microservice is highly available as a Failover Cluster Resource Group.

This is a big deal compared to the old model. NC is a key component that manages and configures virtual network infrastructure on an Azure Local instance. NC is now natively integrated with the host machine using Failover Clustering, rather than being hosted in a VM. No more three dedicated NC VMs eating your RAM. The NC runs as a cluster service on your existing hosts.

The MGMT VLAN on your Azure Local instance is responsible for configuring and deploying network policies from NC to the NC host agent. The NC host agent receives and plumbs policies to your virtual switch.

—

Prerequisites Checklist

Before you run a single command, confirm the following:

• You have access to an Azure Local instance running 2506 and later.
• You have access to an Azure subscription with the Azure Stack HCI Administrator RBAC role. This role grants full access to your Azure Local instance and its resources.
• Your host networking pattern is supported. The following network intent configurations are not supported for SDN enabled by Arc on Azure Local: more than three intents on any deployment size, and combined compute and storage intents, regardless of whether a management intent is included or not.
• You are not already running Network Controller deployed via on-premises tools. If you’re already running Network Controller on your Azure Local cluster that was deployed using on-premises tools, you must not attempt to run this method.
• Plan a maintenance window. Make sure to plan for a maintenance window if you’re running on a production environment. Your workloads experience a short network disruption while SDN Azure Virtual Filtering Platform policies are applied.

One more thing worth burning into your brain: once you enable SDN, you can’t roll back or disable. This is not a “try it out on prod Friday afternoon” situation.

—

Step 1: Enable SDN (Deploy Network Controller)

Connect to a node in your Azure Local instance with the Azure Stack HCI administrator role. Then run the Lifecycle Manager (ECE) action plan to deploy Network Controller as a Failover Cluster service.

The command to run is Add-EceFeature -Name NC -SDNPrefix <SDNPrefix>. To skip the confirmation prompt for the maintenance window, use the -AcknowledgeMaintenanceWindow parameter, and use -AcknowledgeDNSRecordCreation to acknowledge you’ve prepared your DNS environment if not using dynamic DNS. This step can take up to 20 minutes.

# Run from a node in your Azure Local cluster
# Replace <sdn-prefix> with your chosen DNS prefix for the Network Controller
# e.g., "nc" would result in DNS records like nc.contoso.local

Add-EceFeature -Name NC -SDNPrefix <sdn-prefix>

# To skip interactive prompts in an automation scenario:
Add-EceFeature -Name NC `
    -SDNPrefix <sdn-prefix> `
    -AcknowledgeMaintenanceWindow `
    -AcknowledgeDNSRecordCreation

Once the step completes, validate that Network Controller is successfully added to your instance. Once the Network Controller is added, the Add-EceFeature command shows the action plan outcome.

If you see Task Success entries for steps like VerifyNCFirewallRulesEnabled and VerifyNCVMSwitchExtensionEnabled, you’re good. If the action plan fails partway through, check C:\MASLogs\ on the node — the transcript lands there.

—

Step 2: Create a Logical Network

With NC running, you can now create logical networks that map to your physical VLANs. You can use the Azure portal, Azure CLI, or Azure Resource Manager templates to create and manage SDN features including logical networks that project your physical networks.

Enabling SDN with existing Azure Local VMs and logical networks is supported. The logical networks and network interfaces are automatically hydrated into the Network Controller. So if you already had logical networks defined before enabling SDN, they don’t disappear — they get pulled in.

Here’s how to create a new static logical network via Azure CLI:

# Set variables — replace all placeholder values
RESOURCE_GROUP="<resource-group>"
LOCATION="<azure-region>"           # e.g., eastus — must match your Azure Local instance region
CUSTOM_LOCATION_ID="<custom-location-resource-id>"
LNET_NAME="<logical-network-name>"
VLAN_ID="<vlan-id>"                 # e.g., 100
ADDRESS_PREFIX="<subnet-cidr>"      # e.g., 192.168.100.0/24
GATEWAY="<gateway-ip>"              # e.g., 192.168.100.1
DNS_SERVER="<dns-server-ip>"        # e.g., 192.168.1.10

az stack-hci-vm network lnet create \
  --resource-group $RESOURCE_GROUP \
  --name $LNET_NAME \
  --location $LOCATION \
  --custom-location $CUSTOM_LOCATION_ID \
  --vlan $VLAN_ID \
  --address-prefixes $ADDRESS_PREFIX \
  --ip-allocation-method Static \
  --gateway $GATEWAY \
  --dns-servers $DNS_SERVER

Note: NSGs are available only for static logical networks. DHCP-based logical networks aren’t supported. If you want to apply NSGs later (and you do), make sure you’re creating static networks.

—

Step 3: Create a Network Security Group

NSGs manage network traffic between logical networks or VMs on Azure Local. Configure a network security group with security rules that allow or deny either inbound or outbound network traffic.

The network security rules control traffic based on source and destination IP addresses, port numbers, protocols (TCP/UDP), and direction (inbound or outbound). Full 5-tuple control, same as what you’d use in Azure public cloud.

One gotcha: NSGs must have at least one network security rule. An empty NSG denies all inbound traffic by default. A VM or logical network associated with this NSG isn’t reachable. Don’t create an NSG, attach it to a VM, and then wonder why it’s gone dark.

# Create the NSG
NSG_NAME="<nsg-name>"

az stack-hci-vm network nsg create \
  --resource-group $RESOURCE_GROUP \
  --name $NSG_NAME \
  --location $LOCATION \
  --custom-location $CUSTOM_LOCATION_ID

# Add an inbound rule to allow RDP (port 3389) from a specific management subnet
az stack-hci-vm network nsg rule create \
  --resource-group $RESOURCE_GROUP \
  --nsg-name $NSG_NAME \
  --name "Allow-RDP-From-Mgmt" \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefix "<mgmt-subnet-cidr>" \
  --source-port-range "*" \
  --destination-address-prefix "*" \
  --destination-port-range 3389

# Add a rule to deny all other inbound traffic
az stack-hci-vm network nsg rule create \
  --resource-group $RESOURCE_GROUP \
  --nsg-name $NSG_NAME \
  --name "Deny-All-Inbound" \
  --priority 4096 \
  --direction Inbound \
  --access Deny \
  --protocol "*" \
  --source-address-prefix "*" \
  --source-port-range "*" \
  --destination-address-prefix "*" \
  --destination-port-range "*"

—

Step 4: Attach the NSG

You can attach an NSG at two levels: the logical network (applies to all VMs on that VLAN) or the individual VM network interface (more granular). You can safeguard your edge workloads with policy-driven access controls by applying inbound and outbound allow/deny rules on NSGs, just as you would in Azure.

# Option A: Attach NSG to a logical network
NSG_RESOURCE_ID=$(az stack-hci-vm network nsg show \
  --resource-group $RESOURCE_GROUP \
  --name $NSG_NAME \
  --query id -o tsv)

az stack-hci-vm network lnet update \
  --resource-group $RESOURCE_GROUP \
  --name $LNET_NAME \
  --nsg $NSG_RESOURCE_ID

# Option B: Attach NSG to a specific VM network interface
NIC_NAME="<vm-nic-name>"

az stack-hci-vm network nic update \
  --resource-group $RESOURCE_GROUP \
  --name $NIC_NAME \
  --nsg $NSG_RESOURCE_ID

Scope note: The only VMs in scope for using NSGs with this feature are Azure Local VMs — those deployed from Azure client interfaces (Azure CLI, Azure portal, Azure Resource Manager). VMs created directly via Hyper-V Manager or New-VM are not managed by this path.

—

Step 5: Verify in the Portal

Once everything is applied, head to the Azure portal. Navigate to your Azure Local cluster resource → Resources → Network security groups. Go to Azure Local cluster resource > Resources > Network security groups. The new NSG appears in the list of network security groups on your Azure Local.

You can also validate that the Arc Resource Bridge has the NSG state correct. In case ARB on the cluster needs to be recovered, NSGs and their rules can be recovered along with VMs and associated resources. That’s a genuinely useful DR story.

—

What About On-Premises Tools (SDN Express / WAC)?

If you went the on-premises tools route instead, the deployment flow is different. Windows Admin Center enables you to deploy all the SDN infrastructure components on your existing Azure Local, in a defined deployment order. Alternatively, you can deploy the entire SDN infrastructure through the SDN Express scripts.

For the WAC path: SDN Network Controller deployment is a functionality of the SDN Infrastructure extension in Windows Admin Center. In Windows Admin Center, under Tools, select Settings, then select Extensions. On the Installed Extensions tab, verify that the SDN Infrastructure extension is installed.

Specify the number of VMs to be dedicated for Network Controller. Microsoft strongly recommends three VMs for production deployments.

For the SDN Express PowerShell path: to deploy Network Controller with Failover Clustering using PowerShell, you must first install the SDN Express script. The SDN Express script is a PowerShell script that automates the deployment of the SDN infrastructure. Check that your installed version is 1.1.231 or later.

—

Known Limitations Worth Knowing

Don’t go in blind on these:

• SDN isn’t supported on stretched (multi-site) clusters.
• Three-intent configurations on two-node switchless or three-node switchless deployments are not supported.
• AKS is supported on Azure Local instances configured with SDN enabled by Arc. However, associating NSGs with the logical network used for AKS workload deployment or with AKS workload VM NICs isn’t supported.
• If you are using SDN Software Load Balancers (SLB) or Gateway GRE gateways, you must also configure BGP peering with the top-of-rack (ToR) switches so that the SLB and GRE Virtual IP addresses (VIPs) can be advertised. This applies to the on-premises tools path only.

—

What to Watch Next

The Arc-managed SDN path is clearly where Microsoft is heading. The SDN managed by on-premises tools continues to provide full-stack SDN capabilities, including SLBs, Gateways, and VNET peering, while Microsoft actively works on bringing this additional value to the SDN enabled by Azure Arc feature set.

My next moves from here would be:

1. SdnDiagnostics module — install it from the PowerShell Gallery and get familiar with it before you need it at 2am
2. Default Network Access Policies — worth understanding how baseline policies apply at VM creation time so you’re not surprised by blocked ports on new VMs
3. BGP planning — if SLB support lands in the Arc path, you’ll want your ToR switch BGP config ready to go