Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's also udp2raw-tunnel: https://github.com/wangyu-/udp2raw-tunnel

It allows you to tunnel UDP over a fake, non-lossless TCP connection. That is, it wraps packets in TCP headers to make them look like TCP to firewalls, but it doesn't actually implement TCP; instead, each "TCP" packet corresponds to one UDP packet, and it makes no attempt to resend dropped packets. This way you avoid the problems with TCP-over-TCP.



If you're going to pretend to be TCP, you probably need to look like TCP to middleboxes. When we investigated this a few years back, we found that on port 80, only 85% of the client locations we tested would pass TCP if there were holes in the sequence space. In fact this heavily influenced the design of Multipath TCP (MPTCP). The paper is here, relevant section is 4.3: https://conferences.sigcomm.org/imc/2011/docs/p181.pdf


ctrl-f "seq"

In FakeTCP header mode,udp2raw simulates 3-way handshake while establishing a connection,simulates seq and ack_seq while data transferring.

    --seq-mode            <number>        seq increase mode for faketcp:
                                          0:static header,do not increase seq and ack_seq
                                          1:increase seq for every packet,simply ack last seq
                                          2:increase seq randomly, about every 3 packets,simply ack last seq
                                          3:simulate an almost real seq/ack procedure(default)
                                          4:similiar to 3,but do not consider TCP Option Window_Scale,
                                          maybe useful when firewall doesnt support TCP Option
--seq-mode

The FakeTCP mode does not behave 100% like a real tcp connection. ISPs may be able to distinguish the simulated tcp traffic from the real TCP traffic (though it's costly). seq-mode can help you change the seq increase behavior slightly. If you experience connection problems, try to change the value.


Donenfeld himself (Wireguard author) addresses this here: https://news.ycombinator.com/item?id=19766317


There are so many issues with udp2raw, including: poor support, weird configurations, poor code quality, strange DNS solution and loss spikes. Simply put, it's too unreliable at the moment.


The lack of support, documentation, configurability issues and code quality are known to me. After all, it's kind of a hack.

The strange DNS and loss spikes however are not. If they aren't documented in the project, could you elaborate on these issues?


DNS resolution doesn't seem to work on Windows with OpenVPN (ICMP, TCP, UDP work just fine though), on a plain OpenVPN connection everything is working as expected. Maybe I'm wrong and there's a setting, which probably solves the issue, but I've already tried various configurations, including buffer reductions, OpenVPN tweaks, etc. Loss spikes are from small packet size limitation (1200 is a recommended value), programs may try to send big packets, leading to packet fragmentation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: