9.5 Azure VM Networking, NSGs & Connectivity

Azure VM Networking, NSGs & Connectivity

Network architecture in Microsoft Azure forms the communication and security foundation for hybrid Windows Server environments. Unlike traditional physical datacenters where networking is governed by physical switches, VLAN tags, and hardware firewalls, Azure networking operates as a software-defined network (SDN) overlay. Administering Windows Server virtual machines requires an exact understanding of Azure IP allocation rules, Network Security Group (NSG) evaluation mechanics, Application Security Groups (ASGs), User Defined Routes (UDRs), IP forwarding, and private connectivity to Azure PaaS services.

---

1. Virtual Network (VNet) Architecture & IP Addressing for Windows Server

An Azure Virtual Network (VNet) is an isolated private network overlay within an Azure subscription. Subnets partition the address space into routable segments.

+-----------------------------------------------------------------------------+
|                  AZURE VIRTUAL NETWORK IP ALLOCATION ARCHITECTURE           |
|                                                                             |
|   [AZURE VIRTUAL NETWORK: 10.100.0.0/16]                                    |
|   +---------------------------------------------------------------------+   |
|   |  Subnet: IdentitySubnet (10.100.1.0/24)                             |   |
|   |                                                                     |   |
|   |  AZURE FABRIC RESERVED IPs:                                         |   |
|   |  - 10.100.1.0   : Network Address                                   |   |
|   |  - 10.100.1.1   : Default Gateway (Virtual Router)                  |   |
|   |  - 10.100.1.2/3 : Azure DNS Services Mapping                        |   |
|   |  - 10.100.1.255 : Broadcast Address                                 |   |
|   |  (5 IPs Reserved -> 251 Usable IPs in a /24 Subnet)                |   |
|   |                                                                     |   |
|   |  +---------------------------------------------------------------+  |   |
|   |  | VM: AZ-DC01                                                   |  |   |
|   |  | Azure NIC Resource: IP Allocation = STATIC (10.100.1.4)       |  |   |
|   |  | Guest OS Network Adapter: Obtain IP via DHCP (AUTOMATIC!)     |  |   |
|   |  +---------------------------------------------------------------+  |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

Azure Subnet Reserved IP Addresses:

In every Azure subnet, Microsoft reserves 5 IP addresses that cannot be assigned to VMs:

1. x.x.x.0: Network address.
2. x.x.x.1: Default gateway (the virtual router for the subnet).
3. x.x.x.2 and x.x.x.3: Azure DNS mapping addresses used to coordinate Azure fabric name resolution.
4. x.x.x.255: Network broadcast address.

• Formula: Usable IPs per subnet = $2^{(32 - \text{CIDR Prefix})} - 5$.

Static vs. Dynamic Private IP Assignment (The Cardinal Rule):

[!CAUTION] The Guest OS DHCP Rule: To assign a permanent, static private IP address to a Windows Server Azure VM (such as a Domain Controller, DNS Server, or SQL Server):

1. Set the private IP allocation method to Static on the Azure Network Interface (NIC) resource in the Azure Portal, PowerShell, or Bicep.
2. NEVER configure a static IP inside the Windows Server guest OS Network Connections control panel (ncpa.cpl). The guest OS network adapter MUST ALWAYS be set to "Obtain an IP address automatically" (DHCP).

Failure Mode: If a static IP is manually typed into the Windows network adapter, and the VM is later deallocated, resized, or moved to another subnet or host, the guest adapter loses synchronization with the Azure DHCP server, resulting in catastrophic loss of network connectivity and bricking remote RDP/WinRM access.

Multiple Network Interfaces (Multi-NIC) on Windows VMs:

• High-performance enterprise VMs (such as Network Virtual Appliances or multi-homed application servers) can have multiple Azure NICs attached.
• Primary vs. Secondary NICs: The primary NIC possesses the default gateway. Secondary NICs do not receive a default gateway from Azure DHCP. Inter-subnet routing over secondary NICs requires configuring static routes inside the Windows Server route table (route add) or attaching custom Route Tables in Azure.

---

