What is IP address

IP address is a virtual public IP address that is used to facilitate a communication channel to Azure platform resources. Customers can define any address space for their private virtual network in Azure. Therefore, the Azure platform resources must be presented as a unique public IP address. This virtual public IP address facilitates the following operations:

  • Enables the VM Agent to communicate with the Azure platform to signal that it is in a "Ready" state.

  • Enables communication with the DNS virtual server to provide filtered name resolution to the resources (such as VM) that don't have a custom DNS server. This filtering makes sure that customers can resolve only the hostnames of their resources.

  • Enables health probes from Azure Load Balancer to determine the health state of VMs.

  • Enables the VM to obtain a dynamic IP address from the DHCP service in Azure.

  • Enables Guest Agent heartbeat messages for the PaaS role.


In a non-virtual network scenario (Classic), a private IP address is used instead of This private IP address is dynamically discovered through DHCP. Firewall rules specific to need to be adjusted as appropriate.

Scope of IP address

The public IP address is used in all regions and all national clouds. Microsoft owns this special public IP address and it doesn't change. We recommend that you allow this IP address in any local (in the VM) firewall policies (outbound direction). The communication between this special IP address and the resources is safe because only the internal Azure platform can source a message from this IP address. If this address is blocked, unexpected behavior can occur in various scenarios. is a virtual IP of the host node and as such it isn't subject to user defined routes.

  • The VM Agent requires outbound communication over ports 80/tcp and 32526/tcp with WireServer ( These ports should be open in the local firewall on the VM. The communication on these ports with isn't subject to the configured network security groups. The traffic must always come from the primary network interface of the VM.

  • can provide DNS services to the VM. If DNS services provided by isn't desired, outbound traffic to ports 53/udp and 53/tcp can be blocked in the local firewall on the VM.

    By default DNS communication isn't subject to the configured network security groups unless targeted using the AzurePlatformDNS service tag. To block DNS traffic to Azure DNS through NSG, create an outbound rule to deny traffic to AzurePlatformDNS. Specify "Any" as "Source", "*" as "Destination port ranges", "Any" as protocol and "Deny" as action.

    Additionally, the IP address does not support reverse DNS lookup. This means if you try to retrieve the Fully Qualified Domain Name (FQDN) using reverse lookup commands like host, nslookup, or dig -x on, you won't receive any FQDN.

  • When the VM is part of a load balancer backend pool, health probe communication should be allowed to originate from The default network security group configuration has a rule that allows this communication. This rule uses the AzureLoadBalancer service tag. If desired, this traffic can be blocked by configuring the network security group. The configuration of the block result in probes that fail.

Troubleshoot connectivity


When running the following tests, the action must be run as Administrator (Windows) and Root (Linux) to ensure accurate results.

Windows OS

You can test communication to by using the following tests with PowerShell.

Test-NetConnection -ComputerName -Port 80
Test-NetConnection -ComputerName -Port 32526
Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri

Results should return as follows.

Test-NetConnection -ComputerName -Port 80
ComputerName     :
RemoteAddress    :
RemotePort       : 80
InterfaceAlias   : Ethernet
SourceAddress    :
TcpTestSucceeded : True
Test-NetConnection -ComputerName -Port 32526
ComputerName     :
RemoteAddress    :
RemotePort       : 32526
InterfaceAlias   : Ethernet
SourceAddress    :
TcpTestSucceeded : True
Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri
xml                            Versions
---                            --------
version="1.0" encoding="utf-8" Versions

You can also test communication to by using telnet or psping.

If successful, telnet should connect and the file that is created is empty.

telnet 80 >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test-port80.txt
telnet 32526 >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test--port32526.txt
Psping >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test--port80.txt
Psping >> C:\<<EDIT-DIRECTORY>>\168-63-129-16_test-port32526.txt

Linux OS

On Linux, you can test communication to by using the following tests.

echo "Testing 80 Port 80" > 168-63-129-16_test.txt
traceroute -T -p 80 >> 168-63-129-16_test.txt
echo "Testing 80 Port 32526" >> 168-63-129-16_test.txt
traceroute -T -p 32526 >> 168-63-129-16_test.txt
echo "Test Versions"  >> 168-63-129-16_test.txt
curl >> 168-63-129-16_test.txt

Results inside 168-63-129-16_test.txt should return as follows.

traceroute -T -p 80
traceroute to (, 30 hops max, 60 byte packets
1 (  0.974 ms  1.085 ms  1.078 ms

traceroute -T -p 32526
traceroute to (, 30 hops max, 60 byte packets
1 (  0.883 ms  1.004 ms  1.010 ms

<?xml version="1.0" encoding="utf-8"?>

Next steps