Gateway

Thinfinity Gateway is a critical security and routing component within the Thinfinity® Workspace architecture. It functions primarily as a secure reverse proxy to bridge external users to internal network resources.

Key Responsibilities and Characteristics

Secure Entry Point

The Gateway acts as the sole, hardened entry point for all remote access attempts to connect to your organization’s network. It is typically the only component exposed to the public internet and is often placed in a Demilitarized Zone (DMZ) or within a public cloud environment. This strategic placement ensures internal infrastructure (servers, applications, data) remains hidden, drastically reducing the attack surface.

Reverse Connections / Outbound-Only Traffic

Acting as a reverse proxy, the Gateway is the only component that requires opening an outbound port and it protects your internal network by intercepting external client requests. This strategic placement ensures that no internal nodes or servers are directly visible on the public internet; instead, clients only ever see the Gateway’s IP, effectively cloaking your sensitive internal server ports.

Encrypted Communication

All data exchanged between the user’s browser and internal resources is fully encrypted. The Gateway enforces end-to-end SSL/TLS encryption (e.g., TLS 1.3) for every communication channel, protecting sensitive data from eavesdropping.

Traffic Routing and Optimization

The Gateway intelligently routes user traffic to the appropriate Thinfinity Broker or Virtualization Agent within the internal network. It optimizes connection paths based on factors such as Geographic Location (GeoIP), Server Load, or Administrative Preferences. This intelligent routing improves user experience by reducing lag.

Brokering Isolated Browser Sessions

The Gateway brokers isolated browser sessions the same way it brokers other backends. When a user opens a Remote Browser Isolation connection, the browser runs in a Kubernetes-hosted pod that connects outbound to the Gateway and registers with it — exposing no inbound ports, exactly like Brokers and Agents — and the user reaches the isolated browser only through the Gateway. For the isolation model and the Kubernetes side, see Remote Browser Isolation in the Cloud Manager manual.

Firewall-Friendly Design

The Gateway operates efficiently over standard web ports, primarily using HTTPS, which simplifies network security configurations and reduces potential attack vectors compared to solutions requiring numerous inbound ports.

Scalability and High Availability

Engineered for scalability and high availability, the Gateway can work in load-balancing scenarios. Deploying multiple Gateway instances behind a load balancer increases capacity, provides fault tolerance by redirecting traffic if an instance fails, and ensures a consistent user experience under fluctuating demand.

Deployment Flexibility

The Gateway can be deployed in various scenarios, including on-premises DMZ deployment, public cloud deployment, hybrid cloud scenarios, or even as Gateway as a Service. This flexibility accommodates diverse organizational infrastructures and security policies.

Communications Gateway

A Communications Gateway is not a separate binary or a separate Gateway role — it is a normal Gateway instance that the Broker treats as a routing target for session traffic. In a deployment with multiple Gateway instances, the Broker distinguishes between the Primary Gateway — the public-facing entry point that serves the portal, the login page, and every web resource (HTML, JavaScript, CSS) — and one or more Communications Gateways, dedicated to the session data plane (WebSocket traffic, file transfers, the PDF viewer, and virtual channels). By default, session data inherits the Primary Gateway’s address; registering a Communications Gateway routes it to the dedicated address instead.

Communications Gateways serve three purposes, with the specifics depending on how many are registered:

• Network topology. Where a target lives in a segment the Primary Gateway cannot reach, a Communications Gateway placed inside that segment becomes the meeting point for the session. Because both the target and the user reach outward to meet at a gateway — neither listens for inbound connections — the target needs no inbound firewall rule at all, which is what lets the Virtualization Agent path span NAT and segmented networks.
• Load distribution. A single gateway is not infinite: the number of pools one gateway can serve becomes the ceiling for the whole system. With two Communications Gateways registered, the Broker routes each new session to the one serving fewer pools.
• Latency and geography. With a single gateway, every user connects to the same place regardless of where they are, and the round trip that carries every keystroke and every screen refresh pays that distance. From three Communications Gateways onward the Broker auto-enables GeoIP-based distance routing: for each new session it measures the distance from the user’s browser to every registered Communications Gateway, keeps the ones within roughly 100 km of the closest, and uses pool load as a tie-breaker within that set. The practical consequence is that a user is only ever routed to Communications Gateways that are nearly as close to them as the nearest one — so for a geographically dispersed user base, each user effectively picks among the local cluster of gateways rather than the global pool.

This distinction matters when the Primary Gateway sits behind a load balancer: its address routes portal and web-resource traffic correctly, but isn’t necessarily one a client should dial directly for session data. Registering one or more Communications Gateway addresses gives the Broker a directly-reachable address to hand out for the data plane instead — the Primary Gateway continues to serve the portal and web resources, and only the session traffic moves to the Communications Gateway.

For configuration details, see Registering Communications Gateway URLs and the Gateway Tab reference.