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

StarBrilliant coder at poorlab.com
Tue Sep 25 17:52:21 CEST 2018

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/1b80903a83776675031c73ae499438d8#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 =
> ListenPort = 24447
> MTU = 1300
> PostUp = ip route add dev wg0 && wg set wg0 peer <server pubkey> allowed-ips
> PostDown = ip route del
> [Peer]
> #
> PublicKey = <server pubkey>
> Endpoint =
> #AllowedIPs =
> $sudo wg-quick down wg0 ; sudo wg-quick up wg0
> $ping
> 64 bytes from icmp_seq=2113 ttl=64 time=183 ms
> $sudo ip route add dev wg0
> $ping myip.ipip.net
> PING myip.ipip.net ( 56(84) bytes of data.
> 64 bytes from ( 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

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,

More information about the WireGuard mailing list