Wiretap: a WireGuard tunnel that needs no elevated privileges on the server

The privilege problem, and the user-space answer

Wiretap is a transparent, VPN-like proxy server that tunnels traffic via WireGuard and requires no special privileges to run. The reasoning is laid out plainly. Traditional VPN server software cannot be installed by unprivileged users because VPNs rely on dangerous operations like changing network routes and working with raw packets. Wiretap bypasses this by rerouting traffic to a user-space TCP/IP network stack, where a listener accepts connections on behalf of the true destination, and it then creates a new connection to the true destination through the native network stack and copies data between the two, effectively connecting the client to the destination. The README compares this to sshuttle and ligolo-ng, with the difference that Wiretap relies on WireGuard as the tunnelling mechanism rather than SSH or TLS. The primary language is Go, and the last push was on 2026-09-08 with releases v0.9.0 on 2026-02-03 and v0.8.1 on 2026-01-22.

Client and server mean the opposite of what you expect

The terminology is the first thing to understand, and the README flags it in a callout. A Wiretap Server is any machine where a Wiretap binary is running the `serve` command, and servers receive and relay network traffic on behalf of clients, acting like a VPN exit node. A Wiretap Client is any machine running the WireGuard configurations necessary to send and receive traffic through a server, and it functions much like a client in a VPN connection. The important note is that, unlike the typical use of client and server terms in networking, Wiretap's terms have nothing to do with which machine listens for or initiates the initial connection. The client is the machine holding the routes and reaching out to the network, and the server is the machine sitting on the network you want to reach. The client also needs privileged access to configure WireGuard interfaces, while the server needs only the ability to get the binary onto the system and run it.

The network requirements, and the firewall subtlety

The environment requirement is bidirectional UDP communication between the server and the client on one port, and any firewalls between them must allow at least one machine to initiate a UDP connection to the other. The machine receiving the initial connection, which is the client by default, must be able to listen for UDP connections on a port that the initiating machine can connect to. The default is that the server initiates the handshake to the client, because the server is more likely to have outbound UDP allowed through a firewall than inbound UDP, and the reverse is configurable through the Outbound Connections section. This is the single most common deployment failure, since a server on a host with restrictive inbound rules and a client behind NAT will not connect until the direction is flipped. The README also notes that Wiretap can work with TCP instead of UDP, while calling that not ideal and pointing at the experimental section for the details.

Two interfaces per node, and what the relay can and cannot see

To build secure and scalable tunnels across multiple hops, each node in the Wiretap network has two interfaces, Relay and E2EE, meaning end-to-end encrypted. The Relay interfaces simply relay packets between nodes but cannot see the plaintext. When a Relay node sees a packet that does not match routing rules, it forwards it to its own E2EE interface where the contents can be decrypted by only that interface. The consequence is that there are two layers of WireGuard encapsulation between any two nodes. That is the design that makes a multi-hop chain safe to operate, since an intermediate node that only holds a Relay interface cannot read the traffic passing through it, and the operator of a relay never holds the key material for the end-to-end leg. It is also the reason the model uses a routing table rather than a tunnel configuration, since the decision of what to relay and what to decrypt is made per node.

The command surface, and the quick start

The binary exposes a small set of subcommands:

./wiretap --help --show-hidden

with `add` to add a peer to wiretap, `configure` to build the WireGuard config, `expose` to expose local services to servers, `ping` to ping the wiretap server API, `serve` to listen and proxy traffic into the target network, and `status` to show the peer layout. The quick start is six steps. You download binaries from the releases page, one for each machine, and copy the Wiretap binary onto the server. On the client you run `./wiretap configure --endpoint <IP>:<port> --routes <CIDRs>`. You copy the server command output that best suits the server OS and run it there. On the client you then run `sudo wg-quick up ./wiretap_relay.conf && sudo wg-quick up ./wiretap.conf` to create the WireGuard interfaces. You confirm the handshake completed for both configs with `sudo wg show`. And optionally you add more servers and clients with the `wiretap add` command. The `expose` command is the port forwarding path, with `list` and `remove` to manage the exposed services.

The test environment, and what it models

The compose file in the repository is a worked example of a three-node topology rather than a deployment recipe, and the diagram in its comment header is worth reading. There is a client, a server and two targets, joined by three IPv4 and IPv6 networks, 10.1.0.0/16 and fd:1::/64 for the exposed network, 10.2.0.0/16 and fd:2::/64 for the target network, and 10.3.0.0/16 and fd:3::/64 for the second target network. The client and server both get the `NET_ADMIN` and `SYS_MODULE` capabilities, which is a detail worth noting because the whole point of Wiretap is that the server does not need elevated privileges, so those capabilities in the test harness are there for the client side and for the WireGuard interface creation. The server publishes port 6060. The compose file is the clearest available description of how the pieces relate, and it is a good thing for a reader to have in the repository rather than only in a wiki.

Editorial conclusion

Adopt Wiretap if you need to reach a network from a host you cannot reconfigure, because the server side runs unprivileged and the transport is WireGuard rather than a bespoke protocol. Skip it if you need raw packet capture, ICMP or other protocols a user-space stack will not carry, since the whole design routes TCP through a proxy rather than forwarding packets. Before you deploy, note that the machine receiving the initial connection must be able to listen for UDP, that the client does need privileged access to configure WireGuard interfaces, and that the TCP tunnelling mode is documented as experimental.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. sandialabs/wiretap on GitHub