wgproxy

Crates.iowgproxy
lib.rswgproxy
version0.3.0
created_at2026-01-14 00:58:21.296547+00
updated_at2026-01-20 19:36:59.089552+00
descriptionA tiny layer-4-proxy to bridge WireGuard®-like traffic via a jump-host
homepage
repositoryhttps://github.com/KizzyCode/WireguardRelay-rust
max_upload_size
id2041864
size50,040
Keziah Biermann (KizzyCode)

documentation

README

License BSD-2-Clause License MIT AppVeyor CI docs.rs crates.io Download numbers dependency status

wgproxy

Welcome to wgproxy 🎉

wgproxy is a tiny layer-4-proxy to bridge WireGuard®-like traffic via a jump-host. This is e.g. useful to bridge from IPv4-only networks to IPv6-only servers, or to route the traffic via specific gateways.

It basically works as a stateful NAT: A valid WireGuard handshake message is used to allocate a NAT-mapping, which in turn is used to forward/bridge packets between the client and the server.

Example

# Export the necessary environment variables
export WGPROXY_SERVER="my-wireguard-server.invalid:51820"
export WGPROXY_PUBKEY="<the base64 server public key>"

# Configure optional environment variables
export WGPROXY_LISTEN="[::]:51820"
export WGPROXY_TIMEOUT="60"
export WGPROXY_LOGLEVEL="2"

# Start the proxy
wgproxy

Security Model

wgproxy is an simple NAT, meaning that it does not decrypt the traffic or performs deep packet inspection beyond validating the handshake first message. If the relay is public, this means that it is potentially susceptible to be abused by rogue senders.

To prevent rogue packets from creating a new route, two criteria must be fulfilled:

  1. If a session exists, packets must originate from this current session, or
  2. If no session exists, the packet must be a valid handshake first message for the configured server public key.

If these criteria are not fulfilled, the packet is dropped. If no current session exists and the packet is a valid handshake first message, and a new session with a new client-route will be registered.

This means that the main security model depends on an attacker not knowing the server public key. If an attacker knows the server public key, or has captured a valid handshake packet to replay, they can use that to create new routes or hijack existing routes, rendering the relay unstable.

As WireGuard traffic is fully encrypted, it is not possible to perform a full traffic validation without decrypting the traffic on the relay. This security model is a best-effort approach to limit the impact of rogue packets without the need to escrow private keys and decrypt private traffic in transit.

Microsoft Windows Support

Microsoft Windows is not an officially supported target, and is not tested. While the application should compile and might work as expected, Windows networking has subtle differences and might cause weird errors.

Commit count: 16

cargo fmt