From 2106d073044f0bd0c1491cd4ccab312258e4fc0e Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 21 Mar 2026 08:39:38 +0000 Subject: [PATCH] Add source citations with markdown links to relay security note Link to WireGuard Cryptokey Routing docs, the WireGuard whitepaper, Pro Custodibus hub-and-spoke E2EE analysis, and Tailscale DERP relay documentation. https://claude.ai/code/session_01HD798u9s77s7ooQDHA6mGX --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 282d1d6..08dd99d 100644 --- a/README.md +++ b/README.md @@ -280,7 +280,7 @@ Each client only needs to define the publicly accessible servers/peers in its co In summary: only direct connections between clients should be configured, any connections that need to be bounced should not be defined as peers, as they should head to the bounce server first and be routed from there back down the vpn to the correct client. -**Important: traffic bounced through a relay server is not end-to-end encrypted between the two NAT-ed peers.** The relay server decrypts incoming traffic from one peer and re-encrypts it with the destination peer's key before forwarding. This means the relay server can see the plaintext VPN traffic passing through it. Each hop (A↔Relay, Relay↔B) is independently encrypted, but the relay acts as a trusted intermediary. If end-to-end encryption between NAT-ed peers is required, consider using an application-level encryption layer (e.g. TLS) on top of WireGuard, or a solution like Tailscale's DERP relays which forward opaque encrypted packets without decrypting them. +**Important: traffic bounced through a relay server is not end-to-end encrypted between the two NAT-ed peers.** The relay server decrypts incoming traffic from one peer and re-encrypts it with the destination peer's key before forwarding. This means the relay server can see the plaintext VPN traffic passing through it. Each hop (A↔Relay, Relay↔B) is independently encrypted, but the relay acts as a trusted intermediary that performs [Cryptokey Routing](https://www.wireguard.com/#cryptokey-routing) to match the decrypted packet's destination IP to the correct peer. For more details, see the [WireGuard whitepaper](https://www.wireguard.com/papers/wireguard.pdf) and [Pro Custodibus's explanation of hub-and-spoke E2EE limitations](https://www.procustodibus.com/blog/2021/12/wireguard-e2ee-hub-and-spoke/). If end-to-end encryption between NAT-ed peers is required, consider using an application-level encryption layer (e.g. TLS) on top of WireGuard, or a solution like [Tailscale's DERP relays](https://tailscale.com/blog/how-tailscale-works) which forward opaque encrypted packets without decrypting them. ### How WireGuard Routes Packets