Share via

Use port pings instead of ICMP to test Azure VM connectivity

  • Article

Because the ICMP protocol is not permitted through the Azure load balancer, you will notice that you are unable to ping an Azure VM from the internet, and from within the Azure VM, you are unable to ping internet locations.

Note that while this applies to network traffic going through the external IP (VIP) through configured endpoints, ICMP is not blocked when connecting through an Azure virtual network gateway or ExpressRoute. Also, ICMP will work between internal IPs of VMs in the same virtual network or in the same cloud service.

Also note that while an instance-level public IP lets you communicate directly to a specific VM instead of through the cloud service VIP that can be used for multiple VMs, ICMP is not permitted in that scenario either.

To test connectivity, we instead recommend that you do a port ping. While Ping.exe uses ICMP, other tools such as PsPing, Nmap, or Telnet allow you to test connectivity to a specific TCP port.

For example, trying to ping yahoo.com from within an Azure VM fails as expected with request timed out because ICMP is blocked at the Azure load balancer:

C:\>ping yahoo.com

Pinging yahoo.com [206.190.36.45] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 206.190.36.45:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

But using the Sysinternals PsPing tool, which allows you to test connectivity to a specific TCP port, you can successfully test connectivity from within the Azure VM to port 80 on an internet site.

C:\Users\craig\Downloads\PSTools>psping yahoo.com:80

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 206.190.36.45:80:
5 iterations (warmup 1) connecting test:
Connecting to 206.190.36.45:80 (warmup): 53.25ms
Connecting to 206.190.36.45:80: 52.26ms
Connecting to 206.190.36.45:80: 52.14ms
Connecting to 206.190.36.45:80: 52.32ms
Connecting to 206.190.36.45:80: 51.48ms

TCP connect statistics for 206.190.36.45:80:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 51.48ms, Maximum = 52.32ms, Average = 52.05ms

Note that one exception to this is that ICMP pings will work to bing.com because Azure and Bing are both Microsoft properties.

C:\Users\craig\Downloads\PSTools>psping bing.com

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

Pinging 204.79.197.200 with 32 bytes of data:
5 iterations (warmup 1) ping test:
Reply from 204.79.197.200: 6.85ms
Reply from 204.79.197.200: 2.47ms
Reply from 204.79.197.200: 2.30ms
Reply from 204.79.197.200: 2.95ms
Reply from 204.79.197.200: 2.39ms

Ping statistics for 204.79.197.200:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 2.30ms, Maximum = 2.95ms, Average = 2.53ms

