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" 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 wrote: > >> On Tue, Sep 25, 2018 at 1:17 PM KeXianbin(http://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:24447 -a >> > $cat /etc/wireguard/wg0.conf >> > [Interface] >> > PrivateKey = >> > 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 > pubkey> allowed-ips 0.0.0.0/0 >> > PostDown = ip route del 10.0.0.0/24 >> > >> > [Peer] >> > #10.0.0.1 >> > PublicKey = >> > 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： >> > >> > #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 > >