Support SNAT on internal Azure load Balancer
Currently it seems Azure Internal Load Balancer does not support Source NAT.
this mean that if 2 different services hosted on 2 different VM and the VM are on the same vnet the traffic is not load balanced if the ILB route the traffic to the same VM that start the request.
Service A (exposed on port x) and B (exposed on port y) are hosted on VM 1 and VM2 on the same vnet.
Service A has VIP z and Service B has VIP m.
if service A is recalled via VIP z from VM 1 and ILB route the traffic to service A on VM1 a connection timeout is returned.
all works if the ILB route traffic to service A on VM2.
the same scenario works in other clouds (public and private) if on the ILB the source NAT can be enabled
We don’t have plans to provide this in the near term. there’s a potential workaround by using VM’s with multiple interfaces. I’ve added documenting this scenario to our doc backlog.
We are working on platform build based on Kubernetes, and most of the infrastructure is based on dynamic provisioning. we are looking into a way to get traffic in and out via single (or multiple) front facing IPs that stays the same on outbound as well (SNAT). But because we are using private network, we need to use internal load balancers that apparently does not have SNAT functionality compared to public load balancer. . so we have to explain to anyone wanting to use this platform that "yup you need to call THIS IP to interact, but be aware that you will get response from THAT_IP/RANGE on random base which is very inconvenient.. also this calls for possible trouble in future if we want to reuse all backend infrastructure as is, like duplicating - we could just replace load balancer IPs and have fresh instance without any changes in the backend.
In order to use Azure as my primary cloud provider, I need to be able to SNAT from my servers outbound to internal networks. Any word on if you are considering this feature?
Can you share more on the "potential workaround by using VM’s with multiple interfaces" to us? We need this to fix the IP conflicts problem on K8s.
James Dumont le Douarec commented
Just for sharing
[ARM Template] Create a Standard Public Load Balancer with outbound rules : https://jamesdld.github.io/AzureRm-Template/Create-AzureRmLoadBalancerOutboundRules/
I need SNAT on an Internal LB
Hi, Any update on this feature?
Doesn't look like Azure is going to support this soon :(
Check the discussion here "SNAT Outbound Connections from VM behind an ILB to Destination in Vnet" and please add a request on there too https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections
Jerome Robin commented
Hello, any news on that?
Raf Nijs commented
any news about Support SNAT on internal Azure load Balancer
Andy Johnson commented
Yes, this is a really common problem, I am surprised it's not addressed in ILB. You don't even need multiple services to trigger this bug: a single VIP, serving two VM's. If your VM's have to make a self-referencing call (to the ILB VIP), the Source NAT rules don't treat it any differently!
This means if VM1(client) makes call to ILB VIP, and ILB VIP load balances back to VM1(server), the *initial* SYN packet makes it's way to ILB VIP, no problem. When the ILB VIP forwards the packet to VM1(server), the Source NAT steps in, and changes the source IP to become VM1 (just, likely with a different port, for translation purposes). VM1(server) replies to that packet, but since the reply destination is ITS OWN IP, it doesn't leave the network interface.
I am pretty sure most mature load balancers address this by performing NAT translation of any requests coming from the real servers, with a destination of any of the hosted VIPs, to an IP address OTHER than their own.