Must the Gateway Load Balancer Frontend IP be in its own subnet?

Question

Must the Gateway Load Balancer Frontend IP be in its own subnet?

Martin Bright 20

hi!

Recently our deployments with Azure Gateway Load Balancers stopped forwarding traffic back to their chained public load balancers. To solve the issue, we put the GWLB frontend IPs in dedicated subnets beside our NVAs. Is this necessary? Has anything changed to cause this behavior?

Sai Prasanna Sinde 5,485 Reputation points Microsoft External Staff

2025-03-17T08:10:21.11+00:00
@Martin Bright

You mentioned that the GWLB frontend IP and the cPacket broker scale set were in the same subnet. When traffic arrived at the GWLB, it was forwarded to the cPacket broker. When the cPacket broker tried to send traffic to the chained public load balancer, it might have been using the system routes, potentially bypassing the GWLB.

If you had UDRs in place to force traffic through the GWLB, these UDRs might have been conflicting with the system routes within the same subnet. This could have led to unexpected behavior.

NVAs can alter packet headers. Depending on the NVA, it can change the source IP of the traffic. When the return traffic came back, if the GWLB was expecting the original source IP, it would not recognize it.

Kindly let us know if the above helps or you need further assistance on this issue.
Sai Prasanna Sinde 5,485 Reputation points Microsoft External Staff

2025-03-18T09:45:05.1733333+00:00

Hi @Martin Bright

Did you get a chance to review my latest comment? Please let me know if it was helpful or if you have any further questions.
Martin Bright 20 Reputation points

2025-03-18T14:14:54.3766667+00:00

hi Sai,

The cPacket packet broker interacts exclusively with the GWLB IP. There are no UDRs that might have conflicted with the subnet. We also do not alter the packet headers.
Venkat V 1,800 Reputation points Microsoft External Staff

2025-03-19T16:56:35.6+00:00

Hi @Martin Bright

As I can see, the MS Doc also suggests that the Gateway Load Balancer Frontend IP should be in a dedicated subnet (default subnet) instead of another subnet.

In the meantime, I'll check the same scenario in my environment and confirm the behavior.
Martin Bright 20 Reputation points

2025-03-19T22:05:01.22+00:00

Well, no, the document you provided says to deploy the NVAs in the same subnet as the GWLB frontend IP: the default subnet. This doesn't work for us.

Accepted answer

1 additional answer

Your answer

Sai Prasanna Sinde 5,485 Reputation points Microsoft External Staff

2025-03-17T08:10:21.11+00:00

@Martin Bright

You mentioned that the GWLB frontend IP and the cPacket broker scale set were in the same subnet. When traffic arrived at the GWLB, it was forwarded to the cPacket broker. When the cPacket broker tried to send traffic to the chained public load balancer, it might have been using the system routes, potentially bypassing the GWLB.

If you had UDRs in place to force traffic through the GWLB, these UDRs might have been conflicting with the system routes within the same subnet. This could have led to unexpected behavior.

NVAs can alter packet headers. Depending on the NVA, it can change the source IP of the traffic. When the return traffic came back, if the GWLB was expecting the original source IP, it would not recognize it.

Kindly let us know if the above helps or you need further assistance on this issue.
Sai Prasanna Sinde 5,485 Reputation points Microsoft External Staff

2025-03-18T09:45:05.1733333+00:00

Hi @Martin Bright

Did you get a chance to review my latest comment? Please let me know if it was helpful or if you have any further questions.
Martin Bright 20 Reputation points

2025-03-18T14:14:54.3766667+00:00

hi Sai,

The cPacket packet broker interacts exclusively with the GWLB IP. There are no UDRs that might have conflicted with the subnet. We also do not alter the packet headers.
Venkat V 1,800 Reputation points Microsoft External Staff

2025-03-19T16:56:35.6+00:00

Hi @Martin Bright

As I can see, the MS Doc also suggests that the Gateway Load Balancer Frontend IP should be in a dedicated subnet (default subnet) instead of another subnet.

In the meantime, I'll check the same scenario in my environment and confirm the behavior.
Martin Bright 20 Reputation points

2025-03-19T22:05:01.22+00:00

