How Level Works: Secure, Peer-to-Peer Remote Access Explained

The way IT teams provide support has undergone a massive shift over the past decade. Computers of the past had too little processing power or had too weak of an internet connection to consistently support streaming media and real-time data. Today, real time screen sharing and audio are common and critical to troubleshooting issues. IT teams need accurate, up-to-date data on devices via a secure channel with low latency, but they also need the ability to support streaming audio/video data when connecting directly.

However, older Remote Monitoring & Management (RMM) software was developed during the time when establishing and managing connections between devices was not so easy. As a result, older solutions ask a lot of the buyer and require too much trust of the RMM vendor to establish a middleman. The middleman server acts as an access hub between devices, coordinating connections. But it also means the RMM vendor controls the point through which all your company's data flows.

We built Level as a modern, peer-to-peer solution. You don't have to trust a middleman in order to connect to your devices. We've written at length about the advantages of peer-to-peer. In this post, we'll get into the weeds of how Level works, so you can feel secure knowing that your data truly never touches our servers.

How Level Connects to Devices

In the past, if you wanted to connect two devices, you needed a middleman server that established and maintained connections to each device. Today, modern technologies allow us to connect two devices directly, no middleman needed. That brings all kinds of benefits in latency, security, privacy, and accuracy of data.

In order for two devices to connect without a middleman, they need a shared protocol for discovering each other and establishing trust. In our case, we use the Interactive Connectivity Establishment (ICE) protocol. In turn, ICE uses Session Traversal Utilities for NAT (STUN) and/or Traversal Using Relays around NAT (TURN) in order to establish the connection.

These protocols are well established and open source for review if you really want to get into the nitty gritty. Here, we'll just present a basic outline of the connection process.

What is NAT?

Before we explain the connection process, it's important to understand the problem space and why connecting two devices can be so difficult. Many of our issues with direct connections come from NAT.

When the internet was first invented decades ago, the creators made public IP addresses available for up to 4 billion devices. Today, however, there are far more than 4 billion devices in the world when you count every computer, server, tablet, and mobile phone. So, address translation became an important technology to stretch 4 billion IP addresses to cover far more devices. Network address translation (NAT) is the protocol mapping IP addresses to a private address space.

NAT's IP mapping is fairly simple to understand. In most cases, NAT is present on gateways into private or corporate networks (basically wherever the internet meets your home/office). The gateway itself has a single public IP address which can receive requests. The gateway then uses NAT to route requests to individual devices within its private network.

We could write a whole article about NAT and its implications, but the upshot is that your home or office router is changing the IP address of requests and responses. When it sends a request for you, the request has the router's public IP address, not your computer's IP address. In order to connect to your computer for remote access, we need to know what changes are being made in your network's NAT.

Connecting via STUN

So how do we connect to your device for remote access? Following the ICE protocol, our preferred means of connection is via Session Traversal Utilities for NAT. STUN allows us to connect two devices directly with only a few pings. Specifically, STUN helps us determine if a device is behind a NAT gateway, if UDP packets are allowed to be sent, whether a firewall exists on the network, and if so what type of firewall.

STUN follows a few simple steps. First, send a ping to a third-party server on the internet. Request that it echo back the message, along with the IP address the public server sees the message from. If the IP address returned is the same as the client's address, we're not behind a NAT. If the IP address is different, then we know the address has been translated through a NAT.

Next, we send a second ping to a different address at a different port. Once we receive the second response, we can determine, based on the IP addresses returned, whether we're behind a NAT and what type of firewall we might be behind as well.

Once we have NAT information about both devices, we use a technique known as UDP hole punching to send a series of pings between the devices to the public IP addresses we found. That way, the two devices have a direct connection, with no middleman.

Connecting via TURN

The process of connecting devices is more complicated if one of those devices is behind a certain type of NAT known as a "symmetrical NAT" or if there are other complications in establishing a connection.

While we always prefer STUN for its simplicity, in some cases, STUN cannot connect two devices. So, we need a relay device on the open internet to act as a go-between for the connection. Since both devices can connect to the open internet (even if they can't connect directly), each device connects to the relay server and we route encrypted packets through that relay.

It's important to note that TURN relays operate independently. Their only job is to forward encrypted packets of information, with no processing or storage of that information, nor any way to decrypt the information at all.

STUN is a much more efficient protocol because TURN requires running a server with significant bandwidth. Using Interactive Connectivity Establishment (ICE) helps us determine when STUN connections are possible so we avoid opening TURN relays unless we have to.

Peer-to-Peer Remote Access

Connecting via STUN or TURN, we can now send UDP packets of media data between devices. The connection is direct in the case of STUN or an encrypted relay in the case of TURN. Either way, your data never touches our servers, and you enjoy all the benefits of peer-to-peer connections.

From there, we use the open-source WebRTC JavaScript API to parse those UDP packets and render the video and audio in your internet browser. From initialization to connection, this all takes a matter of milliseconds to accomplish, allowing you to connect to devices and get real-time data with low latency.

These peer-to-peer connections are at the heart of what we're trying to build at Level, and they enable a whole host of features and tools to make remote monitoring and management even easier.

‍