Support communicating to the frontend IP address of a globally peered internal load balancer
The VNet peering documentation contains the following constraint:
Resources in one virtual network cannot communicate with the frontend IP address of an Azure internal load balancer in the globally peered virtual network. The load balancer and the resources that communicate with it must be in the same region.
In scenarios that require a resource to access a load balanced application in another region, a 3rd party load balancer is required.
Hélder Pinto commented
Looks like this feature has been implemented in Standard Load Balancer:
Raj Rajput commented
This constraint with Vnet peering is really pushing us back as we are trying to create more resiliency and connectivity between regions via the internal load balancer. Please provide any ETA there.
Eduardo Inoue commented
+1 I have a Load Balancer and VM resources in 2 different regions and need to connect by Internal Load Balancer.
+1 we really need this feature, especially when peering vnets from different subscriptions
This limitation is an headache.
I had to replace my Global VNET peering with VNET2VNET connection (not fair).
I have 2 AKS in 2 different regions and need to connect from one region to the other by ILB.
I cannot use a third party LB, the mission is keep it simple.
Yes please, can you provide an ETA?
Ganesh Majeti commented
Hello, Thankyou for starting to implement the fix for this issue.. Can you please provide an ETA to the fix?