In Azure, a DMZ (Demilitarized Zone) can be implemented using both a public subnet and a private subnet within a virtual network (VNet). This design allows segmentation of public-facing resources from internal components that require tighter security.

DMZ Subnet Responsibilities

• Public Subnet: Application Gateway, Azure Firewall DNAT targets, or public web servers accessible via public IP.
• Private Subnet: Backend services such as API servers or inspection appliances that should not be internet-facing.

Traffic Flow

1. User sends a request to the public IP (e.g., Application Gateway) in the Public Subnet.
2. Application Gateway routes traffic to VMs or services in the Private Subnet.
3. Backend services in the Private Subnet may query internal services (e.g., databases) in a separate internal subnet or VNet.

NSG Rules (Azure Network Security Groups)

1. DMZ Public Subnet → DMZ Private Subnet

2. DMZ Private Subnet → Internal Subnet (Separate VNet or Subnet)

Azure Firewall Rules (if using Azure Firewall)

If using Azure Firewall between DMZ and internal networks, rules would be configured in the Firewall Policy:

• Allow DNAT or Application rules from public IP to internal web service
• Allow network rules from Private Subnet IPs to DB or APIs in Internal Subnet
• Deny all other traffic not explicitly allowed

Best Practices

• Use NSGs to restrict traffic at the subnet or NIC level
• Inspect east-west traffic using Azure Firewall or NVA appliances
• Enable logging with NSG Flow Logs and Azure Monitor
• Use Azure Private Link to access PaaS services securely from Private Subnet

The post Azure DMZ Architecture appeared first on Azure Security Architect.

Setting up an ExpressRoute connection is just the beginning. To ensure high availability, performance, and fast incident response, configuring comprehensive monitoring and alerting is critical.

Types of Alerts: Circuit-Level vs. Gateway-Level

Azure Monitor supports alerts at both the ExpressRoute circuit level and the gateway level.

Circuit-Level Alerts

These focus on peering and protocol availability:

• ARP Availability Down: Alerts when Address Resolution Protocol traffic drops below 100% for a peering type.

• BGP Availability Down: Triggers when BGP peering sessions go inactive.

Use dimensions like Peering Type and Peer when defining these metrics to get precise and actionable data.

Gateway-Level Alerts

Set up alerts for ExpressRoute gateway connections to monitor overall connection health. To create one:

1. Navigate to Azure Monitor > Alerts > + Create Alert Rule.

2. Select the ExpressRoute Gateway as the resource.

3. Choose the signal type (metrics, activity logs, or resource health).

4. Set conditions, thresholds, and actions.

5. Assign an action group (email, webhook, ITSM, etc.).

:::image type=”content” source=”./media/expressroute-monitoring-metrics-alerts/signal.png” alt-text=”Azure Monitor signal selection for ExpressRoute”:::

Alerts by Peering Dimension

Azure lets you create alert rules scoped by peering or individual peers, so you can zero in on specific routes or VNETs for diagnostics.

:::image type=”content” source=”./media/expressroute-monitoring-metrics-alerts/alerts-peering-dimensions.png” alt-text=”Alert scoped by peering dimension”:::

Monitoring with Logs

• Activity Logs: Capture control plane events like route changes and BGP resets.

• Resource Logs: Set diagnostic settings to collect route metrics and session status.

• NSG Flow Logs: Useful for diagnosing network-level anomalies.

• Route Diagnostic Logs: Inspect BGP route advertisements and withdrawals.

Troubleshooting Tips

If ICMP works (ping) but no app-level connectivity (SSH, RDP, SQL), check:

• GatewaySubnet settings: No NSG or NAT gateway should be attached.

• Route Table (UDR): Set to None for GatewaySubnet.

• Connection state: Look for aged-out TCP sessions vs. proper FIN/CLOSE events.

The post Azure ExpressRoute Troubleshooting and Alerts appeared first on Azure Security Architect.