Azure Hub-and-Spoke Asymmetric Routing with a Load-Balanced Gateway Pair
Contoso migrated a three-tier application to Azure. The hub VNet contains two CloudGuard gateways behind an Azure Standard Load Balancer. Three spoke VNets host web, app, and database tiers. User-defined routes in every spoke send 0.0.0.0/0 to the load balancer frontend IP. SSH from the jump host to Linux VMs in spoke A sometimes connects and sometimes times out; HTTPS to the same VMs resets after login. SmartConsole logs show 'TCP packet out of state' and 'First packet isn't SYN' for the failing sessions. The gateways are configured as an HA pair, but the Azure load balancer rule uses a 5-tuple hash and floating IP is disabled. The platform team can make one change this weekend and cannot redesign the VNets. No third-party network virtual appliance is approved; CloudGuard is the only inspection product.
1. Diagnose the root cause of the intermittent SSH and HTTPS failures.
Read the worked answer
The failures are consistent with asymmetric routing across the two gateways, not with a bad application or a bad NSG. The spoke UDR sends all traffic to the load balancer frontend. The Azure load balancer uses a 5-tuple hash, and the return direction has a different 5-tuple from the forward direction. As a result, the forward SYN can be sent to gateway A while the return SYN-ACK is sent to gateway B. Gateway B has no state for that connection and drops the packet, producing 'First packet isn't SYN' and 'TCP packet out of state'. Some flows work because both directions happen to hash to the same gateway.
SSH 'sometimes connects' and HTTPS 'resets after login' fit this pattern: the initial handshake may land on one gateway, while a later flow or a reconnection lands on the other. The HA pair does not help if cluster state sync is not carrying the connection state, and floating IP being disabled means the gateway may not correctly receive traffic addressed to the load balancer frontend as the cluster address.
2. What single change should the team make this weekend, and what must be verified immediately after?
Read the worked answer
Enable floating IP on the Azure load balancer rule and align the CloudGuard cluster virtual IP with the load balancer frontend IP. In Azure, floating IP (direct server return) is the setting that lets the backend gateway receive traffic destined to the load balancer frontend and answer as the cluster address. Without it, the gateway sees a different destination and the HA pair cannot behave as one inspection point.
Immediately after the change, verify: the load balancer health probe is green on both gateways; the cluster VIP is the frontend IP; state sync is active between the gateways; and a repeated SSH and HTTPS test from the jump host succeeds when the flow is forced to each gateway in turn. Also confirm that the spoke UDR still points to the frontend IP and that no NSG rule blocks the probe or the cluster sync ports.
Do not treat this as a substitute for proper HA design. If state sync is not working, floating IP alone will reduce but not eliminate the intermittent drops, and the team should be prepared to run a single gateway temporarily while fixing sync.
3. Why is disabling source/destination check not the fix here, and what would that step indicate about the design?
Read the worked answer
Source/destination check is an AWS EC2 instance attribute, not an Azure load balancer setting. In AWS, disabling it lets an instance receive traffic not addressed to its own ENI, which is relevant for some appliance designs. In Azure, the equivalent concern is handled by the load balancer rule, floating IP, and the guest OS and NSG configuration. Telling the team to disable source/destination check in Azure is a category error and would not address the 5-tuple rehash.
If someone proposes that step, it indicates the design is being translated from AWS without checking the Azure data path. The correct Azure questions are: does the load balancer rule have floating IP enabled, is the gateway cluster VIP bound to the frontend, are the health probes using the right port, and is state sync passing? Those questions target the actual failure. The AWS attribute may still matter if the same team runs CloudGuard in AWS, but it is not part of this Azure fix and should not delay the weekend change.