Connect to VM over Microsoft Azure Bastion isnn't working anymore since 14.10.25

Hello

We haven't had any specific changes to this feature; although that doesn't mean we haven't had a regression somewhere else. Although overall I'm surprised by the error message: the endpoint we're reaching to take the .rdp file from Bastion is returning a 404 in this case. I hope that Microsoft didn't change something on their side, but I can look into this.

In the meantime there's a couple of troubleshooting steps you could take from your side, if you don't mind:

• Can you try the connection in the prior major version (2025.2.x)? You could grab a portable (.zip) copy from our website and then you wouldn't need to uninstall / reinstall.
• If you change the Bastion connection mode setting to "TCP Tunnel", does it work? Although, it looks like you might be using Azure SSO (MFA) so that might not be supported in your case.

Please, let me know if something isn't clear or you have further questions

Kind regards,

Hi Richard,

thanks for the quick reply.
I would appreciate it if you could test the behavior on your site.

The error occurred in version 2025.2.x, which is why I tested version 2025.3.x.
It had been working with 2025.2.x for six months. MFA had also always been set up.
Switching to TCP Tunnel does not work.

Hello

Ok, I've tried it from my side with 2025.3.16 and found it to work well.

Internally, we:

• look up the Bastion instance using the configuration you provide, and then use that configuration to obtain it's DNS name.
• send a GET to the Bastion on that DNS name, at the /api/rdpfile endpoint to retrieve an .rdp file for the target server
  • The query parameters on that GET identify the machine we want, and the options we'd like in the .rdp

Based on your log, the first step must have succeeded which means the Bastion is then returning a "not found" for the specified RDP host. I would encourage you to double-check what you have for the subscription, resource group and VM name (the values that are obfuscated in the log) and make sure they are resolving to something that (still) exists. By default, these values (for the target VM) will use the same subscription and resource group as the Bastion itself; or they can be customized in the VPN tab of the RDP session entry.

If you're happy that it all looks good; the next step would be to test the connection using Azure CLI. The command you want is `az network bastion rdp` and the parameters are documented here with some examples. We're doing basically the same thing as Azure CLI, so:

• If it does not work in Azure CLI, we'll need to identify why that is
• If it does work in Azure CLI, we'll need to compare the command parameters you used, with the connection settings you have in RDM, and what was actually resolved at runtime (the debug logs)

Please, let me know if something isn't clear or you have further questions

Thanks and kind regards,

We have a very similar issue - it affects multiple tenants we have and no changes were made to the tenants.
OpenConnection: Preparing Azure Bastion
OpenVPN: Finding Opener
OpenVPN: Preparing Dynamic Port
OpenVPN: vpnOpener.Open
Resolved Azure Resource ID: /subscriptions/[SubscriptionID]/resourceGroups/[RG Name]/providers/Microsoft.Compute/virtualMachines/[VM Name]
[Devolutions.Az][Trace][2025-10-17 16:04:41Z] Requesting Auth Token. Scope: https://management.azure.com//.default Options: AuthorityHost: https://login.microsoftonline.com/ TenantId: [TenantID]
[Devolutions.Az][Debug][2025-10-17 16:04:44Z] GET https://management.azure.com/subscriptions/[TenantID]/resourceGroups/[RG Name of Bastion Host]/providers/Microsoft.Network/bastionHosts/[Bastion Hostname]?api-version=2022-07-01 HTTP/1.1
[Devolutions.Az][Debug][2025-10-17 16:04:45Z] HTTP/1.1 OK
[Devolutions.Az][Trace][2025-10-17 16:04:45Z] Requesting Auth Token. Scope: https://management.azure.com//.default Options: AuthorityHost: https://login.microsoftonline.com/ TenantId: [TenantID]
[Devolutions.Az][Debug][2025-10-17 16:04:45Z] GET https://[Bastionhostname].bastion.azure.com/api/rdpfile?resourceId=%2Fsubscriptions%2F[Subscription ID]%2FresourceGroups%2F[Resource Group Name]%2Fproviders%2FMicrosoft.Compute%2FvirtualMachines%2F[VM Name]&format=rdp HTTP/1.1
[Devolutions.Az][Debug][2025-10-17 16:04:46Z] HTTP/1.1 NotFound
OpenVPN: Result is Not Null
OpenVPN: Result is not opened
OpenConnection: VPN Result is Null or not opened

One clear difference between the successful HTTP Get and the non-successful is the URL that is being retrieved. The first one has slashes correctly in the url but the failed one escapes the slashes with %2F. Could this be the issue?

A connection via Bastion Web UI works as expected.
Using AZ CLI the following command fails:
az network bastion rdp --name "[Bastion Name]" --resource-group "[Bastion RG Name]" --target-resource-id "[VMID]"

but this works:
az network bastion rdp --name "[Bastion Name]" --resource-group "[Bastion RG Name]" --target-ip-address "[VM IP]"

Please advise how to fix this again and make it running in RDP Manager.

Best regards
Simon

Hi Simon

I really want to rule out an issue outside of RDM. I understand nothing's changed on your side but it wouldn't be the first time Microsoft pulled the rug out from us by making changes on their side.

You wrote that `az network bastion rdp` fails when using a VM ID, but you can clarify how you specified the VM? Did you use the full resource identifier (something like "/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.Compute/virtualMachines/{vm-name")? If so, what error did you get?

Please, let me know if something isn't clear

Kind regards,

Hi Richard

yes I copied the full resource identifier from the JSON viewer in the azure portal and get the error message "Request failed with error: VM is not reachable by the bastion host".
When connecting directly to the IP it works so it's not true that the resource is not reachable from the bastion node.
I totally understand that you rely on Microsofts implementation of the command. As it appeared in multiple tenants at the same time I would also think something changed or is now deprecated on MS side.

Best
Simon

Hello

Ok, interesting.

For what it's worth, if you need to get unblocked, you can try changing the Bastion "connection mode" to "TCP Tunnel" and switching the hostname of the RDP server to the IP address in RDM. Depending on what other options or features you need it may or may not work for you.

I'd like to get to the bottom of this. We don't use `az cli` internally, but we reimplement it's functionality; and in the case of the RD Gateway connection mode it's just a bunch of REST calls to the Azure network API and the Bastion host itself. I did take a quick look at the latest az cli internals and couldn't spot any obvious changes.

Do you know what version of az you're using, and what version of the bastion extension? Perhaps there is an update available for one or both of those? I'm sorry I can't provide more explicit instructions because I'm not a heavy az user and haven't used it much since the Bastion feature became an optional module. But fi you can't figure it out, I can take a look how to check that...

Broadly I want to know if something changed on the server side, and there have been corresponding updates to az to accommodate that. It could be that something changed but I just don't see it yet (historically MS has rolled out features and changes in different regions at different times).

Thanks and kind regards,

Hi Richard

the versions are as follows:
az version
{
"azure-cli": "2.78.0",
"azure-cli-core": "2.78.0",
"azure-cli-telemetry": "1.1.0",
"extensions": {
"bastion": "1.4.2"
}
}

interestingly enough it works when changing it to to tunnel mode in the rdm and changing from hostname to ip.
What does this mean? Does it mean there's an issue in the RD Gateway Connection Mode implementation? Because as mentioned this worked at the beginning of the week. I think until monday and on tuesday suddenly stopped working using the RD Gateway connection mode. The tenant is in switzerland north if that has anything to do with it.

Best
Simon

Hello

Ok, so everything has the latest version. I don't see any significant change in the Bastion module for several months, just incremental changes and bug fixes that aren't relevant here.

What does this mean?

There are two ways to connect to a host using Azure Bastion native client. I don't remember the Microsoft nomenclature but in RDM we call them "RD Gateway" and "TCP Tunnel".

RD Gateway: the Bastion serves an .rdp file preconfigured to use the Bastion as a Remote Desktop Gateway. Launching the .rdp file functions like normal Windows terminal services in that environment. The advantages are that RD Gateway supports more functionality (for example, Azure MFA Authentication) and is likely faster. The disadvantage is that it only works with RDP.

TCP Tunnel: the client opens a secure websocket tunnel to the Bastion and the Bastion forwards the TCP traffic sent over the tunnel to the VM. The advantages are that it can work with different protocols and ports. The extra layer of indirection probably makes performance slightly worse. It doesn't support advanced RDP features (like Azure MFA Authentication).

You might try switching back to RD Gateway and using the IP address, it will be interesting if it works. I remember at the time I implemented this feature (a long time ago), IP-based connect didn't work with RD Gateway mode but I suppose it does now. I don't know if we need to change something on our side to support that.

Broadly, the failure in RDM and az (when using an RD Gateway session and connecting by VM ID) appears to be the same thing. If it won't work in az, it won't work in RDM. The fact that this suddenly broke strongly suggests an issue on the Azure side. I wonder if it's a regional thing - I can't reproduce that problem here (North America), and I note that @alf also appears to be in Europe. I've search the issues on the az cli and cli extensions GitHub and not found anything similar, and the Azure status page all checks out. I would normally point the finger at a misconfiguration on your side, but the fact that you haven't changed anything and that this seems to have broken simultaneously for two users in the same geographic region strongly suggests something on the MS side.

Like I wrote, if it won't work in az it won't work in RDM either. I'm sorry to bear bad news, but I'd suggest taking that to Microsoft and see what they say about it. I would be really interested in the results. In the meantime it looks like you can use either TCP Tunnel or (try using) RD Gateway with an IP-based connection. TCP Tunnel won't work for @alf since they need Azure MFA and it's not clear if their environment is configured for IP-based connection.

Please, let me know if something isn't clear or you have further questions

Kind regards,