How It Works

The Gateway acts as an identity-aware Layer 7 reverse proxy between protocol clients and upstream services, enabling secure access to private infrastructure through Twingate's Zero Trust network. The table below maps generic terms used on this page to their protocol-specific equivalents.

	Kubernetes	SSH	Web App
Protocol client	kubectl	ssh	Web browser, curl, etc.
Upstream service	Kubernetes API server	SSH server	Web application
Client configuration	~/.kube/config (context, CA cert)	~/.ssh/known_hosts (host CA)

Client Configuration

When a protocol needs client configuration, the Twingate Client syncs it automatically. This includes the resource address and trust material (e.g., CA certificate) needed to verify the Gateway's identity. The synced configuration contains no credentials - no tokens, private keys, or passwords to rotate or manage. Auto-sync keeps configuration current as resources are added or removed.

Connection Flow

All protocols share the same connection flow up to authentication. After that, the inner connection is protocol-specific. The example below uses Kubernetes.

A Kubernetes resource is configured on Twingate as follows:

• Address: 10.0.0.1 - The address of the Kubernetes API server that is reachable by the Gateway
• Gateway Address: gateway.int - The address of the Gateway that is reachable by the Connector
• Certificate Authority certificate: the CA certificate to verify the TLS certificate served by the Gateway

The diagram below shows how a kubectl command reaches a private Kubernetes cluster:

sequenceDiagram
    autonumber
    participant kubectl
    participant Client as Twingate Client

    box Private Network
        participant Connector as Twingate Connector
        participant Gateway as Gateway<br/>(gateway.int)
        participant K8s as Kubernetes API Server<br/>(10.0.0.1)
    end

    Note over kubectl: ~/.kube/config synced by Twingate Client<br/>with API server address (10.0.0.1) and CA certificate

    Note over kubectl: kubectl get pods

    kubectl->>Client: TCP to 10.0.0.1

    Note over Client,Connector: 🔒 Encrypted Tunnel

    Connector->>Gateway: Forward TCP connection

    Note over Client,Gateway: 🔒 TLS handshake (outer layer)

    Client->>Gateway: HTTP CONNECT with GAT

    Gateway->>Gateway: Validate GAT

    Gateway-->>Client: 200 Connection Established

    Note over kubectl,Gateway: 🔒 TLS handshake (inner layer)

    kubectl->>Gateway: HTTP request (GET /api/v1/namespaces/default/pods)
    Gateway->>K8s: Forward HTTP request
    K8s-->>Gateway: HTTP response
    Gateway-->>kubectl: Forward response

Loading

Connection Steps

• 1️⃣ Protocol Client Initiates Connection: The protocol client opens a TCP connection to the resource address. Traffic flows through Twingate's encrypted tunnel between Client and Connector.
• 2️⃣ Connector Routes to Gateway: The Connector recognizes this as a resource with a Gateway and forwards the connection to the Gateway instead of the resource address.
• Outer TLS: The Twingate Client establishes TLS with the Gateway for the HTTP CONNECT tunnel.
• 3️⃣ 4️⃣ 5️⃣ Authentication: The Twingate Client sends an HTTP CONNECT request with the GAT; the Gateway validates it.
• Inner Connection: Depending on the protocol, the protocol client may establish an additional secure layer with the Gateway (e.g., TLS for HTTPS, SSH for SSH protocol).
• 6️⃣ 7️⃣ 8️⃣ 9️⃣ Request Proxying: The Gateway forwards the request to the upstream service and returns the response to the protocol client.

Authentication

The Gateway authenticates the user using the Gateway Access Token (GAT). This token is issued by the Twingate control plane after the user satisfies all security policies of the resource, including MFA, device trust, geo-location, and conditional access policies like JIT. The Twingate Client includes the GAT in its initial request to the Gateway during the outer TLS connection.

After authenticating the user, the Gateway handles authentication to the upstream service on the user's behalf. The mechanism is protocol-specific.

Connection Security

The Gateway terminates TLS for the outer connection between the Twingate Client and the Gateway. The Twingate Client validates the Gateway's TLS certificate using the Gateway's CA certificate. This outer layer is the same for all protocols.

Depending on the protocol, the protocol client may establish an additional secure layer with the Gateway within the same TCP connection (e.g., TLS for HTTPS, SSH for SSH protocol). The protocol client verifies the Gateway's identity using the trust material from the synced configuration. When no inner secure layer is present, the outer TLS connection provides the security.