I definitely noticed the performance boost on my Pixel 8, for some reason it seems to really not like wireguard-go, it struggled to pull even 100mbps, maybe something unoptimized on Google's custom hardware. With the new GotaTun version I can pull 500mbps+, though unfortunately it also seems to have introduced a bug that randomly prevents the phone from entering a deep sleep state, so occasionally my battery will randomly start draining at 10x normal speed if I have it enabled until I reboot.
It's very likely that VPNs like this are not CPU-bound, even on somewhat whimpy CPUs. I'd wager even some microcontrollers could sling 500megabits/sec around without trouble.
Oh, this is the reason the Mullvad app on my Pixel 6a was suddenly able to connect in less than a second where before it would take 5-10 seconds, nice!
Nice, I love WireGuard. I ended up building WrapGuard [1] to run applications without root access to the host and choose Go to write it in. I don't really know Rust, but does it make more sense for firmware/networking type software? Is there even a difference?
Very cool. I may use this, but also curious what the best choice would be if you don't need encryption. I'm specifically wanting to enable some local container networking using apple's new container tool [1]. I know I could just use Docker...
Correct me if I’m wrong, but if you use LD_PRELOAD, presumably it will not work for applications that circumvent libc, such as Go binaries (at least those with CGo disabled)?
Can you use user namespaces to create a network namespace with the VPN active and stick applications in that namespace?
From a quick search, https://blog.thea.codes/nordvpn-wireguard-namespaces/ sees to have at least the bones of a decent solution, though I've not had a chance to dig very far. A lot of results use root to set up the namespace, but I was pretty sure that shouldn't be needed with a new kernel and user namespaces enabled
I have no idea. I’ve never messed with it, but maybe something like eBPF to intercept network syscalls? Not sure if that’s a thing—especially without root access? Mostly I was just thinking the project page could use a disclaimer since, in Go, it is common to bypass libc. :shrug:
This seems like a very cool, useful project though!
I believe you are making use of gVisor’s userspace TCP implementation. I’m not sure if there is something similar in Rust that would be so easy to set up like this.
If anyone working on the implementation is here, was it not possible to upstream your changes to BoringTun? The blog mentions some changes but doesn't go into detail on that aspect.
BoringTun is unmaintained. There are various forks being developed.
I work at Obscura VPN and faced with boringtun bugs a few years ago we evaluated a few of the forks and switched our client to be based on top of NepTUN (https://github.com/NordSecurity/NepTUN).
I am curious why Mullvad started their own fork rather than building on top of one of the existing ones. It would be nice if there could be reconsolidation somewhere.
I'm guessing because BoringTun has been in a state of "currently undergoing a restructuring" for something like 3 years by now, I'm guessing Mullvad wasn't too keen to maybe/maybe not be able to contribute, and much more prefer being in 100% control of their own implementation.
As someone who wants to see Wireguard succeed and in even wider use, this move makes sense from that perspective too. The more implementations we have available, the more we can trust that the protocol is secure and stable enough. Personally I also have about 100x more trust in Mullvad than Cloudflare both in terms of security but more importantly privacy, but that's just the cherry on top.
That's more of a job for an encapsulating protocol. (shadowsocks or similar) Wireguard isn't designed to be obfuscating alone. It's just a simple l3 udp tunnel with a minimal attack surface.
That's the traditional answer parroted in the Wireguard documentation but a few hours' serious thought and design is enough to reveal the fatal flaw: any encapsulating protocol will have to reinvent and duplicatively implement all of the routing logic. Perr-based routing is at least 50% of wireguard's value proposition. Having to reimplement it at the higher level defeats the purpose. No, obfuscation _has_ to be part of the same protocol as routing.
(Btw, same sort of thing occurs with zfs combining raid and filesystem to close the parity raid write hole. Often strictly layered systems with separation of concerns are less than the sum of their parts.)
The mullvad apps do offer obfuscation options (shadowsocks, etc) but i agree it would be nice if something was baked into wireguard itself. I recently went through setting up shadowsocks over wg for my homelab and it was a good bit of effort
amnezia-wg is quite cool and they have built the kmod too, I did some test so far they can works even in my location which block wireguard server quickly.
WireGuard is a protocol that, like all protocols, makes necessary trade-offs. This page summarizes known limitations due to these trade-offs.
Deep Packet Inspection
WireGuard does not focus on obfuscation. Obfuscation, rather, should happen at a layer above WireGuard, with WireGuard focused on providing solid crypto with a simple implementation. It is quite possible to plug in various forms of obfuscation, however.
I would not have guessed that iOS allows enough access to APIs to implement anything vpp-based. Very cool to see. I also enjoyed working with vpp (for the brief 6 months that I had with it).
I was thinking that's hard, but I noticed that vpp get ported to FreeBSD using epoll shim library, and I learnt apple Darwin use some some userland of FreeBSD to do POSIX compatibility, then after some tests and hacking, most related to minor POSIX API adaptation such as mmap and one major coroutine need add some assembly code, and it work! But I think most disappointed to me is that apple do lack some vectorized network IO unless do some kernel extension or other sort non standard ways.
Its funny, this is another of the billions of reasons why Mullvad should be the VPN of choice. But so many fucking people can't ever get over that their favorite social media influencer/Youtuber is offering a code for 200% off of NordShark VPN, now with extra AI.
Mullvad is great for privacy. But it's blocked by pretty much every VPN block list. NordVPN at the very least bypasses all the ones I regularly encounter.
I do use Mullvad for most web browsing though. But Imgur for example is blocked on it, and it's blocked in the UK, so I need NordVPN if I want to see any images there.
Most people's VPN usage is literally just geolocation restrictions and Nord is really good at that.
I love and use mullvad myself but I don't think they are very competitive for the average person. They mostly just care about getting around geo blocks on websites and streaming services, which mullvad puts 0 effort into facilitating.
Mullvad seems to care and be competent about privacy, but most average VPN users aren’t seeking the most extreme privacy. They just want something cheap that lets them do geolocation things or access the most websites.
The average VPN user is knowledge-less. At best their internet usage data is being sold to third party analytics companies. At worst third parties are routing their own bots through their local connection.
The increased attack surface mostly only affects that one particular implementation though. So, yes, twice as many implementations that may contain exploitable bugs, but each new implementation could only be used to exploit a fraction of the total user base
Competitions helps in multiple ways. It improve tooling, test suites, CVE response time, documentation and evolution of the protocol. There are some counter examples where compatibility suck, like DLNA but the problem often come from the spec.
I think the general consensus is that it improves security of the protocol, but obviously that won't matter much if the implementation gets something wrong or has worse security by itself.
Issues in the protocol itself would need all implementations to change, but issues in the implementation would obviously be isolated to one implementation. For something like Wireguard, I'd wager a guess that issues in the implementations are more common than issues in the protocol, at least at this stage.
That's really good because it means it will be able to have more exposure, more exposure means more improvement, more improvement eventually dig out bad bugs and reduces the attack surface in the long run
dont fix if it ain't broken. look at sudo-rs and other rust ports.
ofc, thats a cynical view.
i personally think its a bad idea to duplicate efforts. better combine them. otherwise u risk making mistakes that were already solved. missing lessons already learnt.
I definitely noticed the performance boost on my Pixel 8, for some reason it seems to really not like wireguard-go, it struggled to pull even 100mbps, maybe something unoptimized on Google's custom hardware. With the new GotaTun version I can pull 500mbps+, though unfortunately it also seems to have introduced a bug that randomly prevents the phone from entering a deep sleep state, so occasionally my battery will randomly start draining at 10x normal speed if I have it enabled until I reboot.
MTU strikes again. 1320.
Same behavior on raspberry pi 5. Might be just lack of arm optimizations.
It's very likely that VPNs like this are not CPU-bound, even on somewhat whimpy CPUs. I'd wager even some microcontrollers could sling 500megabits/sec around without trouble.
Oh, this is the reason the Mullvad app on my Pixel 6a was suddenly able to connect in less than a second where before it would take 5-10 seconds, nice!
Nice, I love WireGuard. I ended up building WrapGuard [1] to run applications without root access to the host and choose Go to write it in. I don't really know Rust, but does it make more sense for firmware/networking type software? Is there even a difference?
1. https://github.com/puzed/wrapguard
Very cool. I may use this, but also curious what the best choice would be if you don't need encryption. I'm specifically wanting to enable some local container networking using apple's new container tool [1]. I know I could just use Docker...
[1] https://github.com/apple/container/issues/670
Pick the devil you know, as they say.
Very cool project. Is it always an LD_PRELOAD or can it function as a standalone SOCKS proxy similar to wireproxy?
Thanks chjj. Yeah it's always LD_PRELOAD. There is wireproxy [1] though that might do what you want?
1. https://github.com/whyvl/wireproxy
Correct me if I’m wrong, but if you use LD_PRELOAD, presumably it will not work for applications that circumvent libc, such as Go binaries (at least those with CGo disabled)?
Yeah you are right. Can you think of any way we could capture that traffic too?
Can you use user namespaces to create a network namespace with the VPN active and stick applications in that namespace?
From a quick search, https://blog.thea.codes/nordvpn-wireguard-namespaces/ sees to have at least the bones of a decent solution, though I've not had a chance to dig very far. A lot of results use root to set up the namespace, but I was pretty sure that shouldn't be needed with a new kernel and user namespaces enabled
I have no idea. I’ve never messed with it, but maybe something like eBPF to intercept network syscalls? Not sure if that’s a thing—especially without root access? Mostly I was just thinking the project page could use a disclaimer since, in Go, it is common to bypass libc. :shrug:
This seems like a very cool, useful project though!
from TFA, the main advantage would be for embedded (as a library) use case, FFI with Go is harder.
I believe you are making use of gVisor’s userspace TCP implementation. I’m not sure if there is something similar in Rust that would be so easy to set up like this.
There isn't something as mature as gVisor afaik. https://github.com/smoltcp-rs/smoltcp implements many of the same abstractions as gVisor.
If anyone working on the implementation is here, was it not possible to upstream your changes to BoringTun? The blog mentions some changes but doesn't go into detail on that aspect.
BoringTun is unmaintained. There are various forks being developed.
I work at Obscura VPN and faced with boringtun bugs a few years ago we evaluated a few of the forks and switched our client to be based on top of NepTUN (https://github.com/NordSecurity/NepTUN).
I am curious why Mullvad started their own fork rather than building on top of one of the existing ones. It would be nice if there could be reconsolidation somewhere.
I'm guessing because BoringTun has been in a state of "currently undergoing a restructuring" for something like 3 years by now, I'm guessing Mullvad wasn't too keen to maybe/maybe not be able to contribute, and much more prefer being in 100% control of their own implementation.
As someone who wants to see Wireguard succeed and in even wider use, this move makes sense from that perspective too. The more implementations we have available, the more we can trust that the protocol is secure and stable enough. Personally I also have about 100x more trust in Mullvad than Cloudflare both in terms of security but more importantly privacy, but that's just the cherry on top.
I wish they would improve wireguard-the-protocol as well: wireguard doesn't stand a chance against gov/isp blocks.
That's more of a job for an encapsulating protocol. (shadowsocks or similar) Wireguard isn't designed to be obfuscating alone. It's just a simple l3 udp tunnel with a minimal attack surface.
That's the traditional answer parroted in the Wireguard documentation but a few hours' serious thought and design is enough to reveal the fatal flaw: any encapsulating protocol will have to reinvent and duplicatively implement all of the routing logic. Perr-based routing is at least 50% of wireguard's value proposition. Having to reimplement it at the higher level defeats the purpose. No, obfuscation _has_ to be part of the same protocol as routing.
(Btw, same sort of thing occurs with zfs combining raid and filesystem to close the parity raid write hole. Often strictly layered systems with separation of concerns are less than the sum of their parts.)
> It's just a simple l3 udp tunnel
Wait, isn’t UDP L4? Am I missing something?
Wireguard is a L3 VPN that uses UDP (L4) for tunneling. Thats probably what was meant.
Yes, but it tunnels arbitrary IP packets encapsulated in UDP.
The mullvad apps do offer obfuscation options (shadowsocks, etc) but i agree it would be nice if something was baked into wireguard itself. I recently went through setting up shadowsocks over wg for my homelab and it was a good bit of effort
There are forks of wg because of this. Like amnezia-wg
This is a neat project!
https://docs.amnezia.org/documentation/amnezia-wg/
amnezia-wg is quite cool and they have built the kmod too, I did some test so far they can works even in my location which block wireguard server quickly.
Known Limitations
WireGuard is a protocol that, like all protocols, makes necessary trade-offs. This page summarizes known limitations due to these trade-offs.
Deep Packet Inspection
WireGuard does not focus on obfuscation. Obfuscation, rather, should happen at a layer above WireGuard, with WireGuard focused on providing solid crypto with a simple implementation. It is quite possible to plug in various forms of obfuscation, however.
tl;dr Read the docs.
Mullvad does exactly this.
Anywhere I can read more about this?
Is there any way to switch to this implementation for generic WireGuard users?
I tried downloading their Android app, but it's not generally usable for people who host our own WireGuard, which is fair enough.
The github repo is linked in the post which has build instructions: https://github.com/mullvad/gotatun
For the similar reason I do not using any go based proxy code in my MintFlow app, and use rust to implement some proxy protocols.
But my app’s wireguard is natively implemented by fdio vpp plugin, so it’s based on C.
I would not have guessed that iOS allows enough access to APIs to implement anything vpp-based. Very cool to see. I also enjoyed working with vpp (for the brief 6 months that I had with it).
I was thinking that's hard, but I noticed that vpp get ported to FreeBSD using epoll shim library, and I learnt apple Darwin use some some userland of FreeBSD to do POSIX compatibility, then after some tests and hacking, most related to minor POSIX API adaptation such as mmap and one major coroutine need add some assembly code, and it work! But I think most disappointed to me is that apple do lack some vectorized network IO unless do some kernel extension or other sort non standard ways.
Its funny, this is another of the billions of reasons why Mullvad should be the VPN of choice. But so many fucking people can't ever get over that their favorite social media influencer/Youtuber is offering a code for 200% off of NordShark VPN, now with extra AI.
Mullvad is great for privacy. But it's blocked by pretty much every VPN block list. NordVPN at the very least bypasses all the ones I regularly encounter.
I do use Mullvad for most web browsing though. But Imgur for example is blocked on it, and it's blocked in the UK, so I need NordVPN if I want to see any images there.
Most people's VPN usage is literally just geolocation restrictions and Nord is really good at that.
Aren't proxies good enough for that purpose?
I love and use mullvad myself but I don't think they are very competitive for the average person. They mostly just care about getting around geo blocks on websites and streaming services, which mullvad puts 0 effort into facilitating.
It became less of a choice for many after they sadly had to disable port forwarding.
Yeah, their reasoning is solid (easy to abuse) but it is still a very useful feature.
AFAIK, at the moment your choices are AirVPN and ProtonVPN. AirVPN has static port forwarding and Proton has UPNP port forwarding.
private internet access has port forwarding too
Mullvad seems to care and be competent about privacy, but most average VPN users aren’t seeking the most extreme privacy. They just want something cheap that lets them do geolocation things or access the most websites.
The average VPN user is knowledge-less. At best their internet usage data is being sold to third party analytics companies. At worst third parties are routing their own bots through their local connection.
I wish I could use Mullvad. But their IPs are banned from many streaming services and they don't change them often enough so I am stuck with Nord.
Not to mention holding companies which snap up 15 competing VPNs and whitelabel most of them.
You do know that NordSec maintains its own rust fork of BoringTun: https://github.com/NordSecurity/NepTUN ? :)
There is also https://github.com/firezone/boringtun which is a fork by https://www.firezone.dev/
One meta thing I've always wondered ... Are multiple implementations of the same protocol good or bad for security?
Probably naively, I'm thinking:
What do the security folks out there think of the topic?I wouldn't say that multiple implementations are duplicating the attack surface since most users will not end up running them in parallel.
I meant at a global level (think as if you're attacking all wireguard users, not a single one)
The increased attack surface mostly only affects that one particular implementation though. So, yes, twice as many implementations that may contain exploitable bugs, but each new implementation could only be used to exploit a fraction of the total user base
> could only be used to exploit a fraction
If anything this is a even a good thing, since it means that each individual vulnerability an attacker finds is less valuable to them.
Competitions helps in multiple ways. It improve tooling, test suites, CVE response time, documentation and evolution of the protocol. There are some counter examples where compatibility suck, like DLNA but the problem often come from the spec.
I think the general consensus is that it improves security of the protocol, but obviously that won't matter much if the implementation gets something wrong or has worse security by itself.
Issues in the protocol itself would need all implementations to change, but issues in the implementation would obviously be isolated to one implementation. For something like Wireguard, I'd wager a guess that issues in the implementations are more common than issues in the protocol, at least at this stage.
That's really good because it means it will be able to have more exposure, more exposure means more improvement, more improvement eventually dig out bad bugs and reduces the attack surface in the long run
dont fix if it ain't broken. look at sudo-rs and other rust ports.
ofc, thats a cynical view.
i personally think its a bad idea to duplicate efforts. better combine them. otherwise u risk making mistakes that were already solved. missing lessons already learnt.