Frequently Asked Questions

Lightway was built specifically for privacy and security at the scale of a VPN provider like ours. WireGuard is a great VPN protocol and there are many things that we like about it, but it was designed for a very different use case from Lightway. For example, the assumption with WireGuard is that you can trust the people you’re talking to, so you don’t need to hide your IP from someone who’s trusted. Our needs differ in fundamental ways from WireGuard, and that is reflected in Lightway’s core design.

Lightway was designed to have all the key benefits of WireGuard (e.g. speed, less power consumption, fewer lines of code) but go further on other important fronts (e.g. privacy, obfuscation, TCP support). Lightway does not need any additional layers—it provides these features and benefits out of the box for everyone.

Ultimately, we also believe in investing in innovation and think that it’s good to have more options when it comes to picking software.

There are a number of reasons why someone might choose Lightway over WireGuard, but it really comes down to what they want out of their VPN.

If you’re looking to run a privacy-focused and high performance consumer VPN platform, then Lightway might be very attractive as it was designed specifically for this. In native WireGuard, each user’s key is mapped to a specific internal IP or range of IPs. This makes it easy to identify a particular user’s traffic over time. If you want to work around this, you’ll need to write some sort of layer to side step this limitation. On the other hand, Lightway allocates a different IP to each user as they connect, so that there’s nothing in common across connections.

Another key reason is that Lightway supports both TCP and UDP. WireGuard doesn’t support TCP, and will not be able to without significant changes. TCP is perfect for networks like airport Wi-Fis or corporate networks. Some network providers even block UDP entirely, so having the option to use both TCP and UDP is useful for many VPN users.

WireGuard also made it clear that it doesn’t intend to focus on obfuscation. This means that it’s easy to detect and block WireGuard. Lightway supports a plugin infrastructure that makes adding obfuscation trivial.

Lightway Core has around 2000 lines of code. One software engineer from wolfSSL who helped look at the code said he was able to review it in <1 hr. This means that Lightway is easier to audit and maintain.

We chose to write Lightway Core in C for a number of reasons.

First and foremost, Lightway was intended to be fast, as well as light on resources. This was something we could control on every platform with C, but at the time it was not clear if Rust would be able to give us highly optimised code across a range of architectures.

Another issue at the time was ABI stability. We wanted to create a core that could be used on every platform. To do that, we needed to link to it from a number of different languages—and at the time this was not Rust’s strength.

Finally, we have significant C experience in the team and we often work in environments where C is either necessary (for example kernel drivers) or where C is the only mature option (certain embedded hardware).

All that being said, we agree Rust is an impressive language. Its approach to memory management is really exciting, and it will be kept in consideration for future projects.

Lightway has been reviewed by wolfSSL and Cure53. The full audit report by Cure53 can be found here: https://cure53.de/pentest-report_lightway.pdf.

In addition, the Lightway protocol at its core is TLS 1.3 and D/TLS 1.2, and both of these are IETF open standards that have received substantial independent review. We use wolfSSL for this and their implementation has a FIPS rating such that it’s approved for government use. While Lightway is relatively new, it’s using tried and true technology that has been battle tested in the field.

Lightway Core is also now open-sourced, so anyone can review it.

Being in the Linux kernel is just one piece of the puzzle that impacts the overall performance for VPN platforms like ours. It also isn’t really a big selling point for us because it’s trivial to install and run Lightway. The target audience are VPN platforms and those generally have significant customization.

When we designed Lightway we made the conscious decision very early on that we would not implement it in the kernel. Although there are good reasons for working in the kernel, generally speaking it is much easier and simpler to work in user space. For example, we want Lightway to work on all of our supported platforms and share as much code as possible. By working in user space, we can share a core library between our platforms, something which would not be possible if we were implementing kernel versions. We also wanted to leverage the wolfSSL cryptographic library which is a user space library (although it does now offer some kernel options) and our many years of systems development. In short, whilst we can put Lightway in the kernel, user space is the right place for now.

On the flipside, a key advantage to keeping things out of the kernel is the speed at which we can develop and innovate. One area in particular is that of privacy techniques that are designed to address Deep Packet Inspection (DPI) in certain firewall products. DPI is ever evolving and as such the ability to respond to new developments is vital. This is much easier to do in user space, particularly because Lightway was designed specifically to be extensible and to allow adaptations and plugins. Whilst this could be made to work inside a kernel too, it would be significantly more complex and would likely greatly increase the time required to address a problem.

In terms of performance, we have benchmarked against OpenVPN over the last year. Throughout our beta tests, we found that Lightway: Connects 2.5x faster: More than half of the time, Lightway connects the VPN in less than 1 second Improves reliability by 40%: This means that users experience fewer drop-offs and having to reconnect, especially on mobile Increases speed by 2x: Lightway makes VPN speeds even faster

The above data is derived from ExpressVPN users who opted in to share anonymized diagnostics information with us.

We hope to do more tests and share more data comparing Lightway to WireGuard, OpenVPN and other protocols in the future.

Ultimately though, the performance of a VPN service doesn’t just boil down to the protocol—many other aspects, such as server infrastructure, network bandwidth, and server locations are also critical.

The reason we have a CLA is to be upfront and transparent about what happens when someone contributes code to the project. It is important to note that the author maintains ownership of the code at all times and that we will immediately release any contributions under the GPL 2.0 license. This helps to protect the project by ensuring that any code in the repository can be released under the GPL 2.0 license both now and in the future. This is why the Apache Foundation requires a CLA for all contributions—the intent is to protect everyone’s interests.

As part of any code contribution, we will list the author’s name and what was contributed so that the author will get full recognition for their work.

WireGuard is a registered trademark of Jason A. Donenfeld.