Azure: Deploy NAT Gateway for the VM outbound traffic

by | Dec 2, 2024 | Azure, Networking

Having as a fact that on 30 September 2025, Microsoft retires the default outbound access for Azure VMs you will need start considering use other outbound connectivity methods, such as: Azure NAT Gateway, Azure Firewall, Public IP directly assigned.

In this blog post, I will describe configuring an Azure NAT gateway to avoid assigning multiple Public IPs to VMs. After all, this is the Microsoft recommended way to get outbound access. By following the guide steps you will be able to assign the same Public IP on each VM on the subnet.

What is Azure NAT Gateway?

The NAT gateway provides outbound Internet connectivity for Azure virtual networks. Static public IP addresses ensure consistency and streamline scaling. NAT Gateway offers high performance, provides automated scaling, and is ideal for outbound connectivity.

Azure NAT Gateway benefits

  • Scalability: The Azure NAT Gateway can handle a large number of simultaneous connections, making it suitable for applications with heavy traffic demands.
  • Resilience: Due to its high availability and redundancy, NAT Gateway minimizes the risk of single points of failure.
  • Cost-effective: NAT Gateways enable the sharing of a single public IP address across multiple resources, resulting in a significant reduction in IP address consumption costs.
  • Security: The NAT Gateway follows the zero trust network security principle, ensuring it is secure by default. It allows private instances within a subnet to access the internet without requiring public IP addresses.

 

Pros and Cons

Pros

  • Cost-effective: For large-scale outbound traffic needs, a NAT Gateway can be more cost-effective compared to other methods, such as deploying multiple individual public IPs, due to consolidated IP usage and reduced complexity.
  • Managed by Azure: Azure NAT Gateway is managed entirely by Azure, saving you from maintaining or fixing it.
  • Security: Allowing only outbound connections minimizes the attack surface compared to directly assigning public IPs to individual virtual machines.
  • Scalability and HA: NAT Gateway resources are built for high availability within a single availability zone and are distributed across multiple fault domains. You have the option to deploy a NAT gateway in an unallocated zone, which allows Azure to automatically select a zone for its location. Alternatively, you can choose to dedicate the NAT gateway to a specific availability zone.
  • Performance efficiency: Each NAT Gateway is capable of up to 50 Gbps throughput. You can split your deployments into multiple subnets and allocate a NAT gateway to each subnet or group of subnets to enhance scalability.
  • SNAT port exhaustion: NAT Gateway sorts out the SNAT port exhaustion by offering a dynamic pool of SNAT ports that can be utilized by all virtual machines within the connected subnets.

SNAT port exhaustion occurs when available ports for source network address translation are used up, blocking new outbound connections.

Cons

  • Advanced configuration: For those unfamiliar with Azure network services can be a bit of a learning curve.
  • Migration support: An Azure NAT Gateway cannot be transferred between domains, subscriptions, or RGs.
  • Signle-network restriction: A NAT gateway cannot associate to multiple virtual networks.

 

Spin up  an Azure NAT Gateway

Let us walk through by spinning up an Azure NAT Gateway.

Once I have created a new Resource group, i.e. “rg-natgtw”, I create a new resource.

On the Marketplace page search for “nat gateway”, locate the NAT gateway resource and click the Create button.

On the tab ‘Basics‘, fill in the details, such as NAT gateway name, Region, Availability zone, TCP idle timeout and tap the “Next: Outbound IP >” button.

On the tab ‘Outbound IP‘, choose Create a new public IP address (This IP will be used by the Azure NAT Gateway), and choose the “Next: Subnet >” button.

The Azure NAT Gateway’s configuration for public IP prefixes enables the assignment of a continuous range of static IP addresses for outbound traffic, which simplifies management.

Select an existing Virtual network or deploy a new one and click the ‘Review + create‘ button.

To force the Azure VM to use the NAT gateway as the recommended egress for the outbound traffic, tick the checkbox, “Enable private subnet(no default outbound access)”, as the image below depicts.

On the Security section, choose the NAT gateway deployed in the previous steps.

For the sake of clarity the below screenshot depicts the NAT gateway Public IP.

Test the NAT gateway

In the final screenshots, I’m providing the results of the configuration settings I did in the above steps.

  1. The first test was performed using a web browser. The IP Public IP address the Azure VM uses for the outbound traffic is the NAT gateway PIP.

2. The second test was performed using command prompt (CMD), using the nslookup myip.opendns.com resolver1.opendns.com command to get the Public IP by querying OpenDNS resolver.

Below are the stages:

  1. nslookup is sending a DNS query to myip.opendns.com to the DNS server resolver1.opendns.com
  2. opendns server receives the request and acknowledges that the myip.opendns.com is meant to send back the public IP address of the requestor.
  3. opendns server responds with the public IP associated with the request.

 

Related Links

468
Share This