Wiretap is a transparent, VPN-like proxy server that tunnels traffic via WireGuard and requires no special privileges to run.
In this diagram, the client has generated and installed a WireGuard configuration file that will route traffic destined for 10.0.0.0/24 through a WireGuard interface. Wiretap is then deployed to the server with a configuration that connects to the client as a WireGuard peer. The client can then interact with resources local to the server as if on the same network.
Quick Start
- Download binaries from the releases page, one for your client machine and one for your server (if different os/arch)
- Run
./wiretap configure --portwith the appropriate arguments--endpoint --routes - Import the resulting
wiretap.conffile into WireGuard on the client machine - Copy and paste the arguments output from the configure command into Wiretap on the server machine
Requirements
Client System
- WireGuard – https://www.wireguard.com/install/
- Privileged access to configure WireGuard
Server System
- UDP access to client system’s WireGuard endpoint (i.e., UDP traffic can be sent out and come back on at least one port)
While not ideal, Wiretap can still work with outbound TCP instead of UDP. See the TCP Tunneling section for a step-by-step guide.
Installation
Grab a binary from the releases page. You may want two binaries if the OS/ARCH are different on the client and server machines.
If you want to compile it yourself or can’t find the OS/ARCH you’re looking for, install Go (>=1.19) from https://go.dev/dl/ and use the provided Makefile.
Usage
Configure
On the client machine, run Wiretap in configure mode to build a config
./wiretap configure --port 1337 --endpoint 1.3.3.7:1337 --routes 10.0.0.0/24
Configuration successfully generated.
Import the config into WireGuard locally and pass the arguments below to Wiretap on the remote machine.
config: wiretap.conf
────────────────────────────────
[Interface]
PrivateKey = qCvx4DBXqemoO8B7eRI2H9Em8zJn++rIBKO+F+ufQWE=
Address = 192.168.0.2/32
Address = fd::2/128
ListenPort = 1337
[Peer]
PublicKey = 6NxBlwJHujEFr5n9qvFAUyinj0l7Wadd/ZDQMCqTJAA=
AllowedIPs = 10.0.0.0/24,a::/128
────────────────────────────────
args: serve --private qGrU0juci5PLJ1ydSufE/UwlErL/bqfcz6uWil705UU= --public ZhRIAcGVwT7l9dhEXv7cvYKwLxOZJR4bgU4zePZaT04= --endpoint 1.3.3.7:1337
Install the resulting config either by copying and pasting the output or by importing the new wiretap.conf file into WireGuard:
- If using a GUI, select the menu option similar to Import Tunnel(s) From File
- If you have
wg-quickinstalled,sudo wg-quick up ./wiretap.conf
Don’t forget to disable or remove the tunnel when you’re done (e.g., sudo wg-quick down ./wiretap.conf)
Deploy
On the remote machine, upload the binary and then copy the command with the private and public keys to start Wiretap in server mode:
.wiretap.exe serve --private qGrU0juci5PLJ1ydSufE/UwlErL/bqfcz6uWil705UU= --public ZhRIAcGVwT7l9dhEXv7cvYKwLxOZJR4bgU4zePZaT04= --endpoint 1.3.3.7:1337
Confirm that the client and server have successfully completed the handshake. The client should see a successful handshake in whatever WireGuard interface is running. If using the command-line tools, check with wg show.
Add Peers (optional)
You can create new configurations after deployment for sharing access to the target network with others.
To test access to the Wiretap API running on the server, run:
response: pong
from: a::
time: 2.685600 milliseconds
A successful pong message indicates that the API is responsive and commands like add will now work.
Adding a peer is very similar to configuring Wiretap initially. It will generate a configuration file you can share, but it will not output arguments that need to be passed to the server because that information is passed via the API. If you’re generating a configuration for someone else, get their address information for the endpoint and port flags.
./wiretap add --port 1337 --endpoint 1.3.3.8:1337 --routes 10.0.0.0/24
Configuration successfully generated and pushed to server.
Import this config locally or send it to a friend.
config: wiretap_1.conf
────────────────────────────────
[Interface]
PrivateKey = UJsLCSTg6xqfrKJtXQioaek/mCj4gzOdUIrp/+NkJ3Q=
Address = 192.168.0.3/32
Address = fd::3/128
ListenPort = 1337
[Peer]
PublicKey = 7mVguCBt7qxMsjDHR7WzzzNXbyBi5Q35gMvyUxjWMWc=
AllowedIPs = 10.0.0.0/24,a::/128
────────────────────────────────
At this point, the server will attempt to reach out to the provided endpoint. Share the config file and have the recipient import it into WireGuard for Wiretap to connect.
Note
To add another peer on the same machine, you will need to specify an unused port, unused routes, and disable the API route.
Help
./wiretap --help --show-hidden
Usage:
wiretap [flags]
wiretap [command]
Available Commands:
add Add peer to wiretap
configure Build wireguard config
help Help about any command
ping Ping wiretap server API
serve Listen and proxy traffic into target network
Flags:
-h, --help help for wiretap
--show-hidden show hidden flag options
-v, --version version for wiretap
Use "wiretap [command] --help" for more information about a command.
Features
- Network
- IPv4
- IPv6
- ICMPv4: Echo requests and replies
- ICMPv6: Echo requests and replies
- Transport
- TCP
- Transparent connections
- RST response when port is unreachable
- UDP
- Transparent “connections”
- ICMP Destination Unreachable when port is unreachable
- TCP
- API
- API internal to Wiretap for dynamic configuration
- Add peers after deployment for multi-user support
Demo
The demo has three hosts and two networks:
┌──────────┐
│ client │
│ │
│ 10.1.0.2 │
│ fd:1::2 ├┬───────────────────────┐
├──────────┼│ exposed network │
├──────────┼│ 10.1.0.0/16,fd:1::/64 │
│ 10.1.0.3 ├┴───────────────────────┘
│ fd:1::3 │
│ │
│ server │
│ │
│ 10.2.0.3 │
│ fd:2::3 ├┬───────────────────────┐
├──────────┼│ target network │
├──────────┼│ 10.2.0.0/16,fd:2::/64 │
│ 10.2.0.4 ├┴───────────────────────┘
│ fd:2::4 │
│ │
│ target │
└──────────┘
Video
wiretap_demo.mp4
Step-By-Step
You have unprivileged access to the server host and want to reach the target host from the client host using Wiretap.
Setup
Clone this repo.
Start the demo containers with:
docker compose up --build
Open new tabs for interactive sessions with the client and server machines:
docker exec -it wiretap-client-1 bash
docker exec -it wiretap-server-1 bash
Observe Network Limitations
The target network, and therefore the target host, is unreachable from the client machine. Both the server and target hosts are running a web service on port 80, so try interacting with each of the services from each of the hosts:
Accessing the server’s web service from the client should work:
client$ curl http://10.1.0.3
Accessing the target web service from the client should not work, but doing the same thing from the server machine will:
# fails
client$ curl http://10.2.0.4
server$ curl http://10.2.0.4
Configure
Configure Wiretap from the client machine. Remember, --endpoint is how the server machine should reach the client and --routes determines which traffic is routed through Wiretap.
--endpointneeds to be the client address and the default WireGuard port:10.1.0.2:51820--routesneeds to be the subnet of the target network:10.2.0.0/16. But there is also an IPv6 subnet, so we should also putfd:2::/64. If you just wanted to route traffic to the target host, you could put10.2.0.4/32here instead
./wiretap_linux_amd64 configure --endpoint 10.1.0.2:51820 --routes 10.2.0.0/16,fd:2::/64
Install the newly created WireGuard config with:
wg-quick up ./wiretap.conf
Copy and paste the Wiretap arguments printed by the configure command into the server machine prompt. It should look like this:
The WireGuard handshake should be complete. Confirm with:
If the handshake was successful the client should be able to reach the target network transparently. Confirm by running the same test that failed before:
client$ curl http://10.2.0.4
That’s it! Try scanning, pinging, and anything else you can think of (please submit an issue if you think something should work but doesn’t!). Here are a few ideas:
- HTTP
curl http://10.2.0.4curl http://[fd:2::4]
- Nmap
nmap 10.2.0.4 -vnmap -6 fd:2::4 -v
- ICMP
ping 10.2.0.4ping fd:2::4
- UDP
nmap -sU 10.2.0.4 -vnmap -sU -6 fd:2::4 -v
Teardown
To bring down the WireGuard interface on the client machine, run:
wg-quick down ./wiretap.conf
How It Works
A traditional VPN can’t be installed by unprivileged users because VPNs rely on dangerous operations like changing network routes and working with raw packets.
Wiretap bypasses this requirement by rerouting traffic to a user-space TCP/IP network stack, where a listener accepts connections on behalf of the true destination. Then it creates a new connection to the true destination and copies data between the endpoint and the peer. This is similar to how https://github.com/sshuttle/sshuttle works, but relies on WireGuard as the tunneling mechanism rather than SSH.
Experimental
TCP Tunneling
Note
Performance will suffer, only use TCP Tunneling as a last resort
If you have no outbound UDP access, you can still use Wiretap, but you’ll need to tunnel WireGuard traffic through TCP. This should only be used as a last resort. From WireGuard’s Known Limitations page:
TCP Mode
WireGuard explicitly does not support tunneling over TCP, due to the classically terrible network performance of tunneling TCP-over-TCP. Rather, transforming WireGuard’s UDP packets into TCP is the job of an upper layer of obfuscation (see previous point), and can be accomplished by projects like udptunnel and udp2raw.
Another great tool that has similar cross-platform capabilities to Wiretap is Chisel. We can use chisel to forward a UDP port to the remote system over TCP. To use:
Run chisel se
