You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following methods are Azure's most commonly used methods to enable outbound connectivity:
19
+
The following methods are Azure's most commonly used methods to enable outbound connectivity, listed in order of priority when multiple methods are used:
20
20
21
21
| # | Method | Type of port allocation | Production-grade? | Rating |
:::image type="content" source="./media/load-balancer-outbound-connections/outbound-options.png" alt-text="Diagram of Azure outbound options.":::
29
30
30
-
## <aname="outboundrules"></a>1. Use the frontend IP address of a load balancer for outbound via outbound rules
31
+
## 1. Associate a NAT gateway to the subnet
32
+
33
+
:::image type="content" source="./media/load-balancer-outbound-connections/nat-gateway.png" alt-text="Diagram of a NAT gateway and public load balancer.":::
34
+
35
+
Azure NAT Gateway 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 Gateway is fully managed and highly resilient.
36
+
37
+
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.
38
+
39
+
NAT gateway takes precedence over other outbound connectivity methods, including a load balancer, instance-level public IP addresses, and Azure Firewall.
40
+
41
+
For more information about Azure NAT Gateway, see [What is Azure NAT Gateway](../virtual-network/nat-gateway/nat-overview.md).
42
+
For details on how SNAT behavior works with NAT Gateway, see [SNAT with NAT Gateway](/azure/nat-gateway/nat-gateway-snat).
43
+
44
+
## 2. Assign a public IP to the virtual machine
45
+
46
+
:::image type="content" source="./media/load-balancer-outbound-connections/instance-level-public-ip.png" alt-text="Diagram of virtual machines with instance level public IP addresses.":::
47
+
48
+
| Associations | Method | IP protocols |
49
+
| ---------- | ------ | ------------ |
50
+
| Public IP on VM's NIC | SNAT (Source Network Address Translation) </br> isn't used. | TCP (Transmission Control Protocol) </br> UDP (User Datagram Protocol) </br> ICMP (Internet Control Message Protocol) </br> ESP (Encapsulating Security Payload) |
51
+
52
+
Traffic returns to the requesting client from the virtual machine's public IP address (Instance Level IP).
53
+
54
+
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, except for NAT Gateway.
55
+
56
+
A public IP assigned to a VM is a 1:1 relationship (rather than 1: many) and implemented as a stateless 1:1 NAT.
57
+
58
+
## <aname="outboundrules"></a>3. Use the frontend IP address(es) of a load balancer for outbound via outbound rules
31
59
32
60
:::image type="content" source="./media/load-balancer-outbound-connections/public-load-balancer-outbound.png" alt-text="Diagram public load balancer with outbound rules.":::
33
61
@@ -51,38 +79,16 @@ Calculate ports per instance as follows:
51
79
52
80
If you have Virtual Machine Scale Sets in the backend, it's recommended to allocate ports by "maximum number of backend instances". If more VMs are added to the backend than remaining SNAT ports allowed, scale out of Virtual Machine Scale Sets could be blocked, or the new VMs won't receive sufficient SNAT ports.
53
81
54
-
When multiple frontend IPs are configured using outbound rules, outbound connections may come from any of the frontend IPs configured to the backend instance. We do not recommend building any dependencies on which frontend IP may be selected for connections.
82
+
> [!NOTE]
83
+
> When multiple frontend IPs are configured using outbound rules, outbound connections may come from any of the frontend IPs configured to the backend instance. We do not recommend building any dependencies on which frontend IP may be selected for connections.
55
84
56
85
For more information about outbound rules, see [Outbound rules](outbound-rules.md).
57
86
58
-
## 2. Associate a NAT gateway to the subnet
59
-
60
-
:::image type="content" source="./media/load-balancer-outbound-connections/nat-gateway.png" alt-text="Diagram of a NAT gateway and public load balancer.":::
87
+
## 4. Use the frontend IP address(es) of a load balancer for outbound without outbound rules
61
88
62
-
Azure NAT Gateway 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 Gateway is fully managed and highly resilient.
89
+
This option is similar to the previous one, except when no outbound rules are created. In this case, the load balancer frontend(s) are still used for outbound, but this is done implicitly without rules that specify which frontend would be used. Not using outbound rules also decreases scalability of outbound, as implicit outbound connectivity has a fixed number of SNAR ports per frontend IP address, which could lead to port exhaustion in high-traffic scenarios.
63
90
64
-
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.
65
-
66
-
NAT gateway takes precedence over other outbound connectivity methods, including a load balancer, instance-level public IP addresses, and Azure Firewall.
67
-
68
-
For more information about Azure NAT Gateway, see [What is Azure NAT Gateway](../virtual-network/nat-gateway/nat-overview.md).
69
-
For details on how SNAT behavior works with NAT Gateway, see [SNAT with NAT Gateway](/azure/nat-gateway/nat-gateway-snat).
70
-
71
-
## 3. Assign a public IP to the virtual machine
72
-
73
-
:::image type="content" source="./media/load-balancer-outbound-connections/instance-level-public-ip.png" alt-text="Diagram of virtual machines with instance level public IP addresses.":::
74
-
75
-
| Associations | Method | IP protocols |
76
-
| ---------- | ------ | ------------ |
77
-
| Public IP on VM's NIC | SNAT (Source Network Address Translation) </br> isn't used. | TCP (Transmission Control Protocol) </br> UDP (User Datagram Protocol) </br> ICMP (Internet Control Message Protocol) </br> ESP (Encapsulating Security Payload) |
78
-
79
-
Traffic returns to the requesting client from the virtual machine's public IP address (Instance Level IP).
80
-
81
-
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, except for NAT Gateway.
82
-
83
-
A public IP assigned to a VM is a 1:1 relationship (rather than 1: many) and implemented as a stateless 1:1 NAT.
84
-
85
-
## 4. Default outbound access
91
+
## 5. Default outbound access
86
92
87
93
:::image type="content" source="./media/load-balancer-outbound-connections/default-outbound-access.png" alt-text="Diagram of default outbound access.":::
88
94
@@ -131,7 +137,6 @@ The following <a name="snatporttable"></a>table shows the SNAT port preallocatio
131
137
| 401-800 | 64 |
132
138
| 801-1,000 | 32 |
133
139
134
-
135
140
## Port exhaustion
136
141
137
142
Every connection to the same destination IP and destination port uses 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.
0 commit comments