I was following WG development for a while now and I think it's a great project, but sadly not for my particular use case.
The reason Wireguard doesn't do TCP is that it is only a handicap for tunneling, and impedes Wireguard's connectionless features. Maybe Wireguard could add it as a compat option, but the experience will be worse than over UDP.
In the meantime, making a hacky UDP<->TCP<->UDP proxy isn't very hard. Less than 100 lines of Go. It'll handicap Wireguard quite a bit (even more than a built-in TCP compat feature), but it'll probably still be faster than OpenVPN.
Still, I do not have any practical reason for switching to Wireguard, as I do not really see any reduced speed - it is possible that the bandwidth limitation of this network's internet connection is low enough for that to be the bottleneck, instead of OpenVPN. :)
Are the other TCP ports, as well as UDP blocked by a force of nature? :)
> Still, I do not have any practical reason for switching to Wireguard, as I do not really see any reduced speed - it is possible that the bandwidth limitation of this network's internet connection is low enough for that to be the bottleneck, instead of OpenVPN. :)
At lower throughput networks, you don't need wireguard. It'll still mean fewer CPU resources used, much simpler configuration, and things OpenVPN and the likes just cannot do (such as maintain the connection despite both ends changing IP, as long as it doesn't happen simultaneously).
Yes; the force in question is usually spelled out as "auditors." :(
In case of the former, then Wireguard will likely be permitted some day as the status quo of VPNs. OpenVPN and IPSec appear as dead ends, so it's just a matter of time. If Wireguard is successfully upstreamed soon, I wouldn't be surprised if it rose to the throne of VPN monopoly sooner rather than later.
In case of the latter, you're out of luck without a compat mode or a bridge tool... :/