2. Network Security Groups (NSGs): Rule Evaluation & Priority Mechanics

A Network Security Group (NSG) acts as a stateful layer-4 packet-filtering firewall that controls inbound and outbound traffic to Azure resources.

+-----------------------------------------------------------------------------+
|                     NSG 5-TUPLE RULE EVALUATION ENGINE                      |
|                                                                             |
|   TRAFFIC PACKET: [Src: 198.51.100.5 | Dst: 10.100.1.4 | DstPort: 3389 (TCP)]|
|                                     |                                       |
|                                     v                                       |
|   [Priority 100] Allow-Corp-VPN     (Src: 203.0.113.0/24 -> Port 3389) [NO] |
|   [Priority 200] Allow-Admin-Bastion(Src: 10.100.254.0/26 -> Port 3389)[NO] |
|   [Priority 300] Block-Internet-RDP (Src: Internet -> Port 3389)       [MATCH!]|
|                                     |                                       |
|                                     v                                       |
|   ---> ACTION: DENY PACKET (Evaluation Stops Immediately!)                  |
|   (Lower priority rules 400-65500 are never processed)                      |
+-----------------------------------------------------------------------------+

5-Tuple Security Rule Structure:

1. Source: IP address, CIDR block, Service Tag (e.g., VirtualNetwork, Internet, AzureLoadBalancer), or Application Security Group (ASG).
2. Source Port Range: Specific port (e.g., 80), port range (e.g., 8000-8080), or wildcard (*).
3. Destination: IP address, CIDR block, Service Tag, or ASG.
4. Destination Port Range: Target application port (e.g., 443, 3389, 53).
5. Protocol: TCP, UDP, ICMP, AH, ESP, or Any (*).
6. Action: Allow or Deny.

Priority Numbers and Processing Rules:

• Priority numbers range from 100 (highest priority) to 4096 (lowest priority).
• Rules are evaluated sequentially in strictly ascending numerical order (100, 110, 120...).
• First Match Termination: Once a packet matches a rule's 5-tuple criteria, processing terminates immediately, and the action (Allow or Deny) is enforced. Subsequent rules are never evaluated.

Built-in Default Rules (Priorities 65000+):

Default rules cannot be deleted, but they can be overridden by creating custom rules with higher priority (100–4095):

NSG Association Hierarchy (Subnet vs. NIC Level):

INBOUND TRAFFIC FLOW:  [Packet] ---> [Subnet NSG] ---> (Allowed?) ---> [NIC NSG] ---> [VM]
                                          | (Denied?)                       | (Denied?)
                                          v                                 v
                                     [DROPPED]                         [DROPPED]

OUTBOUND TRAFFIC FLOW: [VM]     ---> [NIC NSG]    ---> (Allowed?) ---> [Subnet NSG] ---> [Target]

• Inbound Processing: Traffic hits the Subnet NSG first. If allowed, it hits the NIC NSG second. Both must allow the traffic for the packet to reach the VM.
• Outbound Processing: Traffic hits the NIC NSG first. If allowed, it hits the Subnet NSG second. Both must allow the traffic for the packet to leave the subnet.

---

3. Application Security Groups (ASGs)

In dynamic cloud environments, hardcoding individual VM IP addresses into NSG security rules creates massive administrative overhead and frequent configuration drift.

+-----------------------------------------------------------------------------+
|                  APPLICATION SECURITY GROUP (ASG) ARCHITECTURE              |
|                                                                             |
|   [AZURE VIRTUAL NETWORK]                                                   |
|   +---------------------------------------------------------------------+   |
|   |  Subnet A (10.100.1.0/24)           Subnet B (10.100.2.0/24)        |   |
|   |  +-----------------------------+    +----------------------------+  |   |
|   |  | [VM-WEB01]     [VM-WEB02]   |    | [VM-WEB03]                 |  |   |
|   |  | (Member of: ASG-WebTier)    |    | (Member of: ASG-WebTier)   |  |   |
|   |  +-----------------------------+    +----------------------------+  |   |
|   |                 |                                                   |   |
|   |                 | (NSG Rule: Allow Src: ASG-WebTier                 |   |
|   |                 |            Dst: ASG-DBTier, Port: 1433 [TCP])     |   |
|   |                 v                                                   |   |
|   |  Subnet C (10.100.3.0/24)                                           |   |
|   |  +---------------------------------------------------------------+  |   |
|   |  | [VM-SQL01]     [VM-SQL02]     (Members of: ASG-DBTier)        |  |   |
|   |  +---------------------------------------------------------------+  |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

