Clarification on custom TCP port support for IP-based endpoints via Azure Bastion

## 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

1. **Is support for generic TCP tunneling to IP‑based endpoints on the roadmap?**
2. **Is there an expected timeline for this capability?**
3. **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_