> little more setup

A lot more! PKI infrastructure, chiphersuites and so on and so forth...

By the way OpenVPN also can work with UDP, even it's default mode.

It's a lot more if you do it all manually, however for most "common" use cases, one should probably go with automatically generated config files.

For instance pfSense provides you with single-click configs for any target platform, with certs, credentials etc. properly tied to some ACL or ID management system, etc. It's neat and pain-free and just works.

You could learn all the theory underneath (I mean systems, IT, not the crypto!) and do it manually (and you probably should for a big-enough infra, or specific-enough use-case), but that will be premature optimization I think.

Basic VPN is easy (take a weekend to learn / implement and you'll have all the great benefits of VPNs). Wireguard is "just" more efficient by an order of magnitude as I see it, it'll become the de facto low-profile implementation me thinks.

First setup always needs to be manual.

... yes, obviously? : )

We might not be using the word "manual" to mean the same here.

I meant not writing the whole xml json yaml or whatever yourself, manually copying certs and credentials etc — you're likely to make mistakes, it's tedious and useless most of the time. You rather use tools like Viscosity. Just efficient / best practice sysadmin.

You obviously need access to the target machine in the first place... it's a VPN setup.

Makes a good argument for having a mobile phone on the mainline kernel, rather than on some ancient kernel with a thousand hacks layered on top. Something like Pinephone should get access to this more quickly than a standard Android device.

On that note, I wish and hope Wireguard did TCP as well. Some countries block UDP traffic or at least throttle it.

As I know WireGuard team have no plans and desire for that.

huh .. OpenVPN is UDP by default but you can force it to TCP (we had to do that at one University site that would only open limited tcp ports for us).

I also discovered Wireguard cannot bind to a specific adapter or IP address if you have multiple address on a server. That might not seem like as a big a deal since it only responds to fully authenticated packets, but it does mean that outgoing packets could be leaving from a different IP address than incoming packets.

It's weird that something that's now making it into mainline can't do this very simple kind of bind that almost every other userlevel service, and OpenVPN, can do.

Maybe the best solution is to use a tool like https://github.com/wangyu-/udp2raw-tunnel.

I know, but the performance takes a massive hit. Have you tried it? Maybe it was something I did wrong.

Native wireguard is kernel-only. Udp2raw creates a detour via userspace, so more CPU time, delay, jitter ..

Was it worse than you would expect? Worse than say openvpn or wireguard-rs/wireguard-go?

It's not that bad. Overhead is less than a full TCP encapsulation. I use it all the time

ISPs or countries?

In some cases, countries. In the country I'm thinking of (name omitted on purpose), you have an effective choice of two ISPs, both government-controlled.

Do they actually block/throttle all UDP?

What about encrypted TCP? Do they block/throttle everything but web and recognized traffic? If that's the case wrapping WG or ZeroTier or whatever in TCP would do nothing since it would still look like a weird unrecognized protocol with a max entropy (encrypted) data stream.

Have you taken a look at inlets / inlets PRO? Might be a suitable replacement for your use-case where UDP is not available. https://docs.inlets.dev/

I wonder how WireGuard compares to IPsec with regards to the mobile battery. AFAIK IPsec implemented in kernel while WireGuard uses user-space implementation on mobile devices, at least for now.

I'm pretty sure some ROMs already have kernel support, although I don't know details.

For some Android kernels official WireGuard application supports in-kernel module. Fox example for pixel 3.

The code has been merged into the kernel as of 5.4(?) I believe, but we won't see that on mobile for quite awhile. I'm guessing IPSec will still have a lead on mobile for awhile for that reason, not that it has sort of majority on there anyway.

It was merged in 5.6, which was tagged less than 24 hours ago.

Ah, I remember reading about it like a month ago or so but I though it had already been released

You're not misremembering -- Linux has releases every 6-7 weeks. WireGuard was merged into 5.6-rc1 a little over a month ago and the story was posted to HN from memory.

Wiregard may be speedier (I've never used it so I can't say for certain), but OpenVPN can also use UDP.

WG is much faster in our tests than OpenVPN, and a bit faster than IPSec depending on the system. OpenVPN uses UDP too but OpenVPN is kind of slow.

Or much slower on systems with AES-NI, but relatively slow CPU. Like are used in some hi-end SOHO routers.

I did not test IPSec vs WireGuard, but scp from/to my home router/NAS is about three times faster with AES (used by IPSec) than with Chacha20 (used by WG).

Good point. AES hardware acceleration makes a massive difference. It's why ZeroTier 2.x will use AES. Tiny boxes that lack HW acceleration are generally not used in cases where they're pushing enough bandwidth to matter anyway.

No, but boxes who lack hardware acceleration might care about battery life.

How many 32-bit ARM phones without AES units are there still around?

i did test it. in my setup we couldn't get IPsec to not drop a lotmof packages, so the benefits of aes-ni was lost in retries. switching that IPsec setup to chacha20-poly1305 actually made most of the drops go away.

I have no idea what was going on, but wireguard and IPsec was comparable in that test, with ispec being sliiiightly faster. the network has almost no latency, so if the retries remain on slower networks, that would change.