How ASGs Operate:

• An Application Security Group (ASG) is a logical metadata container to which virtual machine network interfaces (NICs) are assigned.
• In NSG security rules, instead of specifying an explicit IP prefix like 10.100.1.15/32, administrators specify ASG-WebTier as the Source and ASG-DBTier as the Destination.
• Zero Maintenance Scaling: When a new web VM (VM-WEB04) is provisioned and its NIC is associated with ASG-WebTier, all NSG security rules apply to it immediately without updating any NSG rules.
• Boundary Constraint: All network interfaces attached to an ASG must reside within the same Azure Virtual Network.

---

4. User Defined Routes (UDRs) & Route Tables

Azure automatically manages packet routing between subnets, virtual networks, and the internet using Default System Routes:

• Traffic destined within the VNet routes directly via VirtualNetwork local routing.
• Traffic destined to 0.0.0.0/0 routes directly out the Internet gateway.
• Traffic destined to on-premises ranges routes to the VirtualNetworkGateway.

To force traffic through a central firewall or Network Virtual Appliance (NVA) (e.g., Azure Firewall or a third-party Windows/Linux firewall appliance), administrators create Custom Route Tables containing User Defined Routes (UDRs).

+-----------------------------------------------------------------------------+
|                     UDR & NVA TRAFFIC INSPECTION WORKFLOW                   |
|                                                                             |
|   [WEB SUB-NET: 10.100.1.0/24]                [DMZ SUB-NET: 10.100.0.0/24]  |
|   +--------------------------+                +--------------------------+  |
|   | [VM-WEB01]               |                | [NVA Firewall Appliance] |  |
|   | (Attempts out to DB)     |                | NIC Private IP:          |  |
|   +--------------------------+                | 10.100.0.4               |  |
|                |                              | (IP Forwarding: ENABLED!)|  |
|                v                              +--------------------------+  |
|   [UDR: 10.100.3.0/24]                                     ^                |
|   [Next Hop: VirtualAppliance (10.100.0.4)] =============> |                |
|                                                            | (Inspects)     |
|                                                            v                |
|   [DB SUB-NET: 10.100.3.0/24] <=============================                |
|   +--------------------------+                                              |
|   | [VM-SQL01] (Port 1433)   |                                              |
|   +--------------------------+                                              |
+-----------------------------------------------------------------------------+

Next Hop Types in User Defined Routes:

1. VirtualAppliance: Directs traffic to the private IP address of an NVA or internal load balancer frontend.
2. VirtualNetworkGateway: Directs traffic to an Azure VPN Gateway or ExpressRoute Gateway.
3. VNetLocal: Overrides broader routes to force local subnet routing.
4. Internet: Directs traffic directly to the Azure internet backbone (bypassing default blackholes).
5. None: Blackholes and drops all matching traffic.

Longest Prefix Match (LPM) Rule:

When multiple routes exist for a destination IP, Azure evaluates routing in the following order:

1. Most Specific CIDR Prefix (Longest Prefix Match): A route for 10.100.3.0/24 always overrides a broader route for 10.100.0.0/16 or 0.0.0.0/0.
2. Tie-Breaking Precedence: If destination prefixes are identical:
   • User Defined Route (UDR) wins first.
   • BGP / ExpressRoute Route wins second.
   • System Route wins last.

[!IMPORTANT] The NVA IP Forwarding Requirement: When configuring a Windows Server VM to act as a router, NAT gateway, or Network Virtual Appliance, you MUST enable IP Forwarding (EnableIPForwarding = $true) on its Azure NIC resource. By default, Azure drops any packet arriving at a VM's NIC whose destination IP address does not match that NIC's assigned private IP. Enabling IP Forwarding allows the NIC to pass transit traffic through the guest OS routing stack.

---

5. Azure Private Endpoints vs Service Endpoints

Securing communication between Windows Server VMs and Azure PaaS services (such as Azure Storage accounts, Azure SQL Database, or Azure Key Vault) requires eliminating exposure to the public internet.

+-----------------------------------------------------------------------------+
|                 SERVICE ENDPOINTS VS PRIVATE ENDPOINTS                      |
|                                                                             |
|   SERVICE ENDPOINT ARCHITECTURE         PRIVATE ENDPOINT (PRIVATE LINK)     |
|   - Uses PaaS Public IP Address         - Allocates Subnet Private IP       |
|   - Routes over Microsoft Backbone      - Completely Private RFC 1918 IP    |
|   - Subnet-level identity injection     - Resource-level granular mapping   |
|   - No on-prem / VPN connectivity       - Fully reachable over VPN/ExpressR.|
|   - Free of charge                      - Billed hourly + per GB processed  |
+-----------------------------------------------------------------------------+

Detailed Comparison:

1. Virtual Network Service Endpoints:

   • Mechanism: Optimizes the network path to Azure PaaS services over the Microsoft backbone network. The client VM continues to communicate with the PaaS service's public IP address, but Azure validates that the connection originates from an authorized VNet subnet.
   • Limitations: Cannot be accessed from on-premises datacenters over Site-to-Site VPN or ExpressRoute (because traffic must originate inside the Azure VNet subnet).

2. Azure Private Endpoints (Azure Private Link):

   • Mechanism: Provisions a dedicated Virtual Network Interface with a private IP address directly inside your VNet subnet (e.g., 10.100.1.50).
   • DNS Integration: Integrates with Azure Private DNS Zones (e.g., privatelink.blob.core.windows.net) to resolve the PaaS resource FQDN to the internal private IP address.
   • Hybrid Connectivity: Because the endpoint uses a standard private RFC 1918 IP, on-premises Windows Servers can securely access Azure PaaS services across Site-to-Site VPN and ExpressRoute links without traversing the public internet.

PowerShell Automation: NSG with ASG & Custom Route Table

$rg = 'RG-Networking'
$loc = 'eastus'

# 1. Create Application Security Groups
$asgWeb = New-AzApplicationSecurityGroup -ResourceGroupName $rg -Location $loc -Name 'ASG-WebTier'
$asgDb  = New-AzApplicationSecurityGroup -ResourceGroupName $rg -Location $loc -Name 'ASG-DBTier'

# 2. Create Network Security Group with ASG Rules
$nsg = New-AzNetworkSecurityGroup -ResourceGroupName $rg -Location $loc -Name 'NSG-Internal'

# Allow SQL traffic from Web ASG to DB ASG
$nsg | Add-AzNetworkSecurityRuleConfig `
    -Name 'Allow-Web-to-SQL' `
    -Priority 200 `
    -Access Allow `
    -Direction Inbound `
    -Protocol Tcp `
    -SourceApplicationSecurityGroup $asgWeb `
    -SourcePortRange '*' `
    -DestinationApplicationSecurityGroup $asgDb `
    -DestinationPortRange 1433 | Set-AzNetworkSecurityGroup

# 3. Create Route Table with User Defined Route (UDR) to Firewall NVA
$routeTable = New-AzRouteTable -ResourceGroupName $rg -Location $loc -Name 'RT-SpokeSubnets'

$routeTable | Add-AzRouteConfig `
    -Name 'Route-To-Firewall' `
    -AddressPrefix '0.0.0.0/0' `
    -NextHopType VirtualAppliance `
    -NextHopIpAddress '10.100.0.4' | Set-AzRouteTable

# 4. Enable IP Forwarding on the Firewall NVA Network Interface
$nvaNic = Get-AzNetworkInterface -ResourceGroupName $rg -Name 'NIC-Firewall01'
$nvaNic.EnableIPForwarding = $true
$nvaNic | Set-AzNetworkInterface