Archives/wireguard-docs
2
0
Fork 0
mirror of https://github.com/pirate/wireguard-docs synced 2024-11-15 06:12:44 +00:00
Code Issues Releases Wiki Activity

Merge pull request #14 from jgelsey/patch-2

Browse Source 
Correct typo
This commit is contained in:
Nick Sweeting 2019-06-02 02:20:02 -04:00 committed by GitHub
commit 896fb89d84
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -267,7 +267,7 @@ More complex topologies are definitely achievable, but these are the basic routi
- **Node behind local NAT to node behind remote NAT (via UDP NAT hole-punching)**
"Hole Punching" refers to triggering automatic NAT rules of a router in order to allow inbound traffic. When you send a UDP packet out, the router (usually) creates a temporary rule mapping your source address and port to the destination address and port, and vice versa. This is how most UDP applications function behind NATs (e.g. Bittorent, Skype, etc). UDP packets returning from the destination address and port (and no other) are passed through to the original source address and port (and no other). This rule will timeout after some minutes of inactivity, so the client behind the NAT must send regular outgoing packets to keep it open (see `PersistentKeepalive`).
Getting this to work when both end-points are behind NATs or firewalls would require that both end-points send packets to each-other at about the same time. This means that both sides need to know each-other's public IP addresses and port numbers and need to communicate this to each-other by some other means (in our case by defining them in `wg0.conf`).
WireGuard punches holes through NATs natively as a side effect of it's UDP-based design, but it only works if a `ListenPort` is hardcoded for the peer behind the NAT. It does not search for a hole-punching port dynamically like WebRTC/N2N as it has no concept of a signaling server to communicate the port to the other side, it only works with a hardcoded port and `PersistentKeepalive` set to some non-null value.
WireGuard punches holes through NATs natively as a side effect of its UDP-based design, but it only works if a `ListenPort` is hardcoded for the peer behind the NAT. It does not search for a hole-punching port dynamically like WebRTC/N2N as it has no concept of a signaling server to communicate the port to the other side, it only works with a hardcoded port and `PersistentKeepalive` set to some non-null value.
- **Node behind local NAT to node behind remote NAT (via relay)**
In the worst case when both parties are behind remote NATs, both will open a connection to `public-server1`, and traffic will forward through the intermediary bounce server as long as the connections are kept alive.