Overview
We are currently using Azure Bastion for secure access to Azure VM resources inside our private virtual network. The native client + tunnel capability works well for Azure VM access (SSH/RDP), but we would like clarification regarding support for generic TCP tunneling to IP-based endpoints.
Azure Bastion also supports secure tunneling to Azure Kubernetes Service (AKS) private clusters, which further demonstrates the value of generic TCP tunneling beyond Azure VM resource IDs, yet the current support still appears to be scoped to specific services rather than arbitrary IP/port pairs.
Operational Use Cases
In environments where public exposure is disabled and VPN connectivity is intentionally avoided, Azure Bastion tunneling would be our preferred secure access mechanism for tasks such as:
- Secure secret management using Azure Key Vault (public network access disabled)
- Secure file exchange using Azure Files (public network access disabled)
These scenarios require secure, point‑to‑point TCP connectivity to private endpoints without introducing additional infrastructure.
Current Limitation and Architectural Inconsistency
Custom port selection is currently supported when targeting an Azure VM via its resource ID, but it is not yet available for IP-based targets, which I assume reflects a deliberate security design decision on your end. From an architectural perspective, however, this distinction appears inconsistent: if Bastion can establish a TCP tunnel to an arbitrary port on Azure VM, there does not appear to be a technical or objective security reason preventing similar behavior for private IP-based endpoints.
Our current workaround involves creating a DNAT rule on a firewall to redirect traffic, effectively allowing the Azure Bastion host to reach the Non-Azure VM target indirectly, however, this adds operational complexity, additional infrastructure components, and most importantly - it's not a scalable and production-worthy solution.
Questions for the Azure Bastion Product Team
- Is support for generic TCP tunneling to IP‑based endpoints on the roadmap?
- Is there an expected timeline for this capability?
- Are there recommended best practices for securely accessing arbitrary private endpoints without using jump hosts, VPNs, or DNAT rules?
Related command
az network bastion tunnel
--name 'my-bastion-host'
--resource-group 'my-resource-group'
--target-ip-address '10.10.10.10'
--resource-port 443
--port 443
Where 10.10.10.10 is the private endpoint of our Azure Key Vault, for example.
Errors
N/A
Issue script & Debug output
N/A
Expected behavior
N/A
Environment Summary
N/A
Additional context
No response
Overview
We are currently using Azure Bastion for secure access to Azure VM resources inside our private virtual network. The native client + tunnel capability works well for Azure VM access (SSH/RDP), but we would like clarification regarding support for generic TCP tunneling to IP-based endpoints.
Azure Bastion also supports secure tunneling to Azure Kubernetes Service (AKS) private clusters, which further demonstrates the value of generic TCP tunneling beyond Azure VM resource IDs, yet the current support still appears to be scoped to specific services rather than arbitrary IP/port pairs.
Operational Use Cases
In environments where public exposure is disabled and VPN connectivity is intentionally avoided, Azure Bastion tunneling would be our preferred secure access mechanism for tasks such as:
These scenarios require secure, point‑to‑point TCP connectivity to private endpoints without introducing additional infrastructure.
Current Limitation and Architectural Inconsistency
Custom port selection is currently supported when targeting an Azure VM via its resource ID, but it is not yet available for IP-based targets, which I assume reflects a deliberate security design decision on your end. From an architectural perspective, however, this distinction appears inconsistent: if Bastion can establish a TCP tunnel to an arbitrary port on Azure VM, there does not appear to be a technical or objective security reason preventing similar behavior for private IP-based endpoints.
Our current workaround involves creating a DNAT rule on a firewall to redirect traffic, effectively allowing the Azure Bastion host to reach the Non-Azure VM target indirectly, however, this adds operational complexity, additional infrastructure components, and most importantly - it's not a
scalableandproduction-worthysolution.Questions for the Azure Bastion Product Team
Related command
Where
10.10.10.10is the private endpoint of our Azure Key Vault, for example.Errors
N/A
Issue script & Debug output
N/A
Expected behavior
N/A
Environment Summary
N/A
Additional context
No response