wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: wireguard@lists.zx2c4.com
Subject: Userspace Networking Stack + WireGuard + Go
Date: Wed, 13 Jan 2021 17:04:29 +0100	[thread overview]
Message-ID: <X/8aDfdkod+rCPqK@zx2c4.com> (raw)


Sometimes people say things like, "I want to make an application that
connects to the server over WireGuard" or "I want to host this service
application behind WireGuard" or "I want this small utility to initiate
an SSH connection to a specific server over WireGuard." The usual answer
to this is to simply bring up a WireGuard interface on the computer, and
then do networking as usual. And making WireGuard easy enough that
people can pull up ad-hoc interfaces trivially has been a big motivating
factor for the simplicity of the tooling, such as `ip link add wg0 type
wireguard && wg set wg0 ...` and similar commands.

On Linux, adding an interface is easy to do and is a solution that fits
nearly all circumstances. Even if you're unprivileged and want a
WireGuard interface for just a single application that's bound to the
lifetime of that application, you can still use WireGuard's normal
kernel interface inside of a user namespace + a network namespace, and
get a private process-specific WireGuard interface. Pretty cool stuff.
It's not like that's an accident, of course -- WireGuard was originally
developed with Linux's model in mind.

But not all operating systems are as neat as Linux. To that end, we've
tried very hard to make WireGuard integrate as natively as possible into
other operating systems, with native clients for every platform, as well
as APIs for every platform to allow application developers to embed
tunnels: https://www.wireguard.com/embedding/ . This is great and works
well. WireGuard's design centers around the "network interface" as the
central object, and that's what these libraries enable. But still, some
people do not want to think about network interfaces or operating
systems when writing code.

To that end, I've recently written some code that couples a userspace
networking stack (from gVisor) with a userspace WireGuard implementation
(from wireguard-go), along with a little custom DNS client
implementation, so that Go applications can use an in-process WireGuard
interface directly to make TCP and UDP connections and listeners. From
the operating system's point of view, the application just sends and
receives encrypted UDP packets, and never sees the inner TCP or UDP
packets or knows about WireGuard at all.

Here's a quick example of what's possible:

    package main

    import (


    func main() {
        tun, tnet, err := tun.CreateNetTUN(
        if err != nil {
        dev := device.NewDevice(tun, &device.Logger{log.Default(), log.Default(), log.Default()})

        client := http.Client{
            Transport: &http.Transport{
                DialContext: tnet.DialContext,
        resp, err := client.Get("https://www.zx2c4.com/ip")
        if err != nil {
        body, err := io.ReadAll(resp.Body)
        if err != nil {

This snippet prints out:

, because that HTTPS request is going through the demo box.

Other use cases of this include cloud VM providers to bundle an ssh
client directly into their tooling that connects to a "cloud private
network" over WireGuard. Or hosting utilities that allow people to run
web apps from their own computers that are then accessible on the
Internet by connecting in reverse through WireGuard. Or maybe other use

The API and the code is new, and potentially incomplete. Please take it
for a spin and let me know your feedback.


PS: While the gophers on the list might be happy about this, the
rustaceans may well be left wondering, "what about us?" I hope to have
some positive news about wireguard-rs not before too long.

             reply	other threads:[~2021-01-13 16:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13 16:04 Jason A. Donenfeld [this message]
2021-01-13 16:26 ` Userspace Networking Stack + WireGuard + Go Julian Orth
2021-01-13 16:33   ` network namespace wireguard routing [Was: Re: Userspace Networking Stack + WireGuard + Go] Jason A. Donenfeld
2021-01-13 16:40     ` Julian Orth
2021-01-13 16:46     ` Toke Høiland-Jørgensen
2021-01-13 16:49       ` Jason A. Donenfeld
2021-01-14 10:44         ` Toke Høiland-Jørgensen
2021-01-15  8:12   ` Userspace Networking Stack + WireGuard + Go Marc-André Lureau
2021-01-14 23:25 ` Jason A. Donenfeld

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:

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

  git send-email \
    --in-reply-to=X/8aDfdkod+rCPqK@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=wireguard@lists.zx2c4.com \


* 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).