After our VM crashed, Bastion can no longer connect

Chris Vuletich - Thanks for reaching Microsoft QnA platform

It is very likely that the VM OS or its NIC path is unhealthy after the CPU spike/crash, even though Bastion and the VNet are correctly rebuilt and configured.​

Before focusing on the VM, validate that Bastion itself is healthy - https://v4.hkg1.meaqua.org/en-us/azure/bastion/troubleshoot

Please ensure the Bastion resource provisioning state is Succeeded and it is deployed into a subnet named AzureBastionSubnet in the correct VNet (no custom UDR on that subnet).​

If you have attached any NSG to AzureBastionSubnet, ensure it allows outbound to your VM subnet and does not block ports 3389/22 inside the VNet

Microsoft recommends no NSG on AzureBastionSubnet unless you know exactly what you are doing.​

Use Bastion Connection Troubleshoot and Network Watcher - Azure Bastion has a built‑in Connection Troubleshoot blade that will tell you if the problem is between your browser and Bastion or between Bastion and the VM.​

In the Bastion resource, go to Help > Connection troubleshoot, select the target VM and protocol (RDP/SSH) and run the test and if this shows Unreachable from Bastion to VM, it confirms a network or guest OS issue on the VM side.​

Also run Network Watcher > Connection troubleshoot from the Bastion subnet IP to the VM’s private IP on 3389 (Windows) or 22 (Linux) and if Network Watcher shows Allowed but Bastion still fails, suspect guest firewall or RDP/SSH service on the VM. https://v4.hkg1.meaqua.org/en-us/answers/questions/2118498/ssh-to-vm-from-bastion-host-failed

Please validate NSG, UDR, and NIC configuration for the VM - Even if “nothing changed”, re‑validate all control‑plane objects for the VM because a crash plus any recent policy or automation change can alter them.​

Please check the NSG on the VM NIC and subnet: it must allow inbound from the Bastion subnet IP range to port 3389 or 22 and must not have a deny rule that hits before the allow.​

Please confirm there are no custom UDRs on the VM subnet that send traffic to an invalid next hop; hidden or stale UDRs have been known to break Bastion connectivity until support fixes them.​

Verify the NIC is in Succeeded state, attached to the correct subnet, with the expected private IP, and that any IP‑based restrictions in the OS or agents still match that address.​

Check VM guest OS health via Serial Console / Boot Diagnostics

Since the VM went through a CPU spike and became unreachable, treat this as a possible guest OS corruption or service failure.​

Ensure Boot diagnostics is enabled for the VM so that the Serial console can be used (VM > Support + troubleshooting > Serial console).​ - https://v4.hkg1.meaqua.org/en-us/troubleshoot/azure/virtual-machines/windows/serial-console-errors

For Windows - please use the Serial console to open a command prompt (SAC) and check that the TermService (Remote Desktop Services) is running, the firewall allows 3389, and that Safe Mode is not enabled, as RDP is not available in Safe Mode.​

For Linux - please use the Serial console shell to confirm the SSH daemon is running, listening on the expected port, and not blocked by iptables/firewalld or cloud‑init misconfiguration.​

Investigate OS‑level firewall, agents, and policies

Even with correct NSGs, many Bastion issues are caused by guest firewalls or endpoint security.​ Check Windows Firewall or any third‑party firewall/EDR for rules that block inbound RDP/SSH from non‑Internet ranges, including your Bastion subnet.​

Review recent changes to extensions (e.g., Azure Monitor, AV/EDR agents) or Group Policy that could have disabled RDP, changed the listening port, or enforced IP restrictions.​

If RDP/SSH port has been customized, make sure you use the same custom port when connecting from Bastion; docs note Bastion supports custom ports but you must specify them explicitly.​

Use Microsoft recovery patterns if services will not start

If you confirm that RDP/SSH services or networking in the guest OS are irreparable, follow standard Microsoft VM recovery approaches.​

Perform an offline repair by attaching the OS disk to a healthy repair VM to undo firewall or registry changes, restore default RDP/SSH settings, or recover corrupted system files.​

As a last resort, create a new VM from the existing OS disk or from a backup/snapshot, then configure RDP/SSH and test Bastion connectivity before putting it back into production.​

What to try next in your specific case

Given your symptoms (post‑crash VM, rebuilt Bastion, still “cannot reach host”), the highest‑value next steps are:

Run Bastion > Connection troubleshoot and Network Watcher from Bastion subnet to VM IP on RDP/SSH to confirm the path and identify where it fails.​

Enable Boot diagnostics and use Serial console to validate that the OS boots cleanly, that RDP/SSH services are running, and that guest firewall is not blocking Bastion subnet traffic.​

If the VM OS looks damaged or services cannot be brought up, detach the OS disk, mount to a repair VM, fix RDP/SSH/firewall settings per Microsoft VM recovery guidance, and then reattach or recreate the VM.

Regards

Himanshu