Azure Vnet

---
name: azure-vnet
description: "Expert coverage of Azure VNet networking: VNet design, NSGs, ASGs, Azure Firewall, Virtual WAN, ExpressRoute, VPN Gateway, Private Link, Route Server, UDRs, and Azure Front Door. Use for \"Azure VNet\", \"NSG\", \"Azure Firewall\", \"Virtual WAN\", \"vWAN\", \"ExpressRoute\", \"Azure VPN\", \"Private Link\", \"UDR\", \"Azure networking\". Do NOT use for cross-vendor comparison, platform selection, or category-wide architecture -- use the `cloud-networking` skill. Do NOT use for general Azure account/resource management beyond VNet networking -- that's the `azure` skill (in the `cloud-platforms` plugin)."
license: MIT
---

# Azure VNet

This skill covers Azure Virtual Network (VNet) networking. Areas of expertise include:

- VNet design, address space planning, and subnet architecture
- Network Security Groups (NSGs) and Application Security Groups (ASGs)
- Azure Firewall (Standard and Premium) with TLS inspection and IDPS
- Virtual WAN (vWAN) hub-and-spoke at scale
- ExpressRoute (circuits, peering, Global Reach, FastPath)
- VPN Gateway (S2S, P2S, VNet-to-VNet)
- Private Link and Private Endpoints for PaaS services
- User Defined Routes (UDRs) and Route Server
- VNet peering (local and global)
- Azure Front Door and Application Gateway (L7 load balancing + WAF)
- Azure Bastion for secure management access
- Service Endpoints and Service Tags

## How to Approach Tasks

1. **Classify** the request:
   - **Design** -- Load `references/architecture.md` for VNet patterns, vWAN design, ExpressRoute topology
   - **Security** -- Apply NSG, ASG, and Azure Firewall guidance below
   - **Connectivity** -- Determine if intra-VNet, inter-VNet, hybrid, or internet and apply relevant guidance
   - **Troubleshooting** -- Use NSG Flow Logs, Network Watcher, effective routes, effective NSG rules
   - **Automation** -- Apply Azure CLI, PowerShell, ARM template, Bicep, or Terraform guidance

2. **Gather context** -- Number of VNets, regions, subscriptions, traffic patterns, compliance requirements, existing ExpressRoute or VPN

3. **Analyze** -- Apply Azure-specific reasoning. Consider cost, availability (zone redundancy), and Azure-specific constraints (dedicated subnets, reserved IPs).

4. **Recommend** -- Provide actionable guidance with Azure CLI examples, portal paths, or IaC snippets

5. **Verify** -- Suggest validation steps (Network Watcher, NSG Flow Logs, effective routes)

## VNet Design

### Address Space Planning

- VNets support one or more IPv4/IPv6 address spaces
- Subnets subdivide the VNet address space -- cannot overlap
- Azure reserves 5 IPs per subnet (.0, .1, .2, .3, .255)
- Non-overlapping CIDRs required for VNet peering

### Dedicated Subnets

Azure requires dedicated subnets for certain services:

| Service | Subnet Name | Minimum Size |
|---|---|---|
| Azure Firewall | AzureFirewallSubnet | /26 |
| VPN Gateway | GatewaySubnet | /27 (recommended /26) |
| Azure Bastion | AzureBastionSubnet | /26 |
| Azure Route Server | RouteServerSubnet | /27 |
| Azure Application Gateway | Dedicated (any name) | /24 recommended |

### Subnet Architecture

```
VNet: 10.1.0.0/16

Frontend Subnet:         10.1.1.0/24    -- App Gateway, public-facing LBs
Application Subnet:      10.1.10.0/24   -- App services, AKS nodes
Data Subnet:             10.1.20.0/24   -- SQL, Cosmos DB private endpoints
Management Subnet:       10.1.30.0/26   -- Jump boxes, monitoring agents
AzureFirewallSubnet:     10.1.40.0/26   -- Azure Firewall
GatewaySubnet:           10.1.50.0/27   -- VPN/ExpressRoute Gateway
AzureBastionSubnet:      10.1.60.0/26   -- Azure Bastion
```

## Network Security Groups (NSGs)

Stateful packet filtering at subnet and NIC level:
- Priority-based rules (100-4096, lower number = higher priority)
- Source/Destination: IP, CIDR, Service Tag, or ASG
- Action: Allow or Deny
- Both inbound and outbound rules
- NSGs can be associated with subnets AND NICs simultaneously (both evaluated)

### Service Tags

Pre-defined IP ranges for Azure services that update automatically:

| Service Tag | Description |
|---|---|
| `VirtualNetwork` | VNet address space + peered VNets + VPN-connected networks |
| `AzureLoadBalancer` | Azure health probe source IPs |
| `Internet` | All public IP addresses |
| `AzureCloud` | All Azure public IPs (region-specific variants available) |
| `Storage` | Azure Storage service IPs |
| `Sql` | Azure SQL Database service IPs |
| `AzureActiveDirectory` | Azure AD service IPs |
| `AzureMonitor` | Azure Monitor and Log Analytics IPs |

