32 comments

[ 3.7 ms ] story [ 47.1 ms ] thread
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.
One meta thing I've always wondered ... Are multiple implementations of the same protocol good or bad for security?

Probably naively, I'm thinking:

    - diversity: good
    - doubling the attack surface: real bad
What do the security folks out there think of the topic?
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

I wish they would improve wireguard-the-protocol as well: wireguard doesn't stand a chance against gov/isp blocks.
Mullvad does offers several obfuscation methods well geared towards the scenarios you mention.
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.
Do you have wireguard keepalives on?
Android kernels 4.19 and higher should all have support included for WireGuard unless the OEM specifically disables it: [0]. The Pixel 8 ships with the android 14 6.1 kernel so it most definitely should have WireGuard kernel support. You can check this in the WireGuard app BTW, if you go to settings it will show the backend that's in use.

[0] https://android-review.googlesource.com/c/kernel/common/+/14...

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.
Been buying mullvad for the last 4-5 years but oftentimes I can’t even browse the fucking New York Times website due to low bandwidth, let alone stream anything. At this point, I just keep adding time to my account just in case, without using it.
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.

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.

Fingers crossed that GotaTun will also make its way into the Tailscale Android app (since that's what I use to connect to Mullvad).
I would love to see more root cause analysis data on the crashes they were seeing with wireguard-go. I wonder if it was bugs in the library itself, or the FFI.
Yeah I'm surprised by that. I thought Wireguard was so simple and wireguard-go was so popular that it wouldn't crash. It's just UDP packets.
Can you use DAITA with just gotatun (on linux) or do you require the Mullvad daemon?
I thought Wireguard runs inside the kernel on Android since it ships as part of Linux now.
As far as I know, you need root permissions to add an interface. Even though the module is enabled, it's not used.

The official wireguard app also mentions wireguard-go

the linked issues are quite interesting, why does go have to page in so much memory for the GoString? Is this for some sort of optimization? https://github.com/mullvad/mullvadvpn-app/pull/6727

if anyone else is more familiar with go (I only really do rust) is there no solution to preventing stack smashing on goroutines? https://github.com/mullvad/mullvadvpn-app/pull/7728 I understand that go routines have a smaller stack size (the whole green thread problem) but there's no way to fix this?

Hope tailscale adopts this