azure-cli: Unexpected tunneling issues for databases with Bastion native client

Related command az network bastion tunnel

Describe the bug We are using the command above to tunnel the database port of our local machine to the database running on one of our VMs via Azure bastion native client. Command-line based tools have no problems using this connection to the database. However, GUI-based tools fail after the initial connect to perform a second query. They hang when trying to connect to the database. We suspect that these tools open a second connection under the hood and that the first initial connection “blocks” the tunnel for any other connections.

We have tested multiple GUI-tools (PgAdmin, Azure Data Studio, etc.) and they all experience the same problem. Under the hood, they open a second connection, which then fails to connect. If we connect to the VM directly via public IP using a regular ssh tunnel (ssh -L …), the tools work fine without any other configuration.

All in all, the bastion-based tunnel does not work as expected. It would be great to have the same experience like with regular SSH tunnels.

To Reproduce Have a database ( e.g. Postgres) running on the test VM in the cloud. Postgres by default is port 5432. Open a bastion tunnel to the test VM on this port. Then use a tool like Azure Data Studio on your local machine to connect via localhost:[db_port] using the Bastion tunnel.

Expected behavior There should be no problems with the connections blocking in our database tools.

Current workaround: Use the bastion tunnel for the ssh port of the VM. Then use a regular (open-)ssh tunnel in front of the bastion tunnel for the database port. This works fine as well, however, two tunnels are necessary and using Azure AD for logging into the VM is also more complicated.

Environment summary

Windows-10-10.0.18363-SP0
Python 3.10.4
Installer: MSI

azure-cli 2.36.0

Extensions:
ssh 1.1.1

Dependencies:
msal 1.17.0
azure-mgmt-resource 20.0.0

Additional context