Error after enabling #33632
Comments
|
@d83194 |
|
Thanks - I wonder if it really is as the error message suggests: 'the target machine is taking too long to respond' and Azure Bastion has a minimum spec VM it can work with. Maybe my Standard B1ms test machine isn't high enough spec'd. |
|
@d83194 , the error actually states that the connection from your machine/PC from where you are trying to access VM via Browser is not stable. Actually your HTTPS session will be reaching Azure Bastion host which then translates HTTPS session to RDP session to the VM. Can you try connecting to a different network and check if you get similar issues? |
|
Yes I still receive this error whilst VPN'd in to another Network and going out of that proxy. |
|
Also tried via a different device / different Internet / network, same error message. |
|
@d83194 are you able to connect to the virtual machine via another path besides bastion? |
|
Yes, I can RDP to it fine via a jump box in the same vnet. |
|
@d83194 can you Email me at AzCommunity@microsoft.com with your Subscription Id and the Public IP address of your bastion host? I would love to take a closer look. |
|
I am experiencing the exact same issue described here. I am emailing the requested information, just wanted to add this doesn't seem to be isolated. |
|
If there are any NSGs that block communication to port 3389 to your VM VNET, Azure Bastion will not be able to connect to your VM. Azure Security Center JIT access can also block Azure Bastion's connectivity. |
|
@TravisCragg-MSFT by default an NSG denies all inbound traffic, including 3389, however traffic from within the vnet, including 3389 to anything within the vnet is allowed. Are you saying Azure Bastion is not recognised as being in the vnet? What NSG settings are required / recommended to configure to allow it through? |
Travis was commenting based on my use case. We utilize JIT and it had created rules that blocked any traffic inbound on 3389. I had to create a special rule for the Bastion subnet to allow the traffic. This resolved my issue. |
|
My issue was resolved my resetting the RDP port back to 3389. |
|
@d83194 Default NSGs contain an Allow rule for traffic inside of a VNET. By default, this allows traffic from the "AzureBastionSubnet" subnet. If traffic is blocked in port 3389 from that subnet, Azure Bastion will not be able to connect to your VM. @mrohler not at this time, but keep an eye out in the future for new features to be added to Azure Bastion. If you would like to leave feedback or suggest a feature, you can leave your feedback Here! |
|
@TravisCragg-MSFT yeah I was saying with an out of the box config for NSGs you wouldn't expect being blocked on 3389 from AzureBastionSubnet to vnet resources, as like we're saying out the box vnet resources <> vnet resources is allowed. What I've found is configuring your VM for RDP on another port breaks Azure Bastion, and resetting it back to 3389 resolves it. It'd be good if you could configure which port you want Azure Bastion to run over, or maybe it's just a limitation and for use you need to set RDP back to 3389 in your VMs. Cheers! |
|
Hello, IT work with Active Diretory user for login on our VMs? |
|
@alejosroj2c I do not believe there is a restriction with AAD user login. Any valid login for the VM should work with Azure Bastion. |
|
I had the same error but adding new allowed rule for 3389 port fixed my problem. But now I have another one |
|
@Rutikhal Make sure that you can log into the VM from a different path (RDP on the Public IP, or from a different VM inside the VNET). Once you can confirm you can log in to the VM successfully, try those credentials from Bastion. |
|
@d83194 We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue. |
|
I had a problem with RDS License configuration on server to which I tried to connect. After fixed it, connection via Azure Bastion started to work. |
|
I had the same message "bastion.azure.com took too long to respond." The solution was to allow 443 (SSL) on the AzureBastionSubnet from the public internet. |
How exactly is that done? I have same problem... |
|
@jamico If your "AzureBastionSubnet" subnet has an NSG attached to it, you will need to add an inbound rule that allows port 443 using TCP from the service tag "internet" |
I have no SNG attached |
|
@jamico Then port 443 is not blocked from reaching your Azure Bastion. If you are receiving the "connection closed because the target machine is taking too long to respond" error, then you should check the connectivity between your Azure Bastion and your VM. If additional troubleshooting is needed, your best bet for assistance is via Azure Networking's MSDN Forums. |
|
Folks I have this very same issue, but have isolated it to one vnet. If I use a different vnet and setup a test Bastion host and Bastion subnet, then all works perfect. Just with my main production vnet I see this issue. Are there any requirements in the Route Table that need to be setup for Bastion to work? Also to mention, in my case none of these vnets or vnics have NSG's attached so nothing should be blocking them. |
|
@davek81 Any custom routes or firewalls that would effect RDP / SSH traffic between the Azure Bastion subnet and the VMs will cause issues. |
|
Ok this must be the cause. We have a firewall deployed in Azure and a user defined route for 0.0.0.0/0 with a next hop going to the internal firewall IP. Comparing to the routes on the other vnet where I have the working instance of Bastion, I can see the default route for 0.0.0.0/0 next hop is internet. I just need to confirm what the routing requirements are for this. In the vnet where Bastion isnt working, should I create a route for the Bastion subnet with next hop being internet? Or perhaps a route for the specific IP of the NIC I want to connect to with a next hop of internet? Or both? |
|
@davek81 Do not use a UDR within the AzureBastionSubnet. If your VMs are behind a firewall, it can also pose additional challenges. Here is a doc that discusses how Azure Bastion interacts with firewalls. |
|
@davek81 I would bypass the FW if possible. If you are using a UDR on the AzureBastionSubnet, you will likely see communication issues, and it will be tricky to resolve. You can review this doc to see what traffic is necessary for Azure Bastion to function. For your UDR, make sure that traffic destined for Azure Bastion is not sent to a Virtual Appliance, and is instead sent straight to the Azure Bastion subnet. |
|
I have confirmed the route table is not applied to the Bastion subnet so that simplifies it. However my VM is in a subnet with this route table applied. With 0.0.0.0/0 with next hop to firewall, I presume this will interfere with Bastion connecting to the VM. So would you suggest a UDR for the IP of the VM to bypass the firewall? |
|
@davek81 You can make another route that allows traffic destined for the AzureBastionSubnet to go directly to that subnet, instead of going to the firewall. |
|
That did it. I created a UDR to route traffic back to the Bastion subnet, instead of the 0.0.0.0/0 route to FW that I had in place. Thank you so much! |
|
I get this seemingly randomly on a set of 10 WVD VMs. I can get into some, and others I can't. If I kick all the WVD users off and reboot the VM it'll usually work fine. Sometimes it happens on a WVD VM that isn't even in use. If this was a configuration issue I'd expect it to always be a problem, not be an intermittent issue. |
|
@Imperitiv I would recommend creating a support request if you want to look into that further. Intermittent issues can be hard to track down. |
This doesn't really work for me - how did you actually do this UDR? I've got my routes following on my spoke VNET: 0.0.0.0/0 -> NVA My AzureBastionSubnet is in the hub VNET in 10.2.0.0/27. With this setup there's an asymmetric routing. If I add 10.2.0.0/27 -> Virtual Network it doesn't make any difference. |
|
Should it help others, we had the same issue / found that the error only occurred when connecting to the bastion via a proxy; in our case IBOSS. If we had the proxy enabled (i.e. the IBSA Windows service running on the client) we'd get the error; the moment the service was stopped we'd be able to connect. |
|
I am experiencing the same issue, however I have 3 VMs in the same vNet and subnet, where I can access two of them just fine - the third one fails with the same error message as in this post. The Subnet all three VMs are on utilize on single NSG and the bastion subnet does not use any NSG. I can connect to the unresponsive VM by RDP directly, but not through Bastion for some reason that escapes me. Can any one see where the issue must be? |
After following the guidance on this page, when connecting to a VM I see errors:
'The network connection to the Bastion Host appears unstable.'
and
'The connection has been closed because the target machine is taking too long to respond. This is usually caused by network problems, such as a spotty wireless signal, or slow network speeds. Please check your network connection and try again or contact your system administrator.'
The VM is powered on and has been up for 15 minutes. The 'Provisioning state' of Bastion is 'Succeeded'. Errors in Chrome and Edge.
Document details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: