A few days ago we released a new version of Wiretrustee, v0.0.8. This version brings two major improvements and OS support for Windows:
- Wiretrustee can detect peers in the same internal network or with public IPs without restricted NAT, and it will connect directly without the need for a local go-proxy
- Kernel Wireguard detection. The native Wireguard (shipped with Linux as a kernel module) will be used if available
- Added windows service installation
The documentation was updated to guide you through the Windows support. As we are using https://www.wintun.net/ to manage the interface, the client needs to be executed as a service, so we decided to add the service command which includes the install, stop, start and uninstall subcommands.
The performance improvements include an option to detect if the Linux system supports a native Wireguard® interface, that will be used in place of the tap interfaces from the Wireguard-go package, providing a substantial performance improvement.
Another major improvement introduced in this version is the verification of peers in local networks, or public IPs without restricted NAT, doing that, we are able to skip using a local UDP proxy in front of the connections between peers, together with the use of native interfaces, this provides an increase of 5x compared with the proxy solution.
Infrastructure: Amazon cloud Virginia (us-east-1)
Hosts: 2 x t3.large
Operating system: Ubuntu 20.04 LTS
Network: Same AZ and VPC, to simulate local network or public IPs without restricted NATs.
Tools and commands:
Besides the installation of Wiretrustee, Wireguard-tools, Taiscale, and Zerotier. We used Iperf3 to measure transfer in bits per second, with the client issuing the command:
iperf3 -c SERVER_IP -p 8 -t 20
and the server:
First, we verified the plain performance from the hosts. AWS documentation shows that the network speed for the t3.large instances can reach up to 5gbps and this was the case for the plain communication:
Then we compared our beloved Wireguard® and it didn’t let us down, with a very small performance hit:
Now, in order to gather comparable data, its time to test our old version, with Wiretrustee v0.0.7:
As you can see in the previous version, this was not as close as it should be for local networks, so here comes the test with our new version, v0.0.8:
Wow!! 5x improvement compared to the previous version, still, at the time of release, we find out that our default MTU configuration is to blame for not reaching the performance level of plain Wireguard®. Currently, we set things to 1280 as it is a safe value to support most networks and IPV6, but looking at how wg-quick configures we notice that in AWS, we can evaluate things with a higher MTU, 8921 and this was the result:
This is not yet something we can configure automatically because we need to work on the proxy but watch out for new releases with better MTU support.
Now is time to review some alternatives and see how we are all doing in the same infrastructure:
Taiscale showed a similar performance hit as our proxied solution, but currently, it is performing better than it, still, using native interfaces in v0.0.8 we are almost 4x faster:
Zerotier performed better, almost hitting the 750mbps scale:
Wiretrustee proxied v0.0.7 and Wireguard-go
Wiretrustee v0.0.8 native and direct – 1280 MTU
Wiretrustee v0.0.8 native and direct – 8912 MTU
We acknowledge the need to improve our proxy speed and will work hard in the upcoming release to deliver a better experience. Also, that performance hit will only be most noticeable in places with Gigabit internet connections using cable connections or the latest Wireless standards.
If you are using local Wiretrustee in local networks or hosts with Public IPs, you will be able to take advantage of native Wireguard® interfaces and direct connections.
Hope you give Wiretrustee a try and send us feedback. Our project is on Github: https://github.com/wiretrustee/wiretrustee