We've recently begun piloting Banyan Security for zero-trust access to our internal development tools. The standard setup for our modern web apps (HTTPS on 443 or 8443) works flawlessly. However, we've hit a significant roadblock with a critical legacy monitoring application.
This application runs on an on-premise VM and listens on **TCP port 8077**. It's a proprietary protocol, not HTTP/HTTPS. According to the documentation, Banyan's Access Tiers should tunnel raw TCP traffic for such use cases. Our configuration is straightforward:
```yaml
# Service Definition Snippet
service:
name: legacy-monitoring
description: Legacy TCP-based monitoring app
access:
- tcp:8077
backend:
target:
port: 8077
client_bind_port: 8077
selector:
name: legacy-vm
```
The service publishes successfully, and the device policy assigns access correctly. The connector logs show no errors. Yet, when we attempt to connect via the Banyan desktop app (or CLI), the connection establishes but immediately times out. Packet captures on the legacy VM show no incoming traffic from the connector when we attempt this connection.
This suggests the tunnel is formed but the traffic is not being correctly proxied to the backend port. We've ruled out local firewall issues on the VM.
Has anyone successfully configured Banyan for a non-standard, non-HTTP TCP port? Specifically:
* Are there any inherent limitations on which TCP ports can be used for raw TCP tunneling?
* Could this be related to the `client_bind_port` setting? The documentation on this parameter is sparse.
* Is there a required specific connector version or a needed flag for non-443 TCP services?
We're evaluating if we need to implement a local port-forwarder or a sidecar proxy as a workaround, but that undermines the simplicity we're aiming for. Any insights or similar experiences would be greatly appreciated.
--crusader
Commit early, deploy often, but always rollback-ready.
The immediate timeout after tunnel establishment points to a routing or NAT issue within the connector's network path to the legacy VM. The connector logs might be clean, but its local routing table or any host-based firewall on the VM itself could be dropping the forwarded packets.
Can you verify the connector's outbound path to the legacy VM's IP on port 8077 is open using a simple netcat test from the connector host? Run `nc -zv 8077`. Also, check if the legacy VM's firewall is expecting traffic from the connector's specific source IP, not a translated one. The `client_bind_port` directive can sometimes interact poorly with source NAT.
Post the results of that connectivity test and your connector's network configuration (NAT gateway, security groups on-prem).
Less spend, more headroom.