At least OpenVPN, for all the criticism the article throws at it, has the configurability to pass through the various strange firewall rules that exist in the real World. Waiting eight seconds for negotiation isn't a big deal when the new and shiny 'replacement' doesn't have a hope of working.
http://manpages.ubuntu.com/manpages/xenial/man1/udptunnel.1....
Setup Wireguard on your server as though everything were normal. However, on the server, run this command (as a service):
udptunnel -s 443 127.0.0.1/51820
Then on your client run:
udptunnel -c [SERVER-ADDR]/443 127.0.0.1 51818
In the Client's Wireguard Config, where you would normally specify the server's address / port. Instead specify 127.0.0.1 51818. Finished!
Don't forget to open the firewall on the server's port 443!
Setting up udptunnel as a systemd service to auto start / restart only involves writing two short files! Wireguard uses a standard service file as well so you can simply require the udptunnel service as a prerequisite!
Personally, I find this style of combining simple components much more satisfying (and secure!) than the gargantuan complexity of OpenVPN/IPSec! Wireguard's simplicity means it is easy to have a mental model around how it functions and how it can be composed!
application data in IP+<L4 protocol> in IP+UDP Tunnel (Wireguard) in IP+TCP
So securing the component mess and header bloat is becoming as bad as OpenVPN/IPSec which you abhorred. Still probably faster than OpenVPN though as that implementation is amazingly bad.
Wireguard authenticates (or drops) any packets forwarded by udptunnel. Once a packet leaves the Wireguard interface the attacker (or anyone else) can transform it however they like without impacting security properties.
This config does allow the attacker to make a TCP handshake to the server, but the data they send over the TCP wrapped connection could have equally been sent to the UDP port Wireguard is listening on.
Disclaimer: This of course assumes both Wireguard and udptunnel have no remote code exploits or other implementation errors. However, as we discussed, this is a much safer assumption than OpenVPN...
So it's not a security hole, but it is slightly less secure.
http://sites.inka.de/bigred/devel/tcp-tcp.html
(not that it matters when you're trying to tunnel out of university network, but something to keep in mind, especially on lossy connections)
I've sometimes contemplated just faking the TCP protocol entirely. Do the TCP handshake, then send "TCP packets" but interpret each payload as a datagram, acknowledge everything up to the latest sequence number regardless of whether any of them were lost and don't bother with any flow control or retransmissions.
It's a terrible hack but it would probably work at least some of the time.
Your suggestion is how some "WAN optimisation" network middleboxes work (transparently terminating the TCP in the middlebox itself). To do that with Wireguard you'd have to implement that in the Linux kernel.
https://github.com/wangyu-/udp2raw-tunnel/blob/master/README...
If OTOH they want to allow you to use a VPN, they should allow at least some UDP traffic. The way God intended BTW because running VPN traffic over TCP usually means running error detection and flow control twice on top of each other.
Sure, some of the value of a VPN is running through misconfigured and outright hostile networks, hence various encapsulation schemes (over SSL, in DNS requests, etc), but only some of the value.
Those ancient setups need to die.
But running wireguard on port 53 might just work!
To be honest I'm a bit surprised vy the reactions here. This isn't an unusual configuration, I've worked in two other companies that had the same rules; nothing except web traffic even on the 'public' wifi. The latter permitted any device to connect but had absolutely no exceptions to the firewall rules. The corp nets did have an exception process but only for servers in the DMZ.
Don't do that.
Edit: going by downvotes, it still seems to be a sore spot. That answers my question about its current status in the USA I suppose...
Blocking UDP is not treating all traffic the same. Even if the law would be about treating services equally and not any IP packet equally, then it still has a different impact on services like VoIP (which are often UDP) than it does on other services. Blocking certain types of packets is not compliant with net neutrality -- at least, not in the Netherlands. If there is a different definition whereever you come from, please tell me about it.
I'd be willing to bet my lunch that there are exceptions for private, government, and educational institutions or that there is an exception related to security services.
Any blocks should be necessary/essential for network stability or security. If I have evidence that a trojan is using tcp port 1337, and I am not aware of any other application that uses it, then there is no problem blocking it. In practice, of course, malware would be crazy not to use tcp/443 or tcp/80, so blocking ports is rather pointless these days anyway.
As for network stability: reasons like "by blocking VoIP we can sell our services and use that money to make our network more stable" are not good enough, of course. There has to be a concrete reason why {whatever you want to block} will benefit the network.
> and they need to have all public addresses to get around the fact that no device dynamically NATs all L4 protocols.
I guess since there is scarity in v4-addresses, it's not reasonable to use public addresses for each individual, so "blocking" incoming traffic (or rather, it being unrouteable) shouldn't be an issue. It's essential for the network's operation.
I have never once heard anybody claim that private institutions are not allowed to shape their own network traffic.
Unless you show me Dutch law that clearly spells this out, I will not for a second believe that it is illegal for a university to block certain protocols.
If what you say were true then pretty much every single private organization would be operating illegally, anybody that runs VoIP, blocks UDP or any other way to shape the network.