Troubleshoot outbound connectivity from Azure

1. VM with only private IP assigned (will be depreciated Sept. 2025)
2. Public IP VM network interface (Basic SKU will be depreciated Sept. 30 2025)
3. NAT Gateway
4. Azure Firewall
5. Public Load Balancer

**NAT Gateway takes precedence over all forms of outbound activity

Private IP

All VMs can communicate outbound to the internet without the need for a public IP. The default NSG outbound rule 65001 “AllowInternetOutBound” allows traffic outbound. If no NSG is assigned to the NIC or subnet, the default system routes allow for outbound connectivity to the internet. Custom route tables can override system routes.

Since there is no public IP to connect via RDP, this requires Bastion, or an rdp connection with the private IP alongside Azure VPN.

**Connecting outbound by default on Azure VMs is being depreciated Sept. 2025. Other methods for outbound connectivity must be used instead.

Public IP

1. On the networking tab when creating a new VM make sure to choose ‘create new’ in the public IP section, and then choose Standard. It is set to Standard by default.

2. Give the public IP a name, continue following the prompts and let the VM finish deploying. If rdp was enabled during set up, browse to the connect tab and that will give the assigned Public IP for this VM.

3. Connect to the VM and check to make sure the public IP being routed on the internet matches the assigned public IP for the VM

NAT Gateway

Search for NAT gateway and create a new NAT gateway. Make sure it is in the same region as the subnets you need to connect to the gateway. You can create one NAT public IP or an IP Prefix with up to 16 public IP addresses. They will be assigned at random.

NAT Gateway requires a separate public IP from a VM public IP. You can still keep the associated public IP for the VM in order to remote into since NAT is for outbound connectivity only.

Once the new Public IP is created, associate the NAT gateway to the appropriate subnets. **NAT gateway cannot be associated with an entire vnet, it must be connected to each subnet.

As soon as deployment completes, find the public IP for the NAT gateway and test it from a VM deployed in an attached subnet to make sure the public IP of the VM matches the NAT gateway.

This VM still has the public IP attached for inbound RDP connectivity. The outbound public IP is no longer the public IP associated with the VM NIC, but now the NAT gateway IP. NAT Gateway takes precedence over NIC public IP outbound.

Azure Firewall

To create an Azure Firewall, create the resouce in the same vnet as your NAT GW and VMs for outbound traffic.

Once the firewall is created, you will see an Azure firewall, firewall policy, and public IP for the firewall. Go into the firewall policy and create a new Network rule collection, then network policy. This will allow outbound connectivity for specific subnets to go through the firewall.

When creating a network rule to allow for outbound internet access, set the parameters as follows:

Source IP- This includes the entire vnet or subnet this rule will be applied to

Source port- * for all

Protocol-Set to any

Destination IP-Set to 0.0.0.0/0 for any addresses outbound

Destination port- * for all ports

Now create a route table and associate the route table to the subnet needed for outbound connectivity. Then create a new route and force all traffic within the subnet to be forwarded to the firewall (0.0.0.0/0) next hop: Virtual Applicance and next hop address is the internal IP of the firewall.

Check the public IP for the VM. It should reflect the same address as the public IP of the firewall.

** A custom user defined route (route table) takes precedence over NAT gateways. If a NAT gateway is created solo, it should be attached to the subnet where the vms deployed, but with an Azure firewall in place as well NAT GW must be changed to the AzureFirewallSubnet subnet in order to override the firewall outbound IP. Once set to that subnet, NAT gateway takes precedence over every outbound connectivity. If NAT gw does NOT get changed to the firewall subnet, then the firewall public IP will take precedence as shown above.

• If NSG and UDR are both set up, NSG filters the outbound traffic first and if rules match, then the traffic can be filtered through the UDR. If the NSG blocks the outbound traffic before it hits the UDR, then the traffic gets dropped.

Now that the NAT GW is set for the firewall subnet, it no longer reflects the public IP of the Azure Firewall, but back to the Public IP of the NAT GW. NAT Gateway always takes precedence.

**There is a DNAT rule set up so any incoming RDP requests now are being forwarded to the firewall instead of the Public IP of the VM via the NSG rules. The incoming public IP of the VM is no longer 52.170.144.103, but now reflects the public IP of the firewall.

Public Load Balancer

Create a public load balancer and assign a standard SKU and backend pool to vms. The VMs cannot have their own public IPs associated to the NICs the way you can when deploying a NAT gateway.

Set up an outbound rule that allows for NAT for the backend pool to flow to the designated public IP of the load balancer.

Make sure the DNAT rule for the load balancer is set up. During set up on the inbound rules tab, create a dnat rule to allow for RDP to test later for outbound connectivity. Not required for outbound connectivity. Just to be able to test.

NSG must have RDP enabled (default 3389 or custom port in order to allow rdp traffic to the VM). The dnat rule translates the public to private IP, and then NSG allows or denies traffic to that port.

When creating a vm, setting up an NSG allowing for 3389 to be open auto enables rdp in the registry, and opens rdp port in windows firewall.

Once set up, remote into the vm and check the public IP. It should now show the public IP of the load balancer.

Once we attach the re-add the NAT gateway back to the subnet while keeping the load balancer, it will now show the public IP of the NAT gateway and take precedence for the outbound connection.