Olaf Titz

There are several possibilities of dealing with UDP traffic in OMR.

1) Multipath VPN (glorytun).
Thing is that UDP spread over multiple paths will not as well as MPTCP. MPTCP creates multiple subflows, one for each available path. Each subflow behaves (roughly) as a separate TCP connection, carrying some part of the traffic that goes through the pipe (byte-level splitting of the traffic, not packet-level). What's important here is that each subflow has its own separate congestion control.
The congestion control mechanism [1] is a very important aspect of TCP that basically controls its speed in a way that your internet connection is not overloaded and concurrent connections aren't disrupted. QUIC also includes a congestion control mechanism. But with MPTCP, each path is treated individually; with QUIC-over-multipath-VPN, where we just spread UDP packets somehow over multiple paths, the congestion control mechanism will get confused, b/c in the reality the congestion can happen separately on each path which will be hard to see; also, there will be packet reordering which will not improve the situation either. Basically, this is what happens when you try to spread plain TCP over multiple paths naively, and it's the reason why MPTCP was invented in the first place.

2) UDP-over-TCP.
In this case, I'm afraid that given that QUIC has its own congestion control, we might get unpleasant side effects similar to "TCP meltdown" as in case of TCP-over-TCP [2]

[1]…

WireGuard is a networking primitive. It creates a secure tunnel between two points and only contains the things necessary to make that happen.

The rest of what you're asking for can be implementing on top of WireGuard in external tools and I fully expect will be over the next few years seeing the adoption so far.

And given you mentioned SSH... That's basically what it is, yes, layer 3 forwarding over SSH except done in a way that's actually usable. (For issues, see e.g., http://sites.inka.de/bigred/devel/tcp-tcp.html)

This is a step back towards the unix philosophy of providing simple pieces that can be stacked together to build more complicated things, not a drop-in replacement for OpenVPN et al. Most of us are excited because (1) not everyone is an enterprise, and that "we need everything and the kitchen sink" philosophy makes OpenVPN annoying to work with for everyone else and (2) we'll probably see a lot more options cropping up in this space soon built around WireGuard now that developers have been given a secure primitive to build upon.

Charles Pellegrino/George Zebrowski covers this in _The Killing Star_ (1995). They reason as follows:

1. Any species will place its own survival before that of a different species.
2. Any species that has made it to the top on its planet of origin will be
intelligent, alert, aggressive, and ruthless when necessary.
3. They will assume that the first two rules apply to us.

So any starfaring species might well destroy another starfaring species -- immediately. In _The Killing Star_ the aliens do so at the first opportunity with high-powered relativistic bombardment. The power that they use dwarfs that generated by asteroid impacts and past mass extictions. They blanket the entire hemisphere of planets with relativistic projectiles! The earth is taken out entirely in just two shots.

http://sites.inka.de/mips/reviews/TheKillingStar.html

It's not the TUN/TAP device that gets you; it's tunneling TCP over TCP, which wrecks havoc with TCP's retransmission algorithm[1]. I've personally done measurements and the bandwidth of a TCP connection over a UDP OpenVPN tunnel is just as good as the bandwidth without using a tunnel. In contrast, the bandwidth of a TCP connection over a TCP OpenVPN tunnel is significantly worse.

You may theoretically have worse performance with a TUN/TAP tunnel compared to an IPSEC tunnel because the packets have to travel into and out of userspace whereas IPSEC stays in the kernel, but I've never noticed this in practice. In contrast, the TCP performance degradation is very noticeable in practice.

[1] http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

Can't speak about security aspects, but:

If you ever use SSH to tunnel/forward TCP traffic, you should be aware of certain performance issues [1], due to TCP's re-transmit mis-behaving (stacking) in a TCP-in-TCP scenario. Expect seemingly random delays, followed by bursts of transmission even well below the nominal capacity of the connection. This also causes overall increase in amount of data sent.

The same caveat applies to any other TCP-in-TCP tunnel (as opposed to the usual TCP-in-UDP setup), unless one or both tunnel endpoints specifically handle re-transmits properly.

[1] http://sites.inka.de/bigred/devel/tcp-tcp.html

Generally speaking, tunneling TCP inside TCP is a bad idea. Yes, it’ll “mostly” work with the added latency you mentioned, but it can go very poorly if the network starts having packet congestion or dropped packets.

If the “outer” VPN is UDP or IPsec, then not as much an issue, but many of the VPN providers commonly used are TCP based (of the ones I spot checked from a google search anyway). And remember, since they are TCPinTCP already, you are just making the situation even more likely to occur.

Further reading: http://sites.inka.de/bigred/devel/tcp-tcp.html