Use port pings instead of ICMP to test Azure VM connectivity
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 removedAnonymous
October 24, 2014
Without allowing ping windows azure vm are totaly uselessAnonymous
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