When you have created your Virtual Machine in Microsoft Azure the easiest way to test connectivity is to ping your Virtual Machine. By default, ping is disabled for Azure Virtual Machines. To enable pinging, you need to open your Windows Firewall and your Azure Network Security Group.
In this article I will show you how to ping your Virtual Machine from outside the Virtual Machine’s network (e.g. your local PC) using the public IP address of your Virtual Machine. If you want to ping your Virtual Machine from another Virtual Machine within the same Virtual Network using private IP addresses the same steps can be applied.
Configuring Windows Server
Connect to your Virtual Machine using Remote Desktop (RDP) and navigate to the Windows Defender Firewall with Advanced Security via search or the Windows Administrative Tools (Control Panel\System and Security\Administrative Tools)
Go to Inbound Rules and find the File and Printer Sharing (Echo Request – ICMPv4-In) rule, enable this rule.
Configuring your Azure Network Security Group (NSG)
Besides configuring your Windows Server firewall, you also need to configure your Azure firewall. Navigate to the NSG that is connected to your Virtual Machine. You can also alter your Network Security Group using a PowerShell script but for this article I will use the Azure Portal. By default, your Network Security Group will have several default rules. The following default inbound rules are created when creating a new NSG.
If you want to connect via Remote Desktop you will also need to create a new inbound rule for port 3389, the default port for RDP connections. Make sure to only allow traffic from your own source IP address to prevent exposing your RDP port to the internet.
The default rules are immutable, so you need to overwrite these rules by creating new rules with a higher priority. If you have a test virtual machine and you just want to do a quick ping test, you can allow all traffic from your own source IP by simply creating an allow-all rule. For Source select ‘IP addresses’ and for Source IP addresses use your local IP address followed by /32 to use proper CIRD notation.
After this step, your Virtual Machine ping should work, make sure you use the correct source IP address.
Opening your NSG for all traffic, albeit from a controlled Source IP, is risky. If you need to open your NSG for pinging for an extended period, you can choose to add two additional rules to allow pings but block other traffic. Because ping is neither TCP or UDP traffic, you can create a workaround by blocking both TCP and UDP but allowing other traffic. It is still recommended to use these rules for temporary test scenarios and to always use a Source IP filter.
When overwriting the default rules for your NSG, make sure to add additional rules to allow Virtual Network traffic or other traffic from Azure resources like the Azure Load Balancer if applicable.
Pinging your Virtual Machine when using a Load Balancer
If you want to ping via your public facing or internal load balancer, you will encounter a similar issue as mentioned before with ping neither being UDP or TCP traffic. Azure Load Balancer requires the configuration of load balancing rules to forward traffic to healthy Virtual Machines. These rules must be either TCP or UDP, ping however uses the ICMP protocol. A way to test connectivity through your Load Balancer is to ping on a specific port, which in turn results in a TCP request. You can use telnet for this or other ping-tools like PsPing.
When using port pings, remember to make sure that your Load Balancer is properly configured and that the Load Balancer’s Health Probe can successfully probe your Virtual Machine (and you have a NSG rule allowing the AzureLoadBalancer over chosen port). Adjust your Windows Firewall and NSG to allow for traffic over the chosen port. Also make sure your Virtual Machine is listening and replying to inbound traffic over the chosen port (e.g. having IIS running on port 80 or 443).
Read more on port pings here.
Always keep security in mind when altering your firewall and making changes to your operating system.