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 WireGuard configuration files 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 and chain additional servers to reach new networks. Access to the Wiretap network can also be shared with other clients.
- Download binaries from the releases page, one for your client machine and one for your server (if different os/arch)
- Run
./wiretap configure --port <port> --endpoint <socket> --routes <routes>
with the appropriate arguments - Import the resulting
wiretap.conf
andwiretap_relay.conf
files into WireGuard on the client machine - Copy and paste the server command output that best suits your target system into Wiretap on the server machine
- Add more servers and clients as needed with the
add
subcommand
- WireGuard - https://www.wireguard.com/install/
- Privileged access to configure WireGuard
- Bidirectional UDP access to client on one port. By default the server initiates the handshake to the client because it is more likely to have outbound UDP than inbound, but the reverse is easily configurable
While not ideal, Wiretap can still work with TCP instead of UDP. See the experimental TCP Tunneling section for a step-by-step guide.
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.20) from https://go.dev/dl/ and use the provided Makefile.
On the client machine, run Wiretap in configure mode to build a config
./wiretap configure --endpoint <socket> --port <port> --routes <routes>
--endpoint
tells the Server how to connect to the Client's Relay interface (the E2EE interfaces already know how to talk to each other if the Relay interfaces are working)--port
sets the listening port of the Client's Relay interface. It's set to the same port specified in the--endpoint
socket argument by default. Note that the E2EE listening port (51821) does not need to be accessible to the Server--routes
is the equivalent of WireGuard's AllowedIPs setting. This tells the Client to route traffic that matches these IP ranges through Wiretap.
Following the example in the diagram:
./wiretap configure --endpoint 1.3.3.7:1337 --port 1337 --routes 10.0.0.0/24
Configurations successfully generated.
Import the two configs into WireGuard locally and pass the arguments below to Wiretap on the remote machine.
config: wiretap_relay.conf
────────────────────────────────
[Interface]
PrivateKey = cGsJkcVIajZW7kfN5SMwijmMx59ke7FZ+qdZOcsNDE0=
Address = 172.16.0.1/32
Address = fd:16::1/128
ListenPort = 1337
[Peer]
PublicKey = kMj7HwfYYFO/XEHNFK2kz9cBd7vTHk63fhygyuYLMzI=
AllowedIPs = 172.17.0.0/24,fd:17::/48
────────────────────────────────
config: wiretap.conf
────────────────────────────────
[Interface]
PrivateKey = YCTRVwB4xOEcBtifVmhjMhRYL7+DOlDP5VdHZGclZGg=
Address = 172.19.0.1/32
Address = fd:19::1/128
ListenPort = 51821
MTU = 1340
[Peer]
PublicKey = 3ipWthpJzqVo5wcb1TSDS1M8YOiBQYBPmbj3mVD/5Fg=
AllowedIPs = 10.0.0.0/24,::2/128
Endpoint = 172.17.0.2:51821
────────────────────────────────
server config: wiretap_server.conf
server command:
POSIX Shell: WIRETAP_RELAY_INTERFACE_PRIVATEKEY=WDH8F6rSUZDyQFfEsRjWLCnapU254qrSAfpGyGs+N1Y= WIRETAP_RELAY_INTERFACE_PORT=51820 WIRETAP_RELAY_PEER_PUBLICKEY=Ta75SvIb2v2V8EDo6oE2Fvsys/CNlkzW+aPjxdY+Dlc= WIRETAP_RELAY_PEER_ENDPOINT=1.3.3.7:1337 WIRETAP_E2EE_INTERFACE_PRIVATEKEY=GKzGBe3qS7JuLp0vMAErBW6lAewvmFowCIbcgwzComg= WIRETAP_E2EE_PEER_PUBLICKEY=cXddDGWCzd5igux4FDv97XBsyLH0SRPehhTz3E2IXBM= WIRETAP_E2EE_PEER_ENDPOINT=172.16.0.1:51821 ./wiretap serve
PowerShell: $env:WIRETAP_RELAY_INTERFACE_PRIVATEKEY="WDH8F6rSUZDyQFfEsRjWLCnapU254qrSAfpGyGs+N1Y="; $env:WIRETAP_RELAY_INTERFACE_PORT="51820"; $env:WIRETAP_RELAY_PEER_PUBLICKEY="Ta75SvIb2v2V8EDo6oE2Fvsys/CNlkzW+aPjxdY+Dlc="; $env:WIRETAP_RELAY_PEER_ENDPOINT="1.3.3.7:1337"; $env:WIRETAP_E2EE_INTERFACE_PRIVATEKEY="GKzGBe3qS7JuLp0vMAErBW6lAewvmFowCIbcgwzComg="; $env:WIRETAP_E2EE_PEER_PUBLICKEY="cXddDGWCzd5igux4FDv97XBsyLH0SRPehhTz3E2IXBM="; $env:WIRETAP_E2EE_PEER_ENDPOINT="172.16.0.1:51821"; .\wiretap.exe serve
Config File: ./wiretap serve -f wiretap_server.conf
Note
Wiretap uses 2 WireGuard interfaces per node in order to safely and scalably chain together servers. This means your client will bind to more than one port, but only the Relay Interface port needs to be accessible by the Server. See the How It Works section for details. Use --simple
in both the config
command and the server's serve
command if your setup requires a single interface on the client
Note
The wiretap_server.conf file uses a notation unique to Wiretap. It cannot be used to start a wiretap server with wg-quick or other tools.
Tip
You can modify the AllowedIPs in the wiretap.conf file any time after generating the config files, just reload the config file with wg-quick down/up
after making the change. No changes are needed on the server to update them.
Install the resulting config either by copying and pasting the output or by importing the new wiretap.conf
and wiretap_relay.conf
files into WireGuard:
- If using a GUI, select the menu option similar to Import Tunnel(s) From File
- If you have
wg-quick
installed,sudo wg-quick up ./wiretap.conf
andsudo wg-quick up ./wiretap_relay.conf
Don't forget to disable or remove the tunnels when you're done (e.g., sudo wg-quick down ./wiretap.conf
and sudo wg-quick down ./wiretap_relay.conf
)
On the remote machine, upload the binary and then copy the command with the private and public keys to start Wiretap in server mode:
$env:WIRETAP_RELAY_INTERFACE_PRIVATEKEY="WDH8F6rSUZDyQFfEsRjWLCnapU254qrSAfpGyGs+N1Y="; $env:WIRETAP_RELAY_PEER_PUBLICKEY="Ta75SvIb2v2V8EDo6oE2Fvsys/CNlkzW+aPjxdY+Dlc="; $env:WIRETAP_RELAY_PEER_ENDPOINT="1.3.3.7:1337"; $env:WIRETAP_E2EE_INTERFACE_PRIVATEKEY="GKzGBe3qS7JuLp0vMAErBW6lAewvmFowCIbcgwzComg="; $env:WIRETAP_E2EE_PEER_PUBLICKEY="cXddDGWCzd5igux4FDv97XBsyLH0SRPehhTz3E2IXBM="; $env:WIRETAP_E2EE_PEER_ENDPOINT="172.16.0.1:51821"; .\wiretap.exe serve
There are two other ways to pass arguments to the server:
- With a config file:
-f wiretap_server.conf
- The legacy method of passing command line arguments (
--endpoint 1.3.3.7:1337 ...
). Be aware that this method exposes arguments to other users on the system. A compromised private key can be used to connect to the client as a peer and/or decrypt traffic
Confirm that the relay interfaces on the client and server have successfully completed a handshake. The client should see successful handshakes in whatever WireGuard interface is running. If using the command-line tools, check with wg show
. By default the E2EE handshake will not occur until the client sends data.
Now the client should be able to interact with the routes
specified in the configure
command!
The add server
subcommand is meant to extend the Wiretap network to reach new areas of a target network. One client and at least one server must be configured and deployed before adding another server. Servers can attach to any other server or the client itself.
Warning
All servers must be deployed before adding additional clients. Additionally, if a Wiretap server process exits or dies for any reason it will not remember any added clients when you restart it.
You can view the state of the network and see API addresses with ./wiretap status
./wiretap status
╭────────────────────────╮
│ Wiretap Network Status │
╰────────────┬───────────╯
│
╭──────────┴──────────╮
│client │
│ │
│ relay: Ta75SvIb... │
│ e2ee: cXddDGWC... │
│ │
╰──────────┬──────────╯
│
╭──────────┴──────────╮
│server │
│ relay: kMj7HwfY... │
│ e2ee: 3ipWthpJ... │
│ │
│ api: ::2 │
│ routes: 10.0.0.0/24 │
╰─────────────────────╯
If you plan to attach a server directly to the client, the status command just confirms that everything is working as expected and the network layout is correct. If you want to attach a server to another server you must also specify the existing server's API address in your add server
command with the --server-address
argument; this API address must reference the same Wiretap server that the new server will connect to via the --endpoint
socket.
In the example, we will want to attach to the server with API address ::2
, which is listening on 10.0.0.2:51820
. This command will generate a configuration you can deploy to the new server (through environment variables or a config), just like with the configure
command:
./wiretap add server --server-address ::2 --endpoint 10.0.0.2:51820 --routes 10.0.1.0/24
Configurations successfully generated.
Import the updated config(s) into WireGuard locally and pass the arguments below to Wiretap on the new remote server.
config: wiretap.conf
────────────────────────────────
[Interface]
PrivateKey = YCTRVwB4xOEcBtifVmhjMhRYL7+DOlDP5VdHZGclZGg=
Address = 172.19.0.1/32
Address = fd:19::1/128
ListenPort = 51821
MTU = 1340
[Peer]
PublicKey = 3ipWthpJzqVo5wcb1TSDS1M8YOiBQYBPmbj3mVD/5Fg=
AllowedIPs = 10.0.0.0/24,::2/128
Endpoint = 172.17.0.2:51821
[Peer]
PublicKey = YOVI9nOvjOWTre0OVzrjx8qsYRgyuSLWndv28S2udiQ=
AllowedIPs = 10.0.1.0/24,::3/128
Endpoint = 172.17.0.3:51821
────────────────────────────────
server config: wiretap_server_1.conf
POSIX Shell: WIRETAP_RELAY_INTERFACE_PRIVATEKEY=sLERnxT2+VdwwcJOTUHK5fa5sIN7oJ1Jww9n42txrEQ= WIRETAP_RELAY_INTERFACE_PORT=51820 WIRETAP_RELAY_INTERFACE_IPV4=172.17.0.3 WIRETAP_RELAY_INTERFACE_IPV6=fd:17::3 WIRETAP_RELAY_PEER_PUBLICKEY=kMj7HwfYYFO/XEHNFK2kz9cBd7vTHk63fhygyuYLMzI= WIRETAP_RELAY_PEER_ALLOWED=172.16.0.0/16,fd:16::/40 WIRETAP_RELAY_PEER_ENDPOINT=10.0.0.2:51820 WIRETAP_E2EE_INTERFACE_PRIVATEKEY=uF79x5X8q3Vd/ajWMR5XyDt/haahtpy5PkJj9b+OaUE= WIRETAP_E2EE_INTERFACE_API=::3 WIRETAP_E2EE_PEER_PUBLICKEY=cXddDGWCzd5igux4FDv97XBsyLH0SRPehhTz3E2IXBM= WIRETAP_E2EE_PEER_ENDPOINT=172.16.0.1:51821 ./wiretap serve
PowerShell: $env:WIRETAP_RELAY_INTERFACE_PRIVATEKEY="sLERnxT2+VdwwcJOTUHK5fa5sIN7oJ1Jww9n42txrEQ="; $env:WIRETAP_RELAY_INTERFACE_PORT="51820"; $env:WIRETAP_RELAY_INTERFACE_IPV4="172.17.0.3"; $env:WIRETAP_RELAY_INTERFACE_IPV6="fd:17::3"; $env:WIRETAP_RELAY_PEER_PUBLICKEY="kMj7HwfYYFO/XEHNFK2kz9cBd7vTHk63fhygyuYLMzI="; $env:WIRETAP_RELAY_PEER_ALLOWED="172.16.0.0/16,fd:16::/40"; $env:WIRETAP_RELAY_PEER_ENDPOINT="10.0.0.2:51820"; $env:WIRETAP_E2EE_INTERFACE_PRIVATEKEY="uF79x5X8q3Vd/ajWMR5XyDt/haahtpy5PkJj9b+OaUE="; $env:WIRETAP_E2EE_INTERFACE_API="::3"; $env:WIRETAP_E2EE_PEER_PUBLICKEY="cXddDGWCzd5igux4FDv97XBsyLH0SRPehhTz3E2IXBM="; $env:WIRETAP_E2EE_PEER_ENDPOINT="172.16.0.1:51821"; .\wiretap.exe serve
Config File: ./wiretap serve -f wiretap_server_1.conf
The client's E2EE configuration will be modified to allow communication with the new server, so you need to reimport it. For example, wg-quick down ./wiretap.conf
and wg-quick up ./wiretap.conf
. If you are attaching a server directly to the client, the Relay interface will also need to be refreshed.
Now you can use any of the server command options to deploy Wiretap to the new server. It will then connect to the already existing server.
At this point the new routes should be usable! You can confirm that everything looks correct with wiretap status
:
./wiretap status
╭────────────────────────╮
│ Wiretap Network Status │
╰────────────┬───────────╯
│
╭──────────┴──────────╮
│client │
│ │
│ relay: Ta75SvIb... │
│ e2ee: cXddDGWC... │
│ │
╰──────────┬──────────╯
│
╭──────────┴──────────╮
│server │
│ relay: kMj7HwfY... │
│ e2ee: 3ipWthpJ... │
│ │
│ api: ::2 │
│ routes: 10.0.0.0/24 │
╰──────────┬──────────╯
│
╭──────────┴──────────╮
│server │
│ relay: GMkUzfDy... │
│ e2ee: YOVI9nOv... │
│ │
│ api: ::3 │
│ routes: 10.0.1.0/24 │
╰─────────────────────╯
Now the client can reach 10.0.0.0/24
and 10.0.1.0/24
. From here you can attach more servers to any of the three nodes.
The add client
subcommand can be used to share access to the Wiretap network with others.
Warning
All servers must be deployed before adding additional clients. Additionally, if a Wiretap server process exits or dies for any reason it will not remember any added clients when you restart it.
Adding a client is very similar to the other commands. It will generate a wiretap.conf
and wiretap_relay.conf
for sharing. Make sure that all of the first-hop servers (any server directly attached to the original client) can reach or be reached by the new client or else the new client won't have access to that chain of servers. Once you get the endpoint information from whoever will be running the new client run:
./wiretap add client --endpoint 1.3.3.8:1337 --port 1337
Configurations successfully generated.
Have a friend import these files into WireGuard
config: wiretap_relay_1.conf
────────────────────────────────
[Interface]
PrivateKey = UEgzp6zv8lNnpih31RfzKsz+BLyN5qNfh6PbCdF1Cmg=
Address = 172.16.0.2/32
Address = fd:16::2/128
ListenPort = 1337
[Peer]
PublicKey = kMj7HwfYYFO/XEHNFK2kz9cBd7vTHk63fhygyuYLMzI=
AllowedIPs = 172.17.0.0/24,fd:17::/48
────────────────────────────────
config: wiretap_1.conf
────────────────────────────────
[Interface]
PrivateKey = 8AhL1kDjwBn/IoY4KLd5mMP4GQsyMYNsqYm3aM/bHnE=
Address = 172.19.0.2/32
Address = fd:19::2/128
ListenPort = 51821
MTU = 1340
[Peer]
PublicKey = 3ipWthpJzqVo5wcb1TSDS1M8YOiBQYBPmbj3mVD/5Fg=
AllowedIPs = 10.0.0.0/24,::2/128
Endpoint = 172.17.0.2:51821
[Peer]
PublicKey = YOVI9nOvjOWTre0OVzrjx8qsYRgyuSLWndv28S2udiQ=
AllowedIPs = 10.0.1.0/24,::3/128
Endpoint = 172.17.0.3:51821
────────────────────────────────
Send these files and have the recipient import them into WireGuard to have access to everything in the Wiretap network! By default the routes (AllowedIPs) are copied over, but can be modified by the recipient as needed.
Warning Port forwarding exposes services on your local machine to the remote network, use with caution
You can expose a service on the client by using the expose
subcommand. For example, to allow remote systems to access port 80/tcp on your local machine, you could run:
./wiretap expose --local 80 --remote 8080
Now all Wiretap servers will be bound to port 8080/tcp and proxy connections to your services on port 80/tcp. By default this uses IPv6, so make sure any listening services support IPv6 as well.
To configure Wiretap to only use IPv4, use the configure
subcommand's --disable-ipv6
option.
Warning
If a Wiretap server process exits or dies for any reason it will not remember ports it was previously exposing. You will need to re-expose any ports you configured with this command.
To dynamically forward all ports using SOCKS5:
./wiretap expose --dynamic --remote 8080
All servers will spin up a SOCKS5 server on port 8080 and proxy traffic to your local machine and can be used like this:
curl -x socks5:https://<server-ip>:8080 https://<any-ip>:1337
The destination IP will be rewritten by the server so you can put any address.
Use ./wiretap expose list
to see all forwarding rules currently configured.
Use ./wiretap expose remove
with the same arguments used in expose
to delete a rule. For example, to remove the SOCKS5 example above:
./wiretap expose remove --dynamic --remote 8080
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 and https://github.com/nicocha30/ligolo-ng work, but relies on WireGuard as the tunneling mechanism rather than SSH or TLS.
To build secure and scalable tunnels across multiple hops, each node in the Wiretap network has two interfaces: Relay and E2EE (end-to-end encrypted). The Relay nodes 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 contents can be decrypted by only that interface. There are two layers of WireGuard encapsulation between any two nodes.
./wiretap --help --show-hidden
Usage:
wiretap [flags]
wiretap [command]
Available Commands:
add Add peer to wiretap
configure Build wireguard config
expose Expose local services to servers
help Help about any command
ping Ping wiretap server API
serve Listen and proxy traffic into target network
status Show peer layout
Flags:
-h, --help help for wiretap
-H, --show-hidden show hidden flag options
-v, --version version for wiretap
Use "wiretap [command] --help" for more information about a command.
- Network
- IPv4
- IPv6
- ICMPv4: Echo requests and replies
- ICMPv6: Echo requests and replies
- Transport
- TCP
- Transparent connections
- RST response when port is unreachable
- Reverse Port Forward
- Reverse Socks5 Support
- UDP
- Transparent "connections"
- ICMP Destination Unreachable when port is unreachable
- Reverse Port Forward
- TCP
- Application
- API internal to Wiretap for dynamic configuration
- Chain servers together to tunnel traffic through an arbitrary number of machines
- Add clients after deployment for multi-user support
The demo has four hosts and three networks for testing multi-hop/nested tunnels, but only the first target host is reached in the examples below.
┌──────────┐
│ 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 │
│ │
│ 10.3.0.4 ├┬───────────────────────┐
│ fd:3::4 --- |
└──────────┼│ │
││ target2 network │
││ 10.3.0.0/16,fd:3::/64 │
┌──────────┼│ │
│ 10.3.0.5 --- |
│ fd:3::5 ├┴───────────────────────┘
│ │
│ target2 │
└──────────┘
wiretap_demo.mp4
You have unprivileged access to the server host and want to reach the target host from the client host using Wiretap.
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
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 https://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 https://10.2.0.4
server$ curl https://10.2.0.4
Configure Wiretap from the client machine. Remember, --endpoint
is how the server machine should reach the client (IP:port) and --routes
determines which traffic is routed through Wiretap.
--endpoint
needs to be the client address and listening port:10.1.0.2:51820
- If no
--port
is specified, the client config will use the same port specified in theendpoint
argument as the listening port. In this example, that would be 51820. --routes
needs 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/32
here instead
./wiretap configure --endpoint 10.1.0.2:51820 --routes 10.2.0.0/16,fd:2::/64
Install the newly created WireGuard configs with:
wg-quick up ./wiretap_relay.conf
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:
WIRETAP_RELAY_INTERFACE_PRIVATEKEY=<key> WIRETAP_RELAY_PEER_PUBLICKEY=<key> WIRETAP_RELAY_PEER_ENDPOINT=10.1.0.2:51820 WIRETAP_E2EE_INTERFACE_PRIVATEKEY=<key> WIRETAP_E2EE_PEER_PUBLICKEY=<key> WIRETAP_E2EE_PEER_ENDPOINT=172.16.0.1:51821 ./wiretap serve
The WireGuard handshake should be complete. Confirm with:
wg show
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 https://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 https://10.2.0.4
curl https://[fd:2::4]
- Nmap
nmap 10.2.0.4 -v
nmap -6 fd:2::4 -v
- ICMP
ping 10.2.0.4
ping fd:2::4
- UDP
nmap -sU 10.2.0.4 -v
nmap -sU -6 fd:2::4 -v
Try to reach the second target by adding another server! You should be able to successfully run curl https://10.3.0.5
from the client host if performed correctly. The status
command should output something similar to:
╭────────────────────────╮
│ Wiretap Network Status │
╰────────────┬───────────╯
│
╭──────────┴──────────╮
│client │
│ │
│ relay: Ta75SvIb... │
│ e2ee: cXddDGWC... │
│ │
╰──────────┬──────────╯
│
╭──────────┴──────────╮
│server │
│ relay: kMj7HwfY... │
│ e2ee: 3ipWthpJ... │
│ │
│ api: ::2 │
│ routes: 10.2.0.0/16 │
╰──────────┬──────────╯
│
╭──────────┴──────────╮
│server │
│ relay: GMkUzfDy... │
│ e2ee: YOVI9nOv... │
│ │
│ api: ::3 │
│ routes: 10.3.0.0/16 │
╰─────────────────────╯
To bring down the WireGuard interfaces on the client machine, run:
wg-quick down ./wiretap_relay.conf
wg-quick down ./wiretap.conf
Warning
Performance will suffer, only use TCP Tunneling as a last resort
If you have no outbound or inbound 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 server
on the wiretap client system, specifying a TCP port you can reach from the server system:
./chisel server --port 8080
Note
In this example we run the chisel server ...
command on the Wiretap client, and chisel client ...
command on a Wiretap server. This is because the chisel "client" always tries to reach out and connect to the chisel "server," whereas Wiretap clients and servers are defined by their functionality since either can initiate the connection.
In this example, we're connecting chisel to the listener on 8080 (on the wiretap client) and forwarding 61820/udp from the Wiretap server to 51820 (any interface) on the Wiretap client:
./chisel client <wiretap client address>:8080 61820:0.0.0.0:51820/udp
8080
is the chisel listening port specified in thechisel server
command above61820
is the localhost port on the Wiretap server that will be forwarded back to the Wiretap client.51820
is the port where the Wiretap client is listening (by default is the same port you specified in the--endpoint
argument in the initialwiretap configure
command)
Finally, run Wiretap on the remote server system with the forwarded localhost port in the --endpoint
:
WIRETAP_RELAY_INTERFACE_PRIVATEKEY=<key> WIRETAP_RELAY_PEER_PUBLICKEY=<key> WIRETAP_E2EE_INTERFACE_PRIVATEKEY=<key> WIRETAP_E2EE_PEER_PUBLICKEY=<key> WIRETAP_E2EE_PEER_ENDPOINT=172.16.0.1:51821 ./wiretap serve --endpoint localhost:61820
Note
Clients added to arbitrary servers do not currently have the same capabilities as clients added to first-hop servers (the default)
Clients can be attached to any server in the network by using the --server-address <api-address>
argument when running wiretap add client
. This allows a client on a different network than the first client to still gain access to all of the Wiretap network's routes. But this has some limitations.
In this example, a new client (C2) is added to the second server in the right branch of a Wiretap network (S4). This client will only be able to access routes via the right branch of the network (S3 and S4) and not the left branch (S1 or S2) because the branches are only joined through an existing client (C1), which does not route traffic from other clients:
┌──────┐
│ C1 │
└┬────┬┘
│ │
┌─────┴┐ ┌┴─────┐
│ S1 │ │ S3 │
└──┬───┘ └──┬───┘
│ │
┌──┴───┐ ┌──┴───┐
│ S2 │ │ S4 ◄───────┐
└──────┘ └──────┘ │
┌──┴───┐
│ C2 │
└──────┘
You may also need to manually edit the resulting wiretap.conf
for the new client to remove any AllowedIPs
entries that already exist in the new client's host routing table. If the server that the client is attaching to has a route for 10.2.0.0/16, but the Client already has that route (because that's where it lives), then remove the 10.2.0.0/16
entry from the wiretap.conf
file before importing into WireGuard. Leave the API address and any other routes you wish to access.