Evaluating Twingate Performance
Performance testing Twingate against VPN technologies.
Twingate Connection Performance
To minimize the impact on connection performance, Twingate supports peer-to-peer connections between the Clients installed on users’ devices and the Resources that they are trying to connect to. Testing the performance of your connection to remote Resources through Twingate is straightforward.
Performance Results
As Twingate has been designed from the ground up to be very lightweight and performant, the Client and Remote Network Connectors have minimal impact on performance, typically resulting in a decrease of 5% to 15% in available throughput when using a peer-to-peer connection. The actual impact depends on factors like traffic type, traffic volume, and the number of users connected through a single Connector.
Naturally, context matters. In the case of the tests performed below, a VPS (virtual private server) is used to host the Twingate Connector as well as to act as remote Resources, such as a file share, and to route access to third party sites such as Speedtest.net. The configuration of the VPS is designed to specifically showcase how well the Twingate Connector operates when compared to other available services (such as WireGuard and OpenVPN) when operating on the same hardware.
In these tests, the VPS used is set up with 1 vCPU and 2GB of RAM, and has an S3 compatible “high speed” NVMe-based storage device added, in order to remove the potential of an I/O bottleneck on the server. Both the VPS and the client system used for testing have 1Gbps network connections.
Baseline testing is done by opening ports on the VPS and allowing the client system to connect directly to the service, or in the case of Speedtest.net having the client system run a test directly without routing through the VPS at all. After baseline testing is complete, each of the three remote access services are tested in order, with the VPS being rolled back each time to a clean image taken before any additional packages are installed.
Here are some basic tests comparing Twingate’s performance to self-hosted WireGuard and OpenVPN tunnels:
| Baseline | Twingate | WireGuard | OpenVPN (UDP) | |
|---|---|---|---|---|
| Speedtest.net (Multi-connection) | 943.53Mbps | 906Mbps (-4%) | 148Mbps (-84%) | 120Mbps (-87%) |
| 1.8GB File Transfer (Samba Share) | 600Mbps | 600Mbps (+/- 0%) | 224Mbps (-63%) | 208Mbps (-66%) |
| LAN Speed Test (1GB Dataset) | 459.04Mbps | 455Mbps (-1%) | 166Mbps (-64%) | 133Mbps (-71%) |
In all three tests, Twingate is within at most 5% of the baseline test. In the case of the file transfer, no throughput degradation occurred at all as the constraint was the storage I/O, meaning the user would not have noticed any difference in performance by connecting via Twingate.
When comparing the self-hosted versions of OpenVPN and WireGuard to Twingate’s performance using the same VPS, there are significant drops in throughput caused by additional overhead and differences in how the technologies work. Throughput reduction declined by 63% to 87% among the various test cases.
Twingate’s performance on a single vCPU with 2GB of RAM was almost identical to the baseline tests. In contrast, WireGuard and OpenVPN would have required additional server resources to support higher levels of throughput. In the case of OpenVPN, the recommendation for a full gigabit connection is “…you need approximately 12MHz for each megabit per second (Mbps) transferred in one direction…a modern 4-core system at 3GHz would count as 12,000MHz, which equates to approximately 1,000Mbps maximum throughput.”
In addition, Twingate’s split-tunnel design means that only traffic destined for defined Resources passes through the tunnel. All other traffic, such as video conferences, would continue to use the user’s regular Internet connection, preventing any sort of performance impact.
There are some situations where the connection, due to technical conditions, needs to fall back to using Twingate Relays. In such cases, you should see between 200Mbps to 250Mbps consistently. You can determine whether the connection is a direct peer-to-peer connection or being routed via a Relay by looking at the activity logs in the Admin Console.
Running Your Own Performance Testing
Please be aware that public release of performance testing and benchmarking results requires Twingate’s prior approval.
The best method of testing the performance of your own Twingate instance is to use an online speed test, such as Fast.com or Speedtest.net. You can have a user run a test in their web browser with the Twingate Client disconnected to get a baseline of what their performance should be. Then, you can have the user run the test again with the Twingate Client connected and routing test traffic through to the test destination.
For the following example, we’ll use Speedtest.net, which has a large number of test servers located around the world. For this test to work, you will need to add to Twingate a Remote Network that’s separate from the local network that the user is connected to. This could be a cloud environment or a data center/on-premises setup that is physically separated from the network the user is connecting to. This is important as we want to test the “best case” scenario of the Twingate Client connecting through your Remote Network using a peer-to-peer connection, as well as to make it easier to identify if the local network is the source of any throughput issues.
Ensure the Remote Network that you choose to assign the new test Resource to has an internet connection that is fast enough to perform this testing, so it does not cause a bottleneck that impacts results. We recommend you use a connection of at least 1Gbps for testing.
Here’s how this test would be done:
- Log in to your Twingate Admin Console, click the Resources tab, and click “Add Resource”
- In the Add Resource window that appears, choose your Remote Network at the top and type in a descriptive label such as “Speedtest.net Test”. Next, in the DNS Address box, type
*speedtest*, including the asterisks. This is a wildcard address that will cause the Twingate Client to capture any traffic attempting to reach a domain with “speedtest” anywhere within it, which is key to this test working properly
- Click “Add Resource” at the bottom of this window, and in the next window choose which Group to add the Resource to. If you’re concerned about causing issues for the rest of your users, you could create a new Group to add this Resource to and then add the one test user to the same Group, isolating this test Resource from the rest of your organization
That’s it! The Resource is set up and ready to test. The next step would be to have the user run their baseline test first, without being logged into the Twingate Client. The goal is to see what the typical download speed for their internet connection is. (If it’s relatively low, that may be a cause of any connectivity issues they may be encountering.) Many users will have a relatively slow upload speed, so the focus of this test is primarily on download speed.
Here’s an example baseline test:
We now have our baseline and we know that our download speed is close to 950Mbps. Next let’s log in to Twingate and run the test again.
First, observe the partially visible IP address in the lower left-hand corner of the result, showing that the two tests were done from different locations. This is important to confirm for the test as it should show that the egress point for this test is the Remote Network that the user has been given access to through Twingate, and that the entirety of the test is being performed through this network.
Next, the results of the test are slightly lower, but the download speed is within 4% of the baseline test. If you run the tests multiple times, the results will vary slightly and there will be a small amount of overhead due to the connection being routed through a Remote Network and the additional handling performed by the Twingate Client and Connector. This test shows that the connection through Twingate was successful, the connection to the Resource was via a peer-to-peer connection, and there were no issues with the setup.
If the result was significantly lower, then you would want to go through the troubleshooting steps below, looking at both the user’s system and network, as well as your Remote Network.
Other Tests
There are other types of tests that can be performed that may help to diagnose issues, or that can ascertain what kind of throughput your Resources can handle.
In order to do baseline tests with these methods, you will likely need to open ports in your firewall to allow the specific type of traffic out of your Remote Network. Opening ports should always be done with great caution.
File Transfers
Transferring one or more larger files over several minutes is an easy way to test total throughput of a connection. Setting up a file share on a Windows server or Samba on a Linux server is quick and easy. Once it’s added as a remote Resource that a user can connect to, the testing process above can be followed.
When transferring the files themselves, use a tool like Teracopy or Robocopy (on Windows) or rsync (using the --v --stats --progress flags on macOS) so that you’re able to monitor the progress and throughout as it’s happening.
One thing to keep in mind with using file transfers for testing is that the bottleneck is almost always going to be the physical limitations of the file server’s storage system. Traditional hard disk drive-based systems, even in RAID arrays, will perform far slower than NVMe-based high speed storage blocks and you will likely not be able to saturate a fast internet connection.
LAN Speed Test
LAN Speed Test (https://totusoft.com/lanspeed) is a simple tool for measuring file transfer speeds across local or remote devices, such as network shares. It has a number of customizable options for testing which makes it a useful tool, it is an older tool and hasn’t had updates in several years, so it tends to not be as accurate as pure file transfers or using another test method. To get a more accurate result using LAN Speed Test, a sample test file size of 1GB or higher is recommended.
Last updated 9 months ago