Twingate vs Pomerium

Our Recommendation

Use Twingate for securing backend infrastructure and servers that rely on layer 4 traffic, and use Pomerium for all HTTP-based services and applications.

Twingate is a NextGen VPN designed with specific architecture to address the shortcomings of standard VPNs. Pomerium is an identity and context-aware reverse proxy that enables secure access to internal applications.

Given that Twingate is primarily a Layer 4 tool, it is great for accessing databases and servers and less capable when it comes to securing web applications at Layer 7. Twingate’s own documentation makes it clear that Application Gating is not one of their strong suits.

Use Cases

• Access Control Panel — Managing access control for staging and development environments without exposing them publicly.

• Vendor and contractor access — Twingate facilitates vendor remote access for easy onboarding/offboarding with access controls.

• NextGen VPN — Twingate wants to replace your VPN with their next generation VPN architecture.

Strengths

• Multi-factor authentication — Twingate extends MFA to SSH and limits access to privileged users.

• Security included — By having device posture and activity log policies, Twingate reduces attack surface and mitigates successful attacks.

• Access Control — Twingate provides access control for cloud environments and deployment.

• A trail of breadcrumbs — Twingate has real-time connection logging.

• VPN but better — Twingate designed their architecture around traditional VPN security gaps by splitting the VPN Gateway into a Relay and Connector.

Weaknesses

• Burdensome Clients — Unlike Pomerium, Twingate burdens all your devices and users with a client. To access the Twingate network, all users need to use the Twingate Client application on their device. For a remote network to be part of the Twingate network, you need to install at least one Connector in that network, configure it, and provision them with unique token pairs. There’s a LOT of client maintenance with Twingate when user counts scale.

• Unreliable Availability — In order for Twingate to function, their Relay centers need to be working. If Twingate is compromised or there’s an outage on their end, your Twingate setup will NOT work during that downtime. This isn’t an issue if you selfhost Pomerium as the infrastructure is wholly under your control.

• IdP limited — Twingate only supports a limited list of common identity providers.

• Still a layer 4 tunnel — While Twingate’s architecture does accomplish the goal of fixing the most common VPN issues, the overall design is still based on VPNs. It has lower latencies compared to VPNs, but there is still some backhauling of data to their nearest Relay. Pomerium is deployed at edge with absolutely zero backhauling.

• Price-gated features — The detailed auditing and deployment features, which are critical to any infrastructure, are gated behind Enterprise accounts.

Evaluators Should Know

Twingate is protecting your internals by having you close off your network, insert Connectors which only their Relays can talk to, then sell you access to their Relays.

At the heart of Twingate’s architecture lies the act of embedding their Connectors as proxy agents within your network. These Connectors exclusively interact with their Relay, facilitating the setup of connections for provisioning access. To put this bluntly, they have designed a multi-hop tunnel to reach a reverse proxy with VPN weaknesses.

To be fair, Twingate has made a commendable effort to architect around common VPN weaknesses. Twingate correctly identifies these problems:

• VPN connections have latency from data backhauling

• VPN uptime is only as good as every single hop in the chain being up

• VPNs have the Perimeter Problem in limiting lateral movement

However, Twingate is still susceptible to these fundamental problems because they utilize layer 4 multi-hopping tunnels. Their architecture may mitigate the issues endemic to VPN architecture, but the only way to avoid VPN problems is to not use a NextGen VPN or VPN-like architecture. You cannot design away inherent problems:

• The latency from data backhauling may be reduced, but is not eliminated. Twingate’s architecture proposes for the Relay to only take part during the initial connection establishment step, then once the NAT traversal is established, you have a straight connection to the resource. But for a brief step here, Twingate still adds an interim hop to their Relay server! However small, it’s unavoidable that this adds a degree of latency to each connection, and Twingate’s architecture does not address the fact that…

• Twingate’s entire architecture also requires 3rd-party service uptime. The Relay servers may only play their part during the connection establishment phase, but they are critical for that step. While the architecture means existing established connections should not be cut off, it does mean that new connections cannot be established during any downtime.

• Twingate proposes to limit lateral movement by having Connectors act as “software-defined proxies,” but proxies already exist. Pomerium is used to secure access for each of your applications and services without relying on Twingate Relay servers.