HySecure Turbo Tunnel Guide: When and why to use it
Applies to: HySecure Gateway 7.0 and above
Category: Deployment planning
Overview
HySecure supports two tunnel types for application access: App Tunnel and Turbo Tunnel. App Tunnel is the default and covers most deployments. Turbo Tunnel is an L3 UDP-based tunnel that always provides a performance advantage over App Tunnel — it operates at Layer 3, avoiding the TLS handshake overhead and Layer 7 processing that App Tunnel incurs. Beyond performance, Turbo also supports use cases that App Tunnel cannot address: per-user IP address assignment and reverse connectivity.
App Tunnel is the simpler starting point and is appropriate for most standard deployments. Turbo is the better choice when performance is a priority, or when a specific use case requires network-level access, per-user IP addressing, or server-initiated connections.
How Turbo Tunnel Works
When a user connects via Turbo, the gateway assigns a virtual IP address (VIP) from a pre-configured pool to that session. Traffic flows as an L3 UDP tunnel from the client to the gateway. At the gateway, encryption and decryption happen at Layer 3 — the packet is then forwarded directly toward the backend application without traversing the upper layers of the network stack.
This is the fundamental difference from App Tunnel, which terminates the connection at Layer 7: App Tunnel performs a TLS handshake, decrypts at Layer 7, reads the application payload, and re-encrypts before forwarding. Turbo bypasses this entirely, which is why it is always faster regardless of what else is optimized at the application layer.
Turbo also rotates encryption keys every two minutes, providing an additional layer of session security independent of the application or protocol in use.
Turbo vs. App Tunnel
| Characteristic | App Tunnel | Turbo Tunnel |
|---|---|---|
| Protocol | L4–L7 TCP/TLS | L3 UDP |
| Tunnel scope | Per-application micro-tunnel | Network-level tunnel with ACL-based access control |
| Source IP address visible to backend | Gateway node IP address | Gateway node IP address (masquerade) or unique VIP per session (routable) |
| Reverse connectivity (server-initiated) | Not supported | Supported |
| Latency sensitivity | Moderate | High — optimized for real-time traffic |
| Performance vs. App Tunnel | Baseline | Always faster — L3 encryption avoids TLS handshake and Layer 7 processing overhead |
| Encryption key rotation | Session duration | Every two minutes |
| Default | ✅ Yes | ❌ No — requires explicit configuration |
| Recommended starting point | ✅ Simpler, appropriate for most standard deployments | ✅ Better choice when performance is a priority or use case demands it |
Client Platform Support
All HySecure Workspace Client platforms support Turbo Tunnel.
Note
Browser-based web access does not support Turbo Tunnel. Turbo requires the installed Workspace Client.
When to Evaluate Turbo
VDI Scenarios
High-latency environments (RTT > 350–400 ms)
TCP-based tunnels degrade significantly at high round-trip times due to retransmission overhead and congestion control behavior. Turbo's UDP-based transport handles packet loss more gracefully, making it the better choice for users on high-latency internet links accessing VDI sessions.
Audio and video workloads inside VDI
Applications such as Google Meet, WebEx, and training platforms running within a VDI session generate continuous, latency-sensitive UDP traffic. App Tunnel's TCP stack introduces jitter and buffering that degrade call quality. Turbo eliminates this by passing L3 traffic over UDP.
Turbo provides a display and session performance advantage even when Teams or Zoom multimedia optimization is active. Offload handles audio, video, and screen-sharing traffic at the endpoint — but display traffic still traverses the tunnel. App Tunnel processes this at Layer 7, incurring handshake and encryption overhead at each step. Turbo handles it at Layer 3 and forwards packets without reaching Layer 7, resulting in lower latency for display and session traffic regardless of offload status.
Note
Turbo improves display and session performance irrespective of whether multimedia offload is active. App Tunnel is the simpler starting point; use Turbo when display performance or session responsiveness is a priority.
ZTNA / Private Access Scenarios
High-latency internet access to private applications
Same reasoning as VDI: at RTT > 350–400 ms, TCP-based tunnels introduce cumulative overhead that Turbo avoids.
Applications requiring a unique source IP address per user
Some applications enforce access control or perform compliance auditing based on the source IP address of each request — core banking platforms (such as Finacle), trading systems, and regulated internal tools are common examples. App Tunnel always exposes the gateway node IP address, making all users indistinguishable at the network layer. Turbo with Masquerade OFF assigns a unique routable VIP per session, satisfying per-user IP address requirements without architectural changes to the application.
Reverse connectivity
Some protocols require the server to initiate a connection back to the client — RDP callback, certain VoIP signaling flows, and legacy enterprise applications with callback architectures. App Tunnel does not support server-initiated connections. Turbo does, because it creates an L3 tunnel that maintains a persistent peer entry on the gateway for the duration of the session.
Access Control in Turbo
Turbo provides network-level access, controlled by ACL rules configured by the administrator. ACL rules define which hosts, protocols, and ports are reachable per user or per application — including hostname-based, IP-based, and port-range-based rules. Access is not open-ended; it is bounded by the ACL configuration applied to each Turbo session.
App Tunnel limits access to only the applications published in the console. If strict per-application (TCP only) zero-trust access is required, App Tunnel is the simpler choice.
Important
ACL enforcement must be enabled in the Turbo configuration. Verify that the ACL check is active before deploying Turbo in a production environment. If ACL enforcement is disabled, session traffic is not restricted by access rules.
IP Address Pool Design
The IP address pool is the range of virtual IP addresses the gateway draws from when assigning a VIP to each Turbo session. Each active session consumes one VIP for its duration — this is the primary capacity constraint to plan for.
Important
The IP address pool used for Turbo must not overlap with any existing network infrastructure — including MZ/DMZ networks, LAN segments, or application servers. This range is exclusively reserved for Turbo. If the same IP range is already assigned to any network component, users may experience connectivity issues during Turbo sessions.
Choosing between the two models
| Requirement | Model | Masquerade setting |
|---|---|---|
| Backend does not need per-user IP address visibility | Non-routable pool (any private range) | ON |
| Application uses IP address-based access control or auditing | Routable pool (must be reachable within the customer network) | OFF |
Non-routable pool (Masquerade ON)
Backend servers see the gateway node IP address, not the individual user's VIP. Use any private IP address range not already in use on the network. This is the simpler model and the correct default for most deployments.
Routable pool (Masquerade OFF)
Backend servers see the unique VIP assigned to each user session. The IP address range must be routable within the customer network — routing tables on intervening switches and firewalls must forward traffic destined for the pool range to the gateway. This model requires coordination with the network team before deployment.
Pool sizing
Size the pool to cover the maximum expected number of concurrent Turbo sessions. VIPs return to the pool on session termination. The Pool Utilization view (Policies > IP Address Pools) shows real-time status — Unused, Available, or Busy — for each address in the pool.
Important
A pool that runs out of VIPs will prevent new Turbo sessions from establishing. Size conservatively — add a buffer above the expected peak concurrent session count.
For more information on configuring Turbo Tunnel, click here.