Private VPN Gateway as a Tor Hidden Service: Layered Anonymity

The architecture: WireGuard VPN server bound to localhost, Tor hidden service forwarding to WireGuard's UDP port, clients connect to WireGuard via Tor using udp-over-tcp encapsulation (since Tor does not natively support UDP). Use cases: (1) team shared exit IP - multiple team members connect via the same .onion VPN gateway and exit from the same IP, useful for IP whitelist authentication scenarios, (2) bypass Tor exit blocking - applications that block Tor exit IPs can be accessed through a personal VPN gateway whose IP is not public and not associated with Tor, (3) WireGuard over Tor for contexts where having WireGuard traffic visible is acceptable but the VPN server's IP should be private. Note: Tor does not natively support UDP. WireGuard uses UDP. This requires a udp-over-tcp wrapper (wstunnel, udptunnel) or configuring WireGuard to work over TCP via an additional transport layer.

The implementation requires bridging WireGuard's UDP to TCP (which Tor supports). Use wstunnel: on the server, install wstunnel and run: wstunnel server --server ws://127.0.0.1:8080 --toAddr 127.0.0.1:51820 (where 51820 is WireGuard's UDP port). This creates a WebSocket server on TCP port 8080 that forwards to WireGuard's UDP port. Configure the Tor hidden service to point to port 8080: HiddenServicePort 80 127.0.0.1:8080. On the client side, run wstunnel client --server ws://yourgateway.onion -L UDP://127.0.0.1:51820 (routing through Tor SOCKS: wstunnel client --proxy socks5://127.0.0.1:9050 --server ws://yourgateway.onion -L UDP://127.0.0.1:51820). Configure WireGuard client to use 127.0.0.1:51820 as the peer endpoint.

Configure WireGuard on the server to listen only on localhost: [Interface] Address = 10.0.0.1/24, ListenPort = 51820. Add peers with their public keys: [Peer] PublicKey = ..., AllowedIPs = 10.0.0.2/32. Set up NAT for VPN traffic: iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE and iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT. Enable IP forwarding: sysctl -w net.ipv4.ip_forward=1. The VPN server's eth0 IP is the exit IP for all VPN traffic - this IP is not revealed to clients who connect via Tor (they see only the .onion address). Generate WireGuard key pairs for each client: wg genkey | tee privatekey | wg pubkey > publickey. Add each client's public key to the server's WireGuard configuration as a peer.

The security properties of Tor over personal VPN gateway: (1) the VPN server operator (you, since it is your private gateway) does not know the connecting client's IP because the connection comes through Tor, (2) the VPN server's IP is not revealed to the client because the client connects via the .onion address, (3) the exit traffic appears from the VPN server's IP, not from a Tor exit relay. Threat model gaps: Tor circuit traffic analysis can potentially link the client to the Tor connection to the .onion gateway. The VPN exit IP is fixed and potentially identifiable. For high-security scenarios where the exit IP must be anonymous: use a standard Tor exit relay (random exit) instead of a personal VPN gateway. The personal VPN gateway architecture is best for the specific use case of team IP whitelisting or Tor exit bypass, not for strong exit anonymity.

For team use of the private VPN gateway: generate unique WireGuard key pairs for each team member, add each member's public key to the server with a unique IP (10.0.0.2/32, 10.0.0.3/32, etc.). Each member uses their own private key in their WireGuard client configuration. To revoke access for a team member: remove their public key from the server's WireGuard configuration and run wg syncconf. Audit which team members are connected: wg show lists active peers with last handshake time and transferred bytes. For logging access: configure WireGuard's logging at the kernel level (wg-kernel with trace logging) or use iptables logging rules on the VPN subnet traffic. Each peer's IP within the VPN subnet (10.0.0.X) can be used in iptables rules for per-user traffic accounting.