By default Twingate allows End Users to establish peer-to-peer connections with protected Resources, without requiring any open inbound port.

It is available to all Twingate customers and does not require any additional deployment for existing customers and is completely transparent to end users and administrators.

How it works

Let’s take a look at the flow a Client follows to establish connection to a Resource via a Connector:

1. Establish a signaling channel:

On initial startup, both the Twingate Client and Twingate Connector initiate and establish an authenticated connection to a central service that is publicly accessible (Twingate’s Relay Infrastructure available globally).

The initial role of this service is to establish a signaling channel for the exchange of peer candidate addresses to each peer.

2. Discover peer candidate addresses:

For the client to negotiate a peer-to-peer connection with a connector, both peers must discover their public IP:port address assigned by the NAT layer. (A STUN server facilitates this process and is hosted within Twingate’s relay infrastructure.)

3. Exchange candidate peer addresses:

Each peer next receives one or more candidate addresses for its peer via the signaling channel. The connector will receive candidate address(es) for the client and vice-versa.

4. Negotiate & establish the connection:

The peer candidate addresses are used by the partner peer to attempt to establish a direct peer-to-peer connection and complete the NAT traversal process.

Summary

It is not always possible to establish a direct peer-to-peer connection due to various reasons from blocked ports to incompatible NAT layers. In those cases, a backup data transport method needs to be maintained.

In Twingate’s case, this is a data relay infrastructure that operates in the transport layer of our network architecture. Relays have public addresses and are available across the globe, therefore they are always accessible from clients and deployed connectors, serving as a reliable backup transport method.

Here is what you should keep in mind about peer-to-peer in Twingate:

• NAT traversal is used to create a peer-to-peer connection between clients and resources to minimize latency.

• Relaying infrastructure is available as a backup transport method when NAT traversal is not possible.

• Twingate automatically prioritizes the lowest latency transport option that’s available between peers and requires no special configuration from the Client or Connector.

Under The Hood

If you are interested in the technical details on how peer-to-peer is implemented, read on:

Peer-to-peer introduces QUIC (a new transport layer network protocol) to the Twingate platform to handle peer-to-peer connections.

QUIC introduces several improvements to our transport layer, including faster connection establishment, greater tolerance to network changes (a dominant mode standard in today’s world of mobile devices) and more effective traffic management of multiple, concurrent data streams.

User space network stack implementations like QUIC can evolve more quickly than their kernel space counterparts, and we’re excited to participate in this fast-paced evolution.

QUIC was originally developed by Google and has since been standardized by IETF in RFC 9000 and proposed as the underlying transport protocol for HTTP/3. One of the primary goals of QUIC was to become a better transport mechanism for HTTP/2, which suffers from the so-called head of line blocking problem due to its use of TCP as the underlying transport protocol.

The head of line blocking problem occurs when all HTTP/2 streams multiplexed over a single TCP connection are impacted by retransmission due to packet loss affecting only a subset of streams.

QUIC is built on top of UDP, which is an unreliable network protocol, and so it provides its own reliable delivery mechanisms. QUIC provides reliable and ordered delivery of multiple concurrent data streams by multiplexing them over a single connection. Although TCP implementations have been highly optimized over many years, for many users and use cases, QUIC’s low latency is arguably more critical than raw throughput, and QUIC can match or exceed TCP+TLS in this respect. Thanks to QUIC’s adoption, there are also ongoing efforts to optimize UDP performance in the Linux kernel, which will further improve performance in the future.

The motivation behind the development of QUIC—to improve the throughput of multiple streams on a single reliable connection—is also valuable to maximizing throughput from the Twingate client to multiple private resources. Although QUIC was envisioned to optimize the throughput of multiple streams for a single application (e.g., your browser), Twingate extends this concept by mapping individual data flows from any number of applications to single QUIC streams and delivering those data flows to connectors and resources deployed anywhere in our distributed architecture.

Beyond performance management for multiple data flows, adopting QUIC also introduces several valuable improvements to our network architecture:

• Faster connection establishment
  The initial connection takes a single round trip between client and server. Connection resumption can also be done without any additional round-trip negotiation.
• Support for the latest cryptographic protocols
  QUIC only supports TLS 1.3 and later, and introduces additional security into the encrypted channel.
• Client-side roaming
  QUIC connections survive client-side IP and port changes—for example, due to NAT rebinding or a user switching between networks—which not only results in a better experience for users but is also better suited for today’s mobile work environment.
• Incorporates best practices from TCP
  Although QUIC is a UDP-based protocol, it contains the best practices learned over the long history of the TCP protocol without being restricted by TCP’s legacy (e.g., packet format). For example, QUIC is usually more efficient than TCP in dealing with packet loss recovery.