<div dir="auto">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. <span style="color:rgb(36,41,46);font-family:-apple-system,blinkmacsystemfont,"segoe ui",helvetica,arial,sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol";font-size:14px;background-color:rgb(255,255,255)">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: </span><font color="#24292e" face="-apple-system, blinkmacsystemfont, segoe ui, helvetica, arial, sans-serif, apple color emoji, segoe ui emoji, segoe ui symbol"><span style="font-size:14px"><a href="https://github.com/wangyu-/udp2raw-tunnel/issues/212">https://github.com/wangyu-/udp2raw-tunnel/issues/212</a></span></font></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 2, 2018 11:11, "Breus Blaauwendraad" <<a href="mailto:b.blaauwendraad@gmail.com" target="_blank">b.blaauwendraad@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello StarBrilliant,</div><div><br></div><div>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.</div><div>He (probably) currently uses udp2raw as an alternative, because an UDP-only VPN is sadly enough not working in every situation.</div><div>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.</div><div><br></div><div>So, why would UDP for a VPN service not be enough?<br></div><div><br></div><div>First of all, most VPN traffic obfuscation techniques require a TCP connection instead of UDP. <br></div><div>VPN usage is particularly useful in countries were Internet censorship is applied.<br></div><div>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.<br></div><div><br></div><div>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.). </div><div>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).<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>Could someone tell whether or not TCP would be a future additional option for WireGuard, and why (not)?</div><div><br></div><div>Also, do you think there actually does exist a neat and fitting solution for the problems I described?</div><div><br></div><div>Kind regards,</div><div><br></div><div>Breus Blaauwendraad<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 25 Sep 2018 at 17:54, StarBrilliant <<a href="mailto:coder@poorlab.com" target="_blank">coder@poorlab.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Sep 25, 2018 at 1:17 PM KeXianbin(<a href="http://diyism.com" rel="noreferrer" target="_blank">http://diyism.com</a>)<br>
<<a href="mailto:kexianbin@diyism.com" target="_blank">kexianbin@diyism.com</a>> wrote:<br>
><br>
> Currently, I'm using udp2raw-tunnel to transform wireguard udp traffic into raw tcp (config files as follows),<br>
> It's very stable on my home network than using wireguard alone,<br>
> But if we can integrate RAW TCP feature into wireguard, it would significantly improve performance and stability for end users.<br>
><br>
><br>
> from: <a href="https://gist.github.com/diyism/1b80903a83776675031c73ae499438d8#file-wireguard_config-txt-L145" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>diyism/<wbr>1b80903a83776675031c73ae499438<wbr>d8#file-wireguard_config-txt-<wbr>L145</a><br>
><br>
> $wget <a href="https://github.com/wangyu-/udp2raw-tunnel/releases/download/20180830.2/udp2raw_binaries.tar.gz" rel="noreferrer" target="_blank">https://github.com/wangyu-/<wbr>udp2raw-tunnel/releases/<wbr>download/20180830.2/udp2raw_<wbr>binaries.tar.gz</a><br>
> $tar xzvf udp2raw_binaries.tar.gz<br>
> $sudo cp udp2raw_amd64 /usr/bin/<br>
> $sudo udp2raw_amd64 -c -l127.0.0.2:24448 -r<server ip>:24447 -a<br>
> $cat /etc/wireguard/wg0.conf<br>
> [Interface]<br>
> PrivateKey = <client privkey><br>
> Address = <a href="http://10.0.0.3/32" rel="noreferrer" target="_blank">10.0.0.3/32</a><br>
> ListenPort = 24447<br>
> MTU = 1300<br>
> PostUp = ip route add <a href="http://10.0.0.0/24" rel="noreferrer" target="_blank">10.0.0.0/24</a> dev wg0 && wg set wg0 peer <server pubkey> allowed-ips <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a><br>
> PostDown = ip route del <a href="http://10.0.0.0/24" rel="noreferrer" target="_blank">10.0.0.0/24</a><br>
><br>
> [Peer]<br>
> #10.0.0.1<br>
> PublicKey = <server pubkey><br>
> Endpoint = <a href="http://127.0.0.2:24448" rel="noreferrer" target="_blank">127.0.0.2:24448</a><br>
> #AllowedIPs = <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a><br>
><br>
> $sudo wg-quick down wg0 ; sudo wg-quick up wg0<br>
> $ping 10.0.0.1<br>
> 64 bytes from <a href="http://10.0.0.1" rel="noreferrer" target="_blank">10.0.0.1</a>: icmp_seq=2113 ttl=64 time=183 ms<br>
> $sudo ip route add <a href="http://104.24.0.0/16" rel="noreferrer" target="_blank">104.24.0.0/16</a> dev wg0<br>
> $ping <a href="http://myip.ipip.net" rel="noreferrer" target="_blank">myip.ipip.net</a><br>
> PING <a href="http://myip.ipip.net" rel="noreferrer" target="_blank">myip.ipip.net</a> (104.24.20.50) 56(84) bytes of data.<br>
> 64 bytes from 104.24.20.50 (104.24.20.50): icmp_seq=1 ttl=60 time=185 ms<br>
> $curl <a href="http://myip.ipip.net" rel="noreferrer" target="_blank">http://myip.ipip.net</a><br>
> IP：<server ip><br>
><br>
> #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.<br>
<br>
<br>
Hello Kexianbin,<br>
<br>
This is an UNOFFICIAL response to your question. (But I think the<br>
official developers may have similar answers.)<br>
<br>
Wireguard probably will not accept an official integration to udp2raw.<br>
The reasons are:<br>
<br>
1) Wireguard wants to keep their kernel part code minimized, therefore<br>
easy for security auditing, and less bugs.The UDP protocol is actually<br>
very simple and straightforward. (By the way, if you intended to use<br>
Wireguard in China, be informed that this is a protocol that is very<br>
easy to block by the ISP.)<br>
<br>
2) I have read the source code of udp2raw. To be frank, the code is of<br>
very low quality. For this reason, I don't think udp2raw would be<br>
integrated into Wireguard unless it's rewritten.<br>
<br>
3) Udp2raw is not suitable for everyone or for every country. For<br>
example udp2raw may have problems passing middleboxes, which is common<br>
among satellite ISPs in Oceania. Middleboxes break and resemble TCP<br>
segments thus make udp2raw literally unusable. Also it is not<br>
congestion friendly (by design), so a massive deployment may affect<br>
the global Internet ecology.<br>
<br>
However the good news is, Wireguard provides an open control interface<br>
(see <a href="https://www.wireguard.com/xplatform/" rel="noreferrer" target="_blank">https://www.wireguard.com/<wbr>xplatform/</a> ). By utilizing this<br>
interface, we can develop an alternate frontend application other than<br>
the official command "wg", that automatically sets up the kernel<br>
Wireguard kernel part and a userland udp2raw part, packaged as one<br>
application.<br>
<br>
<br>
My words for Wireguard developers:<br>
<br>
1) In case you may not know the udp2raw protocol, here is a<br>
description. Some ISPs in certain countries have strange QoS strategy<br>
that deprioritize UDP packets during network congestion, resulting a<br>
50% loss rate or more for UDP. The udp2raw protocol simulates a<br>
three-way TCP handshake and add TCP header to UDP packets so they will<br>
not be dropped. This protocol does not do congestion control or rate<br>
control, neither does it understand any TCP semantics. It's a dirty<br>
hack for dirty ISP, not suitable for everyone, but overwhelmingly<br>
useful in certain countries.<br>
<br>
2) Wireguard currently does not support binding to localhost. This is<br>
required for any third-party plugins upon Wireguard to work. We might<br>
need to consider binding to localhost an important feature to go in<br>
the near future.<br>
<br>
<br>
Best regards,<br>
StarBrilliant<br>
______________________________<wbr>_________________<br>
WireGuard mailing list<br>
<a href="mailto:WireGuard@lists.zx2c4.com" target="_blank">WireGuard@lists.zx2c4.com</a><br>
<a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer" target="_blank">https://lists.zx2c4.com/<wbr>mailman/listinfo/wireguard</a><br>
</blockquote></div>
<br>______________________________<wbr>_________________<br>
WireGuard mailing list<br>
<a href="mailto:WireGuard@lists.zx2c4.com">WireGuard@lists.zx2c4.com</a><br>
<a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer" target="_blank">https://lists.zx2c4.com/<wbr>mailman/listinfo/wireguard</a><br>
<br></blockquote></div></div>