7.7 Secure Networking Case Lab

Case background

Contoso is deploying a production application in Azure. The network team requires a hub-and-spoke design in East US, no public IP addresses on workload VMs, centralized outbound inspection, private access to a storage account, and administrator access through a managed service. The app has web VMs, app VMs, and a storage account used for private blob access.

Target design:

                         internet
                            |
                    Azure Firewall public IP
                            |
                  hub-vnet 10.40.0.0/16
         AzureBastionSubnet | AzureFirewallSubnet
                            |
             peering with forwarded traffic
                            |
                spoke-prod 10.41.0.0/16
        snet-web 10.41.1.0/24 | snet-app 10.41.2.0/24 | snet-pe 10.41.10.0/24
              web VMs          app VMs                  storage private endpoint

The administrator must implement controls without breaking required flows. Web VMs must reach app VMs on TCP 8080. App VMs must reach the storage account blob endpoint privately. All VM outbound internet traffic must go through Azure Firewall. Administrators must connect to VMs by private IP through Azure Bastion.

Build sequence

Start with address spaces. The hub uses 10.40.0.0/16, and the spoke uses 10.41.0.0/16. These do not overlap with each other or the corporate network. Create required subnets in the hub: AzureBastionSubnet for Bastion and AzureFirewallSubnet for Azure Firewall. Create workload subnets in the spoke for web and app tiers, plus a separate private endpoint subnet.

Next, peer the hub and spoke. Allow virtual network access. If the firewall will forward traffic between spokes or from spokes to other networks, allow forwarded traffic where required. If the hub later hosts a VPN gateway and the spoke must use it, the hub peering must allow gateway transit and the spoke peering must use remote gateways. In this lab, the central requirement is firewall egress, so route tables are the immediate focus.

Associate a route table to spoke workload subnets. Add a default route 0.0.0.0/0 with next hop type Virtual appliance and next hop address equal to the Azure Firewall private IP. If app-to-storage private endpoint traffic is inside the VNet prefix, do not accidentally blackhole it with an overly specific route. Use effective routes to prove the selected next hop for both internet and private endpoint destinations.

Security rule design

Create ASGs for tiers: asg-web and asg-app. Associate VM NICs to the correct ASGs. On the web subnet NSG, allow inbound HTTPS from the approved frontend source if the design publishes traffic there. In this chapter's secure access lab, direct internet-to-VM access is not allowed, so management ports from Internet should remain denied. On the app subnet NSG, allow inbound TCP 8080 from asg-web to asg-app. Deny broad lateral movement if the requirement asks for tier isolation.

Example rule plan:

The deny for management from Internet may be redundant because default rules deny unsolicited inbound internet, but explicit rules often make intent clear. Be careful with explicit denies. If you deny all VirtualNetwork inbound before allowing web-to-app traffic, you will block the required flow.

Private storage access

Create a private endpoint for the storage account blob subresource in snet-pe. Integrate it with the appropriate private DNS zone, and link the zone to the spoke VNet. If clients in the hub or on-premises also need to resolve the same name, plan DNS forwarding or additional VNet links according to the environment.

Validation from an app VM should include name resolution and connectivity:

nslookup contosoprodstore.blob.core.windows.net
curl -I https://contosoprodstore.blob.core.windows.net/

The expected DNS result is a private IP from the private endpoint subnet, not a public address. If the storage account public network access is disabled and DNS returns a public address, the request will fail. Do not fix that by adding a VM public IP. Fix private DNS or the resolver path.

Bastion management path

Deploy Azure Bastion in the hub if the hub is designed to provide shared management and network paths allow Bastion to reach spoke VMs, or deploy it in the spoke if the design is smaller. The VMs should not have public IP addresses. Administrators connect through Bastion to the private IPs on TCP 3389 or 22.

Troubleshoot Bastion by checking the VM state, VM private IP, peering, NSG rules from the Bastion subnet to the VM, guest firewall, and whether RDP or SSH is enabled in the OS. Do not open management ports from Internet just because a connection fails. That violates the requirement and usually misses the real problem.

Failure drill 1: app cannot reach storage

Symptoms: app VM resolves contosoprodstore.blob.core.windows.net to a public IP, and the storage account has public network access disabled. Effective routes to the public IP go to Azure Firewall, but firewall logs show denies.

Correct diagnosis: private endpoint DNS is not working for the app VM. The private endpoint may exist, but the private DNS zone is not linked to the spoke VNet or custom DNS is not forwarding the private zone. The fix is to configure the private DNS zone and resolver path so the storage FQDN resolves to the private endpoint IP.

Wrong exam answers: assign a public IP to the app VM, enable RDP from Internet, remove all NSGs, or change the VNet address space. None of those addresses the private endpoint DNS failure.

Failure drill 2: web cannot reach app on 8080

Symptoms: web VM can resolve the app VM private name, but TCP 8080 times out. Network Watcher next hop shows VirtualNetwork, so routing is local. IP flow verify on the app VM inbound path reports denied by an NSG rule.

Correct diagnosis: NSG effective security rules block web-to-app traffic. Fix the app subnet or NIC NSG with a lower-priority-number allow rule from asg-web to asg-app on TCP 8080, before any broad deny rule. Then verify the app process listens on 8080 and the guest firewall permits it.

Wrong exam answers: add a NAT Gateway, create a public IP, or enable gateway transit. The flow is private and local; the failure is a security rule or host listener problem.

Failure drill 3: outbound partner API uses the wrong source IP

Symptoms: a partner API allowlists the Azure Firewall public IP, but some requests arrive from a different Azure public IP. Effective routes show one subnet has the default route to the firewall, while another subnet has no route table association and uses a different outbound path.

Correct diagnosis: route table association is inconsistent. Associate the egress route table with all required workload subnets or standardize on NAT Gateway if the design uses NAT instead of firewall. Then confirm firewall policy, SNAT behavior, and partner allowlist.

Final AZ-104 workflow

When the case study is long, write down the packet: source, destination, protocol, and port. Then answer in this order: DNS result, effective route, next hop, NSG effective rule, appliance or firewall policy, destination listener, and return path. This keeps you from overreacting to keywords.

If the requirement says no public IPs on VMs, do not choose a direct VM public IP as a convenience fix. If the requirement says private endpoint, validate private DNS. If the requirement says hub firewall, validate UDRs and forwarded traffic. If the requirement says identify the blocking rule, use IP flow verify or effective security rules. That is the administrator mindset AZ-104 is testing.