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

["KeXianbin(http://diyism.com)" <kexianbin@diyism.com>]

[-- Attachment #1.1: Type: text/plain, Size: 7259 bytes --]

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@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@poorlab.com> wrote:
>
>> On Tue, Sep 25, 2018 at 1:17 PM KeXianbin(http://diyism.com)
>> <kexianbin@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/1b80903a83776675031c73ae499438
>> d8#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@lists.zx2c4.com
>> https://lists.zx2c4.com/mailman/listinfo/wireguard
>>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
>

[-- Attachment #1.2: Type: text/html, Size: 10443 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard