Skip to main content

Technical Lab: Implement Gateway Load Balancer

Questions​

Question 1 — Multiple Choice​

When configuring a Gateway Load Balancer, it's necessary to chain this resource with an existing standard public load balancer. What is the correct mechanism to establish this chaining?

A) Create an inbound NAT rule in the Standard Load Balancer pointing to the Gateway Load Balancer's frontend IP.

B) Associate the Gateway Load Balancer's provider configuration directly to the Standard Load Balancer's backend pool.

C) Reference the Gateway Load Balancer's frontend IP in the Standard Load Balancer's frontend configuration through the Gateway Load Balancer field.

D) Insert the Gateway Load Balancer's IP address as a backend server in the Standard Load Balancer's pool.

Question 2 — Technical Scenario​

A security team deployed a set of Network Virtual Appliances (NVAs) for traffic inspection and wants to use them with a Gateway Load Balancer. During testing, they notice that inspected traffic returns to the client with a different source IP address than expected, breaking stateful application sessions. Analyze the configuration below:

Gateway Load Balancer Backend Pool:
  - NVA-1: external tunnel port 10800, internal tunnel port 10801
  - NVA-2: external tunnel port 10800, internal tunnel port 10801

Load balancing rule:
  - Protocol: All
  - Frontend IP: GatewayLB-Frontend
  - Backend Pool: NVA-Pool
  - Session persistence: None

What is the most likely cause of the unexpected behavior?

A) Session persistence is disabled, causing packets from the same session to be sent to different NVAs that don't share state.

B) Internal and external tunnel ports are identical between NVAs, causing conflict in return traffic routing.

C) Protocol All is not supported in Gateway Load Balancer rules and is silently ignoring VXLAN encapsulation.

D) NVAs need their own public IP address for the Gateway Load Balancer to correctly forward return traffic.

Question 3 — True or False​

A Gateway Load Balancer can be chained simultaneously with multiple frontend resources from different Standard Load Balancers or public IP addresses of VMs, allowing a single set of NVAs to inspect traffic from multiple distinct sources without additional configurations per source.

Question 4 — Technical Scenario​

An architect needs to ensure that all inbound traffic destined to a VM with a public IP in Azure passes through an inspection appliance before reaching the VM, without changing the VM's network configuration or installing agents on it. He proposes the architecture below:

Internet
    |
    v
VM Public IP (Standard SKU)
    |
    v
[Chaining with Gateway Load Balancer]
    |
    v
NVA (inspection)
    |
    v
Target VM (no configuration change)

Which statement correctly describes the behavior of this architecture?

A) The architecture is valid, but requires the VM's public IP to be replaced by a Standard Load Balancer frontend IP, as chaining with direct VM public IP is not supported.

B) The architecture is valid and supported: Standard SKU public IPs associated with VMs can be chained with a Gateway Load Balancer in the same way as Standard Load Balancer frontends.

C) The architecture is invalid because the Gateway Load Balancer operates exclusively at layer 7 and cannot inspect layer 4 traffic destined directly to a VM.

D) The architecture is valid, but the target VM needs to have its public IP removed and replaced with a private IP, as the Gateway Load Balancer doesn't coexist with public IPs on the same network adapter.

Question 5 — Multiple Choice​

The Gateway Load Balancer uses an encapsulation mechanism to transport traffic between the balancer and the NVAs in the backend pool. What is the direct consequence of this encapsulation for the NVAs that integrate the backend pool?

A) NVAs receive traffic already decapsulated with the original destination IP preserved, without requiring any additional interface configuration.

B) NVAs must be configured to terminate and re-encapsulate traffic using the VXLAN-GPE protocol, as the Gateway Load Balancer doesn't perform automatic decapsulation before backend delivery.

C) NVAs receive encapsulated traffic and need to process only the external header, discarding the original payload after inspection.

D) NVAs must expose a network interface dedicated exclusively to the Gateway Load Balancer, separate from the interface used for communication with other networks.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: C

The chaining between a consumer resource (public Standard Load Balancer or VM public IP) and the Gateway Load Balancer is done by referencing the Gateway Load Balancer's frontend IP configuration in the corresponding field of the consumer resource's frontend configuration. This link instructs Azure to redirect traffic through the Gateway Load Balancer before delivering it to the final destination.

Alternatives A and D represent the misconception of treating the Gateway Load Balancer as a conventional backend destination, which is not its function. Alternative B confuses terminology: "provider configuration" relates to the Gateway Load Balancer's own backend pool configuration, not the chaining mechanism with consumer resources.

Answer Key — Question 2​

Answer: A

The Gateway Load Balancer distributes traffic among backend pool NVAs using a 5-tuple hash algorithm by default. With session persistence disabled, packets belonging to the same TCP session can be forwarded to different NVAs. Since stateful inspection appliances maintain local state tables, an NVA that receives only part of a session doesn't have complete context, resulting in incorrect responses or packet drops.

Alternative B is a plausible distractor, but identical ports between distinct NVAs is the expected and correct behavior in the Gateway Load Balancer tunnel model: each NVA has its own tunnel identity defined by the (IP, port) pair. Alternative C is false: the All protocol is explicitly supported. Alternative D reverses the logic: NVAs in the Gateway Load Balancer backend pool must have private IPs, not public ones.

Answer Key — Question 3​

True

A single Gateway Load Balancer can be chained with multiple independent consumer resources, whether frontends from different public Standard Load Balancers or public IPs from distinct VMs. Each consumer resource individually configures chaining by pointing to the same Gateway Load Balancer frontend IP. This allows centralizing traffic inspection from multiple sources into a single set of NVAs, without requiring additional Gateway Load Balancer configurations per chained source.

This behavior is fundamental for centralized security models in hub-and-spoke architectures or scenarios where multiple public services share the same security appliance.

Answer Key — Question 4​

Answer: B

The Gateway Load Balancer supports chaining not only with Standard Load Balancer frontends, but also directly with Standard SKU public IPs associated with VM network interfaces. This is exactly the described use case: complete transparency for the target VM, without changing its configuration, and intermediate inspection by NVAs.

Alternative A represents a common misconception: assuming only Standard Load Balancers can be consumers. Alternative C is incorrect because the Gateway Load Balancer operates at layer 3/4 (not layer 7) and uses VXLAN-GPE to forward packets without inspecting them itself. Alternative D contradicts the product's functionality: the VM keeps its public IP; chaining is configured on that same public IP, it doesn't replace it.

Answer Key — Question 5​

Answer: B

The Gateway Load Balancer encapsulates traffic using VXLAN with Generic Protocol Extension (VXLAN-GPE) when sending it to backend pool NVAs. NVAs are responsible for terminating this encapsulation, inspecting or processing the original payload, and re-encapsulating the traffic before returning it to the Gateway Load Balancer. This model preserves the original client and destination IP addresses, making inspection transparent to both sides of the communication.

Alternative A is the most dangerous misconception: assuming NVAs receive already decapsulated traffic would lead to an incorrect configuration that would simply drop encapsulated packets. Alternative C distorts the model: NVAs process the complete payload, not just the external header. Alternative D confuses the Gateway Load Balancer with solutions requiring dedicated interfaces per traffic type, which is not a requirement for this service.