[feature request] To support "Wireguard over raw TCP"

Tue Oct 2 11:00:54 CEST 2018

Sorry, I've got some help from udp2raw author, he/she tell me
udp2raw/faketcp needs a tcp handshake to build a tcp connection. So
Integrating FakeTCP into wireguard has no possibility to keep the
P2P/nat-traverse feature.
Finally I abandon/recall my Feature Request to integrating faketcp into
Wireguard. Maybe I can only integrate udp2raw into a personal Wireguard
android client to only connect the wireguard on my VPS(with a public
ip:port).

Malcolm Ke

On Oct 2, 2018 14:53, "KeXianbin(http://diyism.com)" <kexianbin at diyism.com>
wrote:

> The most important for me is to keep the P2P feature(auto NAT traverse) of
> wireguard while wrapping the wireguard UDP packets into udp2raw Fake
> TCP/Raw TCP packets. I think that keeping p2p feature of wireguard in
> wireguard+udp2raw is more complex or even impossible than Wireguard itself
> supports Fake TCP/Raw TCP packets: https://github.com/
> wangyu-/udp2raw-tunnel/issues/212
>
> On Oct 2, 2018 11:11, "Breus Blaauwendraad" <b.blaauwendraad at gmail.com>
> wrote:
>
>> Hello StarBrilliant,
>>
>> I think that what Kexianbin is trying to make clear is that it would be
>> nice if  native TCP support would be added in WireGuard.
>> He (probably) currently uses udp2raw as an alternative, because an
>> UDP-only VPN is sadly enough not working in every situation.
>> With him, there have been others pitching ideas on how to wrap the
>> WireGuard UDP traffic in TCP, which in my opinion, is a poor idea.
>>
>> So, why would UDP for a VPN service not be enough?
>>
>> First of all, most VPN traffic obfuscation techniques require a TCP
>> connection instead of UDP.
>> VPN usage is particularly useful in countries were Internet censorship is
>> applied.
>> Since obfuscating VPN traffic comes with performance overhead, wrapping
>> the UDP in TCP and obfuscating this would kill the performance advantage
>> WireGuard has over other protocols.
>>
>> However, what is arguably more important: various corporate firewalls
>> (hotels/restaurants/offices) are known to block UDP (for random ports
>> besides the standard DNS 53 port etc.).
>> In these instances, it would be useful to have the possibility to build a
>> fall back to TCP instead of UDP in a VPN service (or even the protocol
>> itself).
>>
>> Also, various researchers I have spoken to told me that sometimes they
>> need a more reliable (TCP) connection, which is then more important than
>> the speed UDP provides.
>>
>> I'm looking into the possibilities to deploy the WireGuard VPN protocol
>> for an existing VPN service currently using OpenVPN, but I keep stumbling
>> on the problem that WIreGuard does not support TCP.
>> I (think I) have read all posts regarding TCP for WireGuard, but it seems
>> that there do not exists a good way to tackle this problem.
>>
>> Could someone tell whether or not TCP would be a future additional option
>> for WireGuard, and why (not)?
>>
>> Also, do you think there actually does exist a neat and fitting solution
>> for the problems I described?
>>
>> Kind regards,
>>
>> Breus Blaauwendraad
>>
>>
>> On Tue, 25 Sep 2018 at 17:54, StarBrilliant <coder at poorlab.com> wrote:
>>
>>> On Tue, Sep 25, 2018 at 1:17 PM KeXianbin(http://diyism.com)
>>> <kexianbin at diyism.com> wrote:
>>> >
>>> > Currently, I'm using udp2raw-tunnel to transform wireguard udp traffic
>>> into raw tcp (config files as follows),
>>> > It's very stable on my home network than using wireguard alone,
>>> > But if we can integrate RAW TCP feature into wireguard, it would
>>> significantly improve performance and stability for end users.
>>> >
>>> >
>>> > from: https://gist.github.com/diyism/1b80903a83776675031c73ae49943
>>> 8d8#file-wireguard_config-txt-L145
>>> >
>>> > $wget https://github.com/wangyu-/udp2raw-tunnel/releases/download/
>>> 20180830.2/udp2raw_binaries.tar.gz
>>> > $tar xzvf udp2raw_binaries.tar.gz
>>> > $sudo cp udp2raw_amd64 /usr/bin/
>>> > $sudo udp2raw_amd64 -c -l127.0.0.2:24448 -r<server ip>:24447 -a
>>> > $cat /etc/wireguard/wg0.conf
>>> > [Interface]
>>> > PrivateKey = <client privkey>
>>> > Address = 10.0.0.3/32
>>> > ListenPort = 24447
>>> > MTU = 1300
>>> > PostUp = ip route add 10.0.0.0/24 dev wg0 && wg set wg0 peer <server
>>> pubkey> allowed-ips 0.0.0.0/0
>>> > PostDown = ip route del 10.0.0.0/24
>>> >
>>> > [Peer]
>>> > #10.0.0.1
>>> > PublicKey = <server pubkey>
>>> > Endpoint = 127.0.0.2:24448
>>> > #AllowedIPs = 0.0.0.0/0
>>> >
>>> > $sudo wg-quick down wg0 ; sudo wg-quick up wg0
>>> > $ping 10.0.0.1
>>> > 64 bytes from 10.0.0.1: icmp_seq=2113 ttl=64 time=183 ms
>>> > $sudo ip route add 104.24.0.0/16 dev wg0
>>> > $ping myip.ipip.net
>>> > PING myip.ipip.net (104.24.20.50) 56(84) bytes of data.
>>> > 64 bytes from 104.24.20.50 (104.24.20.50): icmp_seq=1 ttl=60 time=185
>>> ms
>>> > $curl http://myip.ipip.net
>>> > IP：<server ip>
>>> >
>>> > #take care, "MTU = 1300" in wg0.conf is needed when wireguard over
>>> udp2raw, or else most https requests will be blocked because of mtu problem.
>>>
>>>
>>> Hello Kexianbin,
>>>
>>> This is an UNOFFICIAL response to your question. (But I think the
>>> official developers may have similar answers.)
>>>
>>> Wireguard probably will not accept an official integration to udp2raw.
>>> The reasons are:
>>>
>>> 1) Wireguard wants to keep their kernel part code minimized, therefore
>>> easy for security auditing, and less bugs.The UDP protocol is actually
>>> very simple and straightforward. (By the way, if you intended to use
>>> Wireguard in China, be informed that this is a protocol that is very
>>> easy to block by the ISP.)
>>>
>>> 2) I have read the source code of udp2raw. To be frank, the code is of
>>> very low quality. For this reason, I don't think udp2raw would be
>>> integrated into Wireguard unless it's rewritten.
>>>
>>> 3) Udp2raw is not suitable for everyone or for every country. For
>>> example udp2raw may have problems passing middleboxes, which is common
>>> among satellite ISPs in Oceania. Middleboxes break and resemble TCP
>>> segments thus make udp2raw literally unusable. Also it is not
>>> congestion friendly (by design), so a massive deployment may affect
>>> the global Internet ecology.
>>>
>>> However the good news is, Wireguard provides an open control interface
>>> (see https://www.wireguard.com/xplatform/ ). By utilizing this
>>> interface, we can develop an alternate frontend application other than
>>> the official command "wg", that automatically sets up the kernel
>>> Wireguard kernel part and a userland udp2raw part, packaged as one
>>> application.
>>>
>>>
>>> My words for Wireguard developers:
>>>
>>> 1) In case you may not know the udp2raw protocol, here is a
>>> description. Some ISPs in certain countries have strange QoS strategy
>>> that deprioritize UDP packets during network congestion, resulting a
>>> 50% loss rate or more for UDP. The udp2raw protocol simulates a
>>> three-way TCP handshake and add TCP header to UDP packets so they will
>>> not be dropped. This protocol does not do congestion control or rate
>>> control, neither does it understand any TCP semantics. It's a dirty
>>> hack for dirty ISP, not suitable for everyone, but overwhelmingly
>>> useful in certain countries.
>>>
>>> 2) Wireguard currently does not support binding to localhost. This is
>>> required for any third-party plugins upon Wireguard to work. We might
>>> need to consider binding to localhost an important feature to go in
>>> the near future.
>>>
>>>
>>> Best regards,
>>> StarBrilliant
>>> _______________________________________________
>>> WireGuard mailing list
>>> WireGuard at lists.zx2c4.com
>>> https://lists.zx2c4.com/mailman/listinfo/wireguard
>>>
>>
>> _______________________________________________
>> WireGuard mailing list
>> WireGuard at lists.zx2c4.com
>> https://lists.zx2c4.com/mailman/listinfo/wireguard
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20181002/61581894/attachment-0001.html>