Access to VM

Hello @Luis Dinis

As discussed over the teams call pls follow this steps.

Step 1 — Protect your data first (most critical given disk swap failed)

Before anything else, snapshot the disks so you have a safe fallback.

1. In the Azure portal, go to your VM → Disks
2. Click on the OS disk (and each data disk) → Create snapshot
3. Give the snapshot a name and choose the same resource group
4. Repeat for all data disks containing user/personal data

This ensures you can recover data no matter what changes you make. This step is specifically called out because the disk swap didn't work — your data is still on the original disk, and you must protect it before proceeding.

 Step 2 — Verify VM and Bastion health

Check the VM:

1. Portal → go to the affected VM → Overview
2. Confirm Status = Running
3. Go to Boot diagnostics → Screenshot — confirm the OS shows a login screen, not a boot error or blank screen
4. Check Activity log for any recent failures, restarts, or platform events

Check Bastion:

1. Portal → search for Bastion → open your Bastion resource
2. Verify Provisioning state = Succeeded
3. Open Diagnose and solve problems — look for any active health alerts
4. Try connecting from a different browser (Chrome/Edge) and a different network — this rules out client-side proxy or browser extension interference

 Step 3 — Run Connection Troubleshoot (most diagnostic step)

This is the single most effective tool and all three AI responses agreed on it.

1. Portal → Network Watcher → Connection troubleshoot
2. Fill in:
   • Source type: Virtual machine (pick a healthy VM in the same VNet) or use Bastion as source
     • Destination type: Virtual machine → select the affected VM
       • Protocol: TCP
         • Port: 3389 (Windows RDP) or 22 (Linux SSH)
         1. Click Check
         2. Interpret results:
            • Reachable → the network path is fine; the issue is OS-level (guest firewall, RDP/SSH service, credentials)
              • Unreachable → the issue is network: NSG, route table, or VM OS crash/hang

 Step 4 — Validate NSG rules

This is the most common silent cause of Bastion failures.

On the AzureBastionSubnet NSG:

1. Portal → Virtual networks → your VNet → Subnets → AzureBastionSubnet
2. Open the attached NSG
3. Verify required inbound rules exist (ports 443, 8080 from GatewayManager and Internet)
4. Verify required outbound rules exist (ports 3389/22 to the VM subnet, ports 443/8080 to Internet and AzureCloud)
5. Make sure there is no custom deny rule with a lower priority number overriding these

On the VM's NIC/subnet NSG:

1. Go to VM → Networking → click the NSG
2. Confirm there is an Allow inbound rule for:
   • Protocol: TCP
     • Port: 3389 (Windows) or 22 (Linux)
       • Source: use the tag VirtualNetwork or specify the Bastion subnet CIDR explicitly
       1. Confirm no higher-priority Deny rule is blocking the same port

 Step 5 — Check for UDRs and DNS conflicts

A force-tunnel route is a very common, hard-to-spot cause of unstable Bastion sessions.

1. Portal → VM's subnet → Route table (if any is associated)
2. Check for any route with:
   • Address prefix: 0.0.0.0/0
     • Next hop type: Virtual appliance or VPN gateway
       • This force-tunnels all traffic through a firewall/NVA that may be dropping the Bastion session
       1. If using a custom/private DNS zone, verify the VM can resolve standard Azure hostnames, or test connecting by private IP directly in Bastion instead of DNS name

 Step 6 — Fix the OS-level service (safe, no data loss)

If the network path is confirmed fine (Step 3 says Reachable), the RDP or SSH service inside the VM may be broken. Fix it without touching the disk using Run Command:

For Windows:

1. VM → Operations → Run command → select EnableRDP
2. Alternatively, run SetRDPPort and set port to 3389
3. This re-enables RDP and adjusts the Windows Firewall rule automatically

For Linux:

1. VM → Run command → RunShellScript
2. Enter: sudo systemctl status sshd — check if the service is active
3. If stopped: sudo systemctl restart sshd
4. Check firewall: sudo ufw status or sudo iptables -L

 Step 7 — VM recovery actions (if still unresponsive)

1. Restart: VM → Overview → Restart — this alone resolves many unstable Bastion states
2. Redeploy: VM → Help → Redeploy + reapply — moves the VM to a fresh Azure host node, preserving all data
3. If the VM fails to boot (boot diagnostics shows errors), attach the OS disk to a repair VM:
   • Create a new VM in the same region/resource group
     • VM → Disks → Detach the OS disk (only if VM is deallocated)
       • Attach it as a data disk on the repair VM
         • Mount and access user data from there

 Step 8 — Isolate: Bastion path vs VM issue

If you're still unsure whether Bastion itself or the VM is the problem:

1. Deploy a test VM in the same VNet and subnet
2. Try to RDP/SSH from the test VM directly to the affected VM's private IP (peer-to-peer, not through Bastion)
3. Interpret:
   • Works → the VM is healthy; the fault is in the Bastion path (Bastion config, its NSG, or the subnet)
     • Fails → the VM itself or its subnet/NSG is the issue

Since the disk swap didn't fix it, the OS/data is almost certainly fine. The priority order for root causes is:

1. NSG rule missing on the VM NIC or AzureBastionSubnet — most common
2. Bastion connectivity glitch — restart the VM + try from another browser first
3. UDR / force-tunnel route — check the subnet route table
4. OS firewall or service crash — use Run Command to fix without data loss

Thanks,
Manish