RDP to an Azure VM times out after the office internet connection changes

An example team moves to a new office connection. Their Azure Windows VM remains running, and no guest configuration was intentionally changed. RDP now times out for everyone at that office. The inbound rule was originally restricted to the old office’s public address. What is a safe way to confirm the cause without exposing RDP to the internet?

Compare the current client egress address with the approved source range in the effective NSG rules. Inspect both subnet and network-interface effects. A connection timeout immediately after an egress change makes the source restriction a useful hypothesis, but confirm it through the actual rule evaluation and route.

If authorized, update the narrow approved source range or restore the intended private access method. Do not use an unrestricted source as a permanent or casual diagnostic fix. After connecting, retain the restricted rule and record the updated access path. This example assumes guest health is unchanged; boot diagnostics remain relevant if the network evidence does not explain the failure.

Would resetting the Windows administrator password help a timeout?

A password reset does not repair packets blocked before authentication. Follow the timeout and network-rule evidence first; credential troubleshooting applies when the authentication stage is reached.

Review whether the VM should use a private administration path in the longer term. That design decision can be planned separately from restoring the already approved access boundary.

RDP to an Azure VM times out after the office internet connection changes

Sources & further reading

2 answers

Your perspective belongs here.

0 question comments