If Express VPN's Lightway protocol is open-source, can it be ported to FreeBSD?

O

Oleg_NYC

According to what I found out, Express VPN's Lightway protocol is open-source: https://github.com/expressvpn/lightway-core . Does it mean it can be added to FreeBSD's ports collection after necessary changes to Lightway's source code are made? It would be nice to have the ability not to rely on the openvpn client for connections to Express VPN because only Lightway users are allowed to connect to TCP/port 443.
 
They allow you to connect via OpenVPN, but then restrict that you can visit https websites? Sounds very shady to me.

A quick look reveals that they use a custom build system "ceedling", which doesn't seem to have a FreeBSD port. That alone will make it a pain.

The code itself is probably not that bad since it already has a macOS port.
 
Doesn't look like a lot of code, so just creating a small Makefile could solve this as well ...

BUT: This is nothing but a library implementing their protocol. They don't opensource their actual client (supposedly using that library), so you'd have to write your own, basically, maybe the "reference" project helps:
github.com

GitHub - expressvpn/lightway-laser: Lightway Laser is a reference point-to-point Linux client/server implementation for Lightway Core.

Lightway Laser is a reference point-to-point Linux client/server implementation for Lightway Core. - expressvpn/lightway-laser
github.com github.com
 
I am saying that connections to Express VPN itself can only be done via UDP for OpenVPN clients because this is Express VPN's policy. If there are no firewall restrictions on the client side, then a user can use OpenVPN to connect to Express VPN via UDP and browse https sites just fine. But if there are firewall restrictions, TCP/port 443 is still usually allowed for connection purposes, but only Lightway users are allowed to connect to port 443 via TCP.
 
Well, just using TCP/443 won't help you in these typical restrictive environments any more either, most of them moved to terminating TLS (issuing fake certificates towards your browser) and doing some DPI crap...

If it wasn't for that nonsense, nobody would ever think about putting a VPN on top of TCP, that's crazy overhead ;)

You might ask them for FreeBSD support. I wouldn't have too much hope, but at least they already support Linux and MacOS, so it shouldn't be TOO much work for them...
 
I often wonder about all these new VPN things popping up. OpenVPN has been around long enough for the code to be vetted a fair amount, there may be performance issues (I think at one point openvpn was a bit single threaded. that may be old information, so grain of pink himalaya salt), there is WireGuard, so both relatively "standard" interfaces.
To me a lot boils down to trust: do I trust this new thing more than old standards? Same thing with things like PGP, GPG, encryption algorithms...
 
mer, I'd also generally trust ssh(1), so, let's tunnel ppp(8) through it. :cool: Ok, will perform even (a lot!) worse than OpenVPN. :D

And sure, I also tend to prefer proven solutions. Been happy with OpenVPN for a very long time now. Meanwhile, I feel I should really give wireguard a try some day, though...
 
  • Like
Reactions: mer
zirias@ said:
Well, just using TCP/443 won't help you in these typical restrictive environments any more either, most of them moved to terminating TLS (issuing fake certificates towards your browser) and doing some DPI crap...

If it wasn't for that nonsense, nobody would ever think about putting a VPN on top of TCP, that's crazy overhead
Click to expand...

At my current location, firewall rules are quite restrictive, but they still permit connections to tcp/443... I can connect to Express VPN just fine there (on a Linux computer). And according to this article, the TCP thing is a big plus: https://lightway.com/docs/lightway-core/1.0.0/faq .
 
Oleg_NYC said:
And according to this article, the TCP thing is a big plus:
Click to expand...
Well, read carefully, their argument why "TCP support is great" is exactly networks blocking e.g. UDP. Sure, that might help you in some stupidly configured semi-public networks. It's unlikely to help in corporate networks and similar, because, as I said, the trend is TLS termination and DPI.

What they just don't mention is the performance penalty. TCP does complex things to ensure reliability and congestion control. That's pointless for putting another layer of (unreliable) IP on top, and it really hurts when the next layer of TCP (inside the VPN) gets added (where e.g. congestion control can't be aware of the congestion control already happening on the "virtual physical" layer). From the (network) technical perspective, a VPN on TCP is a bad idea.
 
You must log in or register to reply here.
Back
Top