Well, no, the document you provided says to deploy the NVAs in the same subnet as the GWLB frontend IP: the default subnet. This doesn't work for us.

Answer 1

Sai Prasanna Sinde 5,485 Microsoft External Staff

Hi @Martin Bright

Could you please elaborate on the issue you are facing with the above request?
We believe the issue was resolved by placing the GWLB frontend IPs in dedicated subnets alongside your NVAs. Could you please confirm?
Please let us know what exactly you are trying to achieve and if possible, please share your network diagram for better understanding of the issue.

Martin Bright 20 Reputation points

2025-03-12T19:05:54.36+00:00

Yes, the issue was resolved when we moved the GWLB frontend IP to a dedicated subnet that was different from the subnet that contained the NVAs.

However, we don't understand why. In the attached diagram, the cPacket broker scale set was in the same subnet as the GWLB frontend IP. This stopped working. So we moved the GWLB to its own subnet and it started working again.
KapilAnanth-MSFT 49,331 Reputation points Microsoft Employee

2025-03-20T13:12:21.0733333+00:00
@Martin Bright ,

Greetings.

From your verbatim,

You had a working Gateway Load Balancer with it's frontend IP in the same subnet as the NVAs

Your NVA Partner is cPacket Networks

Recently, you are seeing that the Gateway Load Balancer stopped forwarding traffic back to their chained public load balancers

Please let me know if I missed anything.

From Create a gateway load balancer, I see that the backend NVAs and the front end IP of the GWLB are in the same subnet only (called backend-subnet)

Observation,

When you say, "forwarding traffic back", do you mean to say that the packets are logged at the NVAs?

And it is just not received by the chained Load Balancer?

Or the packets are never logged/ does not reach the NVA itself?

May I ask how are you validating that the traffic never reached the chained Load Balancers?

Did you check the logs or collected captures at the Application VMs? (Backend of the chained Load Balancers)

I see you mentioned moving the frontend IP of the GWLB to a separate subnet other than the NVA fixes this,

May I ask if this was suggested to you by any documents/wiki/forum?

that moving this would fix the issue.

Cheers,

Kapil
Martin Bright 20 Reputation points

2025-03-20T18:11:49.6866667+00:00

hi Kapil,

For context, I'm actually a cPacket Networks employee, and I'm testing our NVAs in Azure.

Yes, the packets are logged by the NVAs. We see traffic coming into the NVA via the GWLB external tunnel, but not going out via the internal tunnel. That is, we see the traffic exiting the internal tunnel with tcpdump, but it never arrives to the workload machines.

I was inspired to move the GWLB frontend IP to a separate subnet because that is what they recommend in AWS, where the subnet routing tables sometimes need to be adjusted in order to route traffic their GWLB endpoint.
KapilAnanth-MSFT 49,331 Reputation points Microsoft Employee

2025-03-28T07:47:14+00:00
Hi @Martin Bright ,

Per the discussion we had in our Private Chats and with the Product Team, it appears that we should add the below route - in case the NVA and the GWLB Front End IP are to be deployed in the same subnet.

route add -host <GWLB frontend IP> gw <first address of the subnet, x.x.x.1> dev <NIC> metric 80

As an example: route add -host 10.0.0.6 gw 10.0.0.1 dev eth0 metric 80

Kindly let us know if this helps or you need further assistance on this issue.

Thanks,

Kapil

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.
Martin Bright 20 Reputation points

2025-04-04T15:08:38.5433333+00:00

Confirmed, adding the route resolves the issue. For our NVA, we didn't have net-tools installed (it's an Ubuntu based system), so the command we used is:

sudo ip route add 10.0.254.4/32 via 10.0.254.1 dev eth0 metric 80

... where 10.0.254.4 was the GWLB frontend IP and 10.0.254.1 was the subnet gateway.

Best,

Martin

Answer 2

Sarthak Agarwal 76 Microsoft Employee

Hi Martin Bright,

It seems there were some routing changes(UDR/NSG configs) on the older subnet in which your GW LB frontend IP was deployed. Upon moving the GWLB to dedicated subnet the default behavior for routing was restored and things started working.

Regards,

Sarthak.

Share via

Must the Gateway Load Balancer Frontend IP be in its own subnet?

1 additional answer

Your answer