Clarification Needed: Peer Configuration for NAT-ed Nodes in WireGuard VPN Setup

[vv1vv2]

Hi,

I’ve been reviewing the WireGuard VPN configuration outlined in the documentation (specifically the section on defining peers for a public bounce server and NAT-ed clients), and I believe there’s a potential issue or ambiguity that could confuse users.

Problem

The documentation states:

"Nodes that are behind separate NATs should not be defined as peers outside of the public server config... Instead, nodes behind NATs should only define the public relay servers and other public clients as their peers, and should specify AllowedIPs = 192.0.2.1/24 on the public server that accept routes and bounce traffic for the VPN subnet to the remote NAT-ed peers."

This suggests that two NAT-ed nodes (e.g., A and B) should not list each other as peers in their local configurations, relying solely on the relay server to handle traffic. However, WireGuard requires each peer to know the public key of the other peer to perform handshake and signature verification. If A and B don’t define each other as peers (with their respective PublicKey and AllowedIPs), they cannot establish an encrypted tunnel, even through a relay server. The relay server only forwards encrypted packets and doesn’t perform signature verification or encryption on behalf of the endpoints.

In this setup:

• If A sends traffic to B’s virtual IP (e.g., 192.0.2.3), but B isn’t listed as a peer in A’s config, WireGuard won’t generate an encrypted packet, and the relay server won’t have anything to forward.
• The relay server’s AllowedIPs = 192.0.2.1/24 only defines routing scope, not peer authentication.

Expected Behavior

For two NAT-ed nodes to communicate via the relay server, they must:

1. Be defined as peers on the relay server (which the doc already suggests).
2. Define each other as peers in their own configurations (with the relay server’s Endpoint), so they can verify signatures and establish an end-to-end tunnel.

Suggested Fix

I propose updating the documentation to clarify that NAT-ed nodes need to define all peers they intend to communicate with, including other NAT-ed nodes, in their local configurations. For example:

Revised text:

"Nodes behind separate NATs should define all peers they need to communicate with (including other NAT-ed nodes) in their configurations, using the public relay server’s Endpoint for indirect communication. The relay server must define all nodes as peers and use a broad AllowedIPs (e.g., 192.0.2.1/24) to route traffic between them. Direct peer definitions between NAT-ed nodes are necessary for WireGuard’s end-to-end encryption and signature verification, even if traffic is relayed."

Example Configuration

For a relay server (192.0.2.1), NAT-ed node A (192.0.2.2), and NAT-ed node B (192.0.2.3):

• Relay Server:

  [Peer]
  PublicKey = A_public_key
  AllowedIPs = 192.0.2.2/32
  
  [Peer]
  PublicKey = B_public_key
  AllowedIPs = 192.0.2.3/32

• Node A:

  [Peer]
  PublicKey = Relay_public_key
  Endpoint = relay_public_ip:51820
  AllowedIPs = 192.0.2.1/24
  
  [Peer]
  PublicKey = B_public_key
  AllowedIPs = 192.0.2.3/32

• Node B:

  [Peer]
  PublicKey = Relay_public_key
  Endpoint = relay_public_ip:51820
  AllowedIPs = 192.0.2.1/24
  
  [Peer]
  PublicKey = A_public_key
  AllowedIPs = 192.0.2.2/32

This ensures A and B can authenticate each other via the relay server.

Request

Could you please confirm if this is the intended behavior? If so, I’d suggest updating the docs to reflect this requirement. If not, could you clarify how NAT-ed nodes can communicate without defining each other as peers?

Thanks for your time and effort on this project!

---

Notes

• This issue is polite, detailed, and provides a concrete example to illustrate the problem.
• You can adjust the tone or details (e.g., specific IP addresses) based on the project’s context or your preferences.
• Submit this to the project’s GitHub repository (or wherever issues are tracked) after reviewing.

Let me know if you’d like any tweaks!