Mirrors/wireguard-docs
1
0
Fork 0
mirror of https://github.com/pirate/wireguard-docs.git synced 2026-04-25 06:56:18 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Add source citations with markdown links to relay security note

Browse Source 
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
This commit is contained in:
Claude
2026-03-21 08:39:38 +00:00
parent 2a03397ea5
commit 2106d07304
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@@ -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. 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 ### How WireGuard Routes Packets