wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: "KeXianbin(http://diyism.com)" <kexianbin@diyism.com>
To: Breus Blaauwendraad <b.blaauwendraad@gmail.com>
Cc: wireguard@lists.zx2c4.com
Subject: Re: [feature request] To support "Wireguard over raw TCP"
Date: Tue, 2 Oct 2018 17:00:54 +0800	[thread overview]
Message-ID: <CAKVinOU1_nd1Us_NMRWFQ3U=T8wijHm+jwggqm3uNXRCTpaDxA@mail.gmail.com> (raw)
In-Reply-To: <CAKVinOWN4+r4T6X2RsDFpOhV_kTrEquUe4fRoB6j0Q8+r-YLNg@mail.gmail.com>


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

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@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@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/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@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: 11407 bytes --]

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

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

  reply	other threads:[~2018-10-02  9:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKVinOU6xpbJNfCPAecX7kOgk_PbCzThYtER9d3ax1h6k3DGTw@mail.gmail.com>
2018-09-25 15:52 ` [feature request] To support "Wireguard over raw TCP" StarBrilliant
2018-09-25 16:29   ` Breus Blaauwendraad
2018-10-02  6:40     ` Matthias Urlichs
2018-10-02  6:53     ` KeXianbin(http://diyism.com)
2018-10-02  9:00       ` KeXianbin(http://diyism.com) [this message]
     [not found]   ` <CAKVinOXXqMDRZcjVbOS4-iMBONdiYKaho8e3tEAZO+JKOZ_Gxw@mail.gmail.com>
2018-09-25 20:25     ` Michael Rash
2018-09-26  7:14 Saeid Akbari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKVinOU1_nd1Us_NMRWFQ3U=T8wijHm+jwggqm3uNXRCTpaDxA@mail.gmail.com' \
    --to=kexianbin@diyism.com \
    --cc=b.blaauwendraad@gmail.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).