IP address returns timeout on SSH and unreachable from port 80 and 443

If SSH, HTTP, and HTTPS all suddenly time out from multiple countries, and worldwide ping shows 100% packet loss, the fastest way to narrow it down is to determine whether the packets are being dropped before they reach the VM, on the network path, or at the destination.

1. Check Azure-side health first.
   • In Azure Portal, review Service Health and the VM’s Power state and metrics.
   • If available for the VM, review Resource health for any platform event around the time the issue started.
2. Verify the VM is still reachable at the Azure networking layer.
   • Confirm the public IP and DNS mapping did not change.
   • Run Connection troubleshoot on the VM NIC.
   • Review Effective security rules and confirm the required ports are allowed: 22, 80, and 443.
   • Verify no NSG, UDR, or Azure Firewall rule is blocking traffic.
3. Determine whether the destination is actually listening.
   • If shell access is possible through Serial Console or another recovery path, use netstat -anob on the destination to confirm the expected TCP ports are in the LISTENING state.
   • If the port is not listening, the service is down even if the VM itself is running.
4. Collect traces from both ends if possible.
   • When a TCP peer sends packets and receives no response, TCP retransmits and eventually closes with an ACK reset.
   • Simultaneous traces at source and destination help confirm whether packets leave the source but never arrive at the destination. If packets appear on the source trace but not on the destination trace, an intermediate network device is dropping them.
5. Check for local packet drops on the destination.
   • If packets reach the VM but there is no response, enable Windows Filtering Platform packet-drop auditing:

          auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
     

   • Review the Security event log for dropped packets and the related filter ID.
   • Run:

          netsh wfp show state
     

     Then inspect the generated wfpstate.xml to identify the firewall rule associated with the filter ID.
6. Use VM recovery features if the guest OS may be unhealthy.
   • Use Boot diagnostics and Serial Console to check for boot or OS errors.
   • If networking on the VM appears broken, Reset network interface can help.
   • If needed, Redeploy moves the VM to a new host without changing the disk.
   • Before risky recovery actions, snapshot the OS disk.
7. If traces show packet loss on the path, escalate with evidence.
   • Packet loss over the network means the issue can be between the source and destination, not necessarily a broad Azure outage.
   • If source-side traces show retransmissions and destination-side traces show the packets never arrive, the path between them is dropping traffic.
   • In that case, engage the network provider or open an Azure support case with timestamps, affected public IP, and packet captures.

A BGP issue is possible, but the evidence needed is path-level proof: source trace shows SYN retransmissions, destination trace shows nothing, and Azure-side health/rules do not explain the failure. That combination points to packet drops in the intermediate network path rather than an application problem.

References:

• One of my VMs just stopped working... - Microsoft Q&A
• Troubleshoot TCP/IP connectivity
• Diagnose packet loss