Testing from on-premises to the Azure VM shows the same behavior. The ICMP traffic is blocked by the Azure load balancer and the ping requests timeout. But if you instead do a port ping, they will succeed (assuming the VM is running, isn't blocking the port in the guest firewall, and the port has a configured endpoint for the VM).

To confirm which ports are opened to the VM with Azure endpoints, in the Azure management portal, go to Virtual Machines, select the VM, then select Endpoints.

C:\>ping CLJun21WS12R2A.cloudapp.net

Pinging CLJun21WS12R2A.cloudapp.net [23.100.76.67] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 23.100.76.67:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\>psping CLJun21WS12R2A.cloudapp.net:56972

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 23.100.76.67:56972:
5 iterations (warmup 1) connecting test:
Connecting to 23.100.76.67:56972 (warmup): 60.44ms
Connecting to 23.100.76.67:56972: 61.28ms
Connecting to 23.100.76.67:56972: 63.41ms
Connecting to 23.100.76.67:56972: 63.69ms
Connecting to 23.100.76.67:56972: 60.41ms

TCP connect statistics for 23.100.76.67:56972:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 60.41ms, Maximum = 63.69ms, Average = 62.20ms

C:\>psping CLJun21WS12R2A.cloudapp.net:5986

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 23.100.76.67:5986:
5 iterations (warmup 1) connecting test:
Connecting to 23.100.76.67:5986 (warmup): 61.49ms
Connecting to 23.100.76.67:5986: 65.29ms
Connecting to 23.100.76.67:5986: 67.08ms
Connecting to 23.100.76.67:5986: 62.70ms
Connecting to 23.100.76.67:5986: 60.99ms

TCP connect statistics for 23.100.76.67:5986:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 60.99ms, Maximum = 67.08ms, Average = 64.02ms

Comments

  • Anonymous
    August 12, 2014
    ICMP is a critical tool for troubleshooting connectivity. This is a must if Microsoft wants to compete in the Enterprise Cloud market!

  • Anonymous
    September 20, 2014
    They don't allow ping. oh dear. The windows firewall is also a nightmare. I generally feel google is the way to go.

  • Anonymous
    September 22, 2014
    The comment has been removed

  • Anonymous
    October 24, 2014
    Without allowing ping windows azure vm are totaly useless

  • Anonymous
    November 05, 2014
    I have been looking for this information for hours. Thanks!

  • Anonymous
    March 18, 2015
    psping does not give the same results as a ping test. Stupid Microsoft.

  • Anonymous
    March 23, 2015
    Thank you for this blog post. I am a network engineer and been tasked with setting up our Azure's network Iaas for a POC. This is very helpful information, as I have been trying to ping from a virtual machine out to the internet. I thought it could not be possible that ICMP was not permitted/supported, so i thought, I  must need to implement something like a virtual gateway/router, rule, or some other abstracted virtual device... but whoop there it is  :) ...Thanks again!

  • Anonymous
    April 11, 2015
    hi, I have a problem where I have deployed a two-node SQL 2014 cluster (SAN less cluster using SIOS Data Keeper). I have set up an Internal Load Balancer (ILB) to my SQL Cluster VIP. However when I setup my application on another VM the installer program needs to communicate over TCP 135 and 445 when configuring the database location (SQL Server name & Instance). How can I get this to work?

  • Anonymous
    April 22, 2015
    PsPing normal work in Azure. But i don`t understand, Connecting to 23.100.76.67:5986: 65.29ms Its time only to 23.100.76.67:5986 or to 23.100.76.67:5986 and back?

  • Anonymous
    May 04, 2015
    Hi Team, I am configuring icinga monitoing for my windows azure machines. How to make it work since ping is not enabled in azure. Icinga works in ping response. Since ping is blocked it shows my machine in down state. Is there any way to enable it. I would highly appreciate a quick response on this.

  • Anonymous
    May 24, 2015
    Surely better to use powershell Test-NetConnection cmdlet?

  • Anonymous
    July 18, 2015
    Hi, Would this tool works on WinCE 6.0 platform? If not, could you suggest any other solutions/options/tools to test it from WinCE platform based device...

  • Anonymous
    August 26, 2015
    PSPing works great for me.

  • Anonymous
    November 19, 2015
    Are you seriously guys? Disable ICMP? Do you understand what it is critical?

  • Anonymous
    January 11, 2016
    OK, by all means have it disabled by default, however when I ssh into a box and try to diagnose problems I'll do something like $ tracepath 8.8.8.8 I keep a log of the route between various end points, and when people complain that "it's slow" I inevitably find BGP has changed the routing somewhere and it's passing through some shoddy ISP in Khazakstan. From a linode instance in London I have I can immediately tell the link to an ISP in Singapore is fine traceroute to 203.211.158.109 (203.211.158.109), 30 hops max, 60 byte packets 1  router1-lon.linode.com (212.111.33.229)  0.643 ms  0.695 ms  0.793 ms 2  212.111.33.233 (212.111.33.233)  1.420 ms  1.406 ms  1.388 ms 3  85.90.238.69 (85.90.238.69)  6.363 ms  1.278 ms  6.337 ms 4  * * * 5  195.66.237.10 (195.66.237.10)  1.228 ms  1.203 ms  1.187 ms 6  203.208.152.242 (203.208.152.242)  1.133 ms 203.208.152.238 (203.208.152.238)  1.073 ms 203.208.172.153 (203.208.172.153)  1.054 ms 7  203.208.172.14 (203.208.172.14)  186.733 ms 203.208.158.61 (203.208.158.61)  186.544 ms 203.208.152.125 (203.208.152.125)  1.240 ms 8  203.208.152.89 (203.208.152.89)  188.492 ms 203.208.149.161 (203.208.149.161)  188.918 ms 203.208.166.62 (203.208.166.62)  185.388 ms 9  203.208.191.230 (203.208.191.230)  189.560 ms  190.575 ms 203.208.166.173 (203.208.166.173)  195.455 ms 10  xe-5-1-0.a088.m1net.com.sg (203.211.158.109)  185.492 ms  185.451 ms  185.412 ms Or tracepath $ tracepath 203.211.158.109/80 1?: [LOCALHOST]                                         pmtu 1500 1:  router1-lon.linode.com                                0.487ms 1:  router1-lon.linode.com                                0.650ms 2:  212.111.33.233                                        1.243ms 3:  85.90.238.69                                          0.972ms asymm  4 4:  no reply 5:  195.66.237.10                                         1.170ms 6:  203.208.172.169                                       1.422ms 7:  203.208.152.125                                       1.385ms asymm  5 8:  203.208.151.233                                     186.353ms asymm  7 9:  203.208.151.233                                     186.921ms 10:  203.208.171.241                                     194.619ms asymm  9 11:  no reply 12:  no reply 13:  no reply In the past I've noticed the rtt jump to 300ms, and investigation shows that a cable cut in the Indian ocean has sent the signal via LA instead, causing the problems, allowing us to eliminate local issues and move to a workaround. How do I do this with Azure? Looks like I can't. I'm not even sure how PMTU would work if ICMP is being blocked, I have two nodes with MTUs of 1500 and a link between them which drops the MTU to 1400. I send a packet with don't fragment set, and I get an ICMP "fragmentation needed" response. This is presumably also blocked by microsoft and my azure based client has no idea!

  • Anonymous
    January 15, 2016
    Outbound Ping (ICMP) is available in Azure VM after configuring a ILPIP. azure.microsoft.com/.../virtual-networks-instance-level-public-ip