Skip to content
Build Cloud Skills
Blog

Load Balance and Route Internet Traffic

In this lab, you will configure an External Load Balancer, Public IP, and Network Security Groups (NSGs) to securely publish a web application to the internet. You will also configure outbound traffic from your web application subnet to be routed through a Linux-based Network Virtual Appliance (NVA) using a User Defined Route (UDR). The NVA will act as a simple packet forwarder (firewall).

Pre-Provisioned Resources

The following resources are already deployed for you: Pre-provisioned environment

  • Virtual Network: vnet-webapp (10.0.0.0/16) with:
    • subnet-web (10.0.1.0/24) – for web VMs
    • subnet-nva (10.0.2.0/24) – for the NVA
  • Virtual Machines:
    • webvm1 and webvm2 (Ubuntu, Nginx pre-installed) in subnet-web
    • nva-vm (Ubuntu, IP forwarding enabled) in subnet-nva
  • NSG: Attached to subnet-web with default rules
  • No public IPs on VMs
  • NVA VM is configured to forward packets (IP forwarding enabled, basic firewall rules applied to allow forwarding)
  • Internet connectivity is available via the NVA

Connection Details

  • You will not SSH directly to the VMs. All access is via the Load Balancer’s public IP.

Your Tasks

Task 1: Create a Public IP and External Load Balancer

  1. In the Azure portal, create a Standard Public IP named web-lb-pip in RG-WebApp-Lab.
  2. Create a Standard Load Balancer named web-lb:
    • Region: Same as resource group
    • Type: Public
    • SKU: Standard
    • Frontend IP: Use web-lb-pip
    • Backend pool: Add webvm1 and webvm2 (use their NICs)
  3. Create a health probe:
    • Protocol: TCP
    • Port: 80
  4. Create a load balancing rule:
    • Frontend port: 80
    • Backend port: 80
    • Protocol: TCP
    • Health probe: Use the probe created above

lab with loadbalancer

Task 2: Update NSG to Allow Only HTTP/HTTPS

  1. In the portal, go to the NSG attached to subnet-web.
  2. Add an Allow inbound rule:
    • Priority: 100
    • Source: Any
    • Destination: Any
    • Protocol: TCP
    • Port: 80, 443
    • Action: Allow
  3. Ensure the default deny rule blocks all other inbound traffic.

Lab with NSG rule

Task 3: Validate Load Balancer and Security

  1. In the portal, get the public IP address of web-lb-pip.
  2. In your browser, navigate to http://<public-ip>.
    • You should see the Nginx welcome page from either webvm1 or webvm2.
    • Refresh several times to confirm load balancing.
  3. Attempt to connect to any other port (e.g., http://<public-ip>:22 or :3389).
    • Connection should fail (blocked by NSG).

Task 4 (Optional): Introduce Asymmetric Routing

Routing outbound traffic through the NVA using a UDR is a common practice in Azure for security and monitoring, but if you apply a default route to a subnet that also handles inbound traffic from a public Load Balancer, you can unintentionally break those inbound connections due to asymmetric routing. This is a common pitfall when combining UDRs and public Load Balancers.

  1. Create a Route Table:

    • Name: rt-web-to-nva
    • Resource Group: RG-WebApp-Lab
    • Region: Same as VNet

  2. Add a Route to the Route Table:

    • Route name: default-to-nva
    • Address prefix: 0.0.0.0/0
    • Next hop type: Virtual appliance
    • Next hop address: Private IP address of nva-vm (find this in the portal under nva-vm’s NIC)

  3. Associate the Route Table:

    • Associate rt-web-to-nva with subnet-web.

  4. Verify NVA Forwarding:

    • The NVA (nva-vm) is already configured to forward packets (IP forwarding enabled).
    • Outbound internet traffic from webvm1 and webvm2 should now flow through the NVA.
    • You can test this by checking the NVA’s network interface metrics or by running a packet capture on the NVA.

Lab with NSG rule

Lab Note: Asymmetric Routing and Public Load Balancer

When you associate a route table with a default route (0.0.0.0/0) pointing to the NVA (virtual appliance) to the web subnet, all outbound traffic—including replies to inbound connections from the public Load Balancer—will be sent to the NVA.

This causes asymmetric routing: inbound packets arrive via the Load Balancer, but return packets are sent out via the NVA. Because the NVA did not see the original inbound packets, it cannot properly handle or NAT the return traffic. As a result, connections from the Internet to your web app via the Load Balancer will fail after this step.

This is expected behavior in Azure and is a common scenario when using UDRs with public Load Balancers. It is not a valid production architecture, but it is useful for demonstrating the effects of UDRs and asymmetric routing.

Be sure to complete all inbound validation (Task 3) before applying the UDR in Task 4.

Success Criteria

  • The web application is accessible via the Load Balancer’s public IP on HTTP (port 80).
  • Only HTTP/HTTPS traffic is allowed inbound; all other inbound traffic is blocked.
  • Load Balancer distributes requests between both VMs.
  • Outbound internet traffic from the web VMs is routed through the NVA VM.

Optional Challenge

  • Add a load balancing rule for HTTPS (port 443).
  • Configure session persistence on the Load Balancer.
  • Deploy a custom HTML page to each VM to verify which VM serves each request.
  • Configure the NVA to log or restrict outbound traffic for additional security.