Clarify peer configuration requirements for NAT-to-NAT communication in WireGuard

[Copilot]

Problem

The documentation previously stated that NAT-ed nodes should not define each other as peers outside of the public server config, suggesting that the relay server's catchall AllowedIPs = 192.0.2.1/24 route would handle all communication between NAT-ed clients. This guidance was misleading and would prevent NAT-ed peers from communicating with each other.

Why this doesn't work:

WireGuard uses end-to-end encryption where each peer must have the public key of every peer it communicates with to perform cryptographic operations (handshakes, encryption, and authentication). The relay server only forwards encrypted packets at the network layer—it does not decrypt and re-encrypt traffic on behalf of clients.

If node A (behind NAT) tries to send traffic to node B (also behind NAT), but B isn't defined as a peer in A's config with its public key, WireGuard cannot encrypt the packets for B, and no traffic will flow.

Solution

This PR updates the documentation to:

1. Distinguish between two configuration scenarios:

   • Simple relay-only: NAT-ed clients can reach public servers but not each other (current examples)
   • Full mesh through relay: NAT-ed clients can communicate with all peers including other NAT-ed nodes

2. Clarify peer definition requirements:

   • NAT-ed peers must define each other with PublicKey and AllowedIPs for communication
   • Endpoint is omitted for NAT-ed peers since they're not directly reachable
   • The relay's catchall route enables packet forwarding, but peer definitions are required for encryption

3. Add concrete examples:

   • Configuration examples for both scenarios
   • Example showing how to add NAT-ed peer definitions
   • Clear peer lists showing which nodes should be defined where

Changes

• Updated "How Public Relay Servers Work" section with detailed explanation of relay functionality and peer requirements
• Revised [Peer] section to present both configuration scenarios clearly
• Added example configurations showing NAT-to-NAT peer definitions
• Updated QuickStart section with clearer instructions about peer definitions
• Enhanced example-full/README.md with important note about the current relay-only setup

Technical Accuracy

These changes correctly reflect WireGuard's cryptographic architecture:

• Public-key cryptography requires peer definitions for authentication
• End-to-end encryption happens between actual peers, not through the relay
• Relay servers operate at the network routing layer only
• The relay's AllowedIPs enables routing; peer definitions enable encryption

Impact

This clarification will help users:

• Understand when NAT-ed peers need to define each other
• Configure setups where NAT-ed clients communicate with each other
• Avoid configuration errors that would silently block communication
• Better understand WireGuard's end-to-end encryption model

Fixes issue raised in #[issue_number] about clarification needed for peer configuration with NAT-ed nodes.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Clarification Needed: Peer Configuration for NAT-ed Nodes in WireGuard VPN Setup</issue_title>
<issue_description>
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!</issue_description>

<agent_instructions>fix the docs to account for this</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Fixes #95

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.