6 ms·

> WireGuard doesn't work over TCP. I see this repeated in a lot of places about WireGuard but is there anything wrong with UDPTunnel (http://www.cs.columbia.ed

by Znafon 7y ago

> WireGuard doesn't work over TCP. I see this repeated in a lot of places about WireGuard but is there anything wrong with UDPTunnel (http://www.cs.columbia.edu/~lennox/udptunnel/ http://www.cs.columbia.edu/~lennox/udptunnel/)? Why would one prefer this instead of WireGuard + UDPTunnel?

comex 7y ago
There's also udp2raw-tunnel: https://github.com/wangyu-/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.
- mhandley 7y ago
  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 https://conferences.sigcomm.org/imc/2011/docs/p181.pdf
  - Hello71 7y ago
    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.
- bspammer 7y ago
  Donenfeld himself (Wireguard author) addresses this here: https://news.ycombinator.com/item?id=19766317 https://news.ycombinator.com/item?id=19766317
- ac130kz 7y ago
  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.
  - namibj 7y ago
    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?
    - ac130kz 7y ago
      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.
Tepix 7y ago
Perhaps because you don't have UDPTunnel on your phone?
- microcolonel 7y ago
  Could be added to the app, it's just a matter of standardizing it. You probably wouldn't want to run a standalone userspace UDP tunnel process anyway. Though it would probably be wise at that point to make it congestion control aware, since TCP over TCP has some issues which are not considered solved.
9876ghkjh 7y ago
Theres no more right or wrong with vpn's as you can still work out what type of traffic is passing down the wire by the volume of encrypted traffic. YouTube traffic surges which gives you an idea they are watching YouTube, large file downloads like Linux distro's will be typically a continuous consistent level of traffic, webpages are short and brief. Googles services like DNS, api's etc are also joined up in realtime but DYOR. The NSA's Ghidra is a useful tool to start with and is superior to more expensive reverse engineering tools on offer.
- Crinus 7y ago
  Would it be possible to send random bytes through the wire when it is otherwise 'idle' and/or randomize the packet rate?
  - _eht 7y ago
    Yes.
move-on-by 7y ago
Right! This is a bizarre statement. Even HTTP is moving to UDP in HTTPv3. Why would I want even more TCP?
- mavihs 7y ago
  Maybe because in some networks UDP traffic is blocked by their administrator?
  - move-on-by 7y ago
    The technology mentioned by the commentator - UDP Tunnel - is designed to tunnel UDP packets through TCP. I was agreeing with the commentator that it would be a valid solution. I was also pointing out that the days of blocking UDP by default is numbered with the incoming HTTPv3 changes.
Wheaties466 7y ago
Apparently no one here has been on locked down wifi where only ports 80 and 443(TCP) are available to the internet. Thats not that uncommon to see and is a completely legitimate reason to start this project. Theres nothing "wrong" with udptunnel or wireguard other than it doesn't use the transport protocols that the network that he is on allows.
- 7ewis 7y ago
  But even then, my work network for example decrypts traffic or if it can't blocks it.
  - theamk 7y ago
    Yeah, in those environments you may have no choice. But in my case, many local hospitals have free WiFi which blocks everything "suspicious", including most of UDP and many VPN-related TCP ports.
  - Wheaties466 7y ago
    Thats not incredibly uncommon either but i've always wondered how companies get away with decrypting certain sites, i.e. Healthcare. I don't know if it would be appropriate for me to comment further as I work for a middlebox provider.
    - gervase 7y ago
      > i've always wondered how companies get away with decrypting certain sites, i.e. Healthcare. Often, through some kind of employee code of conduct; think along the lines of "I agree to refrain from using my work computer for personal business." or similar. Then, if something sensitive is decrypted, the employer has some legal cover.
      - pnutjam 7y ago
        In my experience, those aren't decrypted. I see company generated certs for most https, but not banks and healthcare sites. I'm guessing there is some sort of whitelist.

by Znafon 7y ago

comex 7y ago

There's also udp2raw-tunnel: https://github.com/wangyu-/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.

mhandley 7y ago
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 https://conferences.sigcomm.org/imc/2011/docs/p181.pdf
- Hello71 7y ago
  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.
bspammer 7y ago
Donenfeld himself (Wireguard author) addresses this here: https://news.ycombinator.com/item?id=19766317 https://news.ycombinator.com/item?id=19766317
ac130kz 7y ago
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.
- namibj 7y ago
  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?
  - ac130kz 7y ago
    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.

Tepix 7y ago

Perhaps because you don't have UDPTunnel on your phone?

microcolonel 7y ago
Could be added to the app, it's just a matter of standardizing it. You probably wouldn't want to run a standalone userspace UDP tunnel process anyway. Though it would probably be wise at that point to make it congestion control aware, since TCP over TCP has some issues which are not considered solved.

9876ghkjh 7y ago

Theres no more right or wrong with vpn's as you can still work out what type of traffic is passing down the wire by the volume of encrypted traffic. YouTube traffic surges which gives you an idea they are watching YouTube, large file downloads like Linux distro's will be typically a continuous consistent level of traffic, webpages are short and brief. Googles services like DNS, api's etc are also joined up in realtime but DYOR. The NSA's Ghidra is a useful tool to start with and is superior to more expensive reverse engineering tools on offer.

Crinus 7y ago
Would it be possible to send random bytes through the wire when it is otherwise 'idle' and/or randomize the packet rate?
- _eht 7y ago
  Yes.

move-on-by 7y ago

Right! This is a bizarre statement. Even HTTP is moving to UDP in HTTPv3. Why would I want even more TCP?

mavihs 7y ago
Maybe because in some networks UDP traffic is blocked by their administrator?
- move-on-by 7y ago
  The technology mentioned by the commentator - UDP Tunnel - is designed to tunnel UDP packets through TCP. I was agreeing with the commentator that it would be a valid solution. I was also pointing out that the days of blocking UDP by default is numbered with the incoming HTTPv3 changes.

Wheaties466 7y ago

Apparently no one here has been on locked down wifi where only ports 80 and 443(TCP) are available to the internet. Thats not that uncommon to see and is a completely legitimate reason to start this project. Theres nothing "wrong" with udptunnel or wireguard other than it doesn't use the transport protocols that the network that he is on allows.

7ewis 7y ago
But even then, my work network for example decrypts traffic or if it can't blocks it.
- theamk 7y ago
  Yeah, in those environments you may have no choice. But in my case, many local hospitals have free WiFi which blocks everything "suspicious", including most of UDP and many VPN-related TCP ports.
- Wheaties466 7y ago
  Thats not incredibly uncommon either but i've always wondered how companies get away with decrypting certain sites, i.e. Healthcare. I don't know if it would be appropriate for me to comment further as I work for a middlebox provider.
  - gervase 7y ago
    > i've always wondered how companies get away with decrypting certain sites, i.e. Healthcare. Often, through some kind of employee code of conduct; think along the lines of "I agree to refrain from using my work computer for personal business." or similar. Then, if something sensitive is decrypted, the employer has some legal cover.
    - pnutjam 7y ago
      In my experience, those aren't decrypted. I see company generated certs for most https, but not banks and healthcare sites. I'm guessing there is some sort of whitelist.