Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Datong Sun <dndx@idndx.com>
To: wireguard@lists.zx2c4.com
Subject: [TOOLS-ANN] Phantun - Run WireGuard over obfuscated TCP connections without the penalty of UDP over TCP (alternative to udp2raw)
Date: Thu, 21 Oct 2021 18:08:22 +0800	[thread overview]
Message-ID: <CAC=S+V8EsFWv0Y6TfzgiqNok04B87hcTdzk_WZ1mqexMQpBR2w@mail.gmail.com> (raw)

Hi everyone,

Apologize in advance if you have already saw my posting in the
WireGuard subreddit. I am posting here again in a hope more people
would find Phantun to be useful for their WireGuard setup and attract
more contributors.

I would like to share a tool that I developed for converting UDP based
connections to fake TCP connections in case UDP is unavailable or
throttled. I have been running the tool with multiple WireGuard setup
for a while and it has been very stable.

Note that I primarily developed Phantun to work with WireGuard in a
UDP restricted environment, but it will work with any other UDP based
protocol as well.

The project is called Phantun. Source code, binary releases and
detailed README are available at: https://github.com/dndx/phantun

In comparison to udp2raw, Phantun was designed to solve some of the
performance issues that I encountered while using udp2raw. In
particular, Phantun is able to utilize multiple CPU cores
simultaneously and have a more predictable MTU overhead, while having
a much leaner codebase and focus only on protocol obfuscation.

Note that this is very different from UDP in TCP which could cause
significant performance penalty because of TCP retransmission and
congestion controls. Phantun simply replaces the UDP header from
WireGuard to TCP header with some sequence number mangling and ACKing
so packets will be regarded by NAT devices and L4 firewalls as valid
packets of a TCP stream. Therefore, all of the desirable properties of
UDP such as or of order delivery are fully preserved. It also means
this protocol will only work between two Phantun instances and will
not work if the other end is a real TCP stack (e.g. when going through
L7 or SOCKS5 proxies).

Please share your feedback and feel free to contribute!

Best regards,
Datong

-- 
Datong Sun
dndx@idndx.com

                 reply	other threads:[~2021-10-25 15:55 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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='CAC=S+V8EsFWv0Y6TfzgiqNok04B87hcTdzk_WZ1mqexMQpBR2w@mail.gmail.com' \
    --to=dndx@idndx.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).