### Default NSG Rules

| Priority | Name | Direction | Source | Destination | Action |
|---|---|---|---|---|---|
| 65000 | AllowVnetInBound | Inbound | VirtualNetwork | VirtualNetwork | Allow |
| 65001 | AllowAzureLoadBalancerInBound | Inbound | AzureLoadBalancer | * | Allow |
| 65500 | DenyAllInBound | Inbound | * | * | Deny |
| 65000 | AllowVnetOutBound | Outbound | VirtualNetwork | VirtualNetwork | Allow |
| 65001 | AllowInternetOutBound | Outbound | * | Internet | Allow |
| 65500 | DenyAllOutBound | Outbound | * | * | Deny |

### Application Security Groups (ASGs)

Group VMs into logical roles for NSG rules without managing IPs:

```
ASG: WebServers
ASG: AppServers
ASG: DBServers

NSG Rule: Allow WebServers -> AppServers:8080
NSG Rule: Allow AppServers -> DBServers:1433
NSG Rule: Deny * -> DBServers:*
```

- VMs assigned to ASGs via NIC configuration
- Multiple ASGs per NIC supported
- ASGs update automatically as VMs are added/removed

## Azure Firewall

### Standard vs Premium

| Feature | Standard | Premium |
|---|---|---|
| L3/L4 filtering | Yes | Yes |
| FQDN filtering | Yes (HTTP/S) | Yes |
| Threat intelligence | Alert only | Alert + Deny |
| TLS inspection | No | Yes (MITM with CA cert) |
| IDPS | No | Yes (58,000+ signatures) |
| URL filtering | No (FQDN only) | Yes (full URL path) |
| Web categories | No | Yes (content filtering) |

### Deployment Pattern

```
Hub VNet:
  AzureFirewallSubnet -> Azure Firewall (10.1.40.4)

Spoke VNets:
  UDR on all subnets: 0.0.0.0/0 -> 10.1.40.4 (Azure Firewall private IP)
  VNet peering to Hub with "Use Remote Gateway" enabled
```

### Azure Firewall Policy

- Hierarchical policy: Parent policy (org-wide rules) -> Child policy (workload-specific)
- Rule collection groups -> Rule collections -> Rules
- Processing order: DNAT rules -> Network rules -> Application rules
- Inherit parent policy rules -- child cannot override parent deny

### IDPS Modes (Premium)

- **Alert mode**: Log matching signatures, do not block
- **Alert and Deny mode**: Block matching traffic and log
- Private IP ranges: Configure which source CIDRs are considered internal
- Signature management: enable/disable individual signatures, import custom signatures

## Virtual WAN (vWAN)

### Architecture

```
vWAN
  Hub-EastUS (Standard)
    |- VPN Gateway
    |- ExpressRoute Gateway
    |- Azure Firewall (Secured Hub)
    |- Spoke VNet: Prod-East
    |- Spoke VNet: Dev-East

  Hub-WestEU (Standard)
    |- VPN Gateway
    |- ExpressRoute Gateway
    |- Spoke VNet: Prod-West
    
  Hub-to-Hub peering (automatic)
```

### Hub Types

- **Basic**: S2S VPN only. No ER, no P2S, no firewall integration.
- **Standard**: Full feature set -- VPN, ER, P2S, Azure Firewall, NVA, routing policies.

### Routing Intent

Force all traffic (private and/or internet) through Azure Firewall or NVA:
- **Internet traffic routing intent**: All internet-bound traffic from spokes goes through hub firewall
- **Private traffic routing intent**: All inter-VNet and branch traffic goes through hub firewall
- Eliminates manual UDR management on spoke VNets

### vWAN vs Hub-and-Spoke (Manual)

| Aspect | vWAN | Manual Hub-and-Spoke |
|---|---|---|
| Routing | Automatic BGP propagation | Manual UDRs |
| Multi-region | Hub-to-hub auto-peering | Manual VNet peering + gateway transit |
| Scalability | Managed by Azure | Manual NVA sizing |
| Firewall | Secured Hub integration | Azure Firewall in hub VNet |
| Cost | Higher (managed infrastructure) | Lower (DIY) |
| Flexibility | Less (managed constraints) | More (full control) |

## ExpressRoute

### Circuit and Peering

- **Circuit**: Ordered through connectivity provider (AT&T, Equinix, etc.)
- **Bandwidth**: 50 Mbps to 100 Gbps
- **Peering types**: Azure Private (VNets), Microsoft Peering (M365, Dynamics)
- **ExpressRoute Gateway**: Deployed in GatewaySubnet; connects VNet to circuit
- **Gateway SKUs**: Standard, HighPerformance, UltraPerformance, ErGw1-3AZ (zone-redundant)

### FastPath

- Bypasses ExpressRoute Gateway for data plane traffic
- Traffic goes directly from circuit to VNet (lower latency, higher throughput)
- Requires UltraPerformance or ErGw3AZ gateway SKU
- Control plane still uses the gateway

### Global Reach

- Connect two on-premises sites through Azure ExpressRoute backbone
- Site-A ER circuit <-> Azure backbone <-> Site-B ER circuit
- No Azure VNet traversal -- purely backbone connectivity
- Use case: connect two data centers via Microsoft's global network

## Private Link

### Private Endpoints

- NIC with private IP in your VNet pointing to a PaaS service
- Supported services: Storage, SQL Database, Key Vault, Cosmos DB, App Service, ACR, etc.
- Disables public access to the PaaS resource when private endpoint is configured
- DNS: Private DNS Zone maps service FQDN to private endpoint IP

### DNS Configuration

```
Resource: mystorageaccount.blob.core.windows.net
Without Private Endpoint: resolves to public IP
With Private Endpoint:    resolves to 10.1.20.10 (private endpoint IP)

Private DNS Zone: privatelink.blob.core.windows.net
  A Record: mystorageaccount -> 10.1.20.10
```

- Link Private DNS Zone to VNets that need to resolve private endpoint
- On-premises DNS: configure conditional forwarder for `privatelink.*.core.windows.net` to Azure DNS (168.63.129.16) via DNS proxy in Azure

### Private Link Service

- Expose your own Standard Load Balancer-backed service
- Consumer creates a Private Endpoint pointing to your service
- NAT applied: consumer sees a private IP, your service sees the NAT IP (not the consumer's IP)
- Approval workflow: auto-approve or manual approval per consumer

## Route Server

- Enables BGP peering between NVAs (Cisco, Palo Alto, etc.) and Azure SDN
- NVA advertises routes to Route Server; Route Server injects them into VNet effective routes
- Eliminates manual UDR management for dynamic routing scenarios
- Supports branch-to-branch via NVA with ECMP
- Deployed in RouteServerSubnet (/27)

## Troubleshooting Tools

### Network Watcher

- **IP Flow Verify**: Test if traffic is allowed/denied between two IPs (checks NSG rules)
- **Next Hop**: Determine the next hop for a given source/destination (checks effective routes)
- **Connection Troubleshoot**: End-to-end connectivity test between resources
- **NSG Diagnostics**: Show which NSG rule is allowing/denying specific traffic
- **Topology**: Visual map of VNet resources and connections

### Effective Routes and NSG Rules

```bash
# Effective routes on a NIC
az network nic show-effective-route-table --resource-group <rg> --name <nic-name>

# Effective NSG rules on a NIC
az network nic list-effective-nsg --resource-group <rg> --name <nic-name>
```

### NSG Flow Logs

```bash
# Enable NSG Flow Logs
az network watcher flow-log create \
  --resource-group <rg> \
  --nsg <nsg-name> \
  --storage-account <storage-id> \
  --enabled true \
  --format JSON \
  --log-version 2
```

## Common Pitfalls

1. **Missing UDR for Azure Firewall** -- Azure Firewall does not attract traffic automatically. Every spoke subnet needs a UDR with 0.0.0.0/0 pointing to the firewall's private IP. Alternatively, use vWAN Routing Intent.

2. **GatewaySubnet NSG restrictions** -- Applying an NSG to GatewaySubnet can break VPN/ExpressRoute connectivity. If you must use an NSG, ensure you allow all gateway-required ports. Microsoft recommends no NSG on GatewaySubnet.

3. **Private DNS Zone not linked** -- Creating a Private Endpoint without linking the Private DNS Zone to the consumer VNet causes DNS resolution to return the public IP instead of the private endpoint IP.

4. **Azure Firewall Premium in vWAN** -- Secured Virtual Hubs support Azure Firewall Standard but not Premium. For Firewall Premium, deploy in a spoke VNet connected to the hub.

5. **VNet peering non-transitivity** -- VNet-A peered to Hub and VNet-B peered to Hub does not mean A can reach B. Enable "Allow Gateway Transit" on hub and "Use Remote Gateway" on spokes, with UDRs pointing to the hub NVA/Firewall.

6. **ExpressRoute Gateway bottleneck** -- Standard and HighPerformance gateway SKUs have limited throughput. Use ErGw3AZ for high-throughput workloads and enable FastPath to bypass the gateway for data plane traffic.

7. **Service Endpoint vs Private Endpoint confusion** -- Service Endpoints route traffic to PaaS over the Azure backbone but the PaaS resource still has a public IP. Private Endpoints give PaaS a private IP in your VNet. For security-sensitive workloads, use Private Endpoints.

## Reference Files

Load these when you need deep knowledge:

- `references/architecture.md` -- VNet internals, vWAN architecture, ExpressRoute topology, Azure Firewall implementation, Private Link DNS integration, Route Server BGP mechanics. Read for design and troubleshooting questions.