It’s a fairly common requirement to need to ensure that traffic leaving your Azure Virtual Network is going so with a static outbound public IP address. Usually, this is down to the need to whitelist traffic from your network on some other resources this can include things like licence servers, source control systems, Azure PaaS resources etc. In AWS this was always relatively easy as it has the concept of a NAT device, but in Azure, it’s not so easy to achieve. By default outbound traffic from an Azure Virtual Network uses a random IP allocated to the virtual network that can change.
However, there have been a few recent changes that have made this a bit less painful. In this article, we will take a look at what options there are to make sure the traffic out of your Virtual Network uses a consistent IP.
Public IP Address
The simplest way to get traffic to have a consistent IP is to give your VM a public IP address. Not only does this give you a static public IP for ingress, but this IP is also used for outbound traffic for this virtual machine.
Even though you are providing the machine with a public IP, you don’t need to use this IP for ingress; you can block access into it using an NSG and use it solely for outbound traffic.
While this is a simple and easy solution, it does require you to assign a public IP to each machine you want to have a consistent IP, and each machine will still have a different IP. You are also having to pay for each IP and have them clutter up your environment.
Instead of assigning a public IP to a VM, you can assign it to a load balancer. Now any machine that you add to the backend pool of that load balancer will use that public IP for outbound traffic.
As with the Public IP, you don’t need to allow inbound traffic to flow through the load balancer for this to work. However, you do need to create some inbound rule; otherwise, the Public IP will not be allocated to the load balancer, as it is assumed it is not in use. The easiest way to deal with this is to create an inbound NAT rule on a high port and then ensure you block this with an NSG.
When there were only basic load balancers, this solution was a bit more painful, as all machines in the backend of a load balancer had to be in the same availability set. With a standard load balancer, this is no longer the case.
The downside to this approach is similar to a Public IP; you are still paying for the public IP and your now confusing your setup with load balancers that aren’t doing any load balancing. You also need to make sure to block inbound traffic properly with your NSG if you are not using the load balancer. On the plus side, you can limit the number of public IP’s required by putting multiple machines behind a load balancer.
Azure Firewall is designed to solve this problem with its outbound SNAT features. Any traffic you send to the Azure Firewall before it goes to the internet will emerge from your network using the outbound IP of your Azure Firewall instance. At the same time, you are gaining all the benefits of the URL filtering and machine learning in the Azure Firewall to block malicious outbound traffic.
To route all traffic through the Firewall you do need to set up a custom route directing that traffic. This can cause problems with asymmetric routing if you have the traffic coming into the network not via the Firewall. If that impacts you, then you need to either route inbound traffic through the Azure Firewall using the in inbound DNAT rule or add exceptions to your route to avoid traffic exiting through the Azure Firewall.
The main downsides of using Azure Firewall is cost and complexity. If you want all the abilities of the Azure Firewall, then this may be worth it, but if all you are doing this for is to get a static outbound IP, then it is an expensive way to do it.
Azure Virtual Network NAT Gateway
Nat Gateway is a new service that went into preview very recently. Once this goes GA, this is likely to be the best way to ensure all of your traffic from your vNet uses the same static outbound IP, if you are not using Azure Firewall.
With this service, you can create a NAT Gateway device and assign a public IP, or public IP prefix t it. This IP is then used for your outbound traffic.
NAT Gateway also supports having VMs or Load Balancers with Public IP’s, where inbound traffic (and the response) still uses the assigned Public IP, but any outbound traffic initiated from the VM uses the NAT gateway.
The downside of this service is that it is in preview and so can’t be used for production workloads. Once this is in GA, it should be the simplest and cheapest way to obtain a static outbound IP. It is also not currently clear how NAT Gateway will be priced.
Private link is not a solution to getting a static outbound IP; however, if your primary concern is access to Azure PaaS services, then this could remove the need to have this static IP. With Private Link, you can join certain Azure PaaS services to your virtual network and have them accessed using a private IP. There is then no need to have your traffic get a static outbound IP as traffic never leaves your virtual network. You can then lock your PaaS resource down to only receive traffic from that private network. As more services adopt Private Link, this will become more and more viable.