Comment by galadran | Hacker News Reader

Comment by galadran | Hacker News Reader

Parent Full thread

Oh man! If only there was a way to take UDP packets and tunnel them over TCP! Wait a second!

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!

Huh. Think I'll package udptunnel for Arch and fix up the ArchWiki entry with this. Super neat.

You doing gods work.

I've not seen/used udptunnel before. Nice. Thanks for the pointer. It looks much simpler than other tricks I've tried to accomplish the same goal.

Obligatory link about tunneling TCP over TCP:

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 wonder whether you could successfully mitigate this a bit by having udptunnel open multiple TCP connections to the destination and sending each tunnelled datagram on the connection with the shortest send queue.

Out of order receives happen. Your method could make things worse.

You would get all kinds of interesting packet reordering issues, which can cause performance problems all their own.

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.

In theory the re-ordering should only happen in the presence of packetloss, which is exactly what you want. Could be worth an experiment, anyway.

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.

vdm further down thread pointed at a repo which does something like this:

https://github.com/wangyu-/udp2raw-tunnel/blob/master/README...

Since you mentioned security note the security implications towards the end of the page as this is actually pretty insecure without additional components. Also note this results in:

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.

I think you've misunderstood. This setup is not insecure.

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...

I was more referring to the DoS attacks on the TCP stack than the spoofing attacks. https://nvd.nist.gov/vuln/detail/CVE-2018-5390 as an example. The attack surface is vastly expanded compared to Wireguard's default attack surface.

It does have one security implication: Wireguard never responds to an attacker. Your tunnel is responding to attackers, so now they know your box exists and can probe it for problems. Each TCP connection takes up memory. If you limit the TCP connections, they can run a slowloris attack and tie them all up.

So it's not a security hole, but it is slightly less secure.

Someone benchmark this compared to raw udp, and then to OpenVPN TCP.

How about you do it?

Nice I am going to try this with a spare AWS instance

Reply on news.ycombinator.com