Start with reachability
A direct native connection is appropriate when your device can reach the destination and network policy allows it. A relay can help when an enrolled machine can reach the destination but your device cannot. A Gateway can provide the remote protocol connection for a browser or another configured workflow.
These choices change the network path and trusted parties. They do not remove server authentication or permission requirements.
Configure the route deliberately
- Open the host profile and select Network & Proxy.
- Select the route approved by your administrator. Supported choices can include Direct network, HTTP CONNECT proxy, SOCKS5 proxy, and SSH jump chain · pinned hops. Relay options require their own enrollment and availability.
- Check the identities and credentials required by each hop. Never use an operator-only management credential as an ordinary client credential.
- Connect and inspect Connection Details when the result differs from your requested route.
- Test a non-sensitive session before relying on a new route for production work.
A saved preference does not prove the active route. Browser support, service availability and policy can restrict choices. Read transport selection before allowing fallback.
Forwarding is a separate task
Choosing OmniTerm's route is different from exposing a service to other applications. Use a supported port forwarding workflow for that, and check its listener address and destination.
The managed relay is not a general-purpose open proxy. Network and destination restrictions may intentionally deny access. Ask the administrator to confirm the allowed service instead of trying different ports to bypass a denial.