Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GotaTun – Mullvad's WireGuard Implementation in Rust

mullvad.net

Post reply on HN
Print view View original

131–140 of 142 posts

Re: GotaTun – Mullvad's WireGuard Implementation in Rust

#131

Post by gvkhna »

nrds wrote: post #62
razighter777 wrote: post #13

Earlier quoted context omitted.

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…

In this case with the, I believe it’s called quantum tunneling by mullvad, it’s actually a good thing. Because the encapsulation protocol is just UDP/IP, a well established existing protocol that can masquerade as any kind of internet traffic easily.

Makes it difficult to block by censors. Great video I saw here: https://youtu.be/pZiG8r-diTM?si=wy35elqMt1T6euq0

This also means wg is just doing one thing instead of a dozen it doesn’t “need” to.

Re: GotaTun – Mullvad's WireGuard Implementation in Rust

#132

Post by criticalfault »

drexlspivey wrote: post #98

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

Re: GotaTun – Mullvad's WireGuard Implementation in Rust

#133

Post by angristan »

drexlspivey wrote: post #98

I thought Wireguard runs inside the kernel on Android since it ships as part of Linux now.

Apparently the module is there: https://www.xda-developers.com/google-adds-wireguard-vpn-and...

But you need to be rooted to use it: https://lists.zx2c4.com/pipermail/wireguard/2022-September/0...

Re: GotaTun – Mullvad's WireGuard Implementation in Rust

#134

Post by Rawa »

vsgherzi wrote: post #115

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 s…

It was solved in another PR by using an alternate stack by setting the flag SA_ONSTACK.

Re: GotaTun – Mullvad's WireGuard Implementation in Rust

#135

Post by zamadatix »

jchw wrote: post #100
zamadatix wrote: post #85

Earlier quoted context omitted.

For most any 5G network you should be safe to 1420 - 80 = 1340 bytes if using IPv6 transport or 1420 - 60 = 1360 bytes if using IPv4 transport. For testing I recommend starting from 1280 as a "does this even work" baseline and then tweaking from there. I.e. 1280 either as the "outside" MTU if you only care about IPv4 or as the "inside" MTU if you want IPv6 to work through the tunnel. This leverages that IPv6 demands…

Hah! I just ran into this recently and can confirm. The coax to my DOCSIS ISP was damaged during a storm, which was causing upstream channels to barely work at all. (Amusingly, downstream had no trouble.) While waiting for the cable person to come around later in the week, I hooked my home gateway device up to an old phone instead of the modem. I figured there would be consequences, but surprisingly, everything went…

Your ultimate conclusion is correct, to my understanding. I know wireguard sought to be ultra minimal but I do wish they had included DPLPMTUD as something which is required to be supported (but not mandated to be used e.g. if the user wants to hard set it as they would currently) because it's one of those cases where "do it yourself separately the UNIX way™" or "have the tunneled things do it if they need it" instead are both significantly more complex and fragile.

Re: GotaTun – Mullvad's WireGuard Implementation in Rust

#137

Post by jchw »

zamadatix wrote: post #135
jchw wrote: post #100

Earlier quoted context omitted.

Hah! I just ran into this recently and can confirm. The coax to my DOCSIS ISP was damaged during a storm, which was causing upstream channels to barely work at all. (Amusingly, downstream had no trouble.) While waiting for the cable person to come around later in the week, I hooked my home gateway device up to an old phone instead of the modem. I figured there would be consequences, but surprisingly, everything went…

Your ultimate conclusion is correct, to my understanding. I know wireguard sought to be ultra minimal but I do wish they had included DPLPMTUD as something which is required to be supported (but not mandated to be used e.g. if the user wants to hard set it as they would currently) because it's one of those cases where "do it yourself separately the UNIX way™" or "have the tunneled things do it if they need it" instea…

On that note, from the TCP layer it should just look like an ICMP blackhole, which makes me wonder if enabling `net.ipv4.tcp_mtu_probing` will magically make TCP connections under Wireguard work even with the MTU set wrong. I'd try it, but unfortunately with a similar configuration I am unable to get the fragmentation behavior I was getting before; which makes me wonder if it was my UniFi Security Gateway that actually didn't like the fragmented packets.

Re: GotaTun – Mullvad's WireGuard Implementation in Rust

#138

Post by prism56 »

0x1ch wrote: post #113
ekjhgkejhgk wrote: post #84

Earlier quoted context omitted.

I'm surprised by this comment. I have wireguard on 24/7 on my shitty Samsung A5 and it lasts forever. By comparison the Pixel 8 is a beast. Sounds like an Android bug more than wireguard.

Pixel 6 here. Vanilla wireguard app. It sucks the life out of my phone and nearly halves the already half-life battery (thanks Google for your crappy OEM producers!)

They must have fixed it in recent versions. My pixel 9 pro battery seems the same with proton VPN (wirrguard) on or off.

Re: GotaTun – Mullvad's WireGuard Implementation in Rust

#139

Post by jorvi »

wing-_-nuts wrote: post #89
jorvi wrote: post #81

Earlier quoted context omitted.

Not only Eddie, their account control panels and site in general look like something from the 90s, and it seriously hampers their business. I can't recommend them to anyone that isn't highly technical. And even then, as a technical user, why do I manually have to select one of 10-20 servers within a city or region, why am I being asked to manually load balance? Why is there no Wireguard over port 53 or 443? It makes…

>Btw, if you're managing things in CLI, you could take a look at their Hummingbird Suite. AFAIK it has a killswitch. Hummingbird doesn't support wireguard iirc, which is a deal breaker

They're planning to introduce OpenVPN Data Channel Offload (DCO) support to more servers once Linux 6.18 starts becoming more mainstream.

With DCO, OpenVPN can perform almost as well as Wireguard, sometimes even better. Although with more performance overhead so not the best choice for laptops and phones.

Tangentially related but I kind of wish Wireguard looked more toward the future and had included AES as alternative to ChaCha20. At the time of development, many ARM devices didn't yet have AES acceleration which is why ChaCha20 was needed for wide hardware support, but they do since ARMv8 which became widespread in 2015. Intel and AMD have had AES acceleration for a long time. And then ChaCha20 would have been the fallback on MIPS and RISC-V.

Post reply on HN