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.
# 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
wgproxywgproxy 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:
- If a session exists, packets must originate from this current session, or
- 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 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.