Since launching Twingate in 2020, we’ve been fortunate to work with some of the fastest-growing companies in the world. These companies work on the bleeding edge of technology, and one of the most common discussions we have is how network connectivity will evolve to fully realize the potential of to Twingate that bring several modern networking technologies into our core networking engine. These include leveraging NAT traversal to facilitate direct, peer-to-peer connections between nodes in your Twingate network, and introducing QUIC, a modern network transport protocol that offers more resilient, lower latency connections.

These enhancements allow us to clarify how we believe network architectures will evolve in the coming years as for remote access, discuss the cloud-based architecture used by most vendors today, and walk-through Twingate’s distributed network architecture and the underlying techniques we’ve used to bring this architecture to life.

Traditional Network with VPN

on that network.

Companies often configure a single VPN into the corporate network and then set up secondary tunnels between other networks, which may be in different geographic locations. In this model, the VPN gateway acts as a concentrator for any remote user to enter the private network before being routed to their final destination. This results in a hub-and-spoke network topology that creates several problems:

• The VPN gateway sits at the edge of the private network with a public IP address, exposing it to the public internet. This makes VPN gateways susceptible to attackers, particularly when vulnerabilities are discovered. Unfortunately, these vulnerabilities are discovered frequently and are commonly exploited by adversaries.
• Because users can only connect to a single VPN gateway before their traffic is routed to its final destination, a significant performance hit often occurs as users bounce around geographically distributed locations before reaching the destination resource.
• Remote VPN users are typically given full access to the private network, which creates a .

  Cloud-based Networks and the PoP Race

  
  
  
  

  In the 2010s, a new crop of vendors emerged that attempted to solve these challenges by taking the on-prem private network managed by the company’s IT team and shifting it to a hosted network managed by the vendor. In this architecture, VPN gateways are replaced by Points-of-Presence (PoPs) that are geographically distributed and managed by the vendor.

  With this approach, the vendor’s private cloud network sits between users and company resources. Remote users need to first connect to the vendor’s nearest PoP before being routed to the final destination. To provide performance improvements over the traditional model, vendors offering this network architecture are in a perpetual race to build as many PoPs as possible (to be geographically close to users) and maintain and upgrade the network backbone between PoPs.

  However, even the largest vendors using this model have PoPs in the low 100s. Depending on the geographic distribution of a company’s workforce and the location of resources, this network architecture can improve the traditional network model. However, this model still puts the customer’s network performance at the mercy of how well a vendor’s distributed PoP footprint aligns with the company’s needs.

  Depending on the specific vendor’s implementation, other downsides with this model may include:

  • Inability to work for all protocols or resource types: Some implementations of this model are optimized for web-based resources accessed through a browser. This means it is difficult (and in some cases impossible) to use these solutions for applications and protocols like SSH and database clients.
  • Hard to integrate: These solutions will often require a complex implementation process so that a company’s private network is connected to the vendor’s network. This may require complex configuration and management of dedicated VPN tunnels, challenges with configuring DNS, and other points of deployment friction.

  Distributed Networks for a Distributed World

  With Twingate, we designed a network architecture with the underlying assumption that users and resources are both highly distributed and in constant motion. We believe that the ideal network architecture for this distributed world must allow network traffic to flow directly between nodes without traversing any intermediate nodes or networks.

  This also means that our customers’ network performance is not limited by our ability to geographically scale-out a large footprint of PoPs in far-flung locations. This brings cloud-based architecture to its logical end state and effectively puts a local PoP on every device.

  
  
  
  

  To make all of this work, we need a new network architecture. While several widely accepted frameworks are available, which we gleaned inspiration from, they did not align with our , mesh networks, and Software-Defined Networking (SDN). Twingate’s architecture has elements of all these frameworks, and we’ve specifically focused on making design decisions that optimize for performance and security without compromising ease of deployment.

  In Twingate’s model, we think about separating our network architecture into three primary concepts:

  • The network layer: The set of resources and devices that need to connect to each other
  • The control layer: Permissions and access rules that determine which users and resources are permitted to communicate
  • The transport layer: The enabling mechanisms and routes for data to move between users and resources

  In a traditional network design, these concepts are tightly coupled and often result in tradeoffs that manifest in some combination of low performance, poor security controls, difficulty in deployment and management, or all of the above. Instead, we decided to decouple each of those concepts into separate layers that allow us to optimize the behavior of each layer to produce the maximum benefit, whether that is connection performance or security controls.

  We describe this as a distributed network architecture, and we believe that this will become the standard way companies will design and manage clients can access assigned resources.

  Clients and resources can access the control and transport layers directly via an embedded library, client application, or a lightweight proxy. These components perform a few critical functions:

  • Policy enforcement: rules passed down by the control layer are enforced locally without any traffic needing to leave the device.
  • Routing: route selections are executed locally to deliver the best connectivity performance.
  • Security: implement security controls such as enforcing themselves. This is enforced and enabled by the control layer, and it interfaces to an decisions are made directly in the client and resource nodes. These decisions are enabled by the control layer and executed by the client and resource nodes, which relegates the transport layer to a zero-knowledge transfer of encrypted bytes.

  In aggregate, the decoupling of these concepts into discrete concepts enables us to drive towards the optimal combination performance, security controls, and ease of management.

  Next, we’ll dive deeper into the underlying network techniques to bring this architecture to life.

  Twingate’s Distributed Network Architecture

  As we’ve worked to implement our version of the distributed network topology, we’ve employed a range of techniques that provide optimal performance in most scenarios and reflect the reality of how people work today.

  It all starts with Routing

  The first problem is routing. How do you get a network connection established from a client to a resource? The easiest solution would involve every device on the Internet having a unique address so that network connections could be directly routable between any two devices. Although this is how the Internet started, with every host uniquely accessible, it was clear as early as 1992 that every unique address in the IPv4 space would and adopted soon thereafter. NAT was intended to be a short-term solution, with IPv6 being the long-term solution to address exhaustion. The last block of IPv4 addresses was assigned in 2011, and in 2021 we’re still waiting for the complete adoption of IPv6. NAT and IPv4 will be with us for some time to come.

  For most use cases, NAT doesn’t present any particular problems. Without realizing it, everyone who uses the Internet today has their traffic constantly traversing multiple layers of NAT to access public Internet services. In this situation, a private host (a user’s device) is accessing a public host (e.g., a web server). Traffic can be exchanged by virtue of the public host having a publicly accessible endpoint that’s routable from the private host via an ISP.

  Where things get interesting is when one private host wants to connect to another private host—known as a peer-to-peer connection—where, for example, two participants wish to initiate a video call, each at home behind the NAT service on their home router. Several technologies have been developed to address the issue of NAT traversal—so-called because each peer must traverse the NAT layer in front of its peer—since the earlier days of the Internet. relies on security through obscurity. The approach taken here is to translate from some public IP address (your home internet router, for example) and a designated port that forwards traffic through to a private address and different port. This exposes only the necessary service(s) that you wish to make available and makes the destination routable to the public internet. Still, this approach leaves the target service and host open to public attack vectors and involves the configuration of router rules, which adds unnecessary complexity at any kind of scale.

