Everybody commenting that WireGuard over TCP is a bad idea, and TFA explains why it exists:
"WireGuard out of the box works only over UDP. This can cause problems because UDP is blocked on many public networks like in cafes and on trains. That’s why we’re introducing a solution for WireGuard over TCP."
Yeah, it's a bad idea, but sometimes it's necessary.
Exactly that. They are including an encapsulation option on their client package and running something on the server side to listen/decode the TCP and shove it back into udp. I have run a wireguard server behind udptunnel for the same reasons in the past and it looks like they are simply setting their own internal standard.
For the most part, if I am providing wifi in a place like that the only thing I want you to do is browse the web. I am not interested in your desire to run a torrent client, stream netflix, or do something else that consumes a significant amount of bandwidth. Most UDP applications are also rather poor when it comes to congestion control and in general do not play nice with the other children. These companies have better things to do than to provide IT support for people trying to use the wifi, so you block all UDP and force re-direct port 53 UDP (DNS lookups) to go to a resolver that you are going to provide in the DHCP lease. This also means that wireguard is not an option for most people if they are on these networks.
Assuming you’re tunneling TCP inside of TCP, then in the event of non-perfect network conditions, you have two layers of the stack that are now trying to adjust the TCP flow parameters, re-transmit packets, etc. This will frequently end up in a situation where overall performance of the link is significantly worse than it needs to be.
"WireGuard out of the box works only over UDP. This can cause problems because UDP is blocked on many public networks like in cafes and on trains. That’s why we’re introducing a solution for WireGuard over TCP."
Yeah, it's a bad idea, but sometimes it's necessary.