Using Source Network Address Translation (SNAT) for outbound connections
Certain scenarios require virtual machines or compute instances to have outbound connectivity to the internet. The frontend IPs of an Azure public load balancer can be used to provide outbound connectivity to the internet for backend instances. This configuration uses source network address translation (SNAT) to translate virtual machine's private IP into Load Balancer's public IP address. SNAT maps the IP address of the backend to the public IP address of your load balancer. SNAT prevents outside sources from having a direct address to the backend instances.
Azure's outbound connectivity methods
Outbound connectivity to the internet can be enabled in the following ways:
|#||Method||Type of port allocation||Production-grade?||Rating|
|1||Using the frontend IP address(es) of a Load Balancer for outbound via Outbound rules||Static, explicit||Yes, but not at scale||OK|
|2||Associating a NAT gateway to the subnet||Static, explicit||Yes||Best|
|3||Assigning a Public IP to the Virtual Machine||Static, explicit||Yes||OK|
|4||Using the frontend IP address(es) of a Load Balancer for outbound (and inbound)||Implicit||No||Second worst|
|5||Using default outbound access||Implicit||No||Worst|
Using the frontend IP address of a load balancer for outbound via outbound rules
Outbound rules enable you to explicitly define SNAT (source network address translation) for a standard public load balancer.
This configuration allows you to use the public IP or IPs of your load balancer for outbound connectivity of the backend instances.
This configuration enables:
- IP masquerading
- Simplifying your allowlists
- Reduces the number of public IP resources for deployment
With outbound rules, you have full declarative control over outbound internet connectivity. Outbound rules allow you to scale and tune this ability to your specific needs.
For more information about outbound rules, see Outbound rules.
When a backend pool is configured by IP address, it will behave as a Basic Load Balancer with default outbound enabled. For secure by default configuration and applications with demanding outbound needs, configure the backend pool by NIC.
Associating a NAT gateway to the subnet
Virtual Network NAT simplifies outbound-only Internet connectivity for virtual networks. When configured on a subnet, all outbound connectivity uses your specified static public IP addresses. Outbound connectivity is possible without load balancer or public IP addresses directly attached to virtual machines. NAT is fully managed and highly resilient.
Using a NAT gateway is the best method for outbound connectivity. A NAT gateway is highly extensible, reliable, and doesn't have the same concerns of SNAT port exhaustion.
For more information about Azure Virtual Network NAT, see What is Azure Virtual Network NAT.
Assigning a public IP to the virtual machine
|Public IP on VM's NIC||SNAT (Source Network Address Translation) isn't used.||TCP (Transmission Control Protocol) UDP (User Datagram Protocol) ICMP (Internet Control Message Protocol) ESP (Encapsulating Security Payload)|
Traffic will return to the requesting client from the virtual machine's public IP address (Instance Level IP).
Azure uses the public IP assigned to the IP configuration of the instance's NIC for all outbound flows. The instance has all ephemeral ports available. It doesn't matter whether the VM is load balanced or not. This scenario takes precedence over the others.
A public IP assigned to a VM is a 1:1 relationship (rather than 1: many) and implemented as a stateless 1:1 NAT.
Using the frontend IP address of a load balancer for outbound (and inbound)
This method is NOT recommended for production workloads as it adds risk of exhausting ports. Please refrain from using this method for production workloads to avoid potential connection failures due to SNAT port exhaustion.
A resource in the backend of a load balancer without:
- Outbound rules
- Instance level public IP address
- NAT gateway configured
creates outbound connections via the frontend IP of the load balancer and leverages default SNAT (also known as Default Outbound Access).
Default outbound access
A resource without:
- Outbound rules
- Instance level public IP address
- NAT gateway configured
- a load balancer
creates outbound connections via default SNAT. This is known as Default Outbound Access. Another example of a scenario using default SNAT is a virtual machine in Azure (without the associations mentioned above). In this case outbound connectivity is provided by the Default Outbound Access IP. This is a dynamic IP assigned by Azure that you cannot control. Default SNAT is not recommended for production workloads.
What are SNAT ports?
Ports are used to generate unique identifiers used to maintain distinct flows. The internet uses a five-tuple to provide this distinction.
If a port is used for inbound connections, it has a listener for inbound connection requests on that port. That port can't be used for outbound connections. To establish an outbound connection, an ephemeral port is used to provide the destination with a port on which to communicate and maintain a distinct traffic flow. When these ephemeral ports are used for SNAT, they're called SNAT ports.
By definition, every IP address has 65,535 ports. Each port can either be used for inbound or outbound connections for TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). When a public IP address is added as a frontend IP to a load balancer, 64,000 ports are eligible for SNAT.
A port used for a load balancing or inbound NAT rule consumes eight ports from the 64,000 ports. This usage reduces the number of ports eligible for SNAT. If a load-balancing or inbound NAT rule is in the same range of eight as another, it doesn't use extra ports.
How does default SNAT work?
When a VM creates an outbound flow, Azure translates the source IP address to an ephemeral IP address. This translation is done via SNAT.
If using SNAT through a load-balancing rule, SNAT ports are pre-allocated as described in the Default SNAT ports allocation table.
When using a standard internal load balancer, an ephemeral IP address isn't used for SNAT. This feature supports security by default. This feature ensures all IP addresses used by resources are configurable and can be reserved.
To achieve outbound connectivity to the internet when using a standard internal load balancer, configure:
- An instance level public IP address
- NAT gateway
- Add backend instances to a standard public load balancer with an outbound rule configured.
What is the IP for default SNAT?
When the VM creates an outbound flow, Azure translates the source IP address to a dynamically given public source IP address. This public IP address isn't configurable and can't be reserved. This address doesn't count against the subscription's public IP resource limit.
The public IP address will be released and a new public IP requested if you redeploy the:
- Virtual Machine
- Availability set
- Virtual machine scale set
This method is NOT recommended for production workloads as it adds risk of exhausting ports. Please refrain from using this method for production workloads to avoid potential connection failures.
|Standard Public Load balancer||Use of load balancer frontend IPs for SNAT|
|Standard Internal Load balancer||No internet connectivity, secure by default|
|Basic Public Load balancer||Use of load balancer frontend IPs for SNAT|
|Basic Internal Load balancer||SNAT with unknown dynamic IP address|
Every connection to the same destination IP and destination port will use a SNAT port. This connection maintains a distinct traffic flow from the backend instance or client to a server. This process gives the server a distinct port on which to address traffic. Without this process, the client machine is unaware of which flow a packet is part of.
Imagine having multiple browsers going to https://www.microsoft.com, which is:
- Destination IP = 126.96.36.199
- Destination Port = 443
- Protocol = TCP
Without different destination ports for the return traffic (the SNAT port used to establish the connection), the client will have no way to separate one query result from another.
Outbound connections can burst. A backend instance can be allocated insufficient ports. Without connection reuse enabled, the risk of SNAT port exhaustion is increased.
New outbound connections to a destination IP will fail when port exhaustion occurs. Connections will succeed when a port becomes available. This exhaustion occurs when the 64,000 ports from an IP address are spread thin across many backend instances. For guidance on mitigation of SNAT port exhaustion, see the troubleshooting guide.
For TCP connections, the load balancer will use a single SNAT port for every destination IP and port. This multiuse enables multiple connections to the same destination IP with the same SNAT port. This multiuse is limited if the connection isn't to different destination ports.
For UDP connections, the load balancer uses a port-restricted cone NAT algorithm, which consumes one SNAT port per destination IP whatever the destination port.
A port is reused for an unlimited number of connections. The port is only reused if the destination IP or port is different.
Default port allocation
Each public IP assigned as a frontend IP of your load balancer is given 64,000 SNAT ports for its backend pool members. Ports can't be shared with backend pool members. A range of SNAT ports can only be used by a single backend instance to ensure return packets are routed correctly.
Should you use the automatic allocation of outbound SNAT through a load-balancing rule, the allocation table will define your port allocation for each IP.
|Pool size (VM instances)||Default SNAT ports per IP configuration|
Manual port allocation
Manually allocating SNAT port based on the backend pool size and number of frontendIPConfigurations can help avoid SNAT exhaustion.
You can manually allocate SNAT ports either by "ports per instance" or "maximum number of backend instances". If you have Virtual Machines in the backend, it's recommended that you allocate ports by "ports per instance" to get maximum SNAT port usage. Ports per instance should be calculated as below: No. of frontend IP * 64K / No. of backend instances. Otherwise, if you have Virtual Machine Scale Sets in the backend, it's recommende to allocate ports by "maximum number of backend instances".
However, if more VMs are added to the backend than remaining SNAT ports allowed, it's possible that VMSS scaling up could be blocked or that the new VMs will not be getting sufficient SNAT ports.
- When a connection is idle with no new packets being sent, the ports will be released after 4 – 120 minutes.
- This threshold can be configured via outbound rules.
- Each IP address provides 64,000 ports that can be used for SNAT.
- Each port can be used for both TCP and UDP connections to a destination IP address
- A UDP SNAT port is needed whether the destination port is unique or not. For every UDP connection to a destination IP, one UDP SNAT port is used.
- A TCP SNAT port can be used for multiple connections to the same destination IP provided the destination ports are different.
- SNAT exhaustion occurs when a backend instance runs out of given SNAT Ports. A load balancer can still have unused SNAT ports. If a backend instance’s used SNAT ports exceed its given SNAT ports, it will be unable to establish new outbound connections.
- Fragmented packets will be dropped unless outbound is through an instance level public IP on the VM's NIC.
- Troubleshoot outbound connection failures because of SNAT exhaustion
- Review SNAT metrics and familiarize yourself with the correct way to filter, split, and view them.