• Port knocking: Also known as Secure Packet Authorization (SPA), this technique is akin to having a secret knock to enter a Prohibition-era speakeasy, hence the technique’s name. While the actual implementation is more complex, the goal is to deter casual port scanners by leaving open ports unresponsive unless a particular sequence and timing of packets arrive to open up the specific port. It’s an effective technique, but one that leaves your host and services wide open if the packet sequence is discovered.
• Data relay: Instead of developing techniques that involve opening up access to the target host from the public Internet, using a relay introduces an intermediate host publicly accessible from both the client and resource hosts. This has the advantage that the client and resource hosts can remain invisible to the public Internet. As long as a relay is available close to either host, minimal additional latency is introduced. The relay can be incorporated into the overall transport such that no connection termination occurs and streams can remain private. This approach is a standard backup method when NAT traversal techniques are unsuccessful.
• Proxies: With the introduction of proxies, we’ve now departed the realm of solutions-driven purely by the routing and transport layers of networks. Proxies work by terminating network connections, either manipulating or validating the packets and payloads they receive, and sending that data forward to either a destination resource or a corresponding reverse proxy, passing data to the destination resource.

Proxies are software-based and operate in the operating system’s user space. Proxies are easily deployed and introduce a significant level of sophistication into the type of routing and transport manipulation that’s possible while often remaining transparent to the application initiating a network connection. For these reasons, proxies are the dominant solution deployed today across many applications involving network traffic management.

There are two approaches taken to deploying proxies in practice. While their underlying functionality may be identical, they differ in the tradeoffs made in their deployment.

1. Public proxies: Public proxies are deployed with a publicly routable address, which means that they can sit in front of a destination resource, making it accessible from clients regardless of whether they have publicly accessible addresses or not. The tradeoff here is that with the convenience of accessibility comes the burden of ensuring that the public proxy is hardened and regularly patched to prevent attacks. This is particularly true because of the role the proxy plays: if identified as a proxy from the outside, it’s an entry point that is securing something in the private network behind it.
2. Private proxies: Private proxies serve the same role, but they are deployed behind firewalls on a private network. There are significant security benefits to this approach—no public address and all the benefits of using a proxy in the first place—but they don’t address the issue of making resources accessible to clients because they, too, are behind a firewall. This leads us to the topic of NAT traversal, which we’ll cover next.

Punching Holes Through (Fire)walls

Since we ended with private proxies in our overview above, it’s a safe bet that we think private proxies represent the best set of tradeoffs for implementing a distributed network topology. The two primary reasons for this are that private proxies are:

1. Invisible to the public internet: Because they sit behind a private network’s firewall, it’s impossible to discover them via public Internet port scanning or probe them for vulnerabilities. Even if a sophisticated attacker can infer the existence of a proxy behind a firewall based on visible traffic patterns, connection to a central service that is publicly accessible. The initial role of this service is to establish a signaling channel for the exchange of peer candidate addresses to each peer. In Twingate’s architecture, our existing authenticated relay infrastructure—already distributed globally—is used to establish a signaling channel.
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 on our 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.

Putting it all together

It’s not always possible to establish a direct peer-to-peer connection for various reasons, from blocked ports to incompatible NAT layers. In that case, 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, so they are always accessible from clients and deployed connectors, serving as a reliable backup transport method.

In summary:

• Private proxies provide the best set of tradeoffs between security and flexibility to specifically deploy into the private networks where access is needed.
• 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.

One more thing…

We mentioned above that proxies provide the opportunity to introduce a significant level of sophistication into network traffic management. We’ve taken advantage of that to introduce QUIC, a new transport layer network protocol, into our 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 , 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 -based protocol, it contains the best practices learned over the long history of the since our launch in 2020. If you’re interested in taking Twingate for a spin, we just launched a free tier where you can implement our secure access solution for your startup, home network, or personal projects. Of course, we also have business plans if you’re interested in moving off VPN for your company.

.

Vollständiges Original-Advisory
Ausführliche Details, Exploit-Analyse & Hersteller-Stellungnahme auf twingate.com.
↗ Original-Artikel auf twingate.com lesen