From ff3992c8e4b9b89bf030b4a8bdf23137dccfab8b Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Mon, 3 Jun 2019 01:18:49 -0400 Subject: [PATCH 01/72] move examples explanation to the top --- README.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index b5ba931..2d87dbb 100644 --- a/README.md +++ b/README.md @@ -187,6 +187,17 @@ Over the last 8+ years I've tried a wide range of VPN solutions. Somewhat out o ## Glossary +### Example Strings + +These are demo hostnames, domain names, ip addresses, and ranges used in the documentation and example configs. + +- Example domain: `example-vpn.dev` can be replaced with any publicly accessible domain you control +- Example hostnames: `public-server1`, `public-server2`, `home-server`, `laptop`, `phone` can be changed to your device hostnames +- IP addresses & ranges: `10.0.0.1/24`, `10.0.0.3`, `10.0.0.3/32` can be replaced with your preferred subnets and addresses (e.g. `192.168.5.1/24`) + +Wherever you see these strings below, they're just being used as placeholder values to illustrate an example and have no special meaning. +Replace them with your preferred values when doing your own setup. + ### Peer/Node/Device A host that connects to the VPN and has registers a VPN subnet address like 10.0.0.3 for itself. It can also optionally route traffic for more than its own address(es) by specifying subnet ranges in comma-separated CIDR notation. @@ -235,13 +246,6 @@ A wireguard public key for a single node, generated with: Domain Name Server, used to resolve hostnames to IPs for VPN clients, instead of allowing DNS requests to leak outside the VPN and reveal traffic. Leaks are testable with http://dnsleak.com. -### Example Strings - -`example-vpn.dev`, `public-server1`, `public-server2`, `home-server`, `laptop`, `phone` - -These are demo host and domain names used in the example config. -Replace them with your own names when doing your actual setup. - --- ## How WireGuard Works From e7c31e0dfcd87a5489b7d787c0c6ea3c412f900d Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Mon, 3 Jun 2019 01:46:10 -0400 Subject: [PATCH 02/72] add config overview section --- README.md | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 2d87dbb..249e70f 100644 --- a/README.md +++ b/README.md @@ -556,6 +556,14 @@ dig example.com A ## Config Reference +### Overview + +WireGuard config is in INI syntax, defined in a file usually called `wg0.conf`. It can be placed anywhere on the system, but is often placed in `/etc/wireguard/wg0.conf`. + +The config path is specificed as an argument when running any `wg-quick` command, e.g: +`wg-quick up /etc/wireguard/wg0.conf` (always specify the full, absolute path) + +Config files can opt to use the limited set of `wg` config options, or the more extended `wg-quick` options, depending on what command is preferred to start WireGuard. These docs recommend sticking to `wg-quick` as it provides a more powerful and user-friendly config experience. **Jump to definition:** @@ -918,7 +926,19 @@ AllowedIPs = 0.0.0.0/0, ::/0 ### NAT To NAT Connections -WireGuard can natively make connections between two clients behind NATs, without need of a public relay server. This is achieved by hardcoding a `ListenPort` on both sides (and enabling `PersistentKeepalive`) so that both peers don't need a separate publicly-accesible signaling server to determine where to send the initial UDP packets. +WireGuard can natively make connections between two clients behind NATs, without need of a public relay server. + +**Requirements** + + - At least one peer has to have to have a hardcoded, directly-accessible `Endpoint` defined. If they're both behind NATs without stable IP addresses, then you'll need to use Dynammic DNS or another solution to have a stable, publicly accessibly domain/IP for at least one peer + - At least one peer has to have a hardcoded UDP `ListenPort` defined, and it's NAT router must not do UDP source port randomization, otherwise return packets will be sent to the hardocded `ListenPort` and dropped by the router, instead of using the random port assigned by the NAT on the outgoing packet + - All NAT'ed peers must have `PersistentKeepalive` enabled on all other peers, so that they continually send outgoing pings to keep connections persisted in their NAT's routing table + +NAT-to-NAT connections are not possible unless at least one host has a stable address, whether thats using a FQDN updated with dnymaic DNS, or a static public IP, anything works as long as all peers can communicate it beforehand. + +*Note:* Some users report having to restart WireGuard to force it to re-rolsve dynamic DNS hostnames for peer `Endpoint`s. You may want to use a `PostUp` hook to make this process easier. + +NAT-to-NAT connections are not possible if all endpoints are behind NAT's with strict UDP source port randomization (e.g. most cellular data networks). Since neither side is able to hardcode a `ListenPort` and guarantee that their NAT will accept traffic on that port after the outgoing ping, you cannot coordinate a port for the initial hole-punch between peers and connections will fail. For this reason, you generally cannot do phone-to-phone connections on LTE/3g networks, but you might be able to do phone-to-office or phone-to-home where the office or home has a stable public IP and doesn't do source port randomization. The connection process looks like this: From 3c9cb147b8c41b0e7413b90b80e936cc0efe1798 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 4 Jun 2019 17:13:34 -0400 Subject: [PATCH 03/72] fix double assignment in example --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 249e70f..c21f9d9 100644 --- a/README.md +++ b/README.md @@ -1000,7 +1000,7 @@ You can also build a dynamic allocation system yourself by reading in IP values ```ini [Interface] ... -PostUp = PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command) +PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command) ``` ### Other WireGuard Implementations From dfa47feddc0387e7f380e258d270388311c12e66 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 4 Jun 2019 17:20:23 -0400 Subject: [PATCH 04/72] add WireGuard-Ligase links --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index c21f9d9..27f59d6 100644 --- a/README.md +++ b/README.md @@ -1025,6 +1025,7 @@ These are some GUI and CLI tools that wrap WireGuard to assist with config, depl - https://github.com/max-moser/network-manager-wireguard - https://github.com/its0x08/wg-install - https://github.com/sowbug/mkwgconf + - https://github.com/SirToffski/WireGuard-Ligase/ - https://pypi.org/project/wireguard-p2p/ - https://github.com/trailofbits/algo - https://github.com/StreisandEffect/streisand @@ -1399,6 +1400,7 @@ PersistentKeepalive = 25 - https://vincent.bernat.ch/en/blog/2018-route-based-vpn-wireguard - https://staaldraad.github.io/2017/04/17/nat-to-nat-with-wireguard - https://try.popho.be/wg.html +- https://docs.artemix.org/sysadmin/wireguard-management/ - https://github.com/adrianmihalko/raspberrypiwireguard - https://www.ericlight.com/wireguard-part-one-installation.html - https://www.ericlight.com/wireguard-part-two-vpn-routing.html @@ -1420,6 +1422,7 @@ PersistentKeepalive = 25 - https://github.com/StreisandEffect/streisand - https://github.com/its0x08/wg-install - https://github.com/sowbug/mkwgconf +- https://github.com/SirToffski/WireGuard-Ligase/ - https://pypi.org/project/wireguard-p2p/ - https://github.com/cloudflare/boringtun - https://git.zx2c4.com/wireguard-go/about/ From f6a0d58ed8c222f55ea6c41f566467565980c4b4 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 4 Jun 2019 17:29:24 -0400 Subject: [PATCH 05/72] add wireguard-hs and other implementations --- README.md | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 27f59d6..ff005ca 100644 --- a/README.md +++ b/README.md @@ -1005,16 +1005,25 @@ PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command) ### Other WireGuard Implementations - - https://git.zx2c4.com/wireguard-go/about/ A compliant userland WireGuard implementation written in Go. +- https://git.zx2c4.com/wireguard-rs/about/ +An incomplete, insecure userspace implementation of Wireguard written in Rust (not ready for the public). + +- https://git.zx2c4.com/wireguard-hs/about/ +An incomplete, insecure userspace implementation of Wireguard written in Haskell (not ready for the public). + - https://github.com/cloudflare/boringtun -A compliant WireGuard implementation with the exact same API, written in Rust. +A compliant, working WireGuard implementation with the exact same API, written in Rust. See https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/ +- Platform-specific WireGuard apps +https://git.zx2c4.com/wireguard-ios/about/ +https://git.zx2c4.com/wireguard-android/about/ +https://git.zx2c4.com/wireguard-windows/about/ -Both of these are slower than the native C version that runs in kernel land, but provide other benefits by running in userland (e.g. easier containerization). +All of the userspace implmentations are slower than the native C version that runs in kernel-land, but provide other benefits by running in userland (e.g. easier containerization, compatibility, etc.). ### WireGuard Setup Tools From 259200ddd426439062cf9400d4eec16814bdac93 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 4 Jun 2019 17:30:10 -0400 Subject: [PATCH 06/72] markdown formatting --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index ff005ca..3c596df 100644 --- a/README.md +++ b/README.md @@ -1011,7 +1011,7 @@ A compliant userland WireGuard implementation written in Go. - https://git.zx2c4.com/wireguard-rs/about/ An incomplete, insecure userspace implementation of Wireguard written in Rust (not ready for the public). -- https://git.zx2c4.com/wireguard-hs/about/ +- https://git.zx2c4.com/wireguard-hs/about/ An incomplete, insecure userspace implementation of Wireguard written in Haskell (not ready for the public). - https://github.com/cloudflare/boringtun From 8a7d914b2717b614b42cec3ff8cb96692aa95d18 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Thu, 13 Jun 2019 17:50:49 -0400 Subject: [PATCH 07/72] add brittson/wireguard_config_maker --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index 3c596df..776b110 100644 --- a/README.md +++ b/README.md @@ -352,6 +352,7 @@ Some services that help with key distribution and deployment: - https://github.com/trailofbits/algo - https://github.com/StreisandEffect/streisand - https://github.com/its0x08/wg-install +- https://github.com/brittson/wireguard_config_maker You can also read in keys from a file or via command if you don't want to hardcode them in `wg0.conf`, this makes managing keys via 3rd party service much easier: @@ -1034,6 +1035,7 @@ These are some GUI and CLI tools that wrap WireGuard to assist with config, depl - https://github.com/max-moser/network-manager-wireguard - https://github.com/its0x08/wg-install - https://github.com/sowbug/mkwgconf + - https://github.com/brittson/wireguard_config_maker - https://github.com/SirToffski/WireGuard-Ligase/ - https://pypi.org/project/wireguard-p2p/ - https://github.com/trailofbits/algo @@ -1431,6 +1433,7 @@ PersistentKeepalive = 25 - https://github.com/StreisandEffect/streisand - https://github.com/its0x08/wg-install - https://github.com/sowbug/mkwgconf +- https://github.com/brittson/wireguard_config_maker - https://github.com/SirToffski/WireGuard-Ligase/ - https://pypi.org/project/wireguard-p2p/ - https://github.com/cloudflare/boringtun From 6a2decf357d8a430801acffcdd8a338f98decbb3 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Sun, 23 Jun 2019 18:16:08 -0400 Subject: [PATCH 08/72] Update README.md --- README.md | 112 +++++++++++++++++++++++++++++------------------------- 1 file changed, 60 insertions(+), 52 deletions(-) diff --git a/README.md b/README.md index 776b110..0a33239 100644 --- a/README.md +++ b/README.md @@ -265,20 +265,13 @@ In summary: only direct connections between clients should be configured, any co More complex topologies are definitely achievable, but these are the basic routing methods used in typical WireGuard setups: - **Direct node-to-node** - In the best case, the nodes are on the same LAN or are both publicly accessible, and traffic will route over encrypted UDP packets sent directly between the nodes. + In the best case, the nodes are on the same LAN or are both publicly accessible. Define directly accessible nodes with hardcoded `Endpoint` addresses and ports so that WireGuard can connect straight to the open port and route UDP packets without intermediate hops. - **Node behind local NAT to public node** - When 1 of the 2 parties is behind a remote NAT (e.g. when laptop behind a NAT connects to `public-server2`), the connection will be opened from NAT -> public client, then traffic will route directly between them in both directions as long as the connection is kept alive. + When 1 of the 2 parties is behind a remote NAT (e.g. when laptop behind a NAT connects to `public-server2`), define the publicly accessible node with a hardcoded `Endpoint` and the NAT-ed node without. The connection will be opened from NAT client -> public client, then traffic will route directly between them in both directions as long as the connection is kept alive by ougoing `PersistentKeepalive` pings from the NAT-ed client. - **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 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. + While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the srcport, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random srcports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random srcports and sends them back so the clients, this is how WebRTC works in modern P2P web apps. Even with a signalling server and known srcports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random srcport to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated srcport). This is espcially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. - -Choosing the proper routing method is handled automatically by WireGuard as long as at least one server is acting as a public relay with `net.ipv4.ip_forward = 1` enabled, and clients have `AllowIPs = 10.0.0.1/24` set in the relay server `[peer]` (to take traffic for the whole subnet). - -More specific (also usually more direct) routes provided by other peers will take precedence when available, otherwise traffic will fall back to the least specific route and use the `10.0.0.1/24` catchall to forward traffic to the bounce server, where it will in turn be routed by the relay server's system routing table back down the VPN to the specific peer that's accepting routes for that traffic. +More specific (also usually more direct) routes provided by other peers will take precedence when available, otherwise traffic will fall back to the least specific route and use the `10.0.0.1/24` catchall to forward traffic to the bounce server, where it will in turn be routed by the relay server's system routing table (`net.ipv4.ip_forward = 1`) back down the VPN to the specific peer that's accepting routes for that traffic. Wireguard does not automatically find the fastest route or attempt to form direct connections between peers if not already defined, it just goes from the most specific route in `[Peers]` to least specific. You can figure out which routing method WireGuard is using for a given address by measuring the ping times to figure out the unique length of each hop, and by inspecting the output of: ```bash @@ -379,7 +372,7 @@ Overview of the general process: - `[Peer]` Create a peer section for each public peer not behind a NAT, make sure to specify a CIDR range for the entire VPN subnet when defining the remote peer acting as the bounce server `AllowedIPs = 10.0.0.1/24`. Make sure to specify individual IPs for remote peers that don't relay traffic and only act as simple clients `AllowedIPs = 10.0.0.3/32`. 5. Start wireguard on the main relay server with `wg-quick up /full/path/to/wg0.conf` 6. Start wireguard on all the client peers with `wg-quick up /full/path/to/wg0.conf` -7. Traffic is routed from peer to peer using most optimal route over the WireGuard interface, e.g. `ping 10.0.0.3` checks for local direct route first, then checks for route via public internet, then finally tries to route by bouncing through the public relay server. +7. Traffic is routed from peer to peer using most specific route first over the WireGuard interface, e.g. `ping 10.0.0.3` checks for a direct route to a peer with `AllowedIPs = 10.0.0.3/32` first, then falls back to a relay server that's accepting ips in the whole subnet ### Setup @@ -927,36 +920,49 @@ AllowedIPs = 0.0.0.0/0, ::/0 ### NAT To NAT Connections -WireGuard can natively make connections between two clients behind NATs, without need of a public relay server. +WireGuard can sometimes natively make connections between two clients behind NATs without need of a public relay server, but in most cases this is not possible. NAT-to-NAT connections are not possible unless at least one host has a stable, publicly-accessible IP address:port pair that can be hardcoded ahead of time, whether thats using a FQDN updated with dnymaic DNS, or a static public IP with a non-randomized NAT port opened by outgoing packets, anything works as long as all peers can communicate it beforehand and it doesn't change once the connection is initiated. + +Wireguard 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 `Endpoint` address and `ListenPort`, and `PersistentKeepalive` set to some non-null value on both sides. + +#### The hole-punching connection process + + 1. Peer1 sends a UDP packet to Peer2, it's rejected Peer2's NAT router immediately, but that's ok, the only purpose was to get Peer1's NAT to start forwarding any expected UDP responses back to Peer1 behind its NAT + 2. Peer2 sends a UDP packet to Peer1, it's accepted and fowarded to Peer1 as Peer1's NAT server is already expecting responses from Peer2 because of the initial outgoing packet + 3. Peer1 sends a UDP response to Peer2's packet, it's accepted and forwarded by Peer2's NAT server as it's also expecting responses because of the initial outgoing packet + +This process of sending an initial packet that gets rejected, then using the fact that the router has now created a forwarding rule to accept responses is called "UDP hole-punching". -**Requirements** +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. 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 is how most UDP applications function behind NATs (e.g. Bittorent, Skype, etc). 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 hard-coding them in `wg0.conf` in advance). WebRTC requires a STUN signaling server to communicate the hole-punching port because it would be impossible for browsers to hardcode listening ports for all possible connections in advance. + +#### Requirements for NAT-to-NAT setups - At least one peer has to have to have a hardcoded, directly-accessible `Endpoint` defined. If they're both behind NATs without stable IP addresses, then you'll need to use Dynammic DNS or another solution to have a stable, publicly accessibly domain/IP for at least one peer - At least one peer has to have a hardcoded UDP `ListenPort` defined, and it's NAT router must not do UDP source port randomization, otherwise return packets will be sent to the hardocded `ListenPort` and dropped by the router, instead of using the random port assigned by the NAT on the outgoing packet - All NAT'ed peers must have `PersistentKeepalive` enabled on all other peers, so that they continually send outgoing pings to keep connections persisted in their NAT's routing table -NAT-to-NAT connections are not possible unless at least one host has a stable address, whether thats using a FQDN updated with dnymaic DNS, or a static public IP, anything works as long as all peers can communicate it beforehand. +#### Drawbacks and limitations + +As of 2019, many of the old hole-punching methods used that used to work are no longer effective. One example was a novel method pioneered by [pwnat]](https://github.com/samyk/pwnat) that faked an ICMP Time Exceeded response from outside the NAT to get a packet back through to a NAT'ed peer, thereby leaking its own srcport. -*Note:* Some users report having to restart WireGuard to force it to re-rolsve dynamic DNS hostnames for peer `Endpoint`s. You may want to use a `PostUp` hook to make this process easier. +##### Source port randomization NAT-to-NAT connections are not possible if all endpoints are behind NAT's with strict UDP source port randomization (e.g. most cellular data networks). Since neither side is able to hardcode a `ListenPort` and guarantee that their NAT will accept traffic on that port after the outgoing ping, you cannot coordinate a port for the initial hole-punch between peers and connections will fail. For this reason, you generally cannot do phone-to-phone connections on LTE/3g networks, but you might be able to do phone-to-office or phone-to-home where the office or home has a stable public IP and doesn't do source port randomization. -The connection process looks like this: +##### Dynamic IP addresses +Many users report having to restart WireGuard whenever a dynamic IP changes, as it only resolves hostnames on startup. To force WireGuard to re-resolve dynamic DNS `Endpoint` hostnames more often, you may want to use a `PostUp` hook to restart Wireguard every few minutes or hours. - 1. Peer1 sends a UDP packet to Peer2, it's rejected Peer2's NAT router immediately, but that's ok, the only purpose was to get Peer1's NAT to start forwarding any expected UDP responses back to Peer1 behind its NAT - 2. Peer2 sends a UDP packet to Peer1, it's accepted and fowarded to Peer1 as Peer1's NAT server is already expecting responses from Peer2 because of the initial outgoing packet - 3. Peer1 sends a UDP response to Peer2's packet, it's accepted and forwarded by Peer2's NAT server as it's also expecting responses because of the initial outgoing packet -This process of sending an initial packet that gets rejected, then using the fact that the router has now created a forwarding rule to accept responses is called "UDP hole-punching". +#### Testing it out -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. 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 is how most UDP applications function behind NATs (e.g. Bittorent, Skype, etc). 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`). +You can see if a hole-punching setup is feasible by using netcat on the client and server to see what ports and connection order work to get a bidirectional connection open: run `nc -v -u -p 51820
51820` (on peer1) and `nc -v -u -l 0.0.0.0 51820` (on peer2), then type in both windows to see if you can get bidirectional traffic going. If it doesn't work regardless of which peer sends the initial packet, then WireGuard won't be unable to work between the peers without a public relay server. -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 hard-coding them in `wg0.conf` in advance). WebRTC requires a STUN signaling server to communicate the hole-punching port because it would be impossible for browsers to hardcode listening ports for all possible connections in advance. +NAT-to-NAT connections are often more unstable and have other limitations, which is why having a fallback public relay server is still advised. -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 on both sides. - -This approach has some limitations, which is why having a fallback public relay server is still advised, see: +#### Further reading + - https://github.com/samyk/pwnat - https://en.wikipedia.org/wiki/UDP_hole_punching - https://stackoverflow.com/questions/8892142/udp-hole-punching-algorithm - https://stackoverflow.com/questions/12359502/udp-hole-punching-not-going-through-on-3g @@ -992,7 +998,9 @@ PersistentKeepalive = 25 ### Dynamic IP Allocation -Dynamic allocation of IPs (instead of only having fixed peers) is being developed, the WIP implementation is available here: +*Note: this section is about dynamic peer IPs within the VPN subnet, not dynamic public `Endpoint` addresses*. + +Dynamic allocation of peer IPs (instead of only having fixed peers) is being developed, the WIP implementation is available here: https://github.com/WireGuard/wg-dynamic You can also build a dynamic allocation system yourself by reading in IP values from files at runtime by using `PostUp` (see below). @@ -1140,11 +1148,11 @@ For more detailed instructions, see the [Quickstart](#Quickstart) guide and API * priv key: `` * pub key: `` * setup required: - 1. install wireguard - 2. generate public/private keypair - 3. create wg0.conf (see below) - 4. enable kernel ip & arp forwarding, add iptables forwarding rules - 5. start wireguard + 1. install wireguard + 2. generate public/private keypair + 3. create wg0.conf (see below) + 4. enable kernel ip & arp forwarding, add iptables forwarding rules + 5. start wireguard * config as remote peer: ```ini [Peer] @@ -1204,11 +1212,11 @@ AllowedIPs = 10.0.0.5/32 * priv key: `` * pub key: `` * setup required: - 1. install wireguard - 2. generate public/private keypair - 3. create wg0.conf (see below) - 4. confirm main public relay server is directly accessible - 4. start wireguard + 1. install wireguard + 2. generate public/private keypair + 3. create wg0.conf (see below) + 4. confirm main public relay server is directly accessible + 4. start wireguard * config as local interface: ```ini [Interface] @@ -1252,11 +1260,11 @@ PersistentKeepalive = 25 * priv key: `` * pub key: `` * setup required: - 1. install wireguard - 2. generate public/private keypair - 3. create wg0.conf (see below) - 4. confirm main public relay server is directly accessible - 4. start wireguard + 1. install wireguard + 2. generate public/private keypair + 3. create wg0.conf (see below) + 4. confirm main public relay server is directly accessible + 4. start wireguard * config as local interface: ```ini [Interface] @@ -1300,11 +1308,11 @@ PersistentKeepalive = 25 * priv key: `` * pub key: `` * setup required: - 1. install wireguard - 2. generate public/private keypair - 3. create wg0.conf (see below) - 4. confirm main public relay server is directly accessible - 4. start wireguard + 1. install wireguard + 2. generate public/private keypair + 3. create wg0.conf (see below) + 4. confirm main public relay server is directly accessible + 4. start wireguard * config as local interface: ```ini [Interface] @@ -1345,11 +1353,11 @@ PersistentKeepalive = 25 * priv key: `` * pub key: `` * setup required: - 1. install wireguard - 2. generate public/private keypair - 3. create wg0.conf (see below) - 4. confirm main public relay server is directly accessible - 4. start wireguard + 1. install wireguard + 2. generate public/private keypair + 3. create wg0.conf (see below) + 4. confirm main public relay server is directly accessible + 4. start wireguard * config as local interface: ```ini [Interface] From 1695ab87a189e3629dc6dfbe8c0f105f42a9b4be Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Mon, 24 Jun 2019 04:40:10 -0400 Subject: [PATCH 09/72] fix it's -> its --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 0a33239..2dde0e2 100644 --- a/README.md +++ b/README.md @@ -1064,7 +1064,7 @@ See: https://lists.zx2c4.com/pipermail/wireguard/2018-December/003703.html You can combine this with `wg addconf` like this: -* Each peer has its own `/etc/wireguard/wg0.conf` file, which only contains it's `[Interface]` section. +* Each peer has its own `/etc/wireguard/wg0.conf` file, which only contains its `[Interface]` section. * Each peer also has a shared `/etc/wireguard/peers.conf` file, which contains all the peers. @@ -1129,7 +1129,7 @@ Whenever possible, nodes should connect directly to each other, depending on whe `public-server1` acts as an intermediate relay server between any VPN clients behind NATs, it will forward any 10.0.0.1/24 traffic it receives to the correct peer at the system level (WireGuard doesn't care how this happens, it's handled by the kernel `net.ipv4.ip_forward = 1` and the iptables routing rules). -Each client only needs to define the publicly accessible servers/peers in it's config, any traffic bound to other peers behind NATs will go to the catchall `10.0.0.1/24` for the server and will be forwarded accordingly once it hits the main server. +Each client only needs to define the publicly accessible servers/peers in its config, any traffic bound to other peers behind NATs will go to the catchall `10.0.0.1/24` for the server and will be forwarded accordingly once it hits the main server. 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. From df573ac3ddea29a4fc78ea1fb8c44036b904b9d8 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Mon, 24 Jun 2019 04:44:43 -0400 Subject: [PATCH 10/72] more typos courtesy of @xairos thanks! --- README.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 2dde0e2..34f3b1e 100644 --- a/README.md +++ b/README.md @@ -252,11 +252,11 @@ Domain Name Server, used to resolve hostnames to IPs for VPN clients, instead of ### How Public Relay Servers Work -Public relays are just normal VPN peers that are able to act as an intermediate relay server between any VPN clients behind NATs, they can forward any VPN subnet traffic they receives to the correct peer at the system level (WireGuard doesn't care how this happens, it's handled by the kernel `net.ipv4.ip_forward = 1` and the iptables routing rules). +Public relays are just normal VPN peers that are able to act as an intermediate relay server between any VPN clients behind NATs, they can forward any VPN subnet traffic they receive to the correct peer at the system level (WireGuard doesn't care how this happens, it's handled by the kernel `net.ipv4.ip_forward = 1` and the iptables routing rules). If all peers are publicly accessible, you don't have to worry about special treatment to make one of them a relay server, it's only needed if you have any peers connecting from behind a NAT. -Each client only needs to define the publicly accessible servers/peers in it's config, any traffic bound to other peers behind NATs will go to the catchall VPN subnet (e.g. `10.0.0.1/24`) in the public relays `AllowedIPs` route and will be forwarded accordingly once it hits the relay server. +Each client only needs to define the publicly accessible servers/peers in its config, any traffic bound to other peers behind NATs will go to the catchall VPN subnet (e.g. `10.0.0.1/24`) in the public relays `AllowedIPs` route and will be forwarded accordingly once it hits the relay server. 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. @@ -387,7 +387,7 @@ brew install wireguard-tools # install on FreeBSD pkg install wireguard -# install on iOS/Andoid using Apple App Store/Google Play Store +# install on iOS/Android using Apple App Store/Google Play Store # install on other systems using https://www.wireguard.com/install/#installation ``` @@ -554,7 +554,7 @@ dig example.com A WireGuard config is in INI syntax, defined in a file usually called `wg0.conf`. It can be placed anywhere on the system, but is often placed in `/etc/wireguard/wg0.conf`. -The config path is specificed as an argument when running any `wg-quick` command, e.g: +The config path is specified as an argument when running any `wg-quick` command, e.g: `wg-quick up /etc/wireguard/wg0.conf` (always specify the full, absolute path) Config files can opt to use the limited set of `wg` config options, or the more extended `wg-quick` options, depending on what command is preferred to start WireGuard. These docs recommend sticking to `wg-quick` as it provides a more powerful and user-friendly config experience. @@ -920,14 +920,14 @@ AllowedIPs = 0.0.0.0/0, ::/0 ### NAT To NAT Connections -WireGuard can sometimes natively make connections between two clients behind NATs without need of a public relay server, but in most cases this is not possible. NAT-to-NAT connections are not possible unless at least one host has a stable, publicly-accessible IP address:port pair that can be hardcoded ahead of time, whether thats using a FQDN updated with dnymaic DNS, or a static public IP with a non-randomized NAT port opened by outgoing packets, anything works as long as all peers can communicate it beforehand and it doesn't change once the connection is initiated. +WireGuard can sometimes natively make connections between two clients behind NATs without the need for a public relay server, but in most cases this is not possible. NAT-to-NAT connections are not possible unless at least one host has a stable, publicly-accessible IP address:port pair that can be hardcoded ahead of time, whether thats using a FQDN updated with Dynamic DNS, or a static public IP with a non-randomized NAT port opened by outgoing packets, anything works as long as all peers can communicate it beforehand and it doesn't change once the connection is initiated. Wireguard 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 `Endpoint` address and `ListenPort`, and `PersistentKeepalive` set to some non-null value on both sides. #### The hole-punching connection process 1. Peer1 sends a UDP packet to Peer2, it's rejected Peer2's NAT router immediately, but that's ok, the only purpose was to get Peer1's NAT to start forwarding any expected UDP responses back to Peer1 behind its NAT - 2. Peer2 sends a UDP packet to Peer1, it's accepted and fowarded to Peer1 as Peer1's NAT server is already expecting responses from Peer2 because of the initial outgoing packet + 2. Peer2 sends a UDP packet to Peer1, it's accepted and forwarded to Peer1 as Peer1's NAT server is already expecting responses from Peer2 because of the initial outgoing packet 3. Peer1 sends a UDP response to Peer2's packet, it's accepted and forwarded by Peer2's NAT server as it's also expecting responses because of the initial outgoing packet This process of sending an initial packet that gets rejected, then using the fact that the router has now created a forwarding rule to accept responses is called "UDP hole-punching". @@ -938,7 +938,7 @@ Getting this to work when both end-points are behind NATs or firewalls would req #### Requirements for NAT-to-NAT setups - - At least one peer has to have to have a hardcoded, directly-accessible `Endpoint` defined. If they're both behind NATs without stable IP addresses, then you'll need to use Dynammic DNS or another solution to have a stable, publicly accessibly domain/IP for at least one peer + - At least one peer has to have to have a hardcoded, directly-accessible `Endpoint` defined. If they're both behind NATs without stable IP addresses, then you'll need to use Dynamic DNS or another solution to have a stable, publicly accessibly domain/IP for at least one peer - At least one peer has to have a hardcoded UDP `ListenPort` defined, and it's NAT router must not do UDP source port randomization, otherwise return packets will be sent to the hardocded `ListenPort` and dropped by the router, instead of using the random port assigned by the NAT on the outgoing packet - All NAT'ed peers must have `PersistentKeepalive` enabled on all other peers, so that they continually send outgoing pings to keep connections persisted in their NAT's routing table @@ -1032,7 +1032,7 @@ https://git.zx2c4.com/wireguard-ios/about/ https://git.zx2c4.com/wireguard-android/about/ https://git.zx2c4.com/wireguard-windows/about/ -All of the userspace implmentations are slower than the native C version that runs in kernel-land, but provide other benefits by running in userland (e.g. easier containerization, compatibility, etc.). +All of the userspace implementations are slower than the native C version that runs in kernel-land, but provide other benefits by running in userland (e.g. easier containerization, compatibility, etc.). ### WireGuard Setup Tools @@ -1089,7 +1089,7 @@ You can read in a file as the `PrivateKey` by doing something like: WireGuard can be run in Docker with varying degrees of ease. In the simplest case, `--privileged` and `--cap-add=all` args can be added to the docker commands to enable the loading of the kernel module. -Setups can get somewhat complex are are highly dependent on what you're trying to achieve. You can have WireGuard itself run in a container and expose a network interface to the host, or you can have WireGuard running on the host exposing an interface to specific containers. +Setups can get somewhat complex and are highly dependent on what you're trying to achieve. You can have WireGuard itself run in a container and expose a network interface to the host, or you can have WireGuard running on the host exposing an interface to specific containers. **Further Reading** From f776b0f9eee1a19d61d49ef1e919db8dab2ea107 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Mon, 24 Jun 2019 04:46:40 -0400 Subject: [PATCH 11/72] Update README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 34f3b1e..244cb08 100644 --- a/README.md +++ b/README.md @@ -1424,6 +1424,7 @@ PersistentKeepalive = 25 - https://www.ericlight.com/wireguard-part-one-installation.html - https://www.ericlight.com/wireguard-part-two-vpn-routing.html - https://www.ericlight.com/wireguard-part-three-troubleshooting.html +- https://wiki.dd-wrt.com/wiki/index.php/The_Easiest_Tunnel_Ever ### Papers, Articles, and Talks From c1e17d03abf9bb4e720f2645fc649620904acb3e Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Mon, 24 Jun 2019 04:56:28 -0400 Subject: [PATCH 12/72] Use documentation IPv6 addresses --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 244cb08..b9c468a 100644 --- a/README.md +++ b/README.md @@ -193,7 +193,7 @@ These are demo hostnames, domain names, ip addresses, and ranges used in the doc - Example domain: `example-vpn.dev` can be replaced with any publicly accessible domain you control - Example hostnames: `public-server1`, `public-server2`, `home-server`, `laptop`, `phone` can be changed to your device hostnames -- IP addresses & ranges: `10.0.0.1/24`, `10.0.0.3`, `10.0.0.3/32` can be replaced with your preferred subnets and addresses (e.g. `192.168.5.1/24`) +- IP addresses & ranges: `10.0.0.1/24`, `10.0.0.3`, `10.0.0.3/32`, `2001:DB8::/64` can be replaced with your preferred subnets and addresses (e.g. `192.168.5.1/24`) Wherever you see these strings below, they're just being used as placeholder values to illustrate an example and have no special meaning. Replace them with your preferred values when doing your own setup. @@ -218,7 +218,7 @@ A way of defining a subnet and its size with a "mask", a smaller mask = more ad + `10.0.0.1/16` (65,536 ips from `10.0.0.0` - `10.0.255.255`) netmask = `255.255.0.0` + `10.0.0.1/8` (16,777,216 ips from `10.0.0.0` - `10.255.255.255`) netmask = `255.0.0.0` + `0.0.0.1/0` (4,294,967,296 ips from `0.0.0.0` - `255.255.255.255`) netmask = `0.0.0.0` - + IPv6 CIDR notation is also supported e.g. `fd42:42:42::1/64` + + IPv6 CIDR notation is also supported e.g. `2001:DB8::/64` https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing @@ -624,7 +624,7 @@ When the node is acting as the public bounce server, it should set this to be th `Address = 10.0.0.1/24` * You can also specify multiple subnets or IPv6 subnets like so: -`Address = 10.0.0.1/24,fd42:42:42::1/64` +`Address = 10.0.0.1/24,2001:DB8::/64` #### `ListenPort` @@ -889,7 +889,7 @@ The examples in these docs primarily use IPv4, but Wireguard natively supports I ```ini [Interface] -AllowedIps = 10.0.0.3/24, fd42:42:42::1/64 +AllowedIps = 10.0.0.3/24, 2001:DB8::/64 [Peer] ... From 889d8a29cfb4ebbb5048318ac051fc0e959e10a6 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Mon, 24 Jun 2019 05:07:18 -0400 Subject: [PATCH 13/72] change all IPs used to IETF example ranges --- README.md | 192 +++++++++++++++++++++++++++++------------------------- 1 file changed, 105 insertions(+), 87 deletions(-) diff --git a/README.md b/README.md index b9c468a..ff34b9e 100644 --- a/README.md +++ b/README.md @@ -152,7 +152,7 @@ Over the last 8+ years I've tried a wide range of VPN solutions. Somewhat out o - minimal config, low config surface area and few exposed tunables - minimal key management overhead, 1 or 2 preshared keys or certs is ok, but ideally not both - - ability to easily create a LAN like 10.0.0.0/24 between all my servers, every peer can connect to every peer, + - ability to easily create a LAN like 192.0.2.0/24 between all my servers, every peer can connect to every peer, - ability to bust through NATs with a signalling server, routing nat-to-nat instead of through a relay (WebRTC-style) - fallback to relay server when nat-to-nat busting is unavailable or unreliable - ability to route to a fixed list of ips/hosts with 1 keypair per host (not needed, but nice to have: ability to route arbitrary local traffic or *all* internet traffic to a given host) @@ -190,17 +190,26 @@ Over the last 8+ years I've tried a wide range of VPN solutions. Somewhat out o ### Example Strings These are demo hostnames, domain names, ip addresses, and ranges used in the documentation and example configs. +Replace them with your preferred values when doing your own setup. - Example domain: `example-vpn.dev` can be replaced with any publicly accessible domain you control - Example hostnames: `public-server1`, `public-server2`, `home-server`, `laptop`, `phone` can be changed to your device hostnames -- IP addresses & ranges: `10.0.0.1/24`, `10.0.0.3`, `10.0.0.3/32`, `2001:DB8::/64` can be replaced with your preferred subnets and addresses (e.g. `192.168.5.1/24`) +- IP addresses & ranges: `192.0.2.1/24`, `192.0.2.3`, `192.0.2.3/32`, `2001:DB8::/64` can be replaced with your preferred subnets and addresses (e.g. `192.168.5.1/24`) Wherever you see these strings below, they're just being used as placeholder values to illustrate an example and have no special meaning. -Replace them with your preferred values when doing your own setup. + +**Make sure to change the IP addresses in your configs!** The blocks used in these docs +are reserved for example purposes by the IETF and should never be used in real network setups. + + - **`192.0.2.0/24`** (TEST-NET-1) IPv4 example range [RFC5737](https://tools.ietf.org/html/rfc5737) + - **`2001:DB8::/32`** IPv6 example range [RFC3849](https://tools.ietf.org/html/rfc3849) + +You can use any private range you want for your own setups, e.g. `10.0.44.0/24`, just make sure +they don't conflict with any of the LAN subnet ranges your peers are on. ### Peer/Node/Device -A host that connects to the VPN and has registers a VPN subnet address like 10.0.0.3 for itself. It can also optionally route traffic for more than its own address(es) by specifying subnet ranges in comma-separated CIDR notation. +A host that connects to the VPN and has registers a VPN subnet address like 192.0.2.3 for itself. It can also optionally route traffic for more than its own address(es) by specifying subnet ranges in comma-separated CIDR notation. ### Bounce Server @@ -208,28 +217,28 @@ A publicly reachable peer/node that serves as a fallback to relay traffic for ot ### Subnet -A group of IPs separate from the public internet, e.g. 10.0.0.1-255 or 192.168.1.1/24. Generally behind a NAT provided by a router, e.g. in office internet LAN or a home WiFi network. +A group of IPs separate from the public internet, e.g. 192.0.2.1-255 or 192.168.1.1/24. Generally behind a NAT provided by a router, e.g. in office internet LAN or a home WiFi network. ### CIDR Notation A way of defining a subnet and its size with a "mask", a smaller mask = more address bits usable by the subnet & more IPs in the range. Most common ones: - + `10.0.0.1/32` (a single ip address, `10.0.0.1`) netmask = `255.255.255.255` - + `10.0.0.1/24` (255 ips from `10.0.0.1`-`255`) netmask = ` 255.255.255.0` - + `10.0.0.1/16` (65,536 ips from `10.0.0.0` - `10.0.255.255`) netmask = `255.255.0.0` - + `10.0.0.1/8` (16,777,216 ips from `10.0.0.0` - `10.255.255.255`) netmask = `255.0.0.0` + + `192.0.2.1/32` (a single ip address, `192.0.2.1`) netmask = `255.255.255.255` + + `192.0.2.1/24` (255 ips from `192.0.2.1`-`255`) netmask = ` 255.255.255.0` + + `192.0.2.1/16` (65,536 ips from `192.0.2.0` - `192.0.255.255`) netmask = `255.255.0.0` + + `192.0.2.1/8` (16,777,216 ips from `192.0.2.0` - `192.255.255.255`) netmask = `255.0.0.0` + `0.0.0.1/0` (4,294,967,296 ips from `0.0.0.0` - `255.255.255.255`) netmask = `0.0.0.0` + IPv6 CIDR notation is also supported e.g. `2001:DB8::/64` https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing -To people just getting started `10.0.0.1/32` may seem like a weird and confusing way to refer to a single IP. This design is nice though because it allows peers to expose multiple IPs if needed without needing multiple notations. Just know that anywhere you see something like `10.0.0.3/32`, it really just means `10.0.0.3`. +To people just getting started `192.0.2.1/32` may seem like a weird and confusing way to refer to a single IP. This design is nice though because it allows peers to expose multiple IPs if needed without needing multiple notations. Just know that anywhere you see something like `192.0.2.3/32`, it really just means `192.0.2.3`. ### NAT A subnet with private IPs provided by a router standing in front of them doing Network Address Translation, individual nodes are not publicly accessible from the internet, instead the router keeps track of outgoing connections and forwards responses to the correct internal ip (e.g. standard office networks, home wifi networks, free public wifi networks, etc) ### Public Endpoint -The publicly accessible address:port for a node, e.g. `123.124.125.126:1234` or `some.domain.tld:1234` (must be accessible via the public internet, generally can't be a private ip like `10.0.0.1` or `192.168.1.1` unless it's directly accessible using that address by other peers on the same subnet). +The publicly accessible address:port for a node, e.g. `123.124.125.126:1234` or `some.domain.tld:1234` (must be accessible via the public internet, generally can't be a private ip like `192.0.2.1` or `192.168.1.1` unless it's directly accessible using that address by other peers on the same subnet). ### Private key @@ -256,7 +265,7 @@ Public relays are just normal VPN peers that are able to act as an intermediate If all peers are publicly accessible, you don't have to worry about special treatment to make one of them a relay server, it's only needed if you have any peers connecting from behind a NAT. -Each client only needs to define the publicly accessible servers/peers in its config, any traffic bound to other peers behind NATs will go to the catchall VPN subnet (e.g. `10.0.0.1/24`) in the public relays `AllowedIPs` route and will be forwarded accordingly once it hits the relay server. +Each client only needs to define the publicly accessible servers/peers in its config, any traffic bound to other peers behind NATs will go to the catchall VPN subnet (e.g. `192.0.2.1/24`) in the public relays `AllowedIPs` route and will be forwarded accordingly once it hits the relay server. 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. @@ -271,7 +280,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)** While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the srcport, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random srcports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random srcports and sends them back so the clients, this is how WebRTC works in modern P2P web apps. Even with a signalling server and known srcports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random srcport to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated srcport). This is espcially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. -More specific (also usually more direct) routes provided by other peers will take precedence when available, otherwise traffic will fall back to the least specific route and use the `10.0.0.1/24` catchall to forward traffic to the bounce server, where it will in turn be routed by the relay server's system routing table (`net.ipv4.ip_forward = 1`) back down the VPN to the specific peer that's accepting routes for that traffic. Wireguard does not automatically find the fastest route or attempt to form direct connections between peers if not already defined, it just goes from the most specific route in `[Peers]` to least specific. +More specific (also usually more direct) routes provided by other peers will take precedence when available, otherwise traffic will fall back to the least specific route and use the `192.0.2.1/24` catchall to forward traffic to the bounce server, where it will in turn be routed by the relay server's system routing table (`net.ipv4.ip_forward = 1`) back down the VPN to the specific peer that's accepting routes for that traffic. Wireguard does not automatically find the fastest route or attempt to form direct connections between peers if not already defined, it just goes from the most specific route in `[Peers]` to least specific. You can figure out which routing method WireGuard is using for a given address by measuring the ping times to figure out the unique length of each hop, and by inspecting the output of: ```bash @@ -365,14 +374,14 @@ Overview of the general process: 1. Install `apt install wireguard` or `pkg/brew install wireguard-tools` on each node 2. Generate public and private keys locally on each node `wg genkey`+`wg pubkey` 3. Create a `wg0.conf` wireguard config file on the main relay server - - `[Interface]` Make sure to specify a CIDR range for the entire VPN subnet when defining the address the server accepts routes for `Address = 10.0.0.1/24` + - `[Interface]` Make sure to specify a CIDR range for the entire VPN subnet when defining the address the server accepts routes for `Address = 192.0.2.1/24` - `[Peer]` Create a peer section for every client joining the VPN, using their corresponding remote public keys 4. Create a `wg0.conf` on each client node - - `[Interface]` Make sure to specify only a single IP for client peers that don't relay traffic `Address = 10.0.0.3/32`. - - `[Peer]` Create a peer section for each public peer not behind a NAT, make sure to specify a CIDR range for the entire VPN subnet when defining the remote peer acting as the bounce server `AllowedIPs = 10.0.0.1/24`. Make sure to specify individual IPs for remote peers that don't relay traffic and only act as simple clients `AllowedIPs = 10.0.0.3/32`. + - `[Interface]` Make sure to specify only a single IP for client peers that don't relay traffic `Address = 192.0.2.3/32`. + - `[Peer]` Create a peer section for each public peer not behind a NAT, make sure to specify a CIDR range for the entire VPN subnet when defining the remote peer acting as the bounce server `AllowedIPs = 192.0.2.1/24`. Make sure to specify individual IPs for remote peers that don't relay traffic and only act as simple clients `AllowedIPs = 192.0.2.3/32`. 5. Start wireguard on the main relay server with `wg-quick up /full/path/to/wg0.conf` 6. Start wireguard on all the client peers with `wg-quick up /full/path/to/wg0.conf` -7. Traffic is routed from peer to peer using most specific route first over the WireGuard interface, e.g. `ping 10.0.0.3` checks for a direct route to a peer with `AllowedIPs = 10.0.0.3/32` first, then falls back to a relay server that's accepting ips in the whole subnet +7. Traffic is routed from peer to peer using most specific route first over the WireGuard interface, e.g. `ping 192.0.2.3` checks for a direct route to a peer with `AllowedIPs = 192.0.2.3/32` first, then falls back to a relay server that's accepting ips in the whole subnet ### Setup @@ -401,7 +410,7 @@ sudo sysctl -p /etc/sysctl.conf iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT -iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE +iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADE ``` ### Config Creation @@ -437,12 +446,12 @@ ip link add dev wg0 type wireguard ip link delete dev wg0 # register/unregister local VPN address -ip address add dev wg0 10.0.0.3/32 -ip address delete dev wg0 10.0.0.3/32 +ip address add dev wg0 192.0.2.3/32 +ip address delete dev wg0 192.0.2.3/32 # register/unregister VPN route -ip route add 10.0.0.3/32 dev wg0 -ip route delete 10.0.0.3/32 dev wg0 +ip route add 192.0.2.3/32 dev wg0 +ip route delete 192.0.2.3/32 dev wg0 ``` @@ -488,7 +497,7 @@ ip route show table main ip route show table local # show system route to specific address -ip route get 10.0.0.3 +ip route get 192.0.2.3 ``` ### Testing @@ -499,16 +508,16 @@ ip route get 10.0.0.3 ping public-server1.example-vpn.dev # check that the main relay server is available via VPN -ping 10.0.0.1 +ping 192.0.2.1 # check that public peers are available via VPN -ping 10.0.0.2 +ping 192.0.2.2 # check that remote NAT-ed peers are available via VPN -ping 10.0.0.3 +ping 192.0.2.3 # check that NAT-ed peers in your local lan are available via VPN -ping 10.0.0.4 +ping 192.0.2.4 ``` #### Bandwidth @@ -524,19 +533,19 @@ iperf -c public-server1.example-vpn.dev # on local client # check bandwidth over VPN to relay server iperf -s # on public relay server -iperf -c 10.0.0.1 # on local client +iperf -c 192.0.2.1 # on local client # check bandwidth over VPN to remote public peer iperf -s # on remote public peer -iperf -c 10.0.0.2 # on local client +iperf -c 192.0.2.2 # on local client # check bandwidth over VPN to remote NAT-ed peer iperf -s # on remote NAT-ed peer -iperf -c 10.0.0.3 # on local client +iperf -c 192.0.2.3 # on local client # check bandwidth over VPN to local NAT-ed peer (on same LAN) iperf -s # on local NAT-ed peer -iperf -c 10.0.0.4 # on local client +iperf -c 192.0.2.4 # on local client ``` #### DNS @@ -563,7 +572,7 @@ Config files can opt to use the limited set of `wg` config options, or the more ¶ `[Interface]``# Name = node1.example.tld` -¶ `Address = 10.0.0.3/32` +¶ `Address = 192.0.2.3/32``ListenPort = 51820``PrivateKey = localPrivateKeyAbcAbcAbc=``DNS = 1.1.1.1,8.8.8.8` @@ -577,7 +586,7 @@ Config files can opt to use the limited set of `wg` config options, or the more ¶ `[Peer]``# Name = node2-node.example.tld` -¶ `AllowedIPs = 10.0.0.1/24` +¶ `AllowedIPs = 192.0.2.1/24``Endpoint = node1.example.tld:51820``PublicKey = remotePublicKeyAbcAbcAbc=``PersistentKeepalive = 25` @@ -592,14 +601,14 @@ Defines the VPN settings for the local node. ```ini [Interface] # Name = phone.example-vpn.dev -Address = 10.0.0.5/32 +Address = 192.0.2.5/32 PrivateKey = ``` * Node is a public bounce server that can relay traffic to other peers and exposes route for entire VPN subnet ```ini [Interface] # Name = public-server1.example-vpn.tld -Address = 10.0.0.1/24 +Address = 192.0.2.1/24 ListenPort = 51820 PrivateKey = DNS = 1.1.1.1 @@ -611,20 +620,20 @@ This is just a standard comment in INI syntax used to help keep track of which c #### `Address` -Defines what address range the local node should route traffic for. Depending on whether the node is a simple client joining the VPN subnet, or a bounce server that's relaying traffic between multiple clients, this can be set to a single IP of the node itself (specified with CIDR notation), e.g. 10.0.0.3/32), or a range of IPv4/IPv6 subnets that the node can route traffic for. +Defines what address range the local node should route traffic for. Depending on whether the node is a simple client joining the VPN subnet, or a bounce server that's relaying traffic between multiple clients, this can be set to a single IP of the node itself (specified with CIDR notation), e.g. 192.0.2.3/32), or a range of IPv4/IPv6 subnets that the node can route traffic for. **Examples** * Node is a client that only routes traffic for itself -`Address = 10.0.0.3/32` +`Address = 192.0.2.3/32` * Node is a public bounce server that can relay traffic to other peers When the node is acting as the public bounce server, it should set this to be the entire subnet that it can route traffic, not just a single IP for itself. -`Address = 10.0.0.1/24` +`Address = 192.0.2.1/24` * You can also specify multiple subnets or IPv6 subnets like so: -`Address = 10.0.0.1/24,2001:DB8::/64` +`Address = 192.0.2.1/24,2001:DB8::/64` #### `ListenPort` @@ -722,7 +731,7 @@ This option can appear multiple times, as with PreUp `PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE` * Force WireGuard to re-resolve IP address for peer domain -`PostUp = resolvectl domain %i "~."; resolvectl dns %i 10.0.0.1; resolvectl dnssec %i yes` +`PostUp = resolvectl domain %i "~."; resolvectl dns %i 192.0.2.1; resolvectl dnssec %i yes` #### `PreDown` @@ -759,7 +768,7 @@ This option can appear multiple times, as with PreUp Defines the VPN settings for a remote peer capable of routing traffic for one or more addresses (itself and/or other peers). Peers can be either a public bounce server that relays traffic to other peers, or a directly accessible client via lan/internet that is not behind a NAT and only routes traffic for itself. -All clients must be defined as peers on the public bounce server. Simple clients that only route traffic for themselves, only need to define peers for the public relay, and any other nodes directly accessible. Nodes that are behind separate NATs should _not_ be defined as peers outside of the public server config, as no direct route is available between separate NATs. Instead, nodes behind NATs should only define the public relay servers and other public clients as their peers, and should specify `AllowedIPs = 10.0.0.1/24` on the public server that accept routes and bounce traffic for the VPN subnet to the remote NAT-ed peers. +All clients must be defined as peers on the public bounce server. Simple clients that only route traffic for themselves, only need to define peers for the public relay, and any other nodes directly accessible. Nodes that are behind separate NATs should _not_ be defined as peers outside of the public server config, as no direct route is available between separate NATs. 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. In summary, all nodes must be defined on the main bounce server. On client servers, only peers that are directly accessible from a node should be defined as peers of that node, any peers that must be relayed by a bounce sherver should be left out and will be handled by the relay server's catchall route. @@ -788,7 +797,7 @@ In the configuration outlined in the docs below, a single server `public-server1 # Name = public-server2.example-vpn.dev Endpoint = public-server2.example-vpn.dev:51820 PublicKey = -AllowedIPs = 10.0.0.2/32 +AllowedIPs = 192.0.2.2/32 ``` - Peer is a simple client behind a NAT that only routes traffic for itself @@ -797,7 +806,7 @@ AllowedIPs = 10.0.0.2/32 # Name = home-server.example-vpn.dev Endpoint = home-server.example-vpn.dev:51820 PublicKey = -AllowedIPs = 10.0.0.3/32 +AllowedIPs = 192.0.2.3/32 ``` - Peer is a public bounce server that can relay traffic to other peers @@ -807,7 +816,7 @@ AllowedIPs = 10.0.0.3/32 Endpoint = public-server1.example-vpn.tld:51820 PublicKey = # routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 192.0.2.1/24 PersistentKeepalive = 25 ``` @@ -830,25 +839,25 @@ Defines the publicly accessible address for a remote peer. This should be left This defines the IP ranges for which a peer will route traffic. On simple clients, this is usually a single address (the VPN address of the simple client itself). For bounce servers this will be a range of the IPs or subnets that the relay server is capable of routing traffic for. Multiple IPs and subnets may be specified using comma-separated IPv4 or IPv6 CIDR notation (from a single /32 or /128 address, all the way up to `0.0.0.0/0` and `::/0` to indicate a default route to send all internet and VPN traffic through that peer). This option may be specified multiple times. -When deciding how to route a packet, the system chooses the most specific route first, and falls back to broader routes. So for a packet destined to `10.0.0.3`, the system would first look for a peer advertising `10.0.0.3/32` specifically, and would fall back to a peer advertising `10.0.0.1/24` or a larger range like `0.0.0.0/0` as a last resort. +When deciding how to route a packet, the system chooses the most specific route first, and falls back to broader routes. So for a packet destined to `192.0.2.3`, the system would first look for a peer advertising `192.0.2.3/32` specifically, and would fall back to a peer advertising `192.0.2.1/24` or a larger range like `0.0.0.0/0` as a last resort. **Examples** - peer is a simple client that only accepts traffic to/from itself -`AllowedIPs = 10.0.0.3/32` +`AllowedIPs = 192.0.2.3/32` - peer is a relay server that can bounce VPN traffic to all other peers -`AllowedIPs = 10.0.0.1/24` +`AllowedIPs = 192.0.2.1/24` - peer is a relay server that bounces all internet & VPN traffic (like a proxy), including IPv6 `AllowedIPs = 0.0.0.0/0,::/0` - peer is a relay server that routes to itself and only one other peer -`AllowedIPs = 10.0.0.3/32,10.0.0.4/32` +`AllowedIPs = 192.0.2.3/32,192.0.2.4/32` - peer is a relay server that routes to itself and all nodes on its local LAN -`AllowedIPs = 10.0.0.3/32,192.168.1.1/24` +`AllowedIPs = 192.0.2.3/32,192.168.1.1/24` #### `PublicKey` @@ -889,7 +898,7 @@ The examples in these docs primarily use IPv4, but Wireguard natively supports I ```ini [Interface] -AllowedIps = 10.0.0.3/24, 2001:DB8::/64 +AllowedIps = 192.0.2.3/24, 2001:DB8::/64 [Peer] ... @@ -908,7 +917,7 @@ https://www.reddit.com/r/WireGuard/comments/b0m5g2/ipv6_leaks_psa_for_anyone_her ```ini [Interface] # Name = phone.example-vpn.dev -Address = 10.0.0.3/32 +Address = 192.0.2.3/32 PrivateKey = [Peer] @@ -1105,6 +1114,15 @@ Setups can get somewhat complex and are highly dependent on what you're trying t # Example Server-To-Server Config with Roaming Devices +WARNING: **Make sure to change the IP addresses and ranges in your configs before running!** +The blocks used in these examples are reserved for documentation purposes by the IETF and should never be used in real network setups. + + - **`192.0.2.0/24`** (TEST-NET-1) IPv4 example range [RFC5737](https://tools.ietf.org/html/rfc5737) + - **`2001:DB8::/32`** IPv6 example range [RFC3849](https://tools.ietf.org/html/rfc3849) + +You can use any private range you want instead, e.g. `10.0.44.0/24`, just make sure +it doesn't conflict with any of the LAN subnet ranges your peers are on. + The complete example config for the setup below can be found here: https://github.com/pirate/wireguard-docs/tree/master/full-example (WARNING: do not use it on your devices without changing the public/private keys!). ## Overview @@ -1121,15 +1139,15 @@ These 5 devices are used in our example setup to explain how WireGuard supports ### Explanation -This VPN config simulates setting up a small VPN subnet `10.0.0.1/24` shared by 5 nodes. Two of the nodes (public-server1 and public-server2) are VPS instances living in a cloud somewhere, with public IPs accessible to the internet. home-server is a stationary node that lives behind a NAT with a dynamic IP, but it doesn't change frequently. Phone and laptop are both roaming nodes, that can either be at home in the same LAN as home-server, or out-and-about using public wifi or cell service to connect to the VPN. +This VPN config simulates setting up a small VPN subnet `192.0.2.1/24` shared by 5 nodes. Two of the nodes (public-server1 and public-server2) are VPS instances living in a cloud somewhere, with public IPs accessible to the internet. home-server is a stationary node that lives behind a NAT with a dynamic IP, but it doesn't change frequently. Phone and laptop are both roaming nodes, that can either be at home in the same LAN as home-server, or out-and-about using public wifi or cell service to connect to the VPN. Whenever possible, nodes should connect directly to each other, depending on whether nodes are directly accessible or NATs are between them, traffic will route accordingly: ### The Public Relay -`public-server1` acts as an intermediate relay server between any VPN clients behind NATs, it will forward any 10.0.0.1/24 traffic it receives to the correct peer at the system level (WireGuard doesn't care how this happens, it's handled by the kernel `net.ipv4.ip_forward = 1` and the iptables routing rules). +`public-server1` acts as an intermediate relay server between any VPN clients behind NATs, it will forward any 192.0.2.1/24 traffic it receives to the correct peer at the system level (WireGuard doesn't care how this happens, it's handled by the kernel `net.ipv4.ip_forward = 1` and the iptables routing rules). -Each client only needs to define the publicly accessible servers/peers in its config, any traffic bound to other peers behind NATs will go to the catchall `10.0.0.1/24` for the server and will be forwarded accordingly once it hits the main server. +Each client only needs to define the publicly accessible servers/peers in its config, any traffic bound to other peers behind NATs will go to the catchall `192.0.2.1/24` for the server and will be forwarded accordingly once it hits the main server. 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. @@ -1143,8 +1161,8 @@ For more detailed instructions, see the [Quickstart](#Quickstart) guide and API ### public-server1.example-vpn.tld * public endpoint: `public-server1.example-vpn.tld:51820` - * own vpn ip address: `10.0.0.1` - * can accept traffic for ips: `10.0.0.1/24` + * own vpn ip address: `192.0.2.1` + * can accept traffic for ips: `192.0.2.1/24` * priv key: `` * pub key: `` * setup required: @@ -1160,14 +1178,14 @@ For more detailed instructions, see the [Quickstart](#Quickstart) guide and API Endpoint = public-server1.example-vpn.tld:51820 PublicKey = # routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 192.0.2.1/24 PersistentKeepalive = 25 ``` * config as local interface: ```ini [Interface] # Name = public-server1.example-vpn.tld -Address = 10.0.0.1/24 +Address = 192.0.2.1/24 ListenPort = 51820 PrivateKey = DNS = 1.1.1.1 @@ -1177,7 +1195,7 @@ DNS = 1.1.1.1 ```ini [Interface] # Name = public-server1.example-vpn.tld -Address = 10.0.0.1/24 +Address = 192.0.2.1/24 ListenPort = 51820 PrivateKey = DNS = 1.1.1.1 @@ -1186,29 +1204,29 @@ DNS = 1.1.1.1 # Name = public-server2.example-vpn.dev Endpoint = public-server2.example-vpn.dev:51820 PublicKey = -AllowedIPs = 10.0.0.2/32 +AllowedIPs = 192.0.2.2/32 [Peer] # Name = home-server.example-vpn.dev Endpoint = home-server.example-vpn.dev:51820 PublicKey = -AllowedIPs = 10.0.0.3/32 +AllowedIPs = 192.0.2.3/32 [Peer] # Name = laptop.example-vpn.dev PublicKey = -AllowedIPs = 10.0.0.4/32 +AllowedIPs = 192.0.2.4/32 [Peer] # phone.example-vpn.dev PublicKey = -AllowedIPs = 10.0.0.5/32 +AllowedIPs = 192.0.2.5/32 ``` ### public-server2.example-vpn.dev * public endpoint: `public-server2.example-vpn.dev:51820` - * own vpn ip address: `10.0.0.2` - * can accept traffic for ips: `10.0.0.2/32` + * own vpn ip address: `192.0.2.2` + * can accept traffic for ips: `192.0.2.2/32` * priv key: `` * pub key: `` * setup required: @@ -1221,7 +1239,7 @@ AllowedIPs = 10.0.0.5/32 ```ini [Interface] # Name = public-server2.example-vpn.dev -Address = 10.0.0.2/32 +Address = 192.0.2.2/32 ListenPort = 51820 PrivateKey = DNS = 1.1.1.1 @@ -1232,14 +1250,14 @@ DNS = 1.1.1.1 # Name = public-server2.example-vpn.dev Endpoint = public-server2.example-vpn.dev:51820 PublicKey = -AllowedIPs = 10.0.0.2/32 +AllowedIPs = 192.0.2.2/32 ``` * peers: public-server1 * full `wg0.conf` config file for node: ```ini [Interface] # Name = public-server2.example-vpn.dev -Address = 10.0.0.2/32 +Address = 192.0.2.2/32 ListenPort = 51820 PrivateKey = DNS = 1.1.1.1 @@ -1249,14 +1267,14 @@ DNS = 1.1.1.1 Endpoint = public-server1.example-vpn.tld:51820 PublicKey = # routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 192.0.2.1/24 PersistentKeepalive = 25 ``` ### home-server.example-vpn.dev * public endpoint: (none, behind NAT) - * own vpn ip address: `10.0.0.3` - * can accept traffic for ips: `10.0.0.3/32` + * own vpn ip address: `192.0.2.3` + * can accept traffic for ips: `192.0.2.3/32` * priv key: `` * pub key: `` * setup required: @@ -1269,7 +1287,7 @@ PersistentKeepalive = 25 ```ini [Interface] # Name = home-server.example-vpn.dev -Address = 10.0.0.3/32 +Address = 192.0.2.3/32 ListenPort = 51820 PrivateKey = DNS = 1.1.1.1 @@ -1280,14 +1298,14 @@ DNS = 1.1.1.1 # Name = home-server.example-vpn.dev Endpoint = home-server.example-vpn.dev:51820 PublicKey = -AllowedIPs = 10.0.0.3/32 +AllowedIPs = 192.0.2.3/32 ``` * peers: public-server1 * full `wg0.conf` config file for node: ```ini [Interface] # Name = home-server.example-vpn.dev -Address = 10.0.0.3/32 +Address = 192.0.2.3/32 ListenPort = 51820 PrivateKey = DNS = 1.1.1.1 @@ -1297,14 +1315,14 @@ DNS = 1.1.1.1 Endpoint = public-server1.example-vpn.tld:51820 PublicKey = # routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 192.0.2.1/24 PersistentKeepalive = 25 ``` ### laptop.example-vpn.dev * public endpoint: (none, behind NAT) - * own vpn ip address: `10.0.0.4` - * can accept traffic for ips: `10.0.0.4/32` + * own vpn ip address: `192.0.2.4` + * can accept traffic for ips: `192.0.2.4/32` * priv key: `` * pub key: `` * setup required: @@ -1317,7 +1335,7 @@ PersistentKeepalive = 25 ```ini [Interface] # Name = laptop.example-vpn.dev -Address = 10.0.0.4/32 +Address = 192.0.2.4/32 PrivateKey = DNS = 1.1.1.1 ``` @@ -1326,14 +1344,14 @@ DNS = 1.1.1.1 [Peer] # Name = laptop.example-vpn.dev PublicKey = -AllowedIPs = 10.0.0.4/32 +AllowedIPs = 192.0.2.4/32 ``` * peers: public-server1 * full `wg0.conf` config file for node: ```ini [Interface] # Name = laptop.example-vpn.dev -Address = 10.0.0.4/32 +Address = 192.0.2.4/32 PrivateKey = DNS = 1.1.1.1 @@ -1342,14 +1360,14 @@ DNS = 1.1.1.1 Endpoint = public-server1.example-vpn.tld:51820 PublicKey = # routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 192.0.2.1/24 PersistentKeepalive = 25 ``` ### phone.example-vpn.dev * public endpoint: (none, behind NAT) - * own vpn ip address: `10.0.0.5` - * can accept traffic for ips: `10.0.0.5/32` + * own vpn ip address: `192.0.2.5` + * can accept traffic for ips: `192.0.2.5/32` * priv key: `` * pub key: `` * setup required: @@ -1362,7 +1380,7 @@ PersistentKeepalive = 25 ```ini [Interface] # Name = phone.example-vpn.dev -Address = 10.0.0.5/32 +Address = 192.0.2.5/32 PrivateKey = DNS = 1.1.1.1 ``` @@ -1371,14 +1389,14 @@ DNS = 1.1.1.1 [Peer] # phone.example-vpn.dev PublicKey = -AllowedIPs = 10.0.0.5/32 +AllowedIPs = 192.0.2.5/32 ``` * peers: public-server1 * full `wg0.conf` config file for node: ```ini [Interface] # Name = phone.example-vpn.dev -Address = 10.0.0.5/32 +Address = 192.0.2.5/32 PrivateKey = DNS = 1.1.1.1 @@ -1387,7 +1405,7 @@ DNS = 1.1.1.1 Endpoint = public-server1.example-vpn.tld:51820 PublicKey = # routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 192.0.2.1/24 PersistentKeepalive = 25 ``` From 9ec86c0e0f10e01d6b79e623b628fe58b4efd6c2 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Mon, 24 Jun 2019 05:43:36 -0400 Subject: [PATCH 14/72] move examples to folders --- README.md | 341 +----------------- example-full/README.md | 303 ++++++++++++++++ .../home-server/home-server.key | 0 .../home-server/home-server.key.pub | 0 .../home-server/setup.sh | 0 .../home-server/start.sh | 0 .../home-server/stop.sh | 0 .../home-server/wg0.conf | 0 .../laptop/laptop.key | 0 .../laptop/laptop.key.pub | 0 .../laptop/setup.sh | 0 .../laptop/start.sh | 0 {full-example => example-full}/laptop/stop.sh | 0 .../laptop/wg0.conf | 0 .../phone/phone.key | 0 .../phone/phone.key.pub | 0 {full-example => example-full}/phone/setup.sh | 0 {full-example => example-full}/phone/start.sh | 0 {full-example => example-full}/phone/stop.sh | 0 {full-example => example-full}/phone/wg0.conf | 0 .../public-server1/public-server1.key | 0 .../public-server1/public-server1.key.pub | 0 .../public-server1/setup.sh | 0 .../public-server1/start.sh | 0 .../public-server1/stop.sh | 0 .../public-server1/wg0.conf | 0 .../public-server2/public-server2.key | 0 .../public-server2/public-server2.key.pub | 0 .../public-server2/setup.sh | 0 .../public-server2/start.sh | 0 .../public-server2/stop.sh | 0 .../public-server2/wg0.conf | 0 .../laptop/laptop.key | 1 + .../laptop/laptop.key.pub | 1 + example-internet-browsing-vpn/laptop/setup.sh | 9 + example-internet-browsing-vpn/laptop/start.sh | 5 + example-internet-browsing-vpn/laptop/stop.sh | 5 + example-internet-browsing-vpn/laptop/wg0.conf | 13 + example-internet-browsing-vpn/phone/phone.key | 1 + .../phone/phone.key.pub | 1 + example-internet-browsing-vpn/phone/setup.sh | 4 + example-internet-browsing-vpn/phone/start.sh | 3 + example-internet-browsing-vpn/phone/stop.sh | 3 + example-internet-browsing-vpn/phone/wg0.conf | 13 + .../server/public-server1.key | 1 + .../server/public-server1.key.pub | 1 + example-internet-browsing-vpn/server/setup.sh | 17 + example-internet-browsing-vpn/server/start.sh | 5 + example-internet-browsing-vpn/server/stop.sh | 5 + example-internet-browsing-vpn/server/wg0.conf | 28 ++ .../montreal/public-server1.key | 1 + .../montreal/public-server1.key.pub | 1 + example-lan-briding/montreal/setup.sh | 17 + example-lan-briding/montreal/start.sh | 5 + example-lan-briding/montreal/stop.sh | 5 + example-lan-briding/montreal/wg0.conf | 28 ++ .../newyork/public-server2.key | 1 + .../newyork/public-server2.key.pub | 1 + example-lan-briding/newyork/setup.sh | 6 + example-lan-briding/newyork/start.sh | 5 + example-lan-briding/newyork/stop.sh | 5 + example-lan-briding/newyork/wg0.conf | 14 + .../vancouver/public-server1.key | 1 + .../vancouver/public-server1.key.pub | 1 + example-lan-briding/vancouver/setup.sh | 17 + example-lan-briding/vancouver/start.sh | 5 + example-lan-briding/vancouver/stop.sh | 5 + example-lan-briding/vancouver/wg0.conf | 28 ++ .../client/laptop.key | 1 + .../client/laptop.key.pub | 1 + .../client/setup.sh | 9 + .../client/start.sh | 5 + .../client/stop.sh | 5 + .../client/wg0.conf | 13 + .../server/public-server1.key | 1 + .../server/public-server1.key.pub | 1 + .../server/setup.sh | 17 + .../server/start.sh | 5 + .../server/stop.sh | 5 + .../server/wg0.conf | 28 ++ .../home-server/home-server.key | 1 + .../home-server/home-server.key.pub | 1 + .../home-server/setup.sh | 9 + .../home-server/start.sh | 5 + .../home-server/stop.sh | 5 + .../home-server/wg0.conf | 14 + .../laptop/laptop.key | 1 + .../laptop/laptop.key.pub | 1 + .../laptop/setup.sh | 9 + .../laptop/start.sh | 5 + .../laptop/stop.sh | 5 + .../laptop/wg0.conf | 13 + .../phone/phone.key | 1 + .../phone/phone.key.pub | 1 + .../phone/setup.sh | 4 + .../phone/start.sh | 3 + example-simple-server-to-server/phone/stop.sh | 3 + .../phone/wg0.conf | 13 + .../public-server1/public-server1.key | 1 + .../public-server1/public-server1.key.pub | 1 + .../public-server1/setup.sh | 17 + .../public-server1/start.sh | 5 + .../public-server1/stop.sh | 5 + .../public-server1/wg0.conf | 28 ++ .../public-server2/public-server2.key | 1 + .../public-server2/public-server2.key.pub | 1 + .../public-server2/setup.sh | 6 + .../public-server2/start.sh | 5 + .../public-server2/stop.sh | 5 + .../public-server2/wg0.conf | 14 + 110 files changed, 855 insertions(+), 325 deletions(-) create mode 100644 example-full/README.md rename {full-example => example-full}/home-server/home-server.key (100%) rename {full-example => example-full}/home-server/home-server.key.pub (100%) rename {full-example => example-full}/home-server/setup.sh (100%) rename {full-example => example-full}/home-server/start.sh (100%) rename {full-example => example-full}/home-server/stop.sh (100%) rename {full-example => example-full}/home-server/wg0.conf (100%) rename {full-example => example-full}/laptop/laptop.key (100%) rename {full-example => example-full}/laptop/laptop.key.pub (100%) rename {full-example => example-full}/laptop/setup.sh (100%) rename {full-example => example-full}/laptop/start.sh (100%) rename {full-example => example-full}/laptop/stop.sh (100%) rename {full-example => example-full}/laptop/wg0.conf (100%) rename {full-example => example-full}/phone/phone.key (100%) rename {full-example => example-full}/phone/phone.key.pub (100%) rename {full-example => example-full}/phone/setup.sh (100%) rename {full-example => example-full}/phone/start.sh (100%) rename {full-example => example-full}/phone/stop.sh (100%) rename {full-example => example-full}/phone/wg0.conf (100%) rename {full-example => example-full}/public-server1/public-server1.key (100%) rename {full-example => example-full}/public-server1/public-server1.key.pub (100%) rename {full-example => example-full}/public-server1/setup.sh (100%) rename {full-example => example-full}/public-server1/start.sh (100%) rename {full-example => example-full}/public-server1/stop.sh (100%) rename {full-example => example-full}/public-server1/wg0.conf (100%) rename {full-example => example-full}/public-server2/public-server2.key (100%) rename {full-example => example-full}/public-server2/public-server2.key.pub (100%) rename {full-example => example-full}/public-server2/setup.sh (100%) rename {full-example => example-full}/public-server2/start.sh (100%) rename {full-example => example-full}/public-server2/stop.sh (100%) rename {full-example => example-full}/public-server2/wg0.conf (100%) create mode 100644 example-internet-browsing-vpn/laptop/laptop.key create mode 100644 example-internet-browsing-vpn/laptop/laptop.key.pub create mode 100644 example-internet-browsing-vpn/laptop/setup.sh create mode 100644 example-internet-browsing-vpn/laptop/start.sh create mode 100644 example-internet-browsing-vpn/laptop/stop.sh create mode 100644 example-internet-browsing-vpn/laptop/wg0.conf create mode 100644 example-internet-browsing-vpn/phone/phone.key create mode 100644 example-internet-browsing-vpn/phone/phone.key.pub create mode 100644 example-internet-browsing-vpn/phone/setup.sh create mode 100644 example-internet-browsing-vpn/phone/start.sh create mode 100644 example-internet-browsing-vpn/phone/stop.sh create mode 100644 example-internet-browsing-vpn/phone/wg0.conf create mode 100644 example-internet-browsing-vpn/server/public-server1.key create mode 100644 example-internet-browsing-vpn/server/public-server1.key.pub create mode 100644 example-internet-browsing-vpn/server/setup.sh create mode 100644 example-internet-browsing-vpn/server/start.sh create mode 100644 example-internet-browsing-vpn/server/stop.sh create mode 100644 example-internet-browsing-vpn/server/wg0.conf create mode 100644 example-lan-briding/montreal/public-server1.key create mode 100644 example-lan-briding/montreal/public-server1.key.pub create mode 100644 example-lan-briding/montreal/setup.sh create mode 100644 example-lan-briding/montreal/start.sh create mode 100644 example-lan-briding/montreal/stop.sh create mode 100644 example-lan-briding/montreal/wg0.conf create mode 100644 example-lan-briding/newyork/public-server2.key create mode 100644 example-lan-briding/newyork/public-server2.key.pub create mode 100644 example-lan-briding/newyork/setup.sh create mode 100644 example-lan-briding/newyork/start.sh create mode 100644 example-lan-briding/newyork/stop.sh create mode 100644 example-lan-briding/newyork/wg0.conf create mode 100644 example-lan-briding/vancouver/public-server1.key create mode 100644 example-lan-briding/vancouver/public-server1.key.pub create mode 100644 example-lan-briding/vancouver/setup.sh create mode 100644 example-lan-briding/vancouver/start.sh create mode 100644 example-lan-briding/vancouver/stop.sh create mode 100644 example-lan-briding/vancouver/wg0.conf create mode 100644 example-simple-client-to-server/client/laptop.key create mode 100644 example-simple-client-to-server/client/laptop.key.pub create mode 100644 example-simple-client-to-server/client/setup.sh create mode 100644 example-simple-client-to-server/client/start.sh create mode 100644 example-simple-client-to-server/client/stop.sh create mode 100644 example-simple-client-to-server/client/wg0.conf create mode 100644 example-simple-client-to-server/server/public-server1.key create mode 100644 example-simple-client-to-server/server/public-server1.key.pub create mode 100644 example-simple-client-to-server/server/setup.sh create mode 100644 example-simple-client-to-server/server/start.sh create mode 100644 example-simple-client-to-server/server/stop.sh create mode 100644 example-simple-client-to-server/server/wg0.conf create mode 100644 example-simple-server-to-server/home-server/home-server.key create mode 100644 example-simple-server-to-server/home-server/home-server.key.pub create mode 100644 example-simple-server-to-server/home-server/setup.sh create mode 100644 example-simple-server-to-server/home-server/start.sh create mode 100644 example-simple-server-to-server/home-server/stop.sh create mode 100644 example-simple-server-to-server/home-server/wg0.conf create mode 100644 example-simple-server-to-server/laptop/laptop.key create mode 100644 example-simple-server-to-server/laptop/laptop.key.pub create mode 100644 example-simple-server-to-server/laptop/setup.sh create mode 100644 example-simple-server-to-server/laptop/start.sh create mode 100644 example-simple-server-to-server/laptop/stop.sh create mode 100644 example-simple-server-to-server/laptop/wg0.conf create mode 100644 example-simple-server-to-server/phone/phone.key create mode 100644 example-simple-server-to-server/phone/phone.key.pub create mode 100644 example-simple-server-to-server/phone/setup.sh create mode 100644 example-simple-server-to-server/phone/start.sh create mode 100644 example-simple-server-to-server/phone/stop.sh create mode 100644 example-simple-server-to-server/phone/wg0.conf create mode 100644 example-simple-server-to-server/public-server1/public-server1.key create mode 100644 example-simple-server-to-server/public-server1/public-server1.key.pub create mode 100644 example-simple-server-to-server/public-server1/setup.sh create mode 100644 example-simple-server-to-server/public-server1/start.sh create mode 100644 example-simple-server-to-server/public-server1/stop.sh create mode 100644 example-simple-server-to-server/public-server1/wg0.conf create mode 100644 example-simple-server-to-server/public-server2/public-server2.key create mode 100644 example-simple-server-to-server/public-server2/public-server2.key.pub create mode 100644 example-simple-server-to-server/public-server2/setup.sh create mode 100644 example-simple-server-to-server/public-server2/start.sh create mode 100644 example-simple-server-to-server/public-server2/stop.sh create mode 100644 example-simple-server-to-server/public-server2/wg0.conf diff --git a/README.md b/README.md index ff34b9e..8dfc7cf 100644 --- a/README.md +++ b/README.md @@ -57,13 +57,16 @@ See https://github.com/pirate/wireguard-docs for example code and documentation
  • Table of Contents
    • -
  • Intro
      +
    • Intro +
      • -
    • Wireguard Documentation
        -
      • Glossary
          +
        • Wireguard Documentation +
            +
          • Glossary +
            • -
          • How WireGuard Works
              +
            • How WireGuard Works +
              • -
            • Usage
                +
              • Usage +
                • -
              • Config Reference
                  +
                • Config Reference +
                  • -
                • Advanced Topics
                    +
                  • Advanced Topics +
                    • -
                  • Example Server-To-Server Config with Roaming Devices -
                    • -
                  • Further Reading
                      +
                    • Further Reading +
                      • Reference Docs
                      • Tutorials
                      • Papers, Articles, and Talks
                        • @@ -1112,305 +1102,6 @@ Setups can get somewhat complex and are highly dependent on what you're trying t --- -# Example Server-To-Server Config with Roaming Devices - -WARNING: **Make sure to change the IP addresses and ranges in your configs before running!** -The blocks used in these examples are reserved for documentation purposes by the IETF and should never be used in real network setups. - - - **`192.0.2.0/24`** (TEST-NET-1) IPv4 example range [RFC5737](https://tools.ietf.org/html/rfc5737) - - **`2001:DB8::/32`** IPv6 example range [RFC3849](https://tools.ietf.org/html/rfc3849) - -You can use any private range you want instead, e.g. `10.0.44.0/24`, just make sure -it doesn't conflict with any of the LAN subnet ranges your peers are on. - -The complete example config for the setup below can be found here: https://github.com/pirate/wireguard-docs/tree/master/full-example (WARNING: do not use it on your devices without changing the public/private keys!). - -## Overview - -### Network Topology - -These 5 devices are used in our example setup to explain how WireGuard supports bridging across a variety of network conditions, they're all under an example domain `example-vpn.dev`, with the following short hostnames: - -- `public-server1` (not behind a NAT, acts as the main VPN bounce server) -- `public-server2` (not behind a NAT, joins as a peer without bouncing traffic) -- `home-server` (behind a NAT, joins as a peer without bouncing traffic) -- `laptop` (behind NAT, sometimes shared w/ home-server/phone, sometimes roaming) -- `phone` (behind NAT, sometimes shared w/ home-server/laptop, sometimes roaming) - -### Explanation - -This VPN config simulates setting up a small VPN subnet `192.0.2.1/24` shared by 5 nodes. Two of the nodes (public-server1 and public-server2) are VPS instances living in a cloud somewhere, with public IPs accessible to the internet. home-server is a stationary node that lives behind a NAT with a dynamic IP, but it doesn't change frequently. Phone and laptop are both roaming nodes, that can either be at home in the same LAN as home-server, or out-and-about using public wifi or cell service to connect to the VPN. - -Whenever possible, nodes should connect directly to each other, depending on whether nodes are directly accessible or NATs are between them, traffic will route accordingly: - -### The Public Relay - -`public-server1` acts as an intermediate relay server between any VPN clients behind NATs, it will forward any 192.0.2.1/24 traffic it receives to the correct peer at the system level (WireGuard doesn't care how this happens, it's handled by the kernel `net.ipv4.ip_forward = 1` and the iptables routing rules). - -Each client only needs to define the publicly accessible servers/peers in its config, any traffic bound to other peers behind NATs will go to the catchall `192.0.2.1/24` for the server and will be forwarded accordingly once it hits the main server. - -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. - -## Full Example Code - -To run this full example, simply copy the `full wg0.conf config file for node` section from each node onto each server, enable IP forwarding on the public relay, and then start WireGuard on all the machines. - -For more detailed instructions, see the [Quickstart](#Quickstart) guide and API reference above. You can also download the complete example setup here: https://github.com/pirate/wireguard-docs/tree/master/full-example (WARNING: do not use it on your devices without changing the public/private keys!). - -## Node Config - -### public-server1.example-vpn.tld - * public endpoint: `public-server1.example-vpn.tld:51820` - * own vpn ip address: `192.0.2.1` - * can accept traffic for ips: `192.0.2.1/24` - * priv key: `` - * pub key: `` - * setup required: - 1. install wireguard - 2. generate public/private keypair - 3. create wg0.conf (see below) - 4. enable kernel ip & arp forwarding, add iptables forwarding rules - 5. start wireguard - * config as remote peer: -```ini -[Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 -PublicKey = -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 192.0.2.1/24 -PersistentKeepalive = 25 -``` - * config as local interface: -```ini -[Interface] -# Name = public-server1.example-vpn.tld -Address = 192.0.2.1/24 -ListenPort = 51820 -PrivateKey = -DNS = 1.1.1.1 -``` - * peers: public-server2, home-server, laptop, phone - * full `wg0.conf` config file for node: -```ini -[Interface] -# Name = public-server1.example-vpn.tld -Address = 192.0.2.1/24 -ListenPort = 51820 -PrivateKey = -DNS = 1.1.1.1 - -[Peer] -# Name = public-server2.example-vpn.dev -Endpoint = public-server2.example-vpn.dev:51820 -PublicKey = -AllowedIPs = 192.0.2.2/32 - -[Peer] -# Name = home-server.example-vpn.dev -Endpoint = home-server.example-vpn.dev:51820 -PublicKey = -AllowedIPs = 192.0.2.3/32 - -[Peer] -# Name = laptop.example-vpn.dev -PublicKey = -AllowedIPs = 192.0.2.4/32 - -[Peer] -# phone.example-vpn.dev -PublicKey = -AllowedIPs = 192.0.2.5/32 -``` - -### public-server2.example-vpn.dev - * public endpoint: `public-server2.example-vpn.dev:51820` - * own vpn ip address: `192.0.2.2` - * can accept traffic for ips: `192.0.2.2/32` - * priv key: `` - * pub key: `` - * setup required: - 1. install wireguard - 2. generate public/private keypair - 3. create wg0.conf (see below) - 4. confirm main public relay server is directly accessible - 4. start wireguard - * config as local interface: -```ini -[Interface] -# Name = public-server2.example-vpn.dev -Address = 192.0.2.2/32 -ListenPort = 51820 -PrivateKey = -DNS = 1.1.1.1 -``` - * config as peer: -```ini -[Peer] -# Name = public-server2.example-vpn.dev -Endpoint = public-server2.example-vpn.dev:51820 -PublicKey = -AllowedIPs = 192.0.2.2/32 -``` - * peers: public-server1 - * full `wg0.conf` config file for node: -```ini -[Interface] -# Name = public-server2.example-vpn.dev -Address = 192.0.2.2/32 -ListenPort = 51820 -PrivateKey = -DNS = 1.1.1.1 - -[Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 -PublicKey = -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 192.0.2.1/24 -PersistentKeepalive = 25 -``` - -### home-server.example-vpn.dev - * public endpoint: (none, behind NAT) - * own vpn ip address: `192.0.2.3` - * can accept traffic for ips: `192.0.2.3/32` - * priv key: `` - * pub key: `` - * setup required: - 1. install wireguard - 2. generate public/private keypair - 3. create wg0.conf (see below) - 4. confirm main public relay server is directly accessible - 4. start wireguard - * config as local interface: -```ini -[Interface] -# Name = home-server.example-vpn.dev -Address = 192.0.2.3/32 -ListenPort = 51820 -PrivateKey = -DNS = 1.1.1.1 -``` - * config as peer: -```ini -[Peer] -# Name = home-server.example-vpn.dev -Endpoint = home-server.example-vpn.dev:51820 -PublicKey = -AllowedIPs = 192.0.2.3/32 -``` - * peers: public-server1 - * full `wg0.conf` config file for node: -```ini -[Interface] -# Name = home-server.example-vpn.dev -Address = 192.0.2.3/32 -ListenPort = 51820 -PrivateKey = -DNS = 1.1.1.1 - -[Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 -PublicKey = -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 192.0.2.1/24 -PersistentKeepalive = 25 -``` - -### laptop.example-vpn.dev - * public endpoint: (none, behind NAT) - * own vpn ip address: `192.0.2.4` - * can accept traffic for ips: `192.0.2.4/32` - * priv key: `` - * pub key: `` - * setup required: - 1. install wireguard - 2. generate public/private keypair - 3. create wg0.conf (see below) - 4. confirm main public relay server is directly accessible - 4. start wireguard - * config as local interface: -```ini -[Interface] -# Name = laptop.example-vpn.dev -Address = 192.0.2.4/32 -PrivateKey = -DNS = 1.1.1.1 -``` - * config as peer: -```ini -[Peer] -# Name = laptop.example-vpn.dev -PublicKey = -AllowedIPs = 192.0.2.4/32 -``` - * peers: public-server1 - * full `wg0.conf` config file for node: -```ini -[Interface] -# Name = laptop.example-vpn.dev -Address = 192.0.2.4/32 -PrivateKey = -DNS = 1.1.1.1 - -[Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 -PublicKey = -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 192.0.2.1/24 -PersistentKeepalive = 25 -``` - -### phone.example-vpn.dev - * public endpoint: (none, behind NAT) - * own vpn ip address: `192.0.2.5` - * can accept traffic for ips: `192.0.2.5/32` - * priv key: `` - * pub key: `` - * setup required: - 1. install wireguard - 2. generate public/private keypair - 3. create wg0.conf (see below) - 4. confirm main public relay server is directly accessible - 4. start wireguard - * config as local interface: -```ini -[Interface] -# Name = phone.example-vpn.dev -Address = 192.0.2.5/32 -PrivateKey = -DNS = 1.1.1.1 -``` - * config as peer: -```ini -[Peer] -# phone.example-vpn.dev -PublicKey = -AllowedIPs = 192.0.2.5/32 -``` - * peers: public-server1 - * full `wg0.conf` config file for node: -```ini -[Interface] -# Name = phone.example-vpn.dev -Address = 192.0.2.5/32 -PrivateKey = -DNS = 1.1.1.1 - -[Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 -PublicKey = -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 192.0.2.1/24 -PersistentKeepalive = 25 -``` - ---- - # Further Reading ### Reference Docs diff --git a/example-full/README.md b/example-full/README.md new file mode 100644 index 0000000..1216dc8 --- /dev/null +++ b/example-full/README.md @@ -0,0 +1,303 @@ +# Example Server-To-Server Config with Roaming Devices + +WARNING: **Make sure to change the IP addresses and ranges in your configs before running!** +The blocks used in these examples are reserved for documentation purposes by the IETF and should never be used in real network setups. + + - **`192.0.2.0/24`** (TEST-NET-1) IPv4 example range [RFC5737](https://tools.ietf.org/html/rfc5737) + - **`2001:DB8::/32`** IPv6 example range [RFC3849](https://tools.ietf.org/html/rfc3849) + +You can use any private range you want instead, e.g. `10.0.44.0/24`, just make sure +it doesn't conflict with any of the LAN subnet ranges your peers are on. + +The complete example config for the setup below can be found here: https://github.com/pirate/wireguard-docs/tree/master/full-example (WARNING: do not use it on your devices without changing the public/private keys!). + +## Overview + +### Network Topology + +These 5 devices are used in our example setup to explain how WireGuard supports bridging across a variety of network conditions, they're all under an example domain `example-vpn.dev`, with the following short hostnames: + +- `public-server1` (not behind a NAT, acts as the main VPN bounce server) +- `public-server2` (not behind a NAT, joins as a peer without bouncing traffic) +- `home-server` (behind a NAT, joins as a peer without bouncing traffic) +- `laptop` (behind NAT, sometimes shared w/ home-server/phone, sometimes roaming) +- `phone` (behind NAT, sometimes shared w/ home-server/laptop, sometimes roaming) + +### Explanation + +This VPN config simulates setting up a small VPN subnet `192.0.2.1/24` shared by 5 nodes. Two of the nodes (public-server1 and public-server2) are VPS instances living in a cloud somewhere, with public IPs accessible to the internet. home-server is a stationary node that lives behind a NAT with a dynamic IP, but it doesn't change frequently. Phone and laptop are both roaming nodes, that can either be at home in the same LAN as home-server, or out-and-about using public wifi or cell service to connect to the VPN. + +Whenever possible, nodes should connect directly to each other, depending on whether nodes are directly accessible or NATs are between them, traffic will route accordingly: + +### The Public Relay + +`public-server1` acts as an intermediate relay server between any VPN clients behind NATs, it will forward any 192.0.2.1/24 traffic it receives to the correct peer at the system level (WireGuard doesn't care how this happens, it's handled by the kernel `net.ipv4.ip_forward = 1` and the iptables routing rules). + +Each client only needs to define the publicly accessible servers/peers in its config, any traffic bound to other peers behind NATs will go to the catchall `192.0.2.1/24` for the server and will be forwarded accordingly once it hits the main server. + +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. + +## Full Example Code + +To run this full example, simply copy the `full wg0.conf config file for node` section from each node onto each server, enable IP forwarding on the public relay, and then start WireGuard on all the machines. + +For more detailed instructions, see the [Quickstart](#Quickstart) guide and API reference above. You can also download the complete example setup here: https://github.com/pirate/wireguard-docs/tree/master/full-example (WARNING: do not use it on your devices without changing the public/private keys!). + +## Node Config + +### public-server1.example-vpn.tld + * public endpoint: `public-server1.example-vpn.tld:51820` + * own vpn ip address: `192.0.2.1` + * can accept traffic for ips: `192.0.2.1/24` + * priv key: `` + * pub key: `` + * setup required: + 1. install wireguard + 2. generate public/private keypair + 3. create wg0.conf (see below) + 4. enable kernel ip & arp forwarding, add iptables forwarding rules + 5. start wireguard + * config as remote peer: +```ini +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 192.0.2.1/24 +PersistentKeepalive = 25 +``` + * config as local interface: +```ini +[Interface] +# Name = public-server1.example-vpn.tld +Address = 192.0.2.1/24 +ListenPort = 51820 +PrivateKey = +DNS = 1.1.1.1 +``` + * peers: public-server2, home-server, laptop, phone + * full `wg0.conf` config file for node: +```ini +[Interface] +# Name = public-server1.example-vpn.tld +Address = 192.0.2.1/24 +ListenPort = 51820 +PrivateKey = +DNS = 1.1.1.1 + +[Peer] +# Name = public-server2.example-vpn.dev +Endpoint = public-server2.example-vpn.dev:51820 +PublicKey = +AllowedIPs = 192.0.2.2/32 + +[Peer] +# Name = home-server.example-vpn.dev +Endpoint = home-server.example-vpn.dev:51820 +PublicKey = +AllowedIPs = 192.0.2.3/32 + +[Peer] +# Name = laptop.example-vpn.dev +PublicKey = +AllowedIPs = 192.0.2.4/32 + +[Peer] +# phone.example-vpn.dev +PublicKey = +AllowedIPs = 192.0.2.5/32 +``` + +### public-server2.example-vpn.dev + * public endpoint: `public-server2.example-vpn.dev:51820` + * own vpn ip address: `192.0.2.2` + * can accept traffic for ips: `192.0.2.2/32` + * priv key: `` + * pub key: `` + * setup required: + 1. install wireguard + 2. generate public/private keypair + 3. create wg0.conf (see below) + 4. confirm main public relay server is directly accessible + 4. start wireguard + * config as local interface: +```ini +[Interface] +# Name = public-server2.example-vpn.dev +Address = 192.0.2.2/32 +ListenPort = 51820 +PrivateKey = +DNS = 1.1.1.1 +``` + * config as peer: +```ini +[Peer] +# Name = public-server2.example-vpn.dev +Endpoint = public-server2.example-vpn.dev:51820 +PublicKey = +AllowedIPs = 192.0.2.2/32 +``` + * peers: public-server1 + * full `wg0.conf` config file for node: +```ini +[Interface] +# Name = public-server2.example-vpn.dev +Address = 192.0.2.2/32 +ListenPort = 51820 +PrivateKey = +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 192.0.2.1/24 +PersistentKeepalive = 25 +``` + +### home-server.example-vpn.dev + * public endpoint: (none, behind NAT) + * own vpn ip address: `192.0.2.3` + * can accept traffic for ips: `192.0.2.3/32` + * priv key: `` + * pub key: `` + * setup required: + 1. install wireguard + 2. generate public/private keypair + 3. create wg0.conf (see below) + 4. confirm main public relay server is directly accessible + 4. start wireguard + * config as local interface: +```ini +[Interface] +# Name = home-server.example-vpn.dev +Address = 192.0.2.3/32 +ListenPort = 51820 +PrivateKey = +DNS = 1.1.1.1 +``` + * config as peer: +```ini +[Peer] +# Name = home-server.example-vpn.dev +Endpoint = home-server.example-vpn.dev:51820 +PublicKey = +AllowedIPs = 192.0.2.3/32 +``` + * peers: public-server1 + * full `wg0.conf` config file for node: +```ini +[Interface] +# Name = home-server.example-vpn.dev +Address = 192.0.2.3/32 +ListenPort = 51820 +PrivateKey = +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 192.0.2.1/24 +PersistentKeepalive = 25 +``` + +### laptop.example-vpn.dev + * public endpoint: (none, behind NAT) + * own vpn ip address: `192.0.2.4` + * can accept traffic for ips: `192.0.2.4/32` + * priv key: `` + * pub key: `` + * setup required: + 1. install wireguard + 2. generate public/private keypair + 3. create wg0.conf (see below) + 4. confirm main public relay server is directly accessible + 4. start wireguard + * config as local interface: +```ini +[Interface] +# Name = laptop.example-vpn.dev +Address = 192.0.2.4/32 +PrivateKey = +DNS = 1.1.1.1 +``` + * config as peer: +```ini +[Peer] +# Name = laptop.example-vpn.dev +PublicKey = +AllowedIPs = 192.0.2.4/32 +``` + * peers: public-server1 + * full `wg0.conf` config file for node: +```ini +[Interface] +# Name = laptop.example-vpn.dev +Address = 192.0.2.4/32 +PrivateKey = +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 192.0.2.1/24 +PersistentKeepalive = 25 +``` + +### phone.example-vpn.dev + * public endpoint: (none, behind NAT) + * own vpn ip address: `192.0.2.5` + * can accept traffic for ips: `192.0.2.5/32` + * priv key: `` + * pub key: `` + * setup required: + 1. install wireguard + 2. generate public/private keypair + 3. create wg0.conf (see below) + 4. confirm main public relay server is directly accessible + 4. start wireguard + * config as local interface: +```ini +[Interface] +# Name = phone.example-vpn.dev +Address = 192.0.2.5/32 +PrivateKey = +DNS = 1.1.1.1 +``` + * config as peer: +```ini +[Peer] +# phone.example-vpn.dev +PublicKey = +AllowedIPs = 192.0.2.5/32 +``` + * peers: public-server1 + * full `wg0.conf` config file for node: +```ini +[Interface] +# Name = phone.example-vpn.dev +Address = 192.0.2.5/32 +PrivateKey = +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 192.0.2.1/24 +PersistentKeepalive = 25 +``` + + +
                        + +Suggest changes: https://github.com/pirate/wireguard-docs/issues + +
                        diff --git a/full-example/home-server/home-server.key b/example-full/home-server/home-server.key similarity index 100% rename from full-example/home-server/home-server.key rename to example-full/home-server/home-server.key diff --git a/full-example/home-server/home-server.key.pub b/example-full/home-server/home-server.key.pub similarity index 100% rename from full-example/home-server/home-server.key.pub rename to example-full/home-server/home-server.key.pub diff --git a/full-example/home-server/setup.sh b/example-full/home-server/setup.sh similarity index 100% rename from full-example/home-server/setup.sh rename to example-full/home-server/setup.sh diff --git a/full-example/home-server/start.sh b/example-full/home-server/start.sh similarity index 100% rename from full-example/home-server/start.sh rename to example-full/home-server/start.sh diff --git a/full-example/home-server/stop.sh b/example-full/home-server/stop.sh similarity index 100% rename from full-example/home-server/stop.sh rename to example-full/home-server/stop.sh diff --git a/full-example/home-server/wg0.conf b/example-full/home-server/wg0.conf similarity index 100% rename from full-example/home-server/wg0.conf rename to example-full/home-server/wg0.conf diff --git a/full-example/laptop/laptop.key b/example-full/laptop/laptop.key similarity index 100% rename from full-example/laptop/laptop.key rename to example-full/laptop/laptop.key diff --git a/full-example/laptop/laptop.key.pub b/example-full/laptop/laptop.key.pub similarity index 100% rename from full-example/laptop/laptop.key.pub rename to example-full/laptop/laptop.key.pub diff --git a/full-example/laptop/setup.sh b/example-full/laptop/setup.sh similarity index 100% rename from full-example/laptop/setup.sh rename to example-full/laptop/setup.sh diff --git a/full-example/laptop/start.sh b/example-full/laptop/start.sh similarity index 100% rename from full-example/laptop/start.sh rename to example-full/laptop/start.sh diff --git a/full-example/laptop/stop.sh b/example-full/laptop/stop.sh similarity index 100% rename from full-example/laptop/stop.sh rename to example-full/laptop/stop.sh diff --git a/full-example/laptop/wg0.conf b/example-full/laptop/wg0.conf similarity index 100% rename from full-example/laptop/wg0.conf rename to example-full/laptop/wg0.conf diff --git a/full-example/phone/phone.key b/example-full/phone/phone.key similarity index 100% rename from full-example/phone/phone.key rename to example-full/phone/phone.key diff --git a/full-example/phone/phone.key.pub b/example-full/phone/phone.key.pub similarity index 100% rename from full-example/phone/phone.key.pub rename to example-full/phone/phone.key.pub diff --git a/full-example/phone/setup.sh b/example-full/phone/setup.sh similarity index 100% rename from full-example/phone/setup.sh rename to example-full/phone/setup.sh diff --git a/full-example/phone/start.sh b/example-full/phone/start.sh similarity index 100% rename from full-example/phone/start.sh rename to example-full/phone/start.sh diff --git a/full-example/phone/stop.sh b/example-full/phone/stop.sh similarity index 100% rename from full-example/phone/stop.sh rename to example-full/phone/stop.sh diff --git a/full-example/phone/wg0.conf b/example-full/phone/wg0.conf similarity index 100% rename from full-example/phone/wg0.conf rename to example-full/phone/wg0.conf diff --git a/full-example/public-server1/public-server1.key b/example-full/public-server1/public-server1.key similarity index 100% rename from full-example/public-server1/public-server1.key rename to example-full/public-server1/public-server1.key diff --git a/full-example/public-server1/public-server1.key.pub b/example-full/public-server1/public-server1.key.pub similarity index 100% rename from full-example/public-server1/public-server1.key.pub rename to example-full/public-server1/public-server1.key.pub diff --git a/full-example/public-server1/setup.sh b/example-full/public-server1/setup.sh similarity index 100% rename from full-example/public-server1/setup.sh rename to example-full/public-server1/setup.sh diff --git a/full-example/public-server1/start.sh b/example-full/public-server1/start.sh similarity index 100% rename from full-example/public-server1/start.sh rename to example-full/public-server1/start.sh diff --git a/full-example/public-server1/stop.sh b/example-full/public-server1/stop.sh similarity index 100% rename from full-example/public-server1/stop.sh rename to example-full/public-server1/stop.sh diff --git a/full-example/public-server1/wg0.conf b/example-full/public-server1/wg0.conf similarity index 100% rename from full-example/public-server1/wg0.conf rename to example-full/public-server1/wg0.conf diff --git a/full-example/public-server2/public-server2.key b/example-full/public-server2/public-server2.key similarity index 100% rename from full-example/public-server2/public-server2.key rename to example-full/public-server2/public-server2.key diff --git a/full-example/public-server2/public-server2.key.pub b/example-full/public-server2/public-server2.key.pub similarity index 100% rename from full-example/public-server2/public-server2.key.pub rename to example-full/public-server2/public-server2.key.pub diff --git a/full-example/public-server2/setup.sh b/example-full/public-server2/setup.sh similarity index 100% rename from full-example/public-server2/setup.sh rename to example-full/public-server2/setup.sh diff --git a/full-example/public-server2/start.sh b/example-full/public-server2/start.sh similarity index 100% rename from full-example/public-server2/start.sh rename to example-full/public-server2/start.sh diff --git a/full-example/public-server2/stop.sh b/example-full/public-server2/stop.sh similarity index 100% rename from full-example/public-server2/stop.sh rename to example-full/public-server2/stop.sh diff --git a/full-example/public-server2/wg0.conf b/example-full/public-server2/wg0.conf similarity index 100% rename from full-example/public-server2/wg0.conf rename to example-full/public-server2/wg0.conf diff --git a/example-internet-browsing-vpn/laptop/laptop.key b/example-internet-browsing-vpn/laptop/laptop.key new file mode 100644 index 0000000..686b3d9 --- /dev/null +++ b/example-internet-browsing-vpn/laptop/laptop.key @@ -0,0 +1 @@ +OPmibSXYAAcMIYKNsWqr77zY06Kl750AEB1nWQi1T2o= diff --git a/example-internet-browsing-vpn/laptop/laptop.key.pub b/example-internet-browsing-vpn/laptop/laptop.key.pub new file mode 100644 index 0000000..4165fa8 --- /dev/null +++ b/example-internet-browsing-vpn/laptop/laptop.key.pub @@ -0,0 +1 @@ +BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= diff --git a/example-internet-browsing-vpn/laptop/setup.sh b/example-internet-browsing-vpn/laptop/setup.sh new file mode 100644 index 0000000..5fb0157 --- /dev/null +++ b/example-internet-browsing-vpn/laptop/setup.sh @@ -0,0 +1,9 @@ +#!/bin/bash + +# install wireguard on Ubuntu +#add-apt-repository ppa:wireguard/wireguard +#apt update +#apt install wireguard + +# install wireguard on macOS +brew install wireguard-tools diff --git a/example-internet-browsing-vpn/laptop/start.sh b/example-internet-browsing-vpn/laptop/start.sh new file mode 100644 index 0000000..9e6a2fb --- /dev/null +++ b/example-internet-browsing-vpn/laptop/start.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick up "$PEER_DIR"/wg0.conf +wg show diff --git a/example-internet-browsing-vpn/laptop/stop.sh b/example-internet-browsing-vpn/laptop/stop.sh new file mode 100644 index 0000000..2faef2c --- /dev/null +++ b/example-internet-browsing-vpn/laptop/stop.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick down "$PEER_DIR"/wg0.conf +wg show diff --git a/example-internet-browsing-vpn/laptop/wg0.conf b/example-internet-browsing-vpn/laptop/wg0.conf new file mode 100644 index 0000000..d2f625d --- /dev/null +++ b/example-internet-browsing-vpn/laptop/wg0.conf @@ -0,0 +1,13 @@ +[Interface] +# Name = laptop.example-vpn.dev +Address = 10.0.0.4/32 +PrivateKey = OPmibSXYAAcMIYKNsWqr77zY06Kl750AEB1nWQi1T2o= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 10.0.0.1/24 +PersistentKeepalive = 25 diff --git a/example-internet-browsing-vpn/phone/phone.key b/example-internet-browsing-vpn/phone/phone.key new file mode 100644 index 0000000..a855da1 --- /dev/null +++ b/example-internet-browsing-vpn/phone/phone.key @@ -0,0 +1 @@ +WH98AvjKKZ584ZLb69G912bNry2wOda9+kfzm+qbnUw= diff --git a/example-internet-browsing-vpn/phone/phone.key.pub b/example-internet-browsing-vpn/phone/phone.key.pub new file mode 100644 index 0000000..0d67922 --- /dev/null +++ b/example-internet-browsing-vpn/phone/phone.key.pub @@ -0,0 +1 @@ +VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= diff --git a/example-internet-browsing-vpn/phone/setup.sh b/example-internet-browsing-vpn/phone/setup.sh new file mode 100644 index 0000000..fdbf4f4 --- /dev/null +++ b/example-internet-browsing-vpn/phone/setup.sh @@ -0,0 +1,4 @@ +#!/bin/bash + +# install wireguard on iOS/Android +echo "Use the iOS App Store / Google Play Store to install WireGuard on your mobile device" diff --git a/example-internet-browsing-vpn/phone/start.sh b/example-internet-browsing-vpn/phone/start.sh new file mode 100644 index 0000000..de47355 --- /dev/null +++ b/example-internet-browsing-vpn/phone/start.sh @@ -0,0 +1,3 @@ +#!/bin/bash + +echo "Use the iOS/Android app to load the wg0.conf file and start Wireguard" diff --git a/example-internet-browsing-vpn/phone/stop.sh b/example-internet-browsing-vpn/phone/stop.sh new file mode 100644 index 0000000..4fc7f4a --- /dev/null +++ b/example-internet-browsing-vpn/phone/stop.sh @@ -0,0 +1,3 @@ +#!/bin/bash + +echo "Use the iOS/Android app to load the wg0.conf file and stop Wireguard" diff --git a/example-internet-browsing-vpn/phone/wg0.conf b/example-internet-browsing-vpn/phone/wg0.conf new file mode 100644 index 0000000..47cf7a1 --- /dev/null +++ b/example-internet-browsing-vpn/phone/wg0.conf @@ -0,0 +1,13 @@ +[Interface] +# Name = phone.example-vpn.dev +Address = 10.0.0.5/32 +PrivateKey = WH98AvjKKZ584ZLb69G912bNry2wOda9+kfzm+qbnUw= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 10.0.0.1/24 +PersistentKeepalive = 25 diff --git a/example-internet-browsing-vpn/server/public-server1.key b/example-internet-browsing-vpn/server/public-server1.key new file mode 100644 index 0000000..e97b37e --- /dev/null +++ b/example-internet-browsing-vpn/server/public-server1.key @@ -0,0 +1 @@ +2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= diff --git a/example-internet-browsing-vpn/server/public-server1.key.pub b/example-internet-browsing-vpn/server/public-server1.key.pub new file mode 100644 index 0000000..5912f3f --- /dev/null +++ b/example-internet-browsing-vpn/server/public-server1.key.pub @@ -0,0 +1 @@ +q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= diff --git a/example-internet-browsing-vpn/server/setup.sh b/example-internet-browsing-vpn/server/setup.sh new file mode 100644 index 0000000..b9991f8 --- /dev/null +++ b/example-internet-browsing-vpn/server/setup.sh @@ -0,0 +1,17 @@ +#!/bin/bash + +# install wireguard +add-apt-repository ppa:wireguard/wireguard +apt update +apt install wireguard + +# to enable kernel relaying/forwarding ability on bounce servers +echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf +echo "net.ipv4.conf.all.proxy_arp" >> /etc/sysctl.conf +sudo sysctl -p /etc/sysctl.conf + +# to add iptables forwarding rules on bounce servers +iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT +iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE diff --git a/example-internet-browsing-vpn/server/start.sh b/example-internet-browsing-vpn/server/start.sh new file mode 100644 index 0000000..9e6a2fb --- /dev/null +++ b/example-internet-browsing-vpn/server/start.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick up "$PEER_DIR"/wg0.conf +wg show diff --git a/example-internet-browsing-vpn/server/stop.sh b/example-internet-browsing-vpn/server/stop.sh new file mode 100644 index 0000000..2faef2c --- /dev/null +++ b/example-internet-browsing-vpn/server/stop.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick down "$PEER_DIR"/wg0.conf +wg show diff --git a/example-internet-browsing-vpn/server/wg0.conf b/example-internet-browsing-vpn/server/wg0.conf new file mode 100644 index 0000000..7e28ae4 --- /dev/null +++ b/example-internet-browsing-vpn/server/wg0.conf @@ -0,0 +1,28 @@ +[Interface] +# Name = public-server1.example-vpn.tld +Address = 10.0.0.1/24 +ListenPort = 51820 +PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server2.example-vpn.dev +Endpoint = public-server2.example-vpn.dev:51820 +PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= +AllowedIPs = 10.0.0.2/32 + +[Peer] +# Name = home-server.example-vpn.dev +Endpoint = home-server.example-vpn.dev:51820 +PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= +AllowedIPs = 10.0.0.3/32 + +[Peer] +# Name = laptop.example-vpn.dev +PublicKey = BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= +AllowedIPs = 10.0.0.4/32 + +[Peer] +# Name = phone.example-vpn.dev +PublicKey = VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= +AllowedIPs = 10.0.0.5/32 diff --git a/example-lan-briding/montreal/public-server1.key b/example-lan-briding/montreal/public-server1.key new file mode 100644 index 0000000..e97b37e --- /dev/null +++ b/example-lan-briding/montreal/public-server1.key @@ -0,0 +1 @@ +2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= diff --git a/example-lan-briding/montreal/public-server1.key.pub b/example-lan-briding/montreal/public-server1.key.pub new file mode 100644 index 0000000..5912f3f --- /dev/null +++ b/example-lan-briding/montreal/public-server1.key.pub @@ -0,0 +1 @@ +q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= diff --git a/example-lan-briding/montreal/setup.sh b/example-lan-briding/montreal/setup.sh new file mode 100644 index 0000000..b9991f8 --- /dev/null +++ b/example-lan-briding/montreal/setup.sh @@ -0,0 +1,17 @@ +#!/bin/bash + +# install wireguard +add-apt-repository ppa:wireguard/wireguard +apt update +apt install wireguard + +# to enable kernel relaying/forwarding ability on bounce servers +echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf +echo "net.ipv4.conf.all.proxy_arp" >> /etc/sysctl.conf +sudo sysctl -p /etc/sysctl.conf + +# to add iptables forwarding rules on bounce servers +iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT +iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE diff --git a/example-lan-briding/montreal/start.sh b/example-lan-briding/montreal/start.sh new file mode 100644 index 0000000..9e6a2fb --- /dev/null +++ b/example-lan-briding/montreal/start.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick up "$PEER_DIR"/wg0.conf +wg show diff --git a/example-lan-briding/montreal/stop.sh b/example-lan-briding/montreal/stop.sh new file mode 100644 index 0000000..2faef2c --- /dev/null +++ b/example-lan-briding/montreal/stop.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick down "$PEER_DIR"/wg0.conf +wg show diff --git a/example-lan-briding/montreal/wg0.conf b/example-lan-briding/montreal/wg0.conf new file mode 100644 index 0000000..7e28ae4 --- /dev/null +++ b/example-lan-briding/montreal/wg0.conf @@ -0,0 +1,28 @@ +[Interface] +# Name = public-server1.example-vpn.tld +Address = 10.0.0.1/24 +ListenPort = 51820 +PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server2.example-vpn.dev +Endpoint = public-server2.example-vpn.dev:51820 +PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= +AllowedIPs = 10.0.0.2/32 + +[Peer] +# Name = home-server.example-vpn.dev +Endpoint = home-server.example-vpn.dev:51820 +PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= +AllowedIPs = 10.0.0.3/32 + +[Peer] +# Name = laptop.example-vpn.dev +PublicKey = BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= +AllowedIPs = 10.0.0.4/32 + +[Peer] +# Name = phone.example-vpn.dev +PublicKey = VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= +AllowedIPs = 10.0.0.5/32 diff --git a/example-lan-briding/newyork/public-server2.key b/example-lan-briding/newyork/public-server2.key new file mode 100644 index 0000000..44ad287 --- /dev/null +++ b/example-lan-briding/newyork/public-server2.key @@ -0,0 +1 @@ +eDwURfg8PhpUAdPp+OA9pQ5oZQYqGqY3LToUORMh220= diff --git a/example-lan-briding/newyork/public-server2.key.pub b/example-lan-briding/newyork/public-server2.key.pub new file mode 100644 index 0000000..52e4ce1 --- /dev/null +++ b/example-lan-briding/newyork/public-server2.key.pub @@ -0,0 +1 @@ +SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= diff --git a/example-lan-briding/newyork/setup.sh b/example-lan-briding/newyork/setup.sh new file mode 100644 index 0000000..5bfea98 --- /dev/null +++ b/example-lan-briding/newyork/setup.sh @@ -0,0 +1,6 @@ +#!/bin/bash + +# install wireguard +add-apt-repository ppa:wireguard/wireguard +apt update +apt install wireguard diff --git a/example-lan-briding/newyork/start.sh b/example-lan-briding/newyork/start.sh new file mode 100644 index 0000000..9e6a2fb --- /dev/null +++ b/example-lan-briding/newyork/start.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick up "$PEER_DIR"/wg0.conf +wg show diff --git a/example-lan-briding/newyork/stop.sh b/example-lan-briding/newyork/stop.sh new file mode 100644 index 0000000..2faef2c --- /dev/null +++ b/example-lan-briding/newyork/stop.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick down "$PEER_DIR"/wg0.conf +wg show diff --git a/example-lan-briding/newyork/wg0.conf b/example-lan-briding/newyork/wg0.conf new file mode 100644 index 0000000..fa8cf16 --- /dev/null +++ b/example-lan-briding/newyork/wg0.conf @@ -0,0 +1,14 @@ +[Interface] +# Name = public-server2.example-vpn.dev +Address = 10.0.0.2/32 +ListenPort = 51820 +PrivateKey = eDwURfg8PhpUAdPp+OA9pQ5oZQYqGqY3LToUORMh220= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 10.0.0.1/24 +PersistentKeepalive = 25 diff --git a/example-lan-briding/vancouver/public-server1.key b/example-lan-briding/vancouver/public-server1.key new file mode 100644 index 0000000..e97b37e --- /dev/null +++ b/example-lan-briding/vancouver/public-server1.key @@ -0,0 +1 @@ +2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= diff --git a/example-lan-briding/vancouver/public-server1.key.pub b/example-lan-briding/vancouver/public-server1.key.pub new file mode 100644 index 0000000..5912f3f --- /dev/null +++ b/example-lan-briding/vancouver/public-server1.key.pub @@ -0,0 +1 @@ +q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= diff --git a/example-lan-briding/vancouver/setup.sh b/example-lan-briding/vancouver/setup.sh new file mode 100644 index 0000000..b9991f8 --- /dev/null +++ b/example-lan-briding/vancouver/setup.sh @@ -0,0 +1,17 @@ +#!/bin/bash + +# install wireguard +add-apt-repository ppa:wireguard/wireguard +apt update +apt install wireguard + +# to enable kernel relaying/forwarding ability on bounce servers +echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf +echo "net.ipv4.conf.all.proxy_arp" >> /etc/sysctl.conf +sudo sysctl -p /etc/sysctl.conf + +# to add iptables forwarding rules on bounce servers +iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT +iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE diff --git a/example-lan-briding/vancouver/start.sh b/example-lan-briding/vancouver/start.sh new file mode 100644 index 0000000..9e6a2fb --- /dev/null +++ b/example-lan-briding/vancouver/start.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick up "$PEER_DIR"/wg0.conf +wg show diff --git a/example-lan-briding/vancouver/stop.sh b/example-lan-briding/vancouver/stop.sh new file mode 100644 index 0000000..2faef2c --- /dev/null +++ b/example-lan-briding/vancouver/stop.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick down "$PEER_DIR"/wg0.conf +wg show diff --git a/example-lan-briding/vancouver/wg0.conf b/example-lan-briding/vancouver/wg0.conf new file mode 100644 index 0000000..7e28ae4 --- /dev/null +++ b/example-lan-briding/vancouver/wg0.conf @@ -0,0 +1,28 @@ +[Interface] +# Name = public-server1.example-vpn.tld +Address = 10.0.0.1/24 +ListenPort = 51820 +PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server2.example-vpn.dev +Endpoint = public-server2.example-vpn.dev:51820 +PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= +AllowedIPs = 10.0.0.2/32 + +[Peer] +# Name = home-server.example-vpn.dev +Endpoint = home-server.example-vpn.dev:51820 +PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= +AllowedIPs = 10.0.0.3/32 + +[Peer] +# Name = laptop.example-vpn.dev +PublicKey = BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= +AllowedIPs = 10.0.0.4/32 + +[Peer] +# Name = phone.example-vpn.dev +PublicKey = VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= +AllowedIPs = 10.0.0.5/32 diff --git a/example-simple-client-to-server/client/laptop.key b/example-simple-client-to-server/client/laptop.key new file mode 100644 index 0000000..686b3d9 --- /dev/null +++ b/example-simple-client-to-server/client/laptop.key @@ -0,0 +1 @@ +OPmibSXYAAcMIYKNsWqr77zY06Kl750AEB1nWQi1T2o= diff --git a/example-simple-client-to-server/client/laptop.key.pub b/example-simple-client-to-server/client/laptop.key.pub new file mode 100644 index 0000000..4165fa8 --- /dev/null +++ b/example-simple-client-to-server/client/laptop.key.pub @@ -0,0 +1 @@ +BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= diff --git a/example-simple-client-to-server/client/setup.sh b/example-simple-client-to-server/client/setup.sh new file mode 100644 index 0000000..5fb0157 --- /dev/null +++ b/example-simple-client-to-server/client/setup.sh @@ -0,0 +1,9 @@ +#!/bin/bash + +# install wireguard on Ubuntu +#add-apt-repository ppa:wireguard/wireguard +#apt update +#apt install wireguard + +# install wireguard on macOS +brew install wireguard-tools diff --git a/example-simple-client-to-server/client/start.sh b/example-simple-client-to-server/client/start.sh new file mode 100644 index 0000000..9e6a2fb --- /dev/null +++ b/example-simple-client-to-server/client/start.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick up "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-client-to-server/client/stop.sh b/example-simple-client-to-server/client/stop.sh new file mode 100644 index 0000000..2faef2c --- /dev/null +++ b/example-simple-client-to-server/client/stop.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick down "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-client-to-server/client/wg0.conf b/example-simple-client-to-server/client/wg0.conf new file mode 100644 index 0000000..d2f625d --- /dev/null +++ b/example-simple-client-to-server/client/wg0.conf @@ -0,0 +1,13 @@ +[Interface] +# Name = laptop.example-vpn.dev +Address = 10.0.0.4/32 +PrivateKey = OPmibSXYAAcMIYKNsWqr77zY06Kl750AEB1nWQi1T2o= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 10.0.0.1/24 +PersistentKeepalive = 25 diff --git a/example-simple-client-to-server/server/public-server1.key b/example-simple-client-to-server/server/public-server1.key new file mode 100644 index 0000000..e97b37e --- /dev/null +++ b/example-simple-client-to-server/server/public-server1.key @@ -0,0 +1 @@ +2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= diff --git a/example-simple-client-to-server/server/public-server1.key.pub b/example-simple-client-to-server/server/public-server1.key.pub new file mode 100644 index 0000000..5912f3f --- /dev/null +++ b/example-simple-client-to-server/server/public-server1.key.pub @@ -0,0 +1 @@ +q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= diff --git a/example-simple-client-to-server/server/setup.sh b/example-simple-client-to-server/server/setup.sh new file mode 100644 index 0000000..b9991f8 --- /dev/null +++ b/example-simple-client-to-server/server/setup.sh @@ -0,0 +1,17 @@ +#!/bin/bash + +# install wireguard +add-apt-repository ppa:wireguard/wireguard +apt update +apt install wireguard + +# to enable kernel relaying/forwarding ability on bounce servers +echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf +echo "net.ipv4.conf.all.proxy_arp" >> /etc/sysctl.conf +sudo sysctl -p /etc/sysctl.conf + +# to add iptables forwarding rules on bounce servers +iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT +iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE diff --git a/example-simple-client-to-server/server/start.sh b/example-simple-client-to-server/server/start.sh new file mode 100644 index 0000000..9e6a2fb --- /dev/null +++ b/example-simple-client-to-server/server/start.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick up "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-client-to-server/server/stop.sh b/example-simple-client-to-server/server/stop.sh new file mode 100644 index 0000000..2faef2c --- /dev/null +++ b/example-simple-client-to-server/server/stop.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick down "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-client-to-server/server/wg0.conf b/example-simple-client-to-server/server/wg0.conf new file mode 100644 index 0000000..7e28ae4 --- /dev/null +++ b/example-simple-client-to-server/server/wg0.conf @@ -0,0 +1,28 @@ +[Interface] +# Name = public-server1.example-vpn.tld +Address = 10.0.0.1/24 +ListenPort = 51820 +PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server2.example-vpn.dev +Endpoint = public-server2.example-vpn.dev:51820 +PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= +AllowedIPs = 10.0.0.2/32 + +[Peer] +# Name = home-server.example-vpn.dev +Endpoint = home-server.example-vpn.dev:51820 +PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= +AllowedIPs = 10.0.0.3/32 + +[Peer] +# Name = laptop.example-vpn.dev +PublicKey = BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= +AllowedIPs = 10.0.0.4/32 + +[Peer] +# Name = phone.example-vpn.dev +PublicKey = VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= +AllowedIPs = 10.0.0.5/32 diff --git a/example-simple-server-to-server/home-server/home-server.key b/example-simple-server-to-server/home-server/home-server.key new file mode 100644 index 0000000..2df1302 --- /dev/null +++ b/example-simple-server-to-server/home-server/home-server.key @@ -0,0 +1 @@ +WN+bvd3PCWs5Pk3bvl7abWR0c1L6PCWKYRX56mjVYGo= diff --git a/example-simple-server-to-server/home-server/home-server.key.pub b/example-simple-server-to-server/home-server/home-server.key.pub new file mode 100644 index 0000000..6d118d2 --- /dev/null +++ b/example-simple-server-to-server/home-server/home-server.key.pub @@ -0,0 +1 @@ +8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= diff --git a/example-simple-server-to-server/home-server/setup.sh b/example-simple-server-to-server/home-server/setup.sh new file mode 100644 index 0000000..722ba80 --- /dev/null +++ b/example-simple-server-to-server/home-server/setup.sh @@ -0,0 +1,9 @@ +#!/bin/bash + +# install wireguard on FreeBSD +pkg install wireguard + +# install wireguard on Ubuntu +#add-apt-repository ppa:wireguard/wireguard +#apt update +#apt install wireguard diff --git a/example-simple-server-to-server/home-server/start.sh b/example-simple-server-to-server/home-server/start.sh new file mode 100644 index 0000000..9e6a2fb --- /dev/null +++ b/example-simple-server-to-server/home-server/start.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick up "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-server-to-server/home-server/stop.sh b/example-simple-server-to-server/home-server/stop.sh new file mode 100644 index 0000000..2faef2c --- /dev/null +++ b/example-simple-server-to-server/home-server/stop.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick down "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-server-to-server/home-server/wg0.conf b/example-simple-server-to-server/home-server/wg0.conf new file mode 100644 index 0000000..2373455 --- /dev/null +++ b/example-simple-server-to-server/home-server/wg0.conf @@ -0,0 +1,14 @@ +[Interface] +# Name = home-server.example-vpn.dev +Address = 10.0.0.3/32 +ListenPort = 51820 +PrivateKey = WN+bvd3PCWs5Pk3bvl7abWR0c1L6PCWKYRX56mjVYGo= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 10.0.0.1/24 +PersistentKeepalive = 25 diff --git a/example-simple-server-to-server/laptop/laptop.key b/example-simple-server-to-server/laptop/laptop.key new file mode 100644 index 0000000..686b3d9 --- /dev/null +++ b/example-simple-server-to-server/laptop/laptop.key @@ -0,0 +1 @@ +OPmibSXYAAcMIYKNsWqr77zY06Kl750AEB1nWQi1T2o= diff --git a/example-simple-server-to-server/laptop/laptop.key.pub b/example-simple-server-to-server/laptop/laptop.key.pub new file mode 100644 index 0000000..4165fa8 --- /dev/null +++ b/example-simple-server-to-server/laptop/laptop.key.pub @@ -0,0 +1 @@ +BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= diff --git a/example-simple-server-to-server/laptop/setup.sh b/example-simple-server-to-server/laptop/setup.sh new file mode 100644 index 0000000..5fb0157 --- /dev/null +++ b/example-simple-server-to-server/laptop/setup.sh @@ -0,0 +1,9 @@ +#!/bin/bash + +# install wireguard on Ubuntu +#add-apt-repository ppa:wireguard/wireguard +#apt update +#apt install wireguard + +# install wireguard on macOS +brew install wireguard-tools diff --git a/example-simple-server-to-server/laptop/start.sh b/example-simple-server-to-server/laptop/start.sh new file mode 100644 index 0000000..9e6a2fb --- /dev/null +++ b/example-simple-server-to-server/laptop/start.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick up "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-server-to-server/laptop/stop.sh b/example-simple-server-to-server/laptop/stop.sh new file mode 100644 index 0000000..2faef2c --- /dev/null +++ b/example-simple-server-to-server/laptop/stop.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick down "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-server-to-server/laptop/wg0.conf b/example-simple-server-to-server/laptop/wg0.conf new file mode 100644 index 0000000..d2f625d --- /dev/null +++ b/example-simple-server-to-server/laptop/wg0.conf @@ -0,0 +1,13 @@ +[Interface] +# Name = laptop.example-vpn.dev +Address = 10.0.0.4/32 +PrivateKey = OPmibSXYAAcMIYKNsWqr77zY06Kl750AEB1nWQi1T2o= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 10.0.0.1/24 +PersistentKeepalive = 25 diff --git a/example-simple-server-to-server/phone/phone.key b/example-simple-server-to-server/phone/phone.key new file mode 100644 index 0000000..a855da1 --- /dev/null +++ b/example-simple-server-to-server/phone/phone.key @@ -0,0 +1 @@ +WH98AvjKKZ584ZLb69G912bNry2wOda9+kfzm+qbnUw= diff --git a/example-simple-server-to-server/phone/phone.key.pub b/example-simple-server-to-server/phone/phone.key.pub new file mode 100644 index 0000000..0d67922 --- /dev/null +++ b/example-simple-server-to-server/phone/phone.key.pub @@ -0,0 +1 @@ +VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= diff --git a/example-simple-server-to-server/phone/setup.sh b/example-simple-server-to-server/phone/setup.sh new file mode 100644 index 0000000..fdbf4f4 --- /dev/null +++ b/example-simple-server-to-server/phone/setup.sh @@ -0,0 +1,4 @@ +#!/bin/bash + +# install wireguard on iOS/Android +echo "Use the iOS App Store / Google Play Store to install WireGuard on your mobile device" diff --git a/example-simple-server-to-server/phone/start.sh b/example-simple-server-to-server/phone/start.sh new file mode 100644 index 0000000..de47355 --- /dev/null +++ b/example-simple-server-to-server/phone/start.sh @@ -0,0 +1,3 @@ +#!/bin/bash + +echo "Use the iOS/Android app to load the wg0.conf file and start Wireguard" diff --git a/example-simple-server-to-server/phone/stop.sh b/example-simple-server-to-server/phone/stop.sh new file mode 100644 index 0000000..4fc7f4a --- /dev/null +++ b/example-simple-server-to-server/phone/stop.sh @@ -0,0 +1,3 @@ +#!/bin/bash + +echo "Use the iOS/Android app to load the wg0.conf file and stop Wireguard" diff --git a/example-simple-server-to-server/phone/wg0.conf b/example-simple-server-to-server/phone/wg0.conf new file mode 100644 index 0000000..47cf7a1 --- /dev/null +++ b/example-simple-server-to-server/phone/wg0.conf @@ -0,0 +1,13 @@ +[Interface] +# Name = phone.example-vpn.dev +Address = 10.0.0.5/32 +PrivateKey = WH98AvjKKZ584ZLb69G912bNry2wOda9+kfzm+qbnUw= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 10.0.0.1/24 +PersistentKeepalive = 25 diff --git a/example-simple-server-to-server/public-server1/public-server1.key b/example-simple-server-to-server/public-server1/public-server1.key new file mode 100644 index 0000000..e97b37e --- /dev/null +++ b/example-simple-server-to-server/public-server1/public-server1.key @@ -0,0 +1 @@ +2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= diff --git a/example-simple-server-to-server/public-server1/public-server1.key.pub b/example-simple-server-to-server/public-server1/public-server1.key.pub new file mode 100644 index 0000000..5912f3f --- /dev/null +++ b/example-simple-server-to-server/public-server1/public-server1.key.pub @@ -0,0 +1 @@ +q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= diff --git a/example-simple-server-to-server/public-server1/setup.sh b/example-simple-server-to-server/public-server1/setup.sh new file mode 100644 index 0000000..b9991f8 --- /dev/null +++ b/example-simple-server-to-server/public-server1/setup.sh @@ -0,0 +1,17 @@ +#!/bin/bash + +# install wireguard +add-apt-repository ppa:wireguard/wireguard +apt update +apt install wireguard + +# to enable kernel relaying/forwarding ability on bounce servers +echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf +echo "net.ipv4.conf.all.proxy_arp" >> /etc/sysctl.conf +sudo sysctl -p /etc/sysctl.conf + +# to add iptables forwarding rules on bounce servers +iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT +iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT +iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE diff --git a/example-simple-server-to-server/public-server1/start.sh b/example-simple-server-to-server/public-server1/start.sh new file mode 100644 index 0000000..9e6a2fb --- /dev/null +++ b/example-simple-server-to-server/public-server1/start.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick up "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-server-to-server/public-server1/stop.sh b/example-simple-server-to-server/public-server1/stop.sh new file mode 100644 index 0000000..2faef2c --- /dev/null +++ b/example-simple-server-to-server/public-server1/stop.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick down "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-server-to-server/public-server1/wg0.conf b/example-simple-server-to-server/public-server1/wg0.conf new file mode 100644 index 0000000..7e28ae4 --- /dev/null +++ b/example-simple-server-to-server/public-server1/wg0.conf @@ -0,0 +1,28 @@ +[Interface] +# Name = public-server1.example-vpn.tld +Address = 10.0.0.1/24 +ListenPort = 51820 +PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server2.example-vpn.dev +Endpoint = public-server2.example-vpn.dev:51820 +PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= +AllowedIPs = 10.0.0.2/32 + +[Peer] +# Name = home-server.example-vpn.dev +Endpoint = home-server.example-vpn.dev:51820 +PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= +AllowedIPs = 10.0.0.3/32 + +[Peer] +# Name = laptop.example-vpn.dev +PublicKey = BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= +AllowedIPs = 10.0.0.4/32 + +[Peer] +# Name = phone.example-vpn.dev +PublicKey = VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= +AllowedIPs = 10.0.0.5/32 diff --git a/example-simple-server-to-server/public-server2/public-server2.key b/example-simple-server-to-server/public-server2/public-server2.key new file mode 100644 index 0000000..44ad287 --- /dev/null +++ b/example-simple-server-to-server/public-server2/public-server2.key @@ -0,0 +1 @@ +eDwURfg8PhpUAdPp+OA9pQ5oZQYqGqY3LToUORMh220= diff --git a/example-simple-server-to-server/public-server2/public-server2.key.pub b/example-simple-server-to-server/public-server2/public-server2.key.pub new file mode 100644 index 0000000..52e4ce1 --- /dev/null +++ b/example-simple-server-to-server/public-server2/public-server2.key.pub @@ -0,0 +1 @@ +SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= diff --git a/example-simple-server-to-server/public-server2/setup.sh b/example-simple-server-to-server/public-server2/setup.sh new file mode 100644 index 0000000..5bfea98 --- /dev/null +++ b/example-simple-server-to-server/public-server2/setup.sh @@ -0,0 +1,6 @@ +#!/bin/bash + +# install wireguard +add-apt-repository ppa:wireguard/wireguard +apt update +apt install wireguard diff --git a/example-simple-server-to-server/public-server2/start.sh b/example-simple-server-to-server/public-server2/start.sh new file mode 100644 index 0000000..9e6a2fb --- /dev/null +++ b/example-simple-server-to-server/public-server2/start.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick up "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-server-to-server/public-server2/stop.sh b/example-simple-server-to-server/public-server2/stop.sh new file mode 100644 index 0000000..2faef2c --- /dev/null +++ b/example-simple-server-to-server/public-server2/stop.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" +wg-quick down "$PEER_DIR"/wg0.conf +wg show diff --git a/example-simple-server-to-server/public-server2/wg0.conf b/example-simple-server-to-server/public-server2/wg0.conf new file mode 100644 index 0000000..fa8cf16 --- /dev/null +++ b/example-simple-server-to-server/public-server2/wg0.conf @@ -0,0 +1,14 @@ +[Interface] +# Name = public-server2.example-vpn.dev +Address = 10.0.0.2/32 +ListenPort = 51820 +PrivateKey = eDwURfg8PhpUAdPp+OA9pQ5oZQYqGqY3LToUORMh220= +DNS = 1.1.1.1 + +[Peer] +# Name = public-server1.example-vpn.tld +Endpoint = public-server1.example-vpn.tld:51820 +PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= +# routes traffic to itself and entire subnet of peers as bounce server +AllowedIPs = 10.0.0.1/24 +PersistentKeepalive = 25 From 7163803ff6e4d3b3b485e89c77bc06eca9fc60b9 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Mon, 24 Jun 2019 06:11:21 -0400 Subject: [PATCH 15/72] rename examples --- example-full/home-server/wg0.conf | 4 +- example-full/laptop/wg0.conf | 4 +- example-full/phone/wg0.conf | 4 +- example-full/public-server1/setup.sh | 2 +- example-full/public-server1/wg0.conf | 10 ++--- example-full/public-server2/wg0.conf | 4 +- example-internet-browsing-vpn/laptop/wg0.conf | 9 ++--- example-internet-browsing-vpn/phone/wg0.conf | 9 ++--- .../server/{public-server1.key => server.key} | 0 ...{public-server1.key.pub => server.key.pub} | 0 example-internet-browsing-vpn/server/setup.sh | 2 +- example-internet-browsing-vpn/server/wg0.conf | 22 +++-------- .../{public-server1.key => montreal.key} | 0 ...ublic-server1.key.pub => montreal.key.pub} | 0 example-lan-briding/montreal/setup.sh | 2 +- example-lan-briding/montreal/wg0.conf | 34 ++++++++--------- .../{public-server2.key => newyork.key} | 0 ...public-server2.key.pub => newyork.key.pub} | 0 example-lan-briding/newyork/wg0.conf | 26 +++++++++---- example-lan-briding/vancouver/setup.sh | 2 +- .../{public-server1.key => vancouver.key} | 0 ...blic-server1.key.pub => vancouver.key.pub} | 0 example-lan-briding/vancouver/wg0.conf | 38 +++++++++---------- .../client/{laptop.key => client.key} | 0 .../client/{laptop.key.pub => client.key.pub} | 0 .../client/wg0.conf | 9 ++--- .../server/{public-server1.key => server.key} | 0 ...{public-server1.key.pub => server.key.pub} | 0 .../server/setup.sh | 2 +- .../server/wg0.conf | 23 ++--------- .../home-server/home-server.key | 1 - .../home-server/home-server.key.pub | 1 - .../home-server/setup.sh | 9 ----- .../home-server/wg0.conf | 14 ------- .../laptop/laptop.key | 1 - .../laptop/laptop.key.pub | 1 - .../laptop/setup.sh | 9 ----- .../laptop/wg0.conf | 13 ------- .../phone/phone.key | 1 - .../phone/phone.key.pub | 1 - .../phone/setup.sh | 4 -- .../phone/start.sh | 3 -- example-simple-server-to-server/phone/stop.sh | 3 -- .../phone/wg0.conf | 13 ------- .../public-server1/start.sh | 5 --- .../public-server1/stop.sh | 5 --- .../public-server1/wg0.conf | 28 -------------- .../public-server2/start.sh | 5 --- .../public-server2/stop.sh | 5 --- .../public-server2/wg0.conf | 14 ------- .../server1.key} | 0 .../server1.key.pub} | 0 .../{public-server1 => server1}/setup.sh | 2 +- .../{home-server => server1}/start.sh | 0 .../{home-server => server1}/stop.sh | 0 .../server1/wg0.conf | 12 ++++++ .../server2.key} | 0 .../server2.key.pub} | 0 .../{public-server2 => server2}/setup.sh | 0 .../{laptop => server2}/start.sh | 0 .../{laptop => server2}/stop.sh | 0 .../server2/wg0.conf | 12 ++++++ 62 files changed, 117 insertions(+), 251 deletions(-) rename example-internet-browsing-vpn/server/{public-server1.key => server.key} (100%) rename example-internet-browsing-vpn/server/{public-server1.key.pub => server.key.pub} (100%) rename example-lan-briding/montreal/{public-server1.key => montreal.key} (100%) rename example-lan-briding/montreal/{public-server1.key.pub => montreal.key.pub} (100%) rename example-lan-briding/newyork/{public-server2.key => newyork.key} (100%) rename example-lan-briding/newyork/{public-server2.key.pub => newyork.key.pub} (100%) rename example-lan-briding/vancouver/{public-server1.key => vancouver.key} (100%) rename example-lan-briding/vancouver/{public-server1.key.pub => vancouver.key.pub} (100%) rename example-simple-client-to-server/client/{laptop.key => client.key} (100%) rename example-simple-client-to-server/client/{laptop.key.pub => client.key.pub} (100%) rename example-simple-client-to-server/server/{public-server1.key => server.key} (100%) rename example-simple-client-to-server/server/{public-server1.key.pub => server.key.pub} (100%) delete mode 100644 example-simple-server-to-server/home-server/home-server.key delete mode 100644 example-simple-server-to-server/home-server/home-server.key.pub delete mode 100644 example-simple-server-to-server/home-server/setup.sh delete mode 100644 example-simple-server-to-server/home-server/wg0.conf delete mode 100644 example-simple-server-to-server/laptop/laptop.key delete mode 100644 example-simple-server-to-server/laptop/laptop.key.pub delete mode 100644 example-simple-server-to-server/laptop/setup.sh delete mode 100644 example-simple-server-to-server/laptop/wg0.conf delete mode 100644 example-simple-server-to-server/phone/phone.key delete mode 100644 example-simple-server-to-server/phone/phone.key.pub delete mode 100644 example-simple-server-to-server/phone/setup.sh delete mode 100644 example-simple-server-to-server/phone/start.sh delete mode 100644 example-simple-server-to-server/phone/stop.sh delete mode 100644 example-simple-server-to-server/phone/wg0.conf delete mode 100644 example-simple-server-to-server/public-server1/start.sh delete mode 100644 example-simple-server-to-server/public-server1/stop.sh delete mode 100644 example-simple-server-to-server/public-server1/wg0.conf delete mode 100644 example-simple-server-to-server/public-server2/start.sh delete mode 100644 example-simple-server-to-server/public-server2/stop.sh delete mode 100644 example-simple-server-to-server/public-server2/wg0.conf rename example-simple-server-to-server/{public-server1/public-server1.key => server1/server1.key} (100%) rename example-simple-server-to-server/{public-server1/public-server1.key.pub => server1/server1.key.pub} (100%) rename example-simple-server-to-server/{public-server1 => server1}/setup.sh (89%) rename example-simple-server-to-server/{home-server => server1}/start.sh (100%) rename example-simple-server-to-server/{home-server => server1}/stop.sh (100%) create mode 100644 example-simple-server-to-server/server1/wg0.conf rename example-simple-server-to-server/{public-server2/public-server2.key => server2/server2.key} (100%) rename example-simple-server-to-server/{public-server2/public-server2.key.pub => server2/server2.key.pub} (100%) rename example-simple-server-to-server/{public-server2 => server2}/setup.sh (100%) rename example-simple-server-to-server/{laptop => server2}/start.sh (100%) rename example-simple-server-to-server/{laptop => server2}/stop.sh (100%) create mode 100644 example-simple-server-to-server/server2/wg0.conf diff --git a/example-full/home-server/wg0.conf b/example-full/home-server/wg0.conf index 2373455..b4f77fc 100644 --- a/example-full/home-server/wg0.conf +++ b/example-full/home-server/wg0.conf @@ -1,6 +1,6 @@ [Interface] # Name = home-server.example-vpn.dev -Address = 10.0.0.3/32 +Address = 10.0.44.3/32 ListenPort = 51820 PrivateKey = WN+bvd3PCWs5Pk3bvl7abWR0c1L6PCWKYRX56mjVYGo= DNS = 1.1.1.1 @@ -10,5 +10,5 @@ DNS = 1.1.1.1 Endpoint = public-server1.example-vpn.tld:51820 PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= # routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 10.0.44.1/24 PersistentKeepalive = 25 diff --git a/example-full/laptop/wg0.conf b/example-full/laptop/wg0.conf index d2f625d..384d0e6 100644 --- a/example-full/laptop/wg0.conf +++ b/example-full/laptop/wg0.conf @@ -1,6 +1,6 @@ [Interface] # Name = laptop.example-vpn.dev -Address = 10.0.0.4/32 +Address = 10.0.44.4/32 PrivateKey = OPmibSXYAAcMIYKNsWqr77zY06Kl750AEB1nWQi1T2o= DNS = 1.1.1.1 @@ -9,5 +9,5 @@ DNS = 1.1.1.1 Endpoint = public-server1.example-vpn.tld:51820 PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= # routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 10.0.44.1/24 PersistentKeepalive = 25 diff --git a/example-full/phone/wg0.conf b/example-full/phone/wg0.conf index 47cf7a1..f74fa1b 100644 --- a/example-full/phone/wg0.conf +++ b/example-full/phone/wg0.conf @@ -1,6 +1,6 @@ [Interface] # Name = phone.example-vpn.dev -Address = 10.0.0.5/32 +Address = 10.0.44.5/32 PrivateKey = WH98AvjKKZ584ZLb69G912bNry2wOda9+kfzm+qbnUw= DNS = 1.1.1.1 @@ -9,5 +9,5 @@ DNS = 1.1.1.1 Endpoint = public-server1.example-vpn.tld:51820 PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= # routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 10.0.44.1/24 PersistentKeepalive = 25 diff --git a/example-full/public-server1/setup.sh b/example-full/public-server1/setup.sh index b9991f8..385c4d8 100644 --- a/example-full/public-server1/setup.sh +++ b/example-full/public-server1/setup.sh @@ -14,4 +14,4 @@ sudo sysctl -p /etc/sysctl.conf iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT -iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE +iptables -t nat -A POSTROUTING -s 10.0.44.0/24 -o eth0 -j MASQUERADE diff --git a/example-full/public-server1/wg0.conf b/example-full/public-server1/wg0.conf index 7e28ae4..c821daa 100644 --- a/example-full/public-server1/wg0.conf +++ b/example-full/public-server1/wg0.conf @@ -1,6 +1,6 @@ [Interface] # Name = public-server1.example-vpn.tld -Address = 10.0.0.1/24 +Address = 10.0.44.1/24 ListenPort = 51820 PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= DNS = 1.1.1.1 @@ -9,20 +9,20 @@ DNS = 1.1.1.1 # Name = public-server2.example-vpn.dev Endpoint = public-server2.example-vpn.dev:51820 PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= -AllowedIPs = 10.0.0.2/32 +AllowedIPs = 10.0.44.2/32 [Peer] # Name = home-server.example-vpn.dev Endpoint = home-server.example-vpn.dev:51820 PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= -AllowedIPs = 10.0.0.3/32 +AllowedIPs = 10.0.44.3/32 [Peer] # Name = laptop.example-vpn.dev PublicKey = BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= -AllowedIPs = 10.0.0.4/32 +AllowedIPs = 10.0.44.4/32 [Peer] # Name = phone.example-vpn.dev PublicKey = VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= -AllowedIPs = 10.0.0.5/32 +AllowedIPs = 10.0.44.5/32 diff --git a/example-full/public-server2/wg0.conf b/example-full/public-server2/wg0.conf index fa8cf16..f2dabff 100644 --- a/example-full/public-server2/wg0.conf +++ b/example-full/public-server2/wg0.conf @@ -1,6 +1,6 @@ [Interface] # Name = public-server2.example-vpn.dev -Address = 10.0.0.2/32 +Address = 10.0.44.2/32 ListenPort = 51820 PrivateKey = eDwURfg8PhpUAdPp+OA9pQ5oZQYqGqY3LToUORMh220= DNS = 1.1.1.1 @@ -10,5 +10,5 @@ DNS = 1.1.1.1 Endpoint = public-server1.example-vpn.tld:51820 PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= # routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 10.0.44.1/24 PersistentKeepalive = 25 diff --git a/example-internet-browsing-vpn/laptop/wg0.conf b/example-internet-browsing-vpn/laptop/wg0.conf index d2f625d..38e6187 100644 --- a/example-internet-browsing-vpn/laptop/wg0.conf +++ b/example-internet-browsing-vpn/laptop/wg0.conf @@ -1,13 +1,12 @@ [Interface] # Name = laptop.example-vpn.dev -Address = 10.0.0.4/32 +Address = 10.0.44.2/32 PrivateKey = OPmibSXYAAcMIYKNsWqr77zY06Kl750AEB1nWQi1T2o= DNS = 1.1.1.1 [Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 +# Name = server.example-vpn.tld +Endpoint = server.example-vpn.tld:51820 PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 0.0.0.0/0, ::/0 PersistentKeepalive = 25 diff --git a/example-internet-browsing-vpn/phone/wg0.conf b/example-internet-browsing-vpn/phone/wg0.conf index 47cf7a1..5af3804 100644 --- a/example-internet-browsing-vpn/phone/wg0.conf +++ b/example-internet-browsing-vpn/phone/wg0.conf @@ -1,13 +1,12 @@ [Interface] # Name = phone.example-vpn.dev -Address = 10.0.0.5/32 +Address = 10.0.44.3/32 PrivateKey = WH98AvjKKZ584ZLb69G912bNry2wOda9+kfzm+qbnUw= DNS = 1.1.1.1 [Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 +# Name = server.example-vpn.tld +Endpoint = server.example-vpn.tld:51820 PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 0.0.0.0/0, ::/0 PersistentKeepalive = 25 diff --git a/example-internet-browsing-vpn/server/public-server1.key b/example-internet-browsing-vpn/server/server.key similarity index 100% rename from example-internet-browsing-vpn/server/public-server1.key rename to example-internet-browsing-vpn/server/server.key diff --git a/example-internet-browsing-vpn/server/public-server1.key.pub b/example-internet-browsing-vpn/server/server.key.pub similarity index 100% rename from example-internet-browsing-vpn/server/public-server1.key.pub rename to example-internet-browsing-vpn/server/server.key.pub diff --git a/example-internet-browsing-vpn/server/setup.sh b/example-internet-browsing-vpn/server/setup.sh index b9991f8..385c4d8 100644 --- a/example-internet-browsing-vpn/server/setup.sh +++ b/example-internet-browsing-vpn/server/setup.sh @@ -14,4 +14,4 @@ sudo sysctl -p /etc/sysctl.conf iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT -iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE +iptables -t nat -A POSTROUTING -s 10.0.44.0/24 -o eth0 -j MASQUERADE diff --git a/example-internet-browsing-vpn/server/wg0.conf b/example-internet-browsing-vpn/server/wg0.conf index 7e28ae4..0b0d6b8 100644 --- a/example-internet-browsing-vpn/server/wg0.conf +++ b/example-internet-browsing-vpn/server/wg0.conf @@ -1,28 +1,18 @@ [Interface] -# Name = public-server1.example-vpn.tld -Address = 10.0.0.1/24 +# Name = server.example-vpn.tld +Address = 10.0.44.1/24 ListenPort = 51820 PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= DNS = 1.1.1.1 - -[Peer] -# Name = public-server2.example-vpn.dev -Endpoint = public-server2.example-vpn.dev:51820 -PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= -AllowedIPs = 10.0.0.2/32 - -[Peer] -# Name = home-server.example-vpn.dev -Endpoint = home-server.example-vpn.dev:51820 -PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= -AllowedIPs = 10.0.0.3/32 +PostUp = sysctl -w net.ipv4.ip_forward=1 +PostUp = sysctl -w net.ipv6.conf.all.forwarding=1 [Peer] # Name = laptop.example-vpn.dev PublicKey = BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= -AllowedIPs = 10.0.0.4/32 +AllowedIPs = 10.0.44.2/32 [Peer] # Name = phone.example-vpn.dev PublicKey = VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= -AllowedIPs = 10.0.0.5/32 +AllowedIPs = 10.0.44.3/32 diff --git a/example-lan-briding/montreal/public-server1.key b/example-lan-briding/montreal/montreal.key similarity index 100% rename from example-lan-briding/montreal/public-server1.key rename to example-lan-briding/montreal/montreal.key diff --git a/example-lan-briding/montreal/public-server1.key.pub b/example-lan-briding/montreal/montreal.key.pub similarity index 100% rename from example-lan-briding/montreal/public-server1.key.pub rename to example-lan-briding/montreal/montreal.key.pub diff --git a/example-lan-briding/montreal/setup.sh b/example-lan-briding/montreal/setup.sh index b9991f8..385c4d8 100644 --- a/example-lan-briding/montreal/setup.sh +++ b/example-lan-briding/montreal/setup.sh @@ -14,4 +14,4 @@ sudo sysctl -p /etc/sysctl.conf iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT -iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE +iptables -t nat -A POSTROUTING -s 10.0.44.0/24 -o eth0 -j MASQUERADE diff --git a/example-lan-briding/montreal/wg0.conf b/example-lan-briding/montreal/wg0.conf index 7e28ae4..d97f824 100644 --- a/example-lan-briding/montreal/wg0.conf +++ b/example-lan-briding/montreal/wg0.conf @@ -1,28 +1,26 @@ [Interface] -# Name = public-server1.example-vpn.tld -Address = 10.0.0.1/24 +# Name = montreal.example-vpn.tld +# LAN = 192.168.1.1/24 +Address = 10.0.44.1/24 ListenPort = 51820 PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= DNS = 1.1.1.1 +PostUp = sysctl -w net.ipv4.ip_forward=1 +PostUp = sysctl -w net.ipv6.conf.all.forwarding=1 +PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE +PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE + [Peer] -# Name = public-server2.example-vpn.dev -Endpoint = public-server2.example-vpn.dev:51820 +# Name = newyork.example-vpn.dev +# LAN = 192.168.2.1/24 +Endpoint = newyork.example-vpn.dev:51820 PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= -AllowedIPs = 10.0.0.2/32 +AllowedIPs = 10.0.44.2/32, 192.168.2.1/24 [Peer] -# Name = home-server.example-vpn.dev -Endpoint = home-server.example-vpn.dev:51820 +# Name = vancouver.example-vpn.dev +# LAN = 192.168.3.1/24 +Endpoint = vancouver.example-vpn.dev:51820 PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= -AllowedIPs = 10.0.0.3/32 - -[Peer] -# Name = laptop.example-vpn.dev -PublicKey = BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= -AllowedIPs = 10.0.0.4/32 - -[Peer] -# Name = phone.example-vpn.dev -PublicKey = VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= -AllowedIPs = 10.0.0.5/32 +AllowedIPs = 10.0.44.3/32, 192.168.3.1/24 diff --git a/example-lan-briding/newyork/public-server2.key b/example-lan-briding/newyork/newyork.key similarity index 100% rename from example-lan-briding/newyork/public-server2.key rename to example-lan-briding/newyork/newyork.key diff --git a/example-lan-briding/newyork/public-server2.key.pub b/example-lan-briding/newyork/newyork.key.pub similarity index 100% rename from example-lan-briding/newyork/public-server2.key.pub rename to example-lan-briding/newyork/newyork.key.pub diff --git a/example-lan-briding/newyork/wg0.conf b/example-lan-briding/newyork/wg0.conf index fa8cf16..e1546ca 100644 --- a/example-lan-briding/newyork/wg0.conf +++ b/example-lan-briding/newyork/wg0.conf @@ -1,14 +1,26 @@ [Interface] -# Name = public-server2.example-vpn.dev -Address = 10.0.0.2/32 +# Name = newyork.example-vpn.dev +# LAN = 192.168.2.1/24 +Address = 10.0.44.2/32 ListenPort = 51820 PrivateKey = eDwURfg8PhpUAdPp+OA9pQ5oZQYqGqY3LToUORMh220= DNS = 1.1.1.1 +PostUp = sysctl -w net.ipv4.ip_forward=1 +PostUp = sysctl -w net.ipv6.conf.all.forwarding=1 +PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE +PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE + [Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 +# Name = montreal.example-vpn.dev +# LAN = 192.168.1.1/24 +Endpoint = montreal.example-vpn.dev:51820 PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 -PersistentKeepalive = 25 +AllowedIPs = 10.0.44.1/32, 192.168.1.1/24 + +[Peer] +# Name = vancouver.example-vpn.dev +# LAN = 192.168.3.1/24 +Endpoint = vancouver.example-vpn.dev:51820 +PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= +AllowedIPs = 10.0.44.3/32, 192.168.3.1/24 diff --git a/example-lan-briding/vancouver/setup.sh b/example-lan-briding/vancouver/setup.sh index b9991f8..385c4d8 100644 --- a/example-lan-briding/vancouver/setup.sh +++ b/example-lan-briding/vancouver/setup.sh @@ -14,4 +14,4 @@ sudo sysctl -p /etc/sysctl.conf iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT -iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE +iptables -t nat -A POSTROUTING -s 10.0.44.0/24 -o eth0 -j MASQUERADE diff --git a/example-lan-briding/vancouver/public-server1.key b/example-lan-briding/vancouver/vancouver.key similarity index 100% rename from example-lan-briding/vancouver/public-server1.key rename to example-lan-briding/vancouver/vancouver.key diff --git a/example-lan-briding/vancouver/public-server1.key.pub b/example-lan-briding/vancouver/vancouver.key.pub similarity index 100% rename from example-lan-briding/vancouver/public-server1.key.pub rename to example-lan-briding/vancouver/vancouver.key.pub diff --git a/example-lan-briding/vancouver/wg0.conf b/example-lan-briding/vancouver/wg0.conf index 7e28ae4..f1d755c 100644 --- a/example-lan-briding/vancouver/wg0.conf +++ b/example-lan-briding/vancouver/wg0.conf @@ -1,28 +1,26 @@ [Interface] -# Name = public-server1.example-vpn.tld -Address = 10.0.0.1/24 +# Name = vancouver.example-vpn.tld +# LAN = 192.168.3.1/24 +Address = 10.0.44.3/24 ListenPort = 51820 -PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= +PrivateKey = WN+bvd3PCWs5Pk3bvl7abWR0c1L6PCWKYRX56mjVYGo= DNS = 1.1.1.1 +PostUp = sysctl -w net.ipv4.ip_forward=1 +PostUp = sysctl -w net.ipv6.conf.all.forwarding=1 +PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE +PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE -[Peer] -# Name = public-server2.example-vpn.dev -Endpoint = public-server2.example-vpn.dev:51820 -PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= -AllowedIPs = 10.0.0.2/32 [Peer] -# Name = home-server.example-vpn.dev -Endpoint = home-server.example-vpn.dev:51820 -PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= -AllowedIPs = 10.0.0.3/32 +# Name = montreal.example-vpn.dev +# LAN = 192.168.1.1/24 +Endpoint = montreal.example-vpn.dev:51820 +PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= +AllowedIPs = 10.0.44.1/32, 192.168.1.1/24 [Peer] -# Name = laptop.example-vpn.dev -PublicKey = BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= -AllowedIPs = 10.0.0.4/32 - -[Peer] -# Name = phone.example-vpn.dev -PublicKey = VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= -AllowedIPs = 10.0.0.5/32 +# Name = newyork.example-vpn.dev +# LAN = 192.168.2.1/24 +Endpoint = newyork.example-vpn.dev:51820 +PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= +AllowedIPs = 10.0.44.2/32, 192.168.2.1/24 diff --git a/example-simple-client-to-server/client/laptop.key b/example-simple-client-to-server/client/client.key similarity index 100% rename from example-simple-client-to-server/client/laptop.key rename to example-simple-client-to-server/client/client.key diff --git a/example-simple-client-to-server/client/laptop.key.pub b/example-simple-client-to-server/client/client.key.pub similarity index 100% rename from example-simple-client-to-server/client/laptop.key.pub rename to example-simple-client-to-server/client/client.key.pub diff --git a/example-simple-client-to-server/client/wg0.conf b/example-simple-client-to-server/client/wg0.conf index d2f625d..fd3fdc3 100644 --- a/example-simple-client-to-server/client/wg0.conf +++ b/example-simple-client-to-server/client/wg0.conf @@ -1,13 +1,12 @@ [Interface] # Name = laptop.example-vpn.dev -Address = 10.0.0.4/32 +Address = 10.0.44.2/32 PrivateKey = OPmibSXYAAcMIYKNsWqr77zY06Kl750AEB1nWQi1T2o= DNS = 1.1.1.1 [Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 +# Name = server.example-vpn.tld +Endpoint = server.example-vpn.tld:51820 PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 +AllowedIPs = 10.0.44.1/24 PersistentKeepalive = 25 diff --git a/example-simple-client-to-server/server/public-server1.key b/example-simple-client-to-server/server/server.key similarity index 100% rename from example-simple-client-to-server/server/public-server1.key rename to example-simple-client-to-server/server/server.key diff --git a/example-simple-client-to-server/server/public-server1.key.pub b/example-simple-client-to-server/server/server.key.pub similarity index 100% rename from example-simple-client-to-server/server/public-server1.key.pub rename to example-simple-client-to-server/server/server.key.pub diff --git a/example-simple-client-to-server/server/setup.sh b/example-simple-client-to-server/server/setup.sh index b9991f8..385c4d8 100644 --- a/example-simple-client-to-server/server/setup.sh +++ b/example-simple-client-to-server/server/setup.sh @@ -14,4 +14,4 @@ sudo sysctl -p /etc/sysctl.conf iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT -iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE +iptables -t nat -A POSTROUTING -s 10.0.44.0/24 -o eth0 -j MASQUERADE diff --git a/example-simple-client-to-server/server/wg0.conf b/example-simple-client-to-server/server/wg0.conf index 7e28ae4..24db5bf 100644 --- a/example-simple-client-to-server/server/wg0.conf +++ b/example-simple-client-to-server/server/wg0.conf @@ -1,28 +1,11 @@ [Interface] # Name = public-server1.example-vpn.tld -Address = 10.0.0.1/24 +Address = 10.0.44.1/24 ListenPort = 51820 PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= DNS = 1.1.1.1 [Peer] -# Name = public-server2.example-vpn.dev -Endpoint = public-server2.example-vpn.dev:51820 -PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= -AllowedIPs = 10.0.0.2/32 - -[Peer] -# Name = home-server.example-vpn.dev -Endpoint = home-server.example-vpn.dev:51820 -PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= -AllowedIPs = 10.0.0.3/32 - -[Peer] -# Name = laptop.example-vpn.dev +# Name = client.example-vpn.dev PublicKey = BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= -AllowedIPs = 10.0.0.4/32 - -[Peer] -# Name = phone.example-vpn.dev -PublicKey = VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= -AllowedIPs = 10.0.0.5/32 +AllowedIPs = 10.0.44.2/32 diff --git a/example-simple-server-to-server/home-server/home-server.key b/example-simple-server-to-server/home-server/home-server.key deleted file mode 100644 index 2df1302..0000000 --- a/example-simple-server-to-server/home-server/home-server.key +++ /dev/null @@ -1 +0,0 @@ -WN+bvd3PCWs5Pk3bvl7abWR0c1L6PCWKYRX56mjVYGo= diff --git a/example-simple-server-to-server/home-server/home-server.key.pub b/example-simple-server-to-server/home-server/home-server.key.pub deleted file mode 100644 index 6d118d2..0000000 --- a/example-simple-server-to-server/home-server/home-server.key.pub +++ /dev/null @@ -1 +0,0 @@ -8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= diff --git a/example-simple-server-to-server/home-server/setup.sh b/example-simple-server-to-server/home-server/setup.sh deleted file mode 100644 index 722ba80..0000000 --- a/example-simple-server-to-server/home-server/setup.sh +++ /dev/null @@ -1,9 +0,0 @@ -#!/bin/bash - -# install wireguard on FreeBSD -pkg install wireguard - -# install wireguard on Ubuntu -#add-apt-repository ppa:wireguard/wireguard -#apt update -#apt install wireguard diff --git a/example-simple-server-to-server/home-server/wg0.conf b/example-simple-server-to-server/home-server/wg0.conf deleted file mode 100644 index 2373455..0000000 --- a/example-simple-server-to-server/home-server/wg0.conf +++ /dev/null @@ -1,14 +0,0 @@ -[Interface] -# Name = home-server.example-vpn.dev -Address = 10.0.0.3/32 -ListenPort = 51820 -PrivateKey = WN+bvd3PCWs5Pk3bvl7abWR0c1L6PCWKYRX56mjVYGo= -DNS = 1.1.1.1 - -[Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 -PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 -PersistentKeepalive = 25 diff --git a/example-simple-server-to-server/laptop/laptop.key b/example-simple-server-to-server/laptop/laptop.key deleted file mode 100644 index 686b3d9..0000000 --- a/example-simple-server-to-server/laptop/laptop.key +++ /dev/null @@ -1 +0,0 @@ -OPmibSXYAAcMIYKNsWqr77zY06Kl750AEB1nWQi1T2o= diff --git a/example-simple-server-to-server/laptop/laptop.key.pub b/example-simple-server-to-server/laptop/laptop.key.pub deleted file mode 100644 index 4165fa8..0000000 --- a/example-simple-server-to-server/laptop/laptop.key.pub +++ /dev/null @@ -1 +0,0 @@ -BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= diff --git a/example-simple-server-to-server/laptop/setup.sh b/example-simple-server-to-server/laptop/setup.sh deleted file mode 100644 index 5fb0157..0000000 --- a/example-simple-server-to-server/laptop/setup.sh +++ /dev/null @@ -1,9 +0,0 @@ -#!/bin/bash - -# install wireguard on Ubuntu -#add-apt-repository ppa:wireguard/wireguard -#apt update -#apt install wireguard - -# install wireguard on macOS -brew install wireguard-tools diff --git a/example-simple-server-to-server/laptop/wg0.conf b/example-simple-server-to-server/laptop/wg0.conf deleted file mode 100644 index d2f625d..0000000 --- a/example-simple-server-to-server/laptop/wg0.conf +++ /dev/null @@ -1,13 +0,0 @@ -[Interface] -# Name = laptop.example-vpn.dev -Address = 10.0.0.4/32 -PrivateKey = OPmibSXYAAcMIYKNsWqr77zY06Kl750AEB1nWQi1T2o= -DNS = 1.1.1.1 - -[Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 -PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 -PersistentKeepalive = 25 diff --git a/example-simple-server-to-server/phone/phone.key b/example-simple-server-to-server/phone/phone.key deleted file mode 100644 index a855da1..0000000 --- a/example-simple-server-to-server/phone/phone.key +++ /dev/null @@ -1 +0,0 @@ -WH98AvjKKZ584ZLb69G912bNry2wOda9+kfzm+qbnUw= diff --git a/example-simple-server-to-server/phone/phone.key.pub b/example-simple-server-to-server/phone/phone.key.pub deleted file mode 100644 index 0d67922..0000000 --- a/example-simple-server-to-server/phone/phone.key.pub +++ /dev/null @@ -1 +0,0 @@ -VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= diff --git a/example-simple-server-to-server/phone/setup.sh b/example-simple-server-to-server/phone/setup.sh deleted file mode 100644 index fdbf4f4..0000000 --- a/example-simple-server-to-server/phone/setup.sh +++ /dev/null @@ -1,4 +0,0 @@ -#!/bin/bash - -# install wireguard on iOS/Android -echo "Use the iOS App Store / Google Play Store to install WireGuard on your mobile device" diff --git a/example-simple-server-to-server/phone/start.sh b/example-simple-server-to-server/phone/start.sh deleted file mode 100644 index de47355..0000000 --- a/example-simple-server-to-server/phone/start.sh +++ /dev/null @@ -1,3 +0,0 @@ -#!/bin/bash - -echo "Use the iOS/Android app to load the wg0.conf file and start Wireguard" diff --git a/example-simple-server-to-server/phone/stop.sh b/example-simple-server-to-server/phone/stop.sh deleted file mode 100644 index 4fc7f4a..0000000 --- a/example-simple-server-to-server/phone/stop.sh +++ /dev/null @@ -1,3 +0,0 @@ -#!/bin/bash - -echo "Use the iOS/Android app to load the wg0.conf file and stop Wireguard" diff --git a/example-simple-server-to-server/phone/wg0.conf b/example-simple-server-to-server/phone/wg0.conf deleted file mode 100644 index 47cf7a1..0000000 --- a/example-simple-server-to-server/phone/wg0.conf +++ /dev/null @@ -1,13 +0,0 @@ -[Interface] -# Name = phone.example-vpn.dev -Address = 10.0.0.5/32 -PrivateKey = WH98AvjKKZ584ZLb69G912bNry2wOda9+kfzm+qbnUw= -DNS = 1.1.1.1 - -[Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 -PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 -PersistentKeepalive = 25 diff --git a/example-simple-server-to-server/public-server1/start.sh b/example-simple-server-to-server/public-server1/start.sh deleted file mode 100644 index 9e6a2fb..0000000 --- a/example-simple-server-to-server/public-server1/start.sh +++ /dev/null @@ -1,5 +0,0 @@ -#!/bin/bash - -PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" -wg-quick up "$PEER_DIR"/wg0.conf -wg show diff --git a/example-simple-server-to-server/public-server1/stop.sh b/example-simple-server-to-server/public-server1/stop.sh deleted file mode 100644 index 2faef2c..0000000 --- a/example-simple-server-to-server/public-server1/stop.sh +++ /dev/null @@ -1,5 +0,0 @@ -#!/bin/bash - -PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" -wg-quick down "$PEER_DIR"/wg0.conf -wg show diff --git a/example-simple-server-to-server/public-server1/wg0.conf b/example-simple-server-to-server/public-server1/wg0.conf deleted file mode 100644 index 7e28ae4..0000000 --- a/example-simple-server-to-server/public-server1/wg0.conf +++ /dev/null @@ -1,28 +0,0 @@ -[Interface] -# Name = public-server1.example-vpn.tld -Address = 10.0.0.1/24 -ListenPort = 51820 -PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= -DNS = 1.1.1.1 - -[Peer] -# Name = public-server2.example-vpn.dev -Endpoint = public-server2.example-vpn.dev:51820 -PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= -AllowedIPs = 10.0.0.2/32 - -[Peer] -# Name = home-server.example-vpn.dev -Endpoint = home-server.example-vpn.dev:51820 -PublicKey = 8bSk5fATxg9qdxbK20iTGdrQ7SWvxIBhxdMo+W54pEg= -AllowedIPs = 10.0.0.3/32 - -[Peer] -# Name = laptop.example-vpn.dev -PublicKey = BV5DjXeCugIrjvEZLo4sZ0hN5wveFTH8kOfZ1AIQ5js= -AllowedIPs = 10.0.0.4/32 - -[Peer] -# Name = phone.example-vpn.dev -PublicKey = VpjKa2MQKXuvttXRwJIe0LLYrtFYGQRTtmt8okUGm3A= -AllowedIPs = 10.0.0.5/32 diff --git a/example-simple-server-to-server/public-server2/start.sh b/example-simple-server-to-server/public-server2/start.sh deleted file mode 100644 index 9e6a2fb..0000000 --- a/example-simple-server-to-server/public-server2/start.sh +++ /dev/null @@ -1,5 +0,0 @@ -#!/bin/bash - -PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" -wg-quick up "$PEER_DIR"/wg0.conf -wg show diff --git a/example-simple-server-to-server/public-server2/stop.sh b/example-simple-server-to-server/public-server2/stop.sh deleted file mode 100644 index 2faef2c..0000000 --- a/example-simple-server-to-server/public-server2/stop.sh +++ /dev/null @@ -1,5 +0,0 @@ -#!/bin/bash - -PEER_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" -wg-quick down "$PEER_DIR"/wg0.conf -wg show diff --git a/example-simple-server-to-server/public-server2/wg0.conf b/example-simple-server-to-server/public-server2/wg0.conf deleted file mode 100644 index fa8cf16..0000000 --- a/example-simple-server-to-server/public-server2/wg0.conf +++ /dev/null @@ -1,14 +0,0 @@ -[Interface] -# Name = public-server2.example-vpn.dev -Address = 10.0.0.2/32 -ListenPort = 51820 -PrivateKey = eDwURfg8PhpUAdPp+OA9pQ5oZQYqGqY3LToUORMh220= -DNS = 1.1.1.1 - -[Peer] -# Name = public-server1.example-vpn.tld -Endpoint = public-server1.example-vpn.tld:51820 -PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= -# routes traffic to itself and entire subnet of peers as bounce server -AllowedIPs = 10.0.0.1/24 -PersistentKeepalive = 25 diff --git a/example-simple-server-to-server/public-server1/public-server1.key b/example-simple-server-to-server/server1/server1.key similarity index 100% rename from example-simple-server-to-server/public-server1/public-server1.key rename to example-simple-server-to-server/server1/server1.key diff --git a/example-simple-server-to-server/public-server1/public-server1.key.pub b/example-simple-server-to-server/server1/server1.key.pub similarity index 100% rename from example-simple-server-to-server/public-server1/public-server1.key.pub rename to example-simple-server-to-server/server1/server1.key.pub diff --git a/example-simple-server-to-server/public-server1/setup.sh b/example-simple-server-to-server/server1/setup.sh similarity index 89% rename from example-simple-server-to-server/public-server1/setup.sh rename to example-simple-server-to-server/server1/setup.sh index b9991f8..385c4d8 100644 --- a/example-simple-server-to-server/public-server1/setup.sh +++ b/example-simple-server-to-server/server1/setup.sh @@ -14,4 +14,4 @@ sudo sysctl -p /etc/sysctl.conf iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT -iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE +iptables -t nat -A POSTROUTING -s 10.0.44.0/24 -o eth0 -j MASQUERADE diff --git a/example-simple-server-to-server/home-server/start.sh b/example-simple-server-to-server/server1/start.sh similarity index 100% rename from example-simple-server-to-server/home-server/start.sh rename to example-simple-server-to-server/server1/start.sh diff --git a/example-simple-server-to-server/home-server/stop.sh b/example-simple-server-to-server/server1/stop.sh similarity index 100% rename from example-simple-server-to-server/home-server/stop.sh rename to example-simple-server-to-server/server1/stop.sh diff --git a/example-simple-server-to-server/server1/wg0.conf b/example-simple-server-to-server/server1/wg0.conf new file mode 100644 index 0000000..efd9d06 --- /dev/null +++ b/example-simple-server-to-server/server1/wg0.conf @@ -0,0 +1,12 @@ +[Interface] +# Name = server1.example-vpn.tld +Address = 10.0.44.1/24 +ListenPort = 51820 +PrivateKey = 2P/3ll/TxGTjGqwcWnqJMnjwPqGw7oX1RaXlPfsf2FQ= +DNS = 1.1.1.1 + +[Peer] +# Name = server2.example-vpn.dev +Endpoint = server2.example-vpn.dev:51820 +PublicKey = SceMEaVZaZfOGtGXjMsoJjhwxKHkb++9wjxqN1vm32s= +AllowedIPs = 10.0.44.2/32 diff --git a/example-simple-server-to-server/public-server2/public-server2.key b/example-simple-server-to-server/server2/server2.key similarity index 100% rename from example-simple-server-to-server/public-server2/public-server2.key rename to example-simple-server-to-server/server2/server2.key diff --git a/example-simple-server-to-server/public-server2/public-server2.key.pub b/example-simple-server-to-server/server2/server2.key.pub similarity index 100% rename from example-simple-server-to-server/public-server2/public-server2.key.pub rename to example-simple-server-to-server/server2/server2.key.pub diff --git a/example-simple-server-to-server/public-server2/setup.sh b/example-simple-server-to-server/server2/setup.sh similarity index 100% rename from example-simple-server-to-server/public-server2/setup.sh rename to example-simple-server-to-server/server2/setup.sh diff --git a/example-simple-server-to-server/laptop/start.sh b/example-simple-server-to-server/server2/start.sh similarity index 100% rename from example-simple-server-to-server/laptop/start.sh rename to example-simple-server-to-server/server2/start.sh diff --git a/example-simple-server-to-server/laptop/stop.sh b/example-simple-server-to-server/server2/stop.sh similarity index 100% rename from example-simple-server-to-server/laptop/stop.sh rename to example-simple-server-to-server/server2/stop.sh diff --git a/example-simple-server-to-server/server2/wg0.conf b/example-simple-server-to-server/server2/wg0.conf new file mode 100644 index 0000000..5758827 --- /dev/null +++ b/example-simple-server-to-server/server2/wg0.conf @@ -0,0 +1,12 @@ +[Interface] +# Name = server2.example-vpn.dev +Address = 10.0.44.2/32 +ListenPort = 51820 +PrivateKey = eDwURfg8PhpUAdPp+OA9pQ5oZQYqGqY3LToUORMh220= +DNS = 1.1.1.1 + +[Peer] +# Name = server1.example-vpn.tld +Endpoint = server1.example-vpn.tld:51820 +PublicKey = q/+jwmL5tNuYSB3z+t9Caj00Pc1YQ8zf+uNPu/UE1wE= +AllowedIPs = 10.0.44.1/24 From 83204b403b1095fb2871423980495295dd0646a8 Mon Sep 17 00:00:00 2001 From: Benjamin Porter Date: Mon, 24 Jun 2019 23:55:37 -0600 Subject: [PATCH 16/72] Fix some typos, clear up language --- README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 8dfc7cf..97911cc 100644 --- a/README.md +++ b/README.md @@ -199,7 +199,7 @@ they don't conflict with any of the LAN subnet ranges your peers are on. ### Peer/Node/Device -A host that connects to the VPN and has registers a VPN subnet address like 192.0.2.3 for itself. It can also optionally route traffic for more than its own address(es) by specifying subnet ranges in comma-separated CIDR notation. +A host that connects to the VPN and registers a VPN subnet address such as `192.0.2.3` for itself. It can also optionally route traffic for more than its own address(es) by specifying subnet ranges in comma-separated CIDR notation. ### Bounce Server @@ -263,12 +263,12 @@ In summary: only direct connections between clients should be configured, any co More complex topologies are definitely achievable, but these are the basic routing methods used in typical WireGuard setups: -- **Direct node-to-node** - In the best case, the nodes are on the same LAN or are both publicly accessible. Define directly accessible nodes with hardcoded `Endpoint` addresses and ports so that WireGuard can connect straight to the open port and route UDP packets without intermediate hops. -- **Node behind local NAT to public node** - When 1 of the 2 parties is behind a remote NAT (e.g. when laptop behind a NAT connects to `public-server2`), define the publicly accessible node with a hardcoded `Endpoint` and the NAT-ed node without. The connection will be opened from NAT client -> public client, then traffic will route directly between them in both directions as long as the connection is kept alive by ougoing `PersistentKeepalive` pings from the NAT-ed client. -- **Node behind local NAT to node behind remote NAT (via UDP NAT hole-punching)** - While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the srcport, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random srcports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random srcports and sends them back so the clients, this is how WebRTC works in modern P2P web apps. Even with a signalling server and known srcports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random srcport to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated srcport). This is espcially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. +- **Direct node-to-node** + In the simplest case, the nodes will either be on the same LAN or both be publicly accessible. Define directly accessible nodes with hardcoded `Endpoint` addresses and ports so that WireGuard can connect straight to the open port and route UDP packets without intermediate hops. +- **Node behind local NAT to public node** + When 1 of the 2 parties is behind remote NAT (e.g. when a laptop behind NAT connects to `public-server2`), define the publicly accessible node with a hardcoded `Endpoint` and the NAT-ed node without. The connection will be opened from NAT client -> public client, then traffic will route directly between them in both directions as long as the connection is kept alive by outgoing `PersistentKeepalive` pings from the NAT-ed client. +- **Node behind local NAT to node behind remote NAT (via UDP NAT hole-punching)** + While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the srcport, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random srcports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random srcports and sends them back to the clients. This is how WebRTC works in modern P2P web apps. Even with a signalling server and known srcports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random srcport to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated srcport). This is especially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. More specific (also usually more direct) routes provided by other peers will take precedence when available, otherwise traffic will fall back to the least specific route and use the `192.0.2.1/24` catchall to forward traffic to the bounce server, where it will in turn be routed by the relay server's system routing table (`net.ipv4.ip_forward = 1`) back down the VPN to the specific peer that's accepting routes for that traffic. Wireguard does not automatically find the fastest route or attempt to form direct connections between peers if not already defined, it just goes from the most specific route in `[Peers]` to least specific. From aac0b307c19794eb8e08d091fac1683b54ad03eb Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 25 Jun 2019 14:56:16 -0400 Subject: [PATCH 17/72] markdown formatting --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 97911cc..0cc210c 100644 --- a/README.md +++ b/README.md @@ -263,12 +263,12 @@ In summary: only direct connections between clients should be configured, any co More complex topologies are definitely achievable, but these are the basic routing methods used in typical WireGuard setups: -- **Direct node-to-node** +- **Direct node-to-node** In the simplest case, the nodes will either be on the same LAN or both be publicly accessible. Define directly accessible nodes with hardcoded `Endpoint` addresses and ports so that WireGuard can connect straight to the open port and route UDP packets without intermediate hops. -- **Node behind local NAT to public node** +- **Node behind local NAT to public node** When 1 of the 2 parties is behind remote NAT (e.g. when a laptop behind NAT connects to `public-server2`), define the publicly accessible node with a hardcoded `Endpoint` and the NAT-ed node without. The connection will be opened from NAT client -> public client, then traffic will route directly between them in both directions as long as the connection is kept alive by outgoing `PersistentKeepalive` pings from the NAT-ed client. -- **Node behind local NAT to node behind remote NAT (via UDP NAT hole-punching)** - While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the srcport, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random srcports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random srcports and sends them back to the clients. This is how WebRTC works in modern P2P web apps. Even with a signalling server and known srcports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random srcport to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated srcport). This is especially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. +- **Node behind local NAT to node behind remote NAT (via UDP NAT hole-punching)** + While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the srcport, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random srcports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random srcports and sends them back to the clients. This is how WebRTC works in modern P2P web apps. Even with a signalling server and known srcports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random srcport to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated srcport). This is especially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. More specific (also usually more direct) routes provided by other peers will take precedence when available, otherwise traffic will fall back to the least specific route and use the `192.0.2.1/24` catchall to forward traffic to the bounce server, where it will in turn be routed by the relay server's system routing table (`net.ipv4.ip_forward = 1`) back down the VPN to the specific peer that's accepting routes for that traffic. Wireguard does not automatically find the fastest route or attempt to form direct connections between peers if not already defined, it just goes from the most specific route in `[Peers]` to least specific. From afa96b6a5979edeec3fafca60b5ee4bf5e36927f Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 25 Jun 2019 14:57:20 -0400 Subject: [PATCH 18/72] whoops dunno why I deleted this section before --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 0cc210c..b64f2ca 100644 --- a/README.md +++ b/README.md @@ -267,6 +267,8 @@ More complex topologies are definitely achievable, but these are the basic routi In the simplest case, the nodes will either be on the same LAN or both be publicly accessible. Define directly accessible nodes with hardcoded `Endpoint` addresses and ports so that WireGuard can connect straight to the open port and route UDP packets without intermediate hops. - **Node behind local NAT to public node** When 1 of the 2 parties is behind remote NAT (e.g. when a laptop behind NAT connects to `public-server2`), define the publicly accessible node with a hardcoded `Endpoint` and the NAT-ed node without. The connection will be opened from NAT client -> public client, then traffic will route directly between them in both directions as long as the connection is kept alive by outgoing `PersistentKeepalive` pings from the NAT-ed client. +**Node behind local NAT to node behind remote NAT (via relay)** + Most of the time when both parties are behind NATs, the NATs do srcport randomization makind direct connections infeasible, so they will both have to open a connection to `public-server1`, and traffic will forward through the intermediary bounce server as long as the connections are kept alive. - **Node behind local NAT to node behind remote NAT (via UDP NAT hole-punching)** While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the srcport, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random srcports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random srcports and sends them back to the clients. This is how WebRTC works in modern P2P web apps. Even with a signalling server and known srcports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random srcport to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated srcport). This is especially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. From 4f00598d5d863d044f1c0cdec3733e20b98c42e0 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 25 Jun 2019 14:57:53 -0400 Subject: [PATCH 19/72] markdown --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index b64f2ca..9bb7529 100644 --- a/README.md +++ b/README.md @@ -267,7 +267,7 @@ More complex topologies are definitely achievable, but these are the basic routi In the simplest case, the nodes will either be on the same LAN or both be publicly accessible. Define directly accessible nodes with hardcoded `Endpoint` addresses and ports so that WireGuard can connect straight to the open port and route UDP packets without intermediate hops. - **Node behind local NAT to public node** When 1 of the 2 parties is behind remote NAT (e.g. when a laptop behind NAT connects to `public-server2`), define the publicly accessible node with a hardcoded `Endpoint` and the NAT-ed node without. The connection will be opened from NAT client -> public client, then traffic will route directly between them in both directions as long as the connection is kept alive by outgoing `PersistentKeepalive` pings from the NAT-ed client. -**Node behind local NAT to node behind remote NAT (via relay)** +- **Node behind local NAT to node behind remote NAT (via relay)** Most of the time when both parties are behind NATs, the NATs do srcport randomization makind direct connections infeasible, so they will both have to open a connection to `public-server1`, and traffic will forward through the intermediary bounce server as long as the connections are kept alive. - **Node behind local NAT to node behind remote NAT (via UDP NAT hole-punching)** While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the srcport, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random srcports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random srcports and sends them back to the clients. This is how WebRTC works in modern P2P web apps. Even with a signalling server and known srcports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random srcport to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated srcport). This is especially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. From 0910c7d123cee9a2188aa6f738adc3805ae3666c Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 25 Jun 2019 15:57:22 -0400 Subject: [PATCH 20/72] Rename "Missing" to "Unofficial" --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 9bb7529..cabc1a7 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@
                        -# The Missing Wireguard Documentation +# The Unofficial Wireguard Documentation

                        @@ -23,7 +23,9 @@ Nicer HTML page version: https://docs.sweeting.me/s/wireguard [WireGuard](https://www.wireguard.com/) is a BETA/WIP open-source VPN solution written in C by [Jason Donenfeld](https://www.jasondonenfeld.com) and [others](https://github.com/WireGuard/WireGuard/graphs/contributors), aiming to fix many of the problems that have plagued other modern server-to-server VPN offerings like IPSec/IKEv2, OpenVPN, or L2TP. It shares some similarities with other modern VPN offerings like [Tinc](https://www.tinc-vpn.org/) and [MeshBird](https://github.com/meshbird/meshbird), namely good cipher suites and minimal config. -This is my attempt at writing "The Missing Wireguard Documentation" to make up for the somewhat sparse official docs on an otherwise great piece of software. +This is my attempt at writing "The Unofficial Wireguard Documentation" to make up for the somewhat sparse official docs on an otherwise great piece of software. + +(This repo used to be called "The Missing Wireguard Documentation" but I felt bad about implying that Wireguard has no docs, they do have docs, they're just hidden away in the manpages and mailing lists.) **Official Links** From d5f7cbf6f72e368a9ddddb8590053d63350efd1e Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Fri, 26 Jul 2019 14:04:23 -0700 Subject: [PATCH 21/72] add raspi instructions --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index cabc1a7..6dbcd83 100644 --- a/README.md +++ b/README.md @@ -1138,6 +1138,7 @@ Setups can get somewhat complex and are highly dependent on what you're trying t - https://www.ericlight.com/wireguard-part-two-vpn-routing.html - https://www.ericlight.com/wireguard-part-three-troubleshooting.html - https://wiki.dd-wrt.com/wiki/index.php/The_Easiest_Tunnel_Ever +- https://www.reddit.com/r/pihole/comments/bnihyz/guide_how_to_install_wireguard_on_a_raspberry_pi/ ### Papers, Articles, and Talks From 1a67299e0398c08df75edb8e43c1ecd1d7bf06c9 Mon Sep 17 00:00:00 2001 From: Daniel Luft Date: Fri, 23 Aug 2019 15:10:10 +0200 Subject: [PATCH 22/72] add wg-dashboard to readme --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 6dbcd83..e38f4b1 100644 --- a/README.md +++ b/README.md @@ -1052,6 +1052,7 @@ These are some GUI and CLI tools that wrap WireGuard to assist with config, depl - https://github.com/trailofbits/algo - https://github.com/StreisandEffect/streisand - https://www.veeam.com/blog/veeam-pn-v2-wireguard.html + - https://github.com/wg-dashboard/wg-dashboard ### Config Shortcuts @@ -1167,6 +1168,7 @@ Setups can get somewhat complex and are highly dependent on what you're trying t - https://github.com/WireGuard/wireguard-rs - https://github.com/WireGuard/wireguard-go - https://www.veeam.com/blog/veeam-pn-v2-wireguard.html +- https://github.com/wg-dashboard/wg-dashboard ### Docker From 32c58aee380c29cb357247f5c539303c20ca93cb Mon Sep 17 00:00:00 2001 From: Peppa Pig Date: Thu, 19 Sep 2019 23:36:30 -0400 Subject: [PATCH 23/72] Update README.md --- README.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/README.md b/README.md index e38f4b1..b223fbf 100644 --- a/README.md +++ b/README.md @@ -363,6 +363,12 @@ PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privke ### Quickstart +Automated Script To Install WireGuard + +``` +https://github.com/complexorganizations/wireguard-install +``` + Overview of the general process: 1. Install `apt install wireguard` or `pkg/brew install wireguard-tools` on each node @@ -1152,6 +1158,7 @@ Setups can get somewhat complex and are highly dependent on what you're trying t ### Related Projects +- https://github.com/complexorganizations/wireguard-install - https://github.com/subspacecloud/subspace - https://github.com/trailofbits/algo - https://github.com/StreisandEffect/streisand From d51322b54441b348e5fa1134aebe47a934e145af Mon Sep 17 00:00:00 2001 From: Peppa Pig Date: Fri, 20 Sep 2019 10:18:38 -0400 Subject: [PATCH 24/72] Update README.md --- README.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/README.md b/README.md index b223fbf..7befb4a 100644 --- a/README.md +++ b/README.md @@ -363,12 +363,6 @@ PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privke ### Quickstart -Automated Script To Install WireGuard - -``` -https://github.com/complexorganizations/wireguard-install -``` - Overview of the general process: 1. Install `apt install wireguard` or `pkg/brew install wireguard-tools` on each node From 80de592be03177c3ec966c010a5b8466f329c515 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Sat, 21 Sep 2019 22:55:53 -0400 Subject: [PATCH 25/72] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 7befb4a..68218b6 100644 --- a/README.md +++ b/README.md @@ -270,7 +270,7 @@ More complex topologies are definitely achievable, but these are the basic routi - **Node behind local NAT to public node** When 1 of the 2 parties is behind remote NAT (e.g. when a laptop behind NAT connects to `public-server2`), define the publicly accessible node with a hardcoded `Endpoint` and the NAT-ed node without. The connection will be opened from NAT client -> public client, then traffic will route directly between them in both directions as long as the connection is kept alive by outgoing `PersistentKeepalive` pings from the NAT-ed client. - **Node behind local NAT to node behind remote NAT (via relay)** - Most of the time when both parties are behind NATs, the NATs do srcport randomization makind direct connections infeasible, so they will both have to open a connection to `public-server1`, and traffic will forward through the intermediary bounce server as long as the connections are kept alive. + Most of the time when both parties are behind NATs, the NATs do srcport randomization making direct connections infeasible, so they will both have to open a connection to `public-server1`, and traffic will forward through the intermediary bounce server as long as the connections are kept alive. - **Node behind local NAT to node behind remote NAT (via UDP NAT hole-punching)** While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the srcport, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random srcports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random srcports and sends them back to the clients. This is how WebRTC works in modern P2P web apps. Even with a signalling server and known srcports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random srcport to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated srcport). This is especially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. From b635d44257e86f4ce77ec4f4746f5f0badf76504 Mon Sep 17 00:00:00 2001 From: Richard Huynh <1764089+namidairo@users.noreply.github.com> Date: Sat, 5 Oct 2019 20:22:06 +1000 Subject: [PATCH 26/72] Make use of "WireGuard" consistent, fix a typo Stop use of "wireguard", "Wireguard" in places where it isn't a command or URL. --- README.md | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/README.md b/README.md index 68218b6..0294a04 100644 --- a/README.md +++ b/README.md @@ -1,11 +1,11 @@
                        -# The Unofficial Wireguard Documentation +# The Unofficial WireGuard Documentation

                        -API reference guide for Wireguard including Setup, Configuration, and Usage, with examples. +API reference guide for WireGuard including Setup, Configuration, and Usage, with examples. All credit goes to the WireGuard project, [zx2c4](https://www.zx2c4.com/), [Edge Security](https://www.edgesecurity.com/), and the [open source contributors](https://github.com/WireGuard/WireGuard/graphs/contributors) for the original software,
                        this is my solo unofficial attempt at providing more comprehensive documentation, API references, and examples.                         @@ -23,9 +23,9 @@ Nicer HTML page version: https://docs.sweeting.me/s/wireguard [WireGuard](https://www.wireguard.com/) is a BETA/WIP open-source VPN solution written in C by [Jason Donenfeld](https://www.jasondonenfeld.com) and [others](https://github.com/WireGuard/WireGuard/graphs/contributors), aiming to fix many of the problems that have plagued other modern server-to-server VPN offerings like IPSec/IKEv2, OpenVPN, or L2TP. It shares some similarities with other modern VPN offerings like [Tinc](https://www.tinc-vpn.org/) and [MeshBird](https://github.com/meshbird/meshbird), namely good cipher suites and minimal config. -This is my attempt at writing "The Unofficial Wireguard Documentation" to make up for the somewhat sparse official docs on an otherwise great piece of software. +This is my attempt at writing "The Unofficial WireGuard Documentation" to make up for the somewhat sparse official docs on an otherwise great piece of software. -(This repo used to be called "The Missing Wireguard Documentation" but I felt bad about implying that Wireguard has no docs, they do have docs, they're just hidden away in the manpages and mailing lists.) +(This repo used to be called "The Missing WireGuard Documentation" but I felt bad about implying that WireGuard has no docs, they do have docs, they're just hidden away in the manpages and mailing lists.) **Official Links** @@ -65,7 +65,7 @@ See https://github.com/pirate/wireguard-docs for example code and documentation
                      • List of Possible VPN Solutions
                      • -
                    • Wireguard Documentation +
                    • WireGuard Documentation
                      • Glossary
                          @@ -173,7 +173,7 @@ Over the last 8+ years I've tried a wide range of VPN solutions. Somewhat out o --- -# Wireguard Documentation +# WireGuard Documentation --- @@ -234,12 +234,12 @@ The publicly accessible address:port for a node, e.g. `123.124.125.126:1234` or ### Private key -A wireguard private key for a single node, generated with: +A WireGuard private key for a single node, generated with: `wg genkey > example.key` (never leaves the node it's generated on) ### Public key -A wireguard public key for a single node, generated with: +A WireGuard public key for a single node, generated with: `wg pubkey < example.key > example.key.pub ` (shared with other peers) @@ -274,7 +274,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)** While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the srcport, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random srcports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random srcports and sends them back to the clients. This is how WebRTC works in modern P2P web apps. Even with a signalling server and known srcports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random srcport to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated srcport). This is especially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. -More specific (also usually more direct) routes provided by other peers will take precedence when available, otherwise traffic will fall back to the least specific route and use the `192.0.2.1/24` catchall to forward traffic to the bounce server, where it will in turn be routed by the relay server's system routing table (`net.ipv4.ip_forward = 1`) back down the VPN to the specific peer that's accepting routes for that traffic. Wireguard does not automatically find the fastest route or attempt to form direct connections between peers if not already defined, it just goes from the most specific route in `[Peers]` to least specific. +More specific (also usually more direct) routes provided by other peers will take precedence when available, otherwise traffic will fall back to the least specific route and use the `192.0.2.1/24` catchall to forward traffic to the bounce server, where it will in turn be routed by the relay server's system routing table (`net.ipv4.ip_forward = 1`) back down the VPN to the specific peer that's accepting routes for that traffic. WireGuard does not automatically find the fastest route or attempt to form direct connections between peers if not already defined, it just goes from the most specific route in `[Peers]` to least specific. You can figure out which routing method WireGuard is using for a given address by measuring the ping times to figure out the unique length of each hop, and by inspecting the output of: ```bash @@ -367,14 +367,14 @@ Overview of the general process: 1. Install `apt install wireguard` or `pkg/brew install wireguard-tools` on each node 2. Generate public and private keys locally on each node `wg genkey`+`wg pubkey` -3. Create a `wg0.conf` wireguard config file on the main relay server +3. Create a `wg0.conf` WireGuard config file on the main relay server - `[Interface]` Make sure to specify a CIDR range for the entire VPN subnet when defining the address the server accepts routes for `Address = 192.0.2.1/24` - `[Peer]` Create a peer section for every client joining the VPN, using their corresponding remote public keys 4. Create a `wg0.conf` on each client node - `[Interface]` Make sure to specify only a single IP for client peers that don't relay traffic `Address = 192.0.2.3/32`. - `[Peer]` Create a peer section for each public peer not behind a NAT, make sure to specify a CIDR range for the entire VPN subnet when defining the remote peer acting as the bounce server `AllowedIPs = 192.0.2.1/24`. Make sure to specify individual IPs for remote peers that don't relay traffic and only act as simple clients `AllowedIPs = 192.0.2.3/32`. -5. Start wireguard on the main relay server with `wg-quick up /full/path/to/wg0.conf` -6. Start wireguard on all the client peers with `wg-quick up /full/path/to/wg0.conf` +5. Start WireGuard on the main relay server with `wg-quick up /full/path/to/wg0.conf` +6. Start WireGuard on all the client peers with `wg-quick up /full/path/to/wg0.conf` 7. Traffic is routed from peer to peer using most specific route first over the WireGuard interface, e.g. `ping 192.0.2.3` checks for a direct route to a peer with `AllowedIPs = 192.0.2.3/32` first, then falls back to a relay server that's accepting ips in the whole subnet ### Setup @@ -462,7 +462,7 @@ ip address show ifconfig wg0 ip link show wg0 -# show wireguard VPN interfaces +# show WireGuard VPN interfaces wg show all wg show wg0 ``` @@ -482,7 +482,7 @@ ip address show wg0 #### Routes ```bash -# show wireguard routing table and peer connections +# show WireGuard routing table and peer connections wg show wg show wg0 allowed-ips @@ -886,7 +886,7 @@ If the connection is going from a NAT-ed peer to a public peer, the node behind ### IPv6 -The examples in these docs primarily use IPv4, but Wireguard natively supports IPv6 CIDR notation and addresses everywhere that it supports IPv4, simply add them as you would any other subnet range or address. +The examples in these docs primarily use IPv4, but WireGuard natively supports IPv6 CIDR notation and addresses everywhere that it supports IPv4, simply add them as you would any other subnet range or address. **Example** @@ -923,9 +923,9 @@ AllowedIPs = 0.0.0.0/0, ::/0 ### NAT To NAT Connections -WireGuard can sometimes natively make connections between two clients behind NATs without the need for a public relay server, but in most cases this is not possible. NAT-to-NAT connections are not possible unless at least one host has a stable, publicly-accessible IP address:port pair that can be hardcoded ahead of time, whether thats using a FQDN updated with Dynamic DNS, or a static public IP with a non-randomized NAT port opened by outgoing packets, anything works as long as all peers can communicate it beforehand and it doesn't change once the connection is initiated. +WireGuard can sometimes natively make connections between two clients behind NATs without the need for a public relay server, but in most cases this is not possible. NAT-to-NAT connections are not possible unless at least one host has a stable, publicly-accessible IP address:port pair that can be hardcoded ahead of time, whether that's using a FQDN updated with Dynamic DNS, or a static public IP with a non-randomized NAT port opened by outgoing packets, anything works as long as all peers can communicate it beforehand and it doesn't change once the connection is initiated. -Wireguard 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 `Endpoint` address and `ListenPort`, and `PersistentKeepalive` set to some non-null value on both sides. +WireGuard 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 `Endpoint` address and `ListenPort`, and `PersistentKeepalive` set to some non-null value on both sides. #### The hole-punching connection process @@ -954,7 +954,7 @@ As of 2019, many of the old hole-punching methods used that used to work are no NAT-to-NAT connections are not possible if all endpoints are behind NAT's with strict UDP source port randomization (e.g. most cellular data networks). Since neither side is able to hardcode a `ListenPort` and guarantee that their NAT will accept traffic on that port after the outgoing ping, you cannot coordinate a port for the initial hole-punch between peers and connections will fail. For this reason, you generally cannot do phone-to-phone connections on LTE/3g networks, but you might be able to do phone-to-office or phone-to-home where the office or home has a stable public IP and doesn't do source port randomization. ##### Dynamic IP addresses -Many users report having to restart WireGuard whenever a dynamic IP changes, as it only resolves hostnames on startup. To force WireGuard to re-resolve dynamic DNS `Endpoint` hostnames more often, you may want to use a `PostUp` hook to restart Wireguard every few minutes or hours. +Many users report having to restart WireGuard whenever a dynamic IP changes, as it only resolves hostnames on startup. To force WireGuard to re-resolve dynamic DNS `Endpoint` hostnames more often, you may want to use a `PostUp` hook to restart WireGuard every few minutes or hours. #### Testing it out @@ -1021,10 +1021,10 @@ PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command) A compliant userland WireGuard implementation written in Go. - https://git.zx2c4.com/wireguard-rs/about/ -An incomplete, insecure userspace implementation of Wireguard written in Rust (not ready for the public). +An incomplete, insecure userspace implementation of WireGuard written in Rust (not ready for the public). - https://git.zx2c4.com/wireguard-hs/about/ -An incomplete, insecure userspace implementation of Wireguard written in Haskell (not ready for the public). +An incomplete, insecure userspace implementation of WireGuard written in Haskell (not ready for the public). - https://github.com/cloudflare/boringtun A compliant, working WireGuard implementation with the exact same API, written in Rust. From fe3f84c02033e946381d3cd1055cd696422401ea Mon Sep 17 00:00:00 2001 From: Daniel Alan Miller Date: Wed, 9 Oct 2019 23:56:32 +0000 Subject: [PATCH 27/72] Adding cjdns and adding 'mesh' solutions section --- README.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 68218b6..4350b63 100644 --- a/README.md +++ b/README.md @@ -161,7 +161,7 @@ Over the last 8+ years I've tried a wide range of VPN solutions. Somewhat out o - L2TP: meh - SOCKS: proxy tunnel, not a VPN, not great for this use case - [IPSec (IKEv2)](https://github.com/jawj/IKEv2-setup)/strongSwan: lots of brittle config that's different for each OS, NAT busting setup is very manual and involves updating the central server and starting all the others in the correct order, not great at reconnecting after network downtime, had to be manually restarted often - - [TINC](https://www.tinc-vpn.org/): haven't tried it yet, but it doesn't work on iOS, worst case scenario I could live with that if it's the only option + with that if it's the only option - [OpenVPN](https://openvpn.net/vpn-server-resources/site-to-site-routing-explained-in-detail/): I don't like it from past experience but could be convinced if it's the only option - StealthVPN: haven't tried it - [MeshBird](https://github.com/meshbird/meshbird): "Cloud native" VPN/networking layer @@ -169,6 +169,10 @@ Over the last 8+ years I've tried a wide range of VPN solutions. Somewhat out o - [Striesand](https://github.com/StreisandEffect/streisand): haven't tried it yet, what's the best config to try? - [SoftEther](https://www.softether.org/): haven't tried it yet, should I? - [WireGuard](https://www.wireguard.com/): the subject of this post + +### Mesh VPN Solutions + - [TINC](https://www.tinc-vpn.org/): haven't tried it yet, but it doesn't work on iOS, worst case scenario I could live + - [cjdns](https://github.com/cjdelisle/cjdns): haven't tried it yet, should I? - [ZeroTier](https://www.zerotier.com): haven't tried it yet, should I? --- From bc5811ec4814c49569962d9a871bd7da5f658542 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Thu, 31 Oct 2019 00:25:34 -0400 Subject: [PATCH 28/72] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 68218b6..00371dc 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@
                          -# The Unofficial Wireguard Documentation +# Some Unofficial Wireguard Documentation

                          From 2c94a1d9d5ddfcb4a0836dc9f795a48597c5653a Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Thu, 31 Oct 2019 00:27:33 -0400 Subject: [PATCH 29/72] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 00371dc..75a1a16 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ Nicer HTML page version: https://docs.sweeting.me/s/wireguard This is my attempt at writing "The Unofficial Wireguard Documentation" to make up for the somewhat sparse official docs on an otherwise great piece of software. -(This repo used to be called "The Missing Wireguard Documentation" but I felt bad about implying that Wireguard has no docs, they do have docs, they're just hidden away in the manpages and mailing lists.) +(This repo used to be called "The Missing Wireguard Documentation" but I felt bad about implying that Wireguard has no docs (they do have docs, they're just hidden away in the manpages). I figred I could combine it with some example setup configs, and some of the secret tips and tricks shared only on mailing lists and make a documentation resource.) **Official Links** From c67d9d356218214801d0df4eef3afff3e158b4eb Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 5 Nov 2019 05:56:07 -0500 Subject: [PATCH 30/72] Update README.md --- README.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 75a1a16..64367ff 100644 --- a/README.md +++ b/README.md @@ -923,9 +923,15 @@ AllowedIPs = 0.0.0.0/0, ::/0 ### NAT To NAT Connections -WireGuard can sometimes natively make connections between two clients behind NATs without the need for a public relay server, but in most cases this is not possible. NAT-to-NAT connections are not possible unless at least one host has a stable, publicly-accessible IP address:port pair that can be hardcoded ahead of time, whether thats using a FQDN updated with Dynamic DNS, or a static public IP with a non-randomized NAT port opened by outgoing packets, anything works as long as all peers can communicate it beforehand and it doesn't change once the connection is initiated. +WireGuard can sometimes natively make connections between two clients behind NATs without the need for a public relay server, but in most cases this is not possible. NAT-to-NAT connections are only possible if at least one host has a stable, publicly-accessible IP address:port pair that can be hardcoded ahead of time, whether thats using a FQDN updated with Dynamic DNS, or a static public IP with a non-randomized NAT port opened by outgoing packets, anything works as long as all peers can communicate it beforehand and it doesn't change once the connection is initiated. -Wireguard 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 `Endpoint` address and `ListenPort`, and `PersistentKeepalive` set to some non-null value on both sides. +A known port and address need to be configured ahead of time because Wireguard doesn't have a signalling layer or public STUN servers that can be used to search for other hosts dynamically. WebRTC is an example of a protocol that can dynamically configure a connection between two NATs, but it does this by using an out-of-band signaling server to detect the ip:port combo of each host. Wireguard doesn't have this, so it only works with a hardcoded `Endpoint` + `ListenPort` (and `PersistentKeepalive` so it doesn't drop after inactivity). + +#### Requirements for NAT-to-NAT setups + + - At least one peer has to have to have a hardcoded, directly-accessible `Endpoint` defined. If they're both behind NATs without stable IP addresses, then you'll need to use Dynamic DNS or another solution to have a stable, publicly accessibly domain/IP for at least one peer + - At least one peer has to have a hardcoded UDP `ListenPort` defined, and it's NAT router must not do UDP source port randomization, otherwise return packets will be sent to the hardocded `ListenPort` and dropped by the router, instead of using the random port assigned by the NAT on the outgoing packet + - All NAT'ed peers must have `PersistentKeepalive` enabled on all other peers, so that they continually send outgoing pings to keep connections persisted in their NAT's routing table #### The hole-punching connection process @@ -937,17 +943,11 @@ This process of sending an initial packet that gets rejected, then using the fac 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. 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 is how most UDP applications function behind NATs (e.g. Bittorent, Skype, etc). 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 hard-coding them in `wg0.conf` in advance). WebRTC requires a STUN signaling server to communicate the hole-punching port because it would be impossible for browsers to hardcode listening ports for all possible connections in advance. +Getting this to work when both end-points are behind NATs or firewalls requires 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 ahead of time, in WireGuard's case this is achieved by hard-coding pre-defined ports for both sides in `wg0.conf`. -#### Requirements for NAT-to-NAT setups - - - At least one peer has to have to have a hardcoded, directly-accessible `Endpoint` defined. If they're both behind NATs without stable IP addresses, then you'll need to use Dynamic DNS or another solution to have a stable, publicly accessibly domain/IP for at least one peer - - At least one peer has to have a hardcoded UDP `ListenPort` defined, and it's NAT router must not do UDP source port randomization, otherwise return packets will be sent to the hardocded `ListenPort` and dropped by the router, instead of using the random port assigned by the NAT on the outgoing packet - - All NAT'ed peers must have `PersistentKeepalive` enabled on all other peers, so that they continually send outgoing pings to keep connections persisted in their NAT's routing table - #### Drawbacks and limitations -As of 2019, many of the old hole-punching methods used that used to work are no longer effective. One example was a novel method pioneered by [pwnat]](https://github.com/samyk/pwnat) that faked an ICMP Time Exceeded response from outside the NAT to get a packet back through to a NAT'ed peer, thereby leaking its own srcport. +As of 2019, many of the old hole-punching methods used that used to work are no longer effective. One example was a novel method pioneered by [pwnat]](https://github.com/samyk/pwnat) that faked an ICMP Time Exceeded response from outside the NAT to get a packet back through to a NAT'ed peer, thereby leaking its own srcport. Hardcoding UDP ports and public IPs for both sides of a NAT-to-NAT connection (as described above) still works on a small percentage of networks. Generally the more "enterprisey" a network is, the less likely you'll be able to hole puch public UDP ports (commercial public wifi and cell data NATs often don't work for example). ##### Source port randomization From c489569fc71883600ee719ac9aec1ed20bca7b70 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 5 Nov 2019 12:38:09 -0500 Subject: [PATCH 31/72] Update README.md --- README.md | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 4350b63..7f48961 100644 --- a/README.md +++ b/README.md @@ -157,23 +157,29 @@ Over the last 8+ years I've tried a wide range of VPN solutions. Somewhat out o ## List of Possible VPN Solutions - - PPTP: ancient, inflexible, insecure, doesn't solve all the requirements - - L2TP: meh - - SOCKS: proxy tunnel, not a VPN, not great for this use case + - [WireGuard](https://www.wireguard.com/): the subject of this post - [IPSec (IKEv2)](https://github.com/jawj/IKEv2-setup)/strongSwan: lots of brittle config that's different for each OS, NAT busting setup is very manual and involves updating the central server and starting all the others in the correct order, not great at reconnecting after network downtime, had to be manually restarted often with that if it's the only option - [OpenVPN](https://openvpn.net/vpn-server-resources/site-to-site-routing-explained-in-detail/): I don't like it from past experience but could be convinced if it's the only option - StealthVPN: haven't tried it - - [MeshBird](https://github.com/meshbird/meshbird): "Cloud native" VPN/networking layer - - [Algo](https://github.com/trailofbits/algo): haven't tried it yet, should I? - - [Striesand](https://github.com/StreisandEffect/streisand): haven't tried it yet, what's the best config to try? - - [SoftEther](https://www.softether.org/): haven't tried it yet, should I? - - [WireGuard](https://www.wireguard.com/): the subject of this post + - [DsVPN](https://github.com/jedisct1/dsvpn): does TCP-over-TCP which usually doesn't end well... + - [SoftEther](https://www.softether.org/) ([SSTP](https://en.wikipedia.org/wiki/Secure_Socket_Tunneling_Protocol)): haven't tried it yet, should I? (also does TCP-over-TCP) + - PPTP: ancient, inflexible, insecure, doesn't solve all the requirements + - L2TP: meh + - SOCKS: proxy tunnel, not a VPN, not great for this use case ### Mesh VPN Solutions + - [TINC](https://www.tinc-vpn.org/): haven't tried it yet, but it doesn't work on iOS, worst case scenario I could live - [cjdns](https://github.com/cjdelisle/cjdns): haven't tried it yet, should I? - - [ZeroTier](https://www.zerotier.com): haven't tried it yet, should I? + - [ZeroTier](https://www.zerotier.com): haven't tried it yet, should I + - [MeshBird](https://github.com/meshbird/meshbird): "Cloud native" VPN/networking layer + +### Setup Tools + + - [Algo](https://github.com/trailofbits/algo) WireGuard setup tool + - [Striesand](https://github.com/StreisandEffect/streisand) Multi-protocol setup tool + - [IKEv2-setup](https://github.com/jawj/IKEv2-setup) IKEv2 server setup script --- From b0d447ad66bb447fe0c793c010e91870f928823e Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 5 Nov 2019 12:40:14 -0500 Subject: [PATCH 32/72] Add VPNCloud --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 4e5d6aa..4d8631a 100644 --- a/README.md +++ b/README.md @@ -170,7 +170,8 @@ Over the last 8+ years I've tried a wide range of VPN solutions. Somewhat out o ### Mesh VPN Solutions - - [TINC](https://www.tinc-vpn.org/): haven't tried it yet, but it doesn't work on iOS, worst case scenario I could live + - [TINC](https://www.tinc-vpn.org/): haven't tried it yet, but it doesn't work on iOS, worst case scenario I could live + - [VPNCloud](https://github.com/dswd/vpncloud): similar properties to WireGuard, with more auto-mesh features - [cjdns](https://github.com/cjdelisle/cjdns): haven't tried it yet, should I? - [ZeroTier](https://www.zerotier.com): haven't tried it yet, should I - [MeshBird](https://github.com/meshbird/meshbird): "Cloud native" VPN/networking layer From adf28188b21e7386cb6920310b9ae77fe6a7275e Mon Sep 17 00:00:00 2001 From: Jens Willmer Date: Sun, 17 Nov 2019 17:27:15 +0100 Subject: [PATCH 33/72] Added blog post to tutorials --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 4d8631a..686d110 100644 --- a/README.md +++ b/README.md @@ -1151,6 +1151,7 @@ Setups can get somewhat complex and are highly dependent on what you're trying t - https://www.ericlight.com/wireguard-part-three-troubleshooting.html - https://wiki.dd-wrt.com/wiki/index.php/The_Easiest_Tunnel_Ever - https://www.reddit.com/r/pihole/comments/bnihyz/guide_how_to_install_wireguard_on_a_raspberry_pi/ +- https://jwillmer.de/blog/tutorial/wireguard-proxy-configuration ### Papers, Articles, and Talks From 209c42dc176adf777e5cacde21b05340325b9fdd Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Wed, 18 Dec 2019 02:15:14 -0500 Subject: [PATCH 34/72] Update README.md --- README.md | 50 +++++++++++++++++++++++++++----------------------- 1 file changed, 27 insertions(+), 23 deletions(-) diff --git a/README.md b/README.md index 686d110..eb2bd57 100644 --- a/README.md +++ b/README.md @@ -21,11 +21,7 @@ Nicer HTML page version: https://docs.sweeting.me/s/wireguard --- -[WireGuard](https://www.wireguard.com/) is a BETA/WIP open-source VPN solution written in C by [Jason Donenfeld](https://www.jasondonenfeld.com) and [others](https://github.com/WireGuard/WireGuard/graphs/contributors), aiming to fix many of the problems that have plagued other modern server-to-server VPN offerings like IPSec/IKEv2, OpenVPN, or L2TP. It shares some similarities with other modern VPN offerings like [Tinc](https://www.tinc-vpn.org/) and [MeshBird](https://github.com/meshbird/meshbird), namely good cipher suites and minimal config. - -This is my attempt at writing "The Unofficial WireGuard Documentation" to make up for the somewhat sparse official docs on an otherwise great piece of software. - -(This repo used to be called "The Missing WireGuard Documentation" but I felt bad about implying that WireGuard has no docs (they do have docs, they're just hidden away in the manpages). I figred I could combine it with some example setup configs, and some of the secret tips and tricks shared only on mailing lists and make a documentation resource.) +[WireGuard](https://www.wireguard.com/) is an open-source VPN solution written in C by [Jason Donenfeld](https://www.jasondonenfeld.com) and [others](https://github.com/WireGuard/WireGuard/graphs/contributors), aiming to fix many of the problems that have plagued other modern server-to-server VPN offerings like IPSec/IKEv2, OpenVPN, or L2TP. It shares some similarities with other modern VPN offerings like [Tinc](https://www.tinc-vpn.org/) and [MeshBird](https://github.com/meshbird/meshbird), namely good cipher suites and minimal config. **Official Links** @@ -138,35 +134,43 @@ See https://github.com/pirate/wireguard-docs for example code and documentation # Intro -Over the last 8+ years I've tried a wide range of VPN solutions. Somewhat out of necessity, since the city I was living in was behind the Great Wall of China. Everything from old-school PPTP to crazy round-robin GoAgent AppEngine proxy setups were common back in the early 2010's to break through the GFW, these days it's mostly OpenVPN, StealthVPN, IPSec/IKEv2 and others. From the recommendation of a few people in the [RC](https://recurse.com) Zulip community, I decided to try WireGuard and was surprised to find it checked almost all the boxes. +Whether living behind the Great Wall of China or just trying to form a network between your servers, Wireguard is a great option and serves as a "lego block" for building networks (much in the same way that ZFS is a lego block for building filesystems). -## My Personal Requirements for a VPN Solution +## Wireguard Overview - - minimal config, low config surface area and few exposed tunables - - minimal key management overhead, 1 or 2 preshared keys or certs is ok, but ideally not both - - ability to easily create a LAN like 192.0.2.0/24 between all my servers, every peer can connect to every peer, - - ability to bust through NATs with a signalling server, routing nat-to-nat instead of through a relay (WebRTC-style) - - fallback to relay server when nat-to-nat busting is unavailable or unreliable - - ability to route to a fixed list of ips/hosts with 1 keypair per host (not needed, but nice to have: ability to route arbitrary local traffic or *all* internet traffic to a given host) + - minimal config, low tunable surface area and sane defaults + - minimal key management work needed, just 1 public & 1 private key per host + - behaves like a normal ethernet interface, behaves well with standard kernel packet routing rules + - ability to easily create a LAN like 192.0.2.0/24 between all servers, or more complex networks using custom routes + - ability to some traffic or all traffic to/through arbitrary hosts on the VPN LAN - robust automatic reconnects after reboots / network downtime / NAT connection table drops - - fast (lowest possible latency and line-rate bandwidth) - - encrypted, and secure by default (not needed, nice to have: short copy-pastable key pairs) + - fast (low latency and line-rate bandwidth) + - modern encryption, secure by default with forward secrecy & resilience to downgrade atttacks - ideally support for any type of Level 2 and control traffic, e.g. ARP/DHCP/ICMP (or ideally raw ethernet frames), not just TCP/HTTP - - ability to join the VPN from Ubuntu, FreeBSD, iOS, macOS (Windows/Android not needed but would be nice) - - not a requirement, but ideally it would support running in docker with a single container, config file, and preshared key on each server, but with a full network interface exposed to the host system (maybe with tun/tap on the host passing traffic to the container, but ideally just a single container + config file without outside dependencies) + - ability to join the VPN from Ubuntu, FreeBSD, iOS, macOS, Windows, Android (via open-source apps or natively) + - supports both running on the host routing traffic for docker or running in a docker container routing for the host + +**Things wireguard does not do:** + +- form a self-healing mesh network where nodes automatically gossip with neighbors +- break through double NATs with a signalling server (WebRTC-style) +- handle automatically distributing & revoking keys through a cetral authority +- allow sending raw layer-2 ethernet frames (it's at the IP layer) + +But you can write your own solutions for these problems using WireGuard under the hood (like [AltheaNet](https://althea.net/)). -## List of Possible VPN Solutions +## List of Other VPN Solutions - - [WireGuard](https://www.wireguard.com/): the subject of this post + - [WireGuard](https://www.wireguard.com/) - [IPSec (IKEv2)](https://github.com/jawj/IKEv2-setup)/strongSwan: lots of brittle config that's different for each OS, NAT busting setup is very manual and involves updating the central server and starting all the others in the correct order, not great at reconnecting after network downtime, had to be manually restarted often with that if it's the only option - - [OpenVPN](https://openvpn.net/vpn-server-resources/site-to-site-routing-explained-in-detail/): I don't like it from past experience but could be convinced if it's the only option + - [OpenVPN](https://openvpn.net/vpn-server-resources/site-to-site-routing-explained-in-detail/): stealthy because it looks like HTTPS traffic, but it does TCP-over-TCP (👎) - StealthVPN: haven't tried it - [DsVPN](https://github.com/jedisct1/dsvpn): does TCP-over-TCP which usually doesn't end well... - [SoftEther](https://www.softether.org/) ([SSTP](https://en.wikipedia.org/wiki/Secure_Socket_Tunneling_Protocol)): haven't tried it yet, should I? (also does TCP-over-TCP) + - L2TP: somewhat outdated - PPTP: ancient, inflexible, insecure, doesn't solve all the requirements - - L2TP: meh - - SOCKS: proxy tunnel, not a VPN, not great for this use case + - SOCKS/SSH: good for proxying single-port traffic, not a full networking tunnel or VPN ### Mesh VPN Solutions @@ -176,7 +180,7 @@ Over the last 8+ years I've tried a wide range of VPN solutions. Somewhat out o - [ZeroTier](https://www.zerotier.com): haven't tried it yet, should I - [MeshBird](https://github.com/meshbird/meshbird): "Cloud native" VPN/networking layer -### Setup Tools +### VPN Setup Tools - [Algo](https://github.com/trailofbits/algo) WireGuard setup tool - [Striesand](https://github.com/StreisandEffect/streisand) Multi-protocol setup tool From 9c3d5dab5a6fdf4d7b6b86f83b6a8a4ddaceee6a Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Thu, 9 Jan 2020 07:42:15 -0500 Subject: [PATCH 35/72] correct OpenVPN tcp-over-tcp and a few other lines --- README.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index eb2bd57..3f88de0 100644 --- a/README.md +++ b/README.md @@ -162,12 +162,11 @@ But you can write your own solutions for these problems using WireGuard under th ## List of Other VPN Solutions - [WireGuard](https://www.wireguard.com/) - - [IPSec (IKEv2)](https://github.com/jawj/IKEv2-setup)/strongSwan: lots of brittle config that's different for each OS, NAT busting setup is very manual and involves updating the central server and starting all the others in the correct order, not great at reconnecting after network downtime, had to be manually restarted often - with that if it's the only option - - [OpenVPN](https://openvpn.net/vpn-server-resources/site-to-site-routing-explained-in-detail/): stealthy because it looks like HTTPS traffic, but it does TCP-over-TCP (👎) - - StealthVPN: haven't tried it - - [DsVPN](https://github.com/jedisct1/dsvpn): does TCP-over-TCP which usually doesn't end well... - - [SoftEther](https://www.softether.org/) ([SSTP](https://en.wikipedia.org/wiki/Secure_Socket_Tunneling_Protocol)): haven't tried it yet, should I? (also does TCP-over-TCP) + - [IPSec (IKEv2)](https://github.com/jawj/IKEv2-setup)/strongSwan: in my exprience, there was lots of brittle config that was different for each OS, the NAT busting setup is very manual and involves updating the central server and starting all the others in the correct order, it wasn't great at becoming stable again after network downtime, had to be manually restarted often. your mileage may vary. + - [OpenVPN](https://openvpn.net/vpn-server-resources/site-to-site-routing-explained-in-detail/): can work over UDP or be disguised as HTTPS traffic over TCP + - StealthVPN: haven't tried it, should I? + - [DsVPN](https://github.com/jedisct1/dsvpn): I think it does TCP-over-TCP which usually doesn't end well... + - [SoftEther](https://www.softether.org/) ([SSTP](https://en.wikipedia.org/wiki/Secure_Socket_Tunneling_Protocol)): haven't tried it yet, should I? (also does TCP-over-TCP?) - L2TP: somewhat outdated - PPTP: ancient, inflexible, insecure, doesn't solve all the requirements - SOCKS/SSH: good for proxying single-port traffic, not a full networking tunnel or VPN From 2f69470f80a3f080ebe60738f8af41fd27a91c96 Mon Sep 17 00:00:00 2001 From: Adam Montgomery Date: Wed, 29 Jan 2020 17:03:10 -0500 Subject: [PATCH 36/72] standardize on /etc/wireguard for configs --- README.md | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 3f88de0..ed5183a 100644 --- a/README.md +++ b/README.md @@ -381,14 +381,14 @@ Overview of the general process: 1. Install `apt install wireguard` or `pkg/brew install wireguard-tools` on each node 2. Generate public and private keys locally on each node `wg genkey`+`wg pubkey` -3. Create a `wg0.conf` WireGuard config file on the main relay server +3. Create a `/etc/wireguard/wg0.conf` WireGuard config file on the main relay server - `[Interface]` Make sure to specify a CIDR range for the entire VPN subnet when defining the address the server accepts routes for `Address = 192.0.2.1/24` - `[Peer]` Create a peer section for every client joining the VPN, using their corresponding remote public keys -4. Create a `wg0.conf` on each client node +4. Create a `/etc/wireguard/wg0.conf` WireGuard config file on each client node - `[Interface]` Make sure to specify only a single IP for client peers that don't relay traffic `Address = 192.0.2.3/32`. - `[Peer]` Create a peer section for each public peer not behind a NAT, make sure to specify a CIDR range for the entire VPN subnet when defining the remote peer acting as the bounce server `AllowedIPs = 192.0.2.1/24`. Make sure to specify individual IPs for remote peers that don't relay traffic and only act as simple clients `AllowedIPs = 192.0.2.3/32`. -5. Start WireGuard on the main relay server with `wg-quick up /full/path/to/wg0.conf` -6. Start WireGuard on all the client peers with `wg-quick up /full/path/to/wg0.conf` +5. Start WireGuard on the main relay server with `wg-quick up wg0` +6. Start WireGuard on all the client peers with `wg-quick up wg0` 7. Traffic is routed from peer to peer using most specific route first over the WireGuard interface, e.g. `ping 192.0.2.3` checks for a direct route to a peer with `AllowedIPs = 192.0.2.3/32` first, then falls back to a relay server that's accepting ips in the whole subnet ### Setup @@ -423,7 +423,7 @@ iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADE ### Config Creation ```bash -nano wg0.conf # can be placed anywhere, must be referred to using absolute path +nano /etc/wireguard/wg0.conf ``` ### Key Generation @@ -439,9 +439,9 @@ wg pubkey < example.key > example.key.pub ### Start / Stop ```bash -wg-quick up /full/path/to/wg0.conf -wg-quick down /full/path/to/wg0.conf -# Note: you must specify the absolute path to wg0.conf, relative paths won't work +# first, create a configuration file at /etc/wireguard/wg0.conf +wg-quick up wg0 +wg-quick down wg0 ``` ```bash @@ -569,10 +569,17 @@ dig example.com A ### Overview -WireGuard config is in INI syntax, defined in a file usually called `wg0.conf`. It can be placed anywhere on the system, but is often placed in `/etc/wireguard/wg0.conf`. +WireGuard config files are in INI syntax. The configuration is specified as an argument when running any `wg-quick` command, e.g.: -The config path is specified as an argument when running any `wg-quick` command, e.g: -`wg-quick up /etc/wireguard/wg0.conf` (always specify the full, absolute path) +```bash +# if the configuration file is at /etc/wireguard/wg0.conf +wg-quick up wg0 + +# if the configuration file is stored anywhere else, you must use an absolute path; relative paths won't work +wq-quick up /tmp/wgtest.conf +``` + +The file name must be in the format `${name of the new wireguard interface}.conf`. `wg-quick` looks for config files in `/etc/wireguard` by default, so it usually makes sense to place them there. Wireguard interface names are typically prefixed with `wg` and numbered starting at `0`, but you can use any name that matches the regex `^[a-zA-Z0-9_=+.-]{1,15}$`. A configuration file for the interface `wg0` would typically be found at `/etc/wireguard/wg0.conf`. Config files can opt to use the limited set of `wg` config options, or the more extended `wg-quick` options, depending on what command is preferred to start WireGuard. These docs recommend sticking to `wg-quick` as it provides a more powerful and user-friendly config experience. From efca0c9d9e328e9b49375666de0f3b720cfcc9c9 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Wed, 29 Jan 2020 17:39:44 -0500 Subject: [PATCH 37/72] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 3f88de0..3bef7bd 100644 --- a/README.md +++ b/README.md @@ -423,7 +423,7 @@ iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADE ### Config Creation ```bash -nano wg0.conf # can be placed anywhere, must be referred to using absolute path +nano wg0.conf # can be placed anywhere, must be referred to using absolute path (usually placed in /etc/wireguard/wg0.conf on most Linux systems) ``` ### Key Generation From 5abd2a3edd9e805a539d54315c0b5dc9c044846c Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Wed, 29 Jan 2020 17:42:49 -0500 Subject: [PATCH 38/72] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 3bef7bd..21c793e 100644 --- a/README.md +++ b/README.md @@ -21,7 +21,7 @@ Nicer HTML page version: https://docs.sweeting.me/s/wireguard --- -[WireGuard](https://www.wireguard.com/) is an open-source VPN solution written in C by [Jason Donenfeld](https://www.jasondonenfeld.com) and [others](https://github.com/WireGuard/WireGuard/graphs/contributors), aiming to fix many of the problems that have plagued other modern server-to-server VPN offerings like IPSec/IKEv2, OpenVPN, or L2TP. It shares some similarities with other modern VPN offerings like [Tinc](https://www.tinc-vpn.org/) and [MeshBird](https://github.com/meshbird/meshbird), namely good cipher suites and minimal config. +[WireGuard](https://www.wireguard.com/) is an open-source VPN solution written in C by [Jason Donenfeld](https://www.jasondonenfeld.com) and [others](https://github.com/WireGuard/WireGuard/graphs/contributors), aiming to fix many of the problems that have plagued other modern server-to-server VPN offerings like IPSec/IKEv2, OpenVPN, or L2TP. It shares some similarities with other modern VPN offerings like [Tinc](https://www.tinc-vpn.org/) and [MeshBird](https://github.com/meshbird/meshbird), namely good cipher suites and minimal config. As of 2020-01 [it's been merged into the 5.6 version of the Linux kernel](https://arstechnica.com/gadgets/2020/01/linus-torvalds-pulled-wireguard-vpn-into-the-5-6-kernel-source-tree/), meaning it will ship with most Linux systems out-of-the-box. **Official Links** From 38dda696271fb77fc945ebc251802ad72740711a Mon Sep 17 00:00:00 2001 From: Adam Montgomery Date: Wed, 29 Jan 2020 17:59:17 -0500 Subject: [PATCH 39/72] make config location specific --- README.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index b34d0ce..a255a24 100644 --- a/README.md +++ b/README.md @@ -387,8 +387,8 @@ Overview of the general process: 4. Create a `/etc/wireguard/wg0.conf` WireGuard config file on each client node - `[Interface]` Make sure to specify only a single IP for client peers that don't relay traffic `Address = 192.0.2.3/32`. - `[Peer]` Create a peer section for each public peer not behind a NAT, make sure to specify a CIDR range for the entire VPN subnet when defining the remote peer acting as the bounce server `AllowedIPs = 192.0.2.1/24`. Make sure to specify individual IPs for remote peers that don't relay traffic and only act as simple clients `AllowedIPs = 192.0.2.3/32`. -5. Start WireGuard on the main relay server with `wg-quick up wg0` -6. Start WireGuard on all the client peers with `wg-quick up wg0` +5. Start WireGuard on the main relay server with `wg-quick up /etc/wireguard/wg0.conf` +6. Start WireGuard on all the client peers with `wg-quick up /etc/wireguard/wg0.conf` 7. Traffic is routed from peer to peer using most specific route first over the WireGuard interface, e.g. `ping 192.0.2.3` checks for a direct route to a peer with `AllowedIPs = 192.0.2.3/32` first, then falls back to a relay server that's accepting ips in the whole subnet ### Setup @@ -440,8 +440,9 @@ wg pubkey < example.key > example.key.pub ```bash # first, create a configuration file at /etc/wireguard/wg0.conf -wg-quick up wg0 -wg-quick down wg0 +wg-quick up /etc/wireguard/wg0.conf +wg-quick down /etc/wireguard/wg0.conf +# Note: you must specify the absolute path to wg0.conf, relative paths won't work ``` ```bash @@ -572,11 +573,8 @@ dig example.com A WireGuard config files are in INI syntax. The configuration is specified as an argument when running any `wg-quick` command, e.g.: ```bash -# if the configuration file is at /etc/wireguard/wg0.conf -wg-quick up wg0 - -# if the configuration file is stored anywhere else, you must use an absolute path; relative paths won't work -wq-quick up /tmp/wgtest.conf +# you must use an absolute path; relative paths won't work +wq-quick up /etc/wireguard/wg0.conf ``` The file name must be in the format `${name of the new wireguard interface}.conf`. `wg-quick` looks for config files in `/etc/wireguard` by default, so it usually makes sense to place them there. Wireguard interface names are typically prefixed with `wg` and numbered starting at `0`, but you can use any name that matches the regex `^[a-zA-Z0-9_=+.-]{1,15}$`. A configuration file for the interface `wg0` would typically be found at `/etc/wireguard/wg0.conf`. From d13f79f11d93c15b4abe9778b1fd80aabdeff57d Mon Sep 17 00:00:00 2001 From: Adam Montgomery Date: Thu, 30 Jan 2020 11:39:46 -0500 Subject: [PATCH 40/72] remove references to /etc/wireguard --- README.md | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index a255a24..c3c83b8 100644 --- a/README.md +++ b/README.md @@ -381,14 +381,14 @@ Overview of the general process: 1. Install `apt install wireguard` or `pkg/brew install wireguard-tools` on each node 2. Generate public and private keys locally on each node `wg genkey`+`wg pubkey` -3. Create a `/etc/wireguard/wg0.conf` WireGuard config file on the main relay server +3. Create a `wg0.conf` WireGuard config file on the main relay server - `[Interface]` Make sure to specify a CIDR range for the entire VPN subnet when defining the address the server accepts routes for `Address = 192.0.2.1/24` - `[Peer]` Create a peer section for every client joining the VPN, using their corresponding remote public keys -4. Create a `/etc/wireguard/wg0.conf` WireGuard config file on each client node +4. Create a `wg0.conf` on each client node - `[Interface]` Make sure to specify only a single IP for client peers that don't relay traffic `Address = 192.0.2.3/32`. - `[Peer]` Create a peer section for each public peer not behind a NAT, make sure to specify a CIDR range for the entire VPN subnet when defining the remote peer acting as the bounce server `AllowedIPs = 192.0.2.1/24`. Make sure to specify individual IPs for remote peers that don't relay traffic and only act as simple clients `AllowedIPs = 192.0.2.3/32`. -5. Start WireGuard on the main relay server with `wg-quick up /etc/wireguard/wg0.conf` -6. Start WireGuard on all the client peers with `wg-quick up /etc/wireguard/wg0.conf` +5. Start WireGuard on the main relay server with `wg-quick up /full/path/to/wg0.conf` +6. Start WireGuard on all the client peers with `wg-quick up /full/path/to/wg0.conf` 7. Traffic is routed from peer to peer using most specific route first over the WireGuard interface, e.g. `ping 192.0.2.3` checks for a direct route to a peer with `AllowedIPs = 192.0.2.3/32` first, then falls back to a relay server that's accepting ips in the whole subnet ### Setup @@ -439,9 +439,8 @@ wg pubkey < example.key > example.key.pub ### Start / Stop ```bash -# first, create a configuration file at /etc/wireguard/wg0.conf -wg-quick up /etc/wireguard/wg0.conf -wg-quick down /etc/wireguard/wg0.conf +wg-quick up /full/path/to/wg0.conf +wg-quick down /full/path/to/wg0.conf # Note: you must specify the absolute path to wg0.conf, relative paths won't work ``` @@ -570,14 +569,12 @@ dig example.com A ### Overview -WireGuard config files are in INI syntax. The configuration is specified as an argument when running any `wg-quick` command, e.g.: +WireGuard config is in INI syntax, defined in a file usually called `wg0.conf`. It can be placed anywhere on the system, but is often placed in `/etc/wireguard/wg0.conf`. -```bash -# you must use an absolute path; relative paths won't work -wq-quick up /etc/wireguard/wg0.conf -``` +The config path is specified as an argument when running any `wg-quick` command, e.g: +`wg-quick up /etc/wireguard/wg0.conf` (always specify the full, absolute path) -The file name must be in the format `${name of the new wireguard interface}.conf`. `wg-quick` looks for config files in `/etc/wireguard` by default, so it usually makes sense to place them there. Wireguard interface names are typically prefixed with `wg` and numbered starting at `0`, but you can use any name that matches the regex `^[a-zA-Z0-9_=+.-]{1,15}$`. A configuration file for the interface `wg0` would typically be found at `/etc/wireguard/wg0.conf`. +The config file name must be in the format `${name of the new wireguard interface}.conf`. WireGuard interface names are typically prefixed with `wg` and numbered starting at `0`, but you can use any name that matches the regex `^[a-zA-Z0-9_=+.-]{1,15}$`. Config files can opt to use the limited set of `wg` config options, or the more extended `wg-quick` options, depending on what command is preferred to start WireGuard. These docs recommend sticking to `wg-quick` as it provides a more powerful and user-friendly config experience. From 6eb8313b3ed2213da825a5b79b35da8452e2f0e8 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Thu, 13 Feb 2020 13:45:51 -0500 Subject: [PATCH 41/72] FUNDIng.yml supports multiple usernames --- .github/FUNDING.yml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index 34ebccc..5a40ba7 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -1,5 +1,4 @@ # These are supported funding model platforms -github: pirate -patreon: theSquashSH -custom: https://paypal.me/NicholasSweeting +github: [zx2c4, pirate] +patreon: [zx2c4, theSquashSH] From 0a0bdc2abd3db86ff536295cba10d58f018127f5 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Thu, 13 Feb 2020 13:46:49 -0500 Subject: [PATCH 42/72] Update FUNDING.yml --- .github/FUNDING.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index 5a40ba7..57b59c9 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -1,4 +1,5 @@ # These are supported funding model platforms github: [zx2c4, pirate] -patreon: [zx2c4, theSquashSH] +patreon: [theSquashSH] +custom: https://patreon.com/zx2c4 From c240602de2232cd8bbe75b5065d0377195a60584 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Thu, 13 Feb 2020 13:47:03 -0500 Subject: [PATCH 43/72] Update FUNDING.yml --- .github/FUNDING.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index 57b59c9..92798ba 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -1,5 +1,5 @@ # These are supported funding model platforms github: [zx2c4, pirate] -patreon: [theSquashSH] +patreon: theSquashSH custom: https://patreon.com/zx2c4 From e51e6112c43c0fca26329cd1c66aba8b2609608b Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Thu, 13 Feb 2020 14:04:56 -0500 Subject: [PATCH 44/72] Update README.md --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index c3c83b8..9a87ac7 100644 --- a/README.md +++ b/README.md @@ -1138,6 +1138,7 @@ Setups can get somewhat complex and are highly dependent on what you're trying t - https://www.wireguard.com/quickstart/ - https://www.stavros.io/posts/how-to-configure-wireguard/ - https://nbsoftsolutions.com/blog/wireguard-vpn-walkthrough +- https://networkhobo.com/building-a-wireguard-router/ - https://proprivacy.com/guides/wireguard-hands-on-guide - https://angristan.xyz/how-to-setup-vpn-server-wireguard-nat-ipv6/ - https://medium.com/@headquartershq/setting-up-wireguard-on-a-mac-8a121bfe9d86 @@ -1227,6 +1228,7 @@ Setups can get somewhat complex and are highly dependent on what you're trying t - https://www.reddit.com/r/WireGuard/comments/ap33df/wireguard_what_is_so_special_about_it_and_why/ - https://www.reddit.com/r/VPN/comments/9hgs2x/what_is_the_difference_between_wireguard_openvpn/ - https://www.reddit.com/r/privacytoolsIO/comments/8l0vxt/what_do_you_think_guys_of_wireguard/ +- https://community.ui.com/questions/Edgerouter-with-remote-Wireguard-access-issue/03e4f2e2-3871-437f-8632-3c5c7fb1c7a4 - https://news.ycombinator.com/item?id=20036194 - https://news.ycombinator.com/item?id=17659983 - https://news.ycombinator.com/item?id=17846387 From 984e16f7e3a2938f2030c6f1d292319e7db12e7e Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 18 Feb 2020 11:22:17 -0500 Subject: [PATCH 45/72] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9a87ac7..cb9da85 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ # Some Unofficial WireGuard Documentation -

                          +

                          API reference guide for WireGuard including Setup, Configuration, and Usage, with examples. From cd0cee008b16400322485471e89b518371bb43e8 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 18 Feb 2020 20:44:07 -0500 Subject: [PATCH 46/72] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index cb9da85..ef49d13 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ # Some Unofficial WireGuard Documentation -

                          +

                          API reference guide for WireGuard including Setup, Configuration, and Usage, with examples. From 409d56ffec477e36e7069e55fea6f0319dbad335 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 18 Feb 2020 20:54:19 -0500 Subject: [PATCH 47/72] add manpages --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index ef49d13..435eea2 100644 --- a/README.md +++ b/README.md @@ -28,6 +28,7 @@ Nicer HTML page version: https://docs.sweeting.me/s/wireguard - Homepage: https://www.wireguard.com - Install: https://www.wireguard.com/install/ - QuickStart: https://www.wireguard.com/quickstart/ +- Manpages: [`wg`](https://manpages.debian.org/testing/wireguard-tools/wg.8.en.html), [`wg-quick`](https://manpages.debian.org/unstable/wireguard-tools/wg-quick.8.en.html) - Main Git repo: https://git.zx2c4.com/WireGuard/ - Github Mirror: https://github.com/WireGuard/WireGuard - Mailing List: https://lists.zx2c4.com/mailman/listinfo/wireguard From c0ac216be2418fe4079300a29bc96153d090b21a Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Wed, 19 Feb 2020 11:09:59 -0500 Subject: [PATCH 48/72] Update FUNDING.yml --- .github/FUNDING.yml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index 92798ba..360a2f3 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -1,5 +1,4 @@ # These are supported funding model platforms -github: [zx2c4, pirate] -patreon: theSquashSH -custom: https://patreon.com/zx2c4 +github: zx2c4 +patreon: https://patreon.com/zx2c4 From d19d94dcd4609575081eecdcd762b96a2ce692f8 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Wed, 19 Feb 2020 11:11:03 -0500 Subject: [PATCH 49/72] Update FUNDING.yml --- .github/FUNDING.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index 360a2f3..7caa933 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -1,4 +1,4 @@ # These are supported funding model platforms github: zx2c4 -patreon: https://patreon.com/zx2c4 +patreon: zx2c4 From f413358aae139a9bae6f2d8b69d15b251b5c5604 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Wed, 19 Feb 2020 11:42:44 -0500 Subject: [PATCH 50/72] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 435eea2..22dc009 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ API reference guide for WireGuard including Setup, Configuration, and Usage, with examples. -All credit goes to the WireGuard project, [zx2c4](https://www.zx2c4.com/), [Edge Security](https://www.edgesecurity.com/), and the [open source contributors](https://github.com/WireGuard/WireGuard/graphs/contributors) for the original software,
                          this is my solo unofficial attempt at providing more comprehensive documentation, API references, and examples.                           +All credit goes to the WireGuard project, [zx2c4](https://www.zx2c4.com/) and the [open source contributors](https://github.com/WireGuard/WireGuard/graphs/contributors) for the original software,
                          this is my solo unofficial attempt at providing more comprehensive documentation, API references, and examples.                           From 3654a6cbdcd714b3ec7e645192e0b278fa343f65 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Wed, 19 Feb 2020 11:46:50 -0500 Subject: [PATCH 51/72] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 22dc009..c357978 100644 --- a/README.md +++ b/README.md @@ -1044,7 +1044,7 @@ An incomplete, insecure userspace implementation of WireGuard written in Rust (n An incomplete, insecure userspace implementation of WireGuard written in Haskell (not ready for the public). - https://github.com/cloudflare/boringtun -A compliant, working WireGuard implementation with the exact same API, written in Rust. +A non-compliant, independent WireGuard implementation written in Rust (a separate fork written by CloudFlare). See https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/ - Platform-specific WireGuard apps From f4d369943b85e7b79fde9a0e2390767ecf303e65 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Thu, 20 Feb 2020 04:50:44 -0500 Subject: [PATCH 52/72] link to INI syntax wikipedia page --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c357978..128b429 100644 --- a/README.md +++ b/README.md @@ -570,7 +570,7 @@ dig example.com A ### Overview -WireGuard config is in INI syntax, defined in a file usually called `wg0.conf`. It can be placed anywhere on the system, but is often placed in `/etc/wireguard/wg0.conf`. +WireGuard config is in [INI syntax](https://en.wikipedia.org/wiki/INI_file), defined in a file usually called `wg0.conf`. It can be placed anywhere on the system, but is often placed in `/etc/wireguard/wg0.conf`. The config path is specified as an argument when running any `wg-quick` command, e.g: `wg-quick up /etc/wireguard/wg0.conf` (always specify the full, absolute path) From 779080fdafea0d65d041722ed16e5116c793759c Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 25 Feb 2020 01:04:08 -0500 Subject: [PATCH 53/72] add signaling server implementations for NAT-to-NAT --- README.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/README.md b/README.md index 128b429..64e65ea 100644 --- a/README.md +++ b/README.md @@ -970,6 +970,13 @@ As of 2019, many of the old hole-punching methods used that used to work are no NAT-to-NAT connections are not possible if all endpoints are behind NAT's with strict UDP source port randomization (e.g. most cellular data networks). Since neither side is able to hardcode a `ListenPort` and guarantee that their NAT will accept traffic on that port after the outgoing ping, you cannot coordinate a port for the initial hole-punch between peers and connections will fail. For this reason, you generally cannot do phone-to-phone connections on LTE/3g networks, but you might be able to do phone-to-office or phone-to-home where the office or home has a stable public IP and doesn't do source port randomization. +##### Using a signaling server + +NAT-to-NAT connections from behind NATs with strict source-port randomization is possible, you just need a singaling server to tell each side the other's ip:port tuple. Here are a few implementations that achieve this with WireGuard: + +- https://github.com/takutakahashi/wg-connect +- https://git.zx2c4.com/wireguard-tools/tree/contrib/nat-hole-punching/ + ##### Dynamic IP addresses Many users report having to restart WireGuard whenever a dynamic IP changes, as it only resolves hostnames on startup. To force WireGuard to re-resolve dynamic DNS `Endpoint` hostnames more often, you may want to use a `PostUp` hook to restart WireGuard every few minutes or hours. From 384882b07c976939ae5f03081b0cc6332760f9c8 Mon Sep 17 00:00:00 2001 From: Jaak Ristioja Date: Mon, 9 Mar 2020 18:45:50 +0200 Subject: [PATCH 54/72] README.md: Fixed some typos, abbreviations and capitalization --- README.md | 84 +++++++++++++++++++++++++++---------------------------- 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/README.md b/README.md index 64e65ea..f6a64e0 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,7 @@ Nicer HTML page version: https://docs.sweeting.me/s/wireguard - QuickStart: https://www.wireguard.com/quickstart/ - Manpages: [`wg`](https://manpages.debian.org/testing/wireguard-tools/wg.8.en.html), [`wg-quick`](https://manpages.debian.org/unstable/wireguard-tools/wg-quick.8.en.html) - Main Git repo: https://git.zx2c4.com/WireGuard/ -- Github Mirror: https://github.com/WireGuard/WireGuard +- GitHub Mirror: https://github.com/WireGuard/WireGuard - Mailing List: https://lists.zx2c4.com/mailman/listinfo/wireguard **WireGuard Goals** @@ -90,7 +90,7 @@ See https://github.com/pirate/wireguard-docs for example code and documentation
                        • Usage
                            -
                          • Quickstart
                            • +
                          • QuickStart
                          • Setup
                          • Config Creation
                          • Key Generation
                            • @@ -135,9 +135,9 @@ See https://github.com/pirate/wireguard-docs for example code and documentation # Intro -Whether living behind the Great Wall of China or just trying to form a network between your servers, Wireguard is a great option and serves as a "lego block" for building networks (much in the same way that ZFS is a lego block for building filesystems). +Whether living behind the Great Wall of China or just trying to form a network between your servers, WireGuard is a great option and serves as a "lego block" for building networks (much in the same way that ZFS is a lego block for building filesystems). -## Wireguard Overview +## WireGuard Overview - minimal config, low tunable surface area and sane defaults - minimal key management work needed, just 1 public & 1 private key per host @@ -146,16 +146,16 @@ Whether living behind the Great Wall of China or just trying to form a network b - ability to some traffic or all traffic to/through arbitrary hosts on the VPN LAN - robust automatic reconnects after reboots / network downtime / NAT connection table drops - fast (low latency and line-rate bandwidth) - - modern encryption, secure by default with forward secrecy & resilience to downgrade atttacks + - modern encryption, secure by default with forward secrecy & resilience to downgrade attacks - ideally support for any type of Level 2 and control traffic, e.g. ARP/DHCP/ICMP (or ideally raw ethernet frames), not just TCP/HTTP - - ability to join the VPN from Ubuntu, FreeBSD, iOS, macOS, Windows, Android (via open-source apps or natively) + - ability to join the VPN from Ubuntu, FreeBSD, iOS, MacOS, Windows, Android (via open-source apps or natively) - supports both running on the host routing traffic for docker or running in a docker container routing for the host -**Things wireguard does not do:** +**Things WireGuard does not do:** - form a self-healing mesh network where nodes automatically gossip with neighbors - break through double NATs with a signalling server (WebRTC-style) -- handle automatically distributing & revoking keys through a cetral authority +- handle automatically distributing & revoking keys through a central authority - allow sending raw layer-2 ethernet frames (it's at the IP layer) But you can write your own solutions for these problems using WireGuard under the hood (like [AltheaNet](https://althea.net/)). @@ -163,7 +163,7 @@ But you can write your own solutions for these problems using WireGuard under th ## List of Other VPN Solutions - [WireGuard](https://www.wireguard.com/) - - [IPSec (IKEv2)](https://github.com/jawj/IKEv2-setup)/strongSwan: in my exprience, there was lots of brittle config that was different for each OS, the NAT busting setup is very manual and involves updating the central server and starting all the others in the correct order, it wasn't great at becoming stable again after network downtime, had to be manually restarted often. your mileage may vary. + - [IPSec (IKEv2)](https://github.com/jawj/IKEv2-setup)/strongSwan: in my experience, there was lots of brittle config that was different for each OS, the NAT busting setup is very manual and involves updating the central server and starting all the others in the correct order, it wasn't great at becoming stable again after network downtime, had to be manually restarted often. your mileage may vary. - [OpenVPN](https://openvpn.net/vpn-server-resources/site-to-site-routing-explained-in-detail/): can work over UDP or be disguised as HTTPS traffic over TCP - StealthVPN: haven't tried it, should I? - [DsVPN](https://github.com/jedisct1/dsvpn): I think it does TCP-over-TCP which usually doesn't end well... @@ -196,7 +196,7 @@ But you can write your own solutions for these problems using WireGuard under th ### Example Strings -These are demo hostnames, domain names, ip addresses, and ranges used in the documentation and example configs. +These are demo hostnames, domain names, IP addresses, and ranges used in the documentation and example configs. Replace them with your preferred values when doing your own setup. - Example domain: `example-vpn.dev` can be replaced with any publicly accessible domain you control @@ -224,16 +224,16 @@ A publicly reachable peer/node that serves as a fallback to relay traffic for ot ### Subnet -A group of IPs separate from the public internet, e.g. 192.0.2.1-255 or 192.168.1.1/24. Generally behind a NAT provided by a router, e.g. in office internet LAN or a home WiFi network. +A group of IPs separate from the public internet, e.g. 192.0.2.1-255 or 192.168.1.1/24. Generally behind a NAT provided by a router, e.g. in office internet LAN or a home Wi-Fi network. ### CIDR Notation A way of defining a subnet and its size with a "mask", a smaller mask = more address bits usable by the subnet & more IPs in the range. Most common ones: - + `192.0.2.1/32` (a single ip address, `192.0.2.1`) netmask = `255.255.255.255` - + `192.0.2.1/24` (255 ips from `192.0.2.1`-`255`) netmask = ` 255.255.255.0` - + `192.0.2.1/16` (65,536 ips from `192.0.2.0` - `192.0.255.255`) netmask = `255.255.0.0` - + `192.0.2.1/8` (16,777,216 ips from `192.0.2.0` - `192.255.255.255`) netmask = `255.0.0.0` - + `0.0.0.1/0` (4,294,967,296 ips from `0.0.0.0` - `255.255.255.255`) netmask = `0.0.0.0` + + `192.0.2.1/32` (a single IP address, `192.0.2.1`) netmask = `255.255.255.255` + + `192.0.2.1/24` (255 IPs from `192.0.2.1`-`255`) netmask = ` 255.255.255.0` + + `192.0.2.1/16` (65,536 IPs from `192.0.2.0` - `192.0.255.255`) netmask = `255.255.0.0` + + `192.0.2.1/8` (16,777,216 IPs from `192.0.2.0` - `192.255.255.255`) netmask = `255.0.0.0` + + `0.0.0.1/0` (4,294,967,296 IPs from `0.0.0.0` - `255.255.255.255`) netmask = `0.0.0.0` + IPv6 CIDR notation is also supported e.g. `2001:DB8::/64` https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing @@ -241,11 +241,11 @@ https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing To people just getting started `192.0.2.1/32` may seem like a weird and confusing way to refer to a single IP. This design is nice though because it allows peers to expose multiple IPs if needed without needing multiple notations. Just know that anywhere you see something like `192.0.2.3/32`, it really just means `192.0.2.3`. ### NAT -A subnet with private IPs provided by a router standing in front of them doing Network Address Translation, individual nodes are not publicly accessible from the internet, instead the router keeps track of outgoing connections and forwards responses to the correct internal ip (e.g. standard office networks, home wifi networks, free public wifi networks, etc) +A subnet with private IPs provided by a router standing in front of them doing Network Address Translation, individual nodes are not publicly accessible from the internet, instead the router keeps track of outgoing connections and forwards responses to the correct internal IP (e.g. standard office networks, home Wi-Fi networks, free public Wi-Fi networks, etc) ### Public Endpoint -The publicly accessible address:port for a node, e.g. `123.124.125.126:1234` or `some.domain.tld:1234` (must be accessible via the public internet, generally can't be a private ip like `192.0.2.1` or `192.168.1.1` unless it's directly accessible using that address by other peers on the same subnet). +The publicly accessible address:port for a node, e.g. `123.124.125.126:1234` or `some.domain.tld:1234` (must be accessible via the public internet, generally can't be a private IP like `192.0.2.1` or `192.168.1.1` unless it's directly accessible using that address by other peers on the same subnet). ### Private key @@ -285,9 +285,9 @@ More complex topologies are definitely achievable, but these are the basic routi - **Node behind local NAT to public node** When 1 of the 2 parties is behind remote NAT (e.g. when a laptop behind NAT connects to `public-server2`), define the publicly accessible node with a hardcoded `Endpoint` and the NAT-ed node without. The connection will be opened from NAT client -> public client, then traffic will route directly between them in both directions as long as the connection is kept alive by outgoing `PersistentKeepalive` pings from the NAT-ed client. - **Node behind local NAT to node behind remote NAT (via relay)** - Most of the time when both parties are behind NATs, the NATs do srcport randomization making direct connections infeasible, so they will both have to open a connection to `public-server1`, and traffic will forward through the intermediary bounce server as long as the connections are kept alive. + Most of the time when both parties are behind NATs, the NATs do source port randomization making direct connections infeasible, so they will both have to open a connection to `public-server1`, and traffic will forward through the intermediary bounce server as long as the connections are kept alive. - **Node behind local NAT to node behind remote NAT (via UDP NAT hole-punching)** - While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the srcport, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random srcports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random srcports and sends them back to the clients. This is how WebRTC works in modern P2P web apps. Even with a signalling server and known srcports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random srcport to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated srcport). This is especially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. + While sometimes possible, it's generally infeasible to do direct NAT-to-NAT connections on modern networks, because most NAT routers are quite strict about randomizing the source port, making it impossible to coordinate an open port for both sides ahead of time. Instead, a signaling server (STUN) must be used that stands in the middle and communicates which random source ports are assigned to the other side. Both clients make an initial connection to the public signaling server, then it records the random source ports and sends them back to the clients. This is how WebRTC works in modern P2P web apps. Even with a signalling server and known source ports for both ends, sometimes direct connections are not possible because the NAT routers are strict about only accepting traffic from the original destination address (the signalling server), and will require a new random source port to be opened to accept traffic from other IPs (e.g. the other client attempting to use the originally communicated source port). This is especially true for "carrier-grade NATs" like cellular networks and some enterprise networks, which are designed specifically to prevent this sort of hole-punching connection. See the full section below on [**NAT to NAT Connections**](#NAT-to-NAT-Connections) for more information. More specific (also usually more direct) routes provided by other peers will take precedence when available, otherwise traffic will fall back to the least specific route and use the `192.0.2.1/24` catchall to forward traffic to the bounce server, where it will in turn be routed by the relay server's system routing table (`net.ipv4.ip_forward = 1`) back down the VPN to the specific peer that's accepting routes for that traffic. WireGuard does not automatically find the fastest route or attempt to form direct connections between peers if not already defined, it just goes from the most specific route in `[Peers]` to least specific. @@ -351,9 +351,9 @@ Further reading: ### How WireGuard Manages Keys -Authentication in both directions is achieved with a simple public/private keypair for each peer. Each peer generates these keys during the setup phase, and shares only the public key with other peers. +Authentication in both directions is achieved with a simple public/private key pair for each peer. Each peer generates these keys during the setup phase, and shares only the public key with other peers. -No other certificates or preshared keys are needed beyond the public/private keys for each node. +No other certificates or pre-shared keys are needed beyond the public/private keys for each node. Key generation, distribution, and revocation can be handled in larger deployments using a separate service like Ansible or Kubernetes Secrets. @@ -376,7 +376,7 @@ PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privke ## Usage -### Quickstart +### QuickStart Overview of the general process: @@ -390,7 +390,7 @@ Overview of the general process: - `[Peer]` Create a peer section for each public peer not behind a NAT, make sure to specify a CIDR range for the entire VPN subnet when defining the remote peer acting as the bounce server `AllowedIPs = 192.0.2.1/24`. Make sure to specify individual IPs for remote peers that don't relay traffic and only act as simple clients `AllowedIPs = 192.0.2.3/32`. 5. Start WireGuard on the main relay server with `wg-quick up /full/path/to/wg0.conf` 6. Start WireGuard on all the client peers with `wg-quick up /full/path/to/wg0.conf` -7. Traffic is routed from peer to peer using most specific route first over the WireGuard interface, e.g. `ping 192.0.2.3` checks for a direct route to a peer with `AllowedIPs = 192.0.2.3/32` first, then falls back to a relay server that's accepting ips in the whole subnet +7. Traffic is routed from peer to peer using most specific route first over the WireGuard interface, e.g. `ping 192.0.2.3` checks for a direct route to a peer with `AllowedIPs = 192.0.2.3/32` first, then falls back to a relay server that's accepting IPs in the whole subnet ### Setup @@ -485,12 +485,12 @@ wg show wg0 #### Addresses ```bash -# show public ip address +# show public IP address ifconfig eth0 ip address show eth0 dig -4 +short myip.opendns.com @resolver1.opendns.com -# show VPN ip address +# show VPN IP address ip address show wg0 ``` @@ -525,7 +525,7 @@ ping 192.0.2.2 # check that remote NAT-ed peers are available via VPN ping 192.0.2.3 -# check that NAT-ed peers in your local lan are available via VPN +# check that NAT-ed peers in your local LAN are available via VPN ping 192.0.2.4 ``` @@ -575,7 +575,7 @@ WireGuard config is in [INI syntax](https://en.wikipedia.org/wiki/INI_file), def The config path is specified as an argument when running any `wg-quick` command, e.g: `wg-quick up /etc/wireguard/wg0.conf` (always specify the full, absolute path) -The config file name must be in the format `${name of the new wireguard interface}.conf`. WireGuard interface names are typically prefixed with `wg` and numbered starting at `0`, but you can use any name that matches the regex `^[a-zA-Z0-9_=+.-]{1,15}$`. +The config file name must be in the format `${name of the new WireGuard interface}.conf`. WireGuard interface names are typically prefixed with `wg` and numbered starting at `0`, but you can use any name that matches the regex `^[a-zA-Z0-9_=+.-]{1,15}$`. Config files can opt to use the limited set of `wg` config options, or the more extended `wg-quick` options, depending on what command is preferred to start WireGuard. These docs recommend sticking to `wg-quick` as it provides a more powerful and user-friendly config experience. @@ -716,7 +716,7 @@ This option can be specified multiple times, with commands executed in the order **Examples** -* Add an ip route +* Add an IP route `PreUp = ip rule add ipproto tcp dport 22 table 1234` #### `PostUp` @@ -777,11 +777,11 @@ This option can appear multiple times, as with PreUp ### `[Peer]` -Defines the VPN settings for a remote peer capable of routing traffic for one or more addresses (itself and/or other peers). Peers can be either a public bounce server that relays traffic to other peers, or a directly accessible client via lan/internet that is not behind a NAT and only routes traffic for itself. +Defines the VPN settings for a remote peer capable of routing traffic for one or more addresses (itself and/or other peers). Peers can be either a public bounce server that relays traffic to other peers, or a directly accessible client via LAN/internet that is not behind a NAT and only routes traffic for itself. All clients must be defined as peers on the public bounce server. Simple clients that only route traffic for themselves, only need to define peers for the public relay, and any other nodes directly accessible. Nodes that are behind separate NATs should _not_ be defined as peers outside of the public server config, as no direct route is available between separate NATs. 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. -In summary, all nodes must be defined on the main bounce server. On client servers, only peers that are directly accessible from a node should be defined as peers of that node, any peers that must be relayed by a bounce sherver should be left out and will be handled by the relay server's catchall route. +In summary, all nodes must be defined on the main bounce server. On client servers, only peers that are directly accessible from a node should be defined as peers of that node, any peers that must be relayed by a bounce server should be left out and will be handled by the relay server's catchall route. In the configuration outlined in the docs below, a single server `public-server1` acts as the relay bounce server for a mix of publicly accessible and NAT-ed clients, and peers are configured on each node accordingly: @@ -791,13 +791,13 @@ In the configuration outlined in the docs below, a single server `public-server1 - **in `public-server2` `wg0.conf` (simple public client)** `[peer]` list: `public-server1` -- **in `home-server` `wg0.conf` (simple client behind nat)** +- **in `home-server` `wg0.conf` (simple client behind NAT)** `[peer]` list: `public-server1`, `public-server2` -- **in `laptop` `wg0.conf` (simple client behind nat)** +- **in `laptop` `wg0.conf` (simple client behind NAT)** `[peer]` list: `public-server1`, `public-server2` -- **in `phone` `wg0.conf` (simple client behind nat)** +- **in `phone` `wg0.conf` (simple client behind NAT)** `[peer]` list: `public-server1`, `public-server2` **Examples** @@ -940,14 +940,14 @@ AllowedIPs = 0.0.0.0/0, ::/0 ### NAT To NAT Connections -WireGuard can sometimes natively make connections between two clients behind NATs without the need for a public relay server, but in most cases this is not possible. NAT-to-NAT connections are only possible if at least one host has a stable, publicly-accessible IP address:port pair that can be hardcoded ahead of time, whether thats using a FQDN updated with Dynamic DNS, or a static public IP with a non-randomized NAT port opened by outgoing packets, anything works as long as all peers can communicate it beforehand and it doesn't change once the connection is initiated. +WireGuard can sometimes natively make connections between two clients behind NATs without the need for a public relay server, but in most cases this is not possible. NAT-to-NAT connections are only possible if at least one host has a stable, publicly-accessible IP address:port pair that can be hardcoded ahead of time, whether that's using a FQDN updated with Dynamic DNS, or a static public IP with a non-randomized NAT port opened by outgoing packets, anything works as long as all peers can communicate it beforehand and it doesn't change once the connection is initiated. -A known port and address need to be configured ahead of time because Wireguard doesn't have a signalling layer or public STUN servers that can be used to search for other hosts dynamically. WebRTC is an example of a protocol that can dynamically configure a connection between two NATs, but it does this by using an out-of-band signaling server to detect the ip:port combo of each host. WireGuard doesn't have this, so it only works with a hardcoded `Endpoint` + `ListenPort` (and `PersistentKeepalive` so it doesn't drop after inactivity). +A known port and address need to be configured ahead of time because WireGuard doesn't have a signalling layer or public STUN servers that can be used to search for other hosts dynamically. WebRTC is an example of a protocol that can dynamically configure a connection between two NATs, but it does this by using an out-of-band signaling server to detect the IP:port combo of each host. WireGuard doesn't have this, so it only works with a hardcoded `Endpoint` + `ListenPort` (and `PersistentKeepalive` so it doesn't drop after inactivity). #### Requirements for NAT-to-NAT setups - At least one peer has to have to have a hardcoded, directly-accessible `Endpoint` defined. If they're both behind NATs without stable IP addresses, then you'll need to use Dynamic DNS or another solution to have a stable, publicly accessibly domain/IP for at least one peer - - At least one peer has to have a hardcoded UDP `ListenPort` defined, and it's NAT router must not do UDP source port randomization, otherwise return packets will be sent to the hardocded `ListenPort` and dropped by the router, instead of using the random port assigned by the NAT on the outgoing packet + - At least one peer has to have a hardcoded UDP `ListenPort` defined, and it's NAT router must not do UDP source port randomization, otherwise return packets will be sent to the hardcoded `ListenPort` and dropped by the router, instead of using the random port assigned by the NAT on the outgoing packet - All NAT'ed peers must have `PersistentKeepalive` enabled on all other peers, so that they continually send outgoing pings to keep connections persisted in their NAT's routing table #### The hole-punching connection process @@ -958,13 +958,13 @@ A known port and address need to be configured ahead of time because Wireguard d This process of sending an initial packet that gets rejected, then using the fact that the router has now created a forwarding rule to accept responses is called "UDP hole-punching". -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. 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 is how most UDP applications function behind NATs (e.g. Bittorent, Skype, etc). 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`). +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. 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 is how most UDP applications function behind NATs (e.g. BitTorrent, Skype, etc). 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 requires 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 ahead of time, in WireGuard's case this is achieved by hard-coding pre-defined ports for both sides in `wg0.conf`. #### Drawbacks and limitations -As of 2019, many of the old hole-punching methods used that used to work are no longer effective. One example was a novel method pioneered by [pwnat](https://github.com/samyk/pwnat) that faked an ICMP Time Exceeded response from outside the NAT to get a packet back through to a NAT'ed peer, thereby leaking its own srcport. Hardcoding UDP ports and public IPs for both sides of a NAT-to-NAT connection (as described above) still works on a small percentage of networks. Generally the more "enterprisey" a network is, the less likely you'll be able to hole puch public UDP ports (commercial public wifi and cell data NATs often don't work for example). +As of 2019, many of the old hole-punching methods used that used to work are no longer effective. One example was a novel method pioneered by [pwnat](https://github.com/samyk/pwnat) that faked an ICMP Time Exceeded response from outside the NAT to get a packet back through to a NAT'ed peer, thereby leaking its own source port. Hardcoding UDP ports and public IPs for both sides of a NAT-to-NAT connection (as described above) still works on a small percentage of networks. Generally the more "enterprisey" a network is, the less likely you'll be able to hole punch public UDP ports (commercial public Wi-Fi and cell data NATs often don't work for example). ##### Source port randomization @@ -972,7 +972,7 @@ NAT-to-NAT connections are not possible if all endpoints are behind NAT's with s ##### Using a signaling server -NAT-to-NAT connections from behind NATs with strict source-port randomization is possible, you just need a singaling server to tell each side the other's ip:port tuple. Here are a few implementations that achieve this with WireGuard: +NAT-to-NAT connections from behind NATs with strict source-port randomization is possible, you just need a signaling server to tell each side the other's IP:port tuple. Here are a few implementations that achieve this with WireGuard: - https://github.com/takutakahashi/wg-connect - https://git.zx2c4.com/wireguard-tools/tree/contrib/nat-hole-punching/ @@ -1115,7 +1115,7 @@ You can read in a file as the `PrivateKey` by doing something like: ### Containerization -WireGuard can be run in Docker with varying degrees of ease. In the simplest case, `--privileged` and `--cap-add=all` args can be added to the docker commands to enable the loading of the kernel module. +WireGuard can be run in Docker with varying degrees of ease. In the simplest case, `--privileged` and `--cap-add=all` arguments can be added to the docker commands to enable the loading of the kernel module. Setups can get somewhat complex and are highly dependent on what you're trying to achieve. You can have WireGuard itself run in a container and expose a network interface to the host, or you can have WireGuard running on the host exposing an interface to specific containers. @@ -1241,7 +1241,7 @@ Setups can get somewhat complex and are highly dependent on what you're trying t - https://news.ycombinator.com/item?id=17659983 - https://news.ycombinator.com/item?id=17846387 -For more detailed instructions, see the [Quickstart](#Quickstart) guide and API reference above. You can also download the complete example setup here: https://github.com/pirate/wireguard-example. +For more detailed instructions, see the [QuickStart](#QuickStart) guide and API reference above. You can also download the complete example setup here: https://github.com/pirate/wireguard-example. --- From 88799afb61d0041bbd20e6eae88c21c41b442ac6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Per=20=28=E1=B5=94=E1=B4=A5=E1=B5=94=29?= Date: Tue, 10 Mar 2020 18:51:35 +0100 Subject: [PATCH 55/72] Add Yggdrasil network. A Ygg node can look like this: https://ygg.tlbs.ai --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 64e65ea..b35382f 100644 --- a/README.md +++ b/README.md @@ -177,6 +177,7 @@ But you can write your own solutions for these problems using WireGuard under th - [TINC](https://www.tinc-vpn.org/): haven't tried it yet, but it doesn't work on iOS, worst case scenario I could live - [VPNCloud](https://github.com/dswd/vpncloud): similar properties to WireGuard, with more auto-mesh features - [cjdns](https://github.com/cjdelisle/cjdns): haven't tried it yet, should I? + - [Yggdrasil network](https://yggdrasil-network.github.io/): It is lightweight, self-arranging, supported on multiple platforms and allows pretty much any IPv6-capable application to communicate securely with other Yggdrasil nodes. - [ZeroTier](https://www.zerotier.com): haven't tried it yet, should I - [MeshBird](https://github.com/meshbird/meshbird): "Cloud native" VPN/networking layer From 4868e3fdad7d520cff45890a63d72a0db3b620e7 Mon Sep 17 00:00:00 2001 From: Maximilian Ehlers <2843450+b-m-f@users.noreply.github.com> Date: Sun, 22 Mar 2020 15:42:32 +0800 Subject: [PATCH 56/72] Add wirt.network configurator Adds https://wirt.network to related project --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 64e65ea..c90df6f 100644 --- a/README.md +++ b/README.md @@ -1196,6 +1196,7 @@ Setups can get somewhat complex and are highly dependent on what you're trying t - https://github.com/WireGuard/wireguard-go - https://www.veeam.com/blog/veeam-pn-v2-wireguard.html - https://github.com/wg-dashboard/wg-dashboard +- https://wirt.network ### Docker From cb44fb16d79d6933dec04bd9f01e83b0d45a1813 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Tue, 24 Mar 2020 14:21:43 -0400 Subject: [PATCH 57/72] add note about sharing private keys --- README.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/README.md b/README.md index 64e65ea..81c3802 100644 --- a/README.md +++ b/README.md @@ -372,6 +372,11 @@ You can also read in keys from a file or via command if you don't want to hardco ... PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privkey) ``` + +Technically, multiple servers can share the same private key as long as clients arent connected to two servers with the same key simulatenously. +An example of a scenario where this is a reasonable setup is if you're using round-robin DNS to load-balance connections between two servers that are pretending to be a single server. +Most of the time however, every peer should have its own pubic/private keypair so that peers can't read eachothers traffic and can be individually revoked. + --- ## Usage From e2058c16a04e1ce5f1c05efc68e02e6d2f907218 Mon Sep 17 00:00:00 2001 From: Stanislas Lange Date: Tue, 31 Mar 2020 15:22:26 +0200 Subject: [PATCH 58/72] Add angristan/wireguard-install to related projects Signed-off-by: Stanislas Lange --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 81c3802..1ea8ac0 100644 --- a/README.md +++ b/README.md @@ -1201,6 +1201,7 @@ Setups can get somewhat complex and are highly dependent on what you're trying t - https://github.com/WireGuard/wireguard-go - https://www.veeam.com/blog/veeam-pn-v2-wireguard.html - https://github.com/wg-dashboard/wg-dashboard +- https://github.com/angristan/wireguard-install ### Docker From 4e21b7878bd57c563dbf98ace194bd2828221e4a Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Wed, 1 Apr 2020 20:24:20 -0400 Subject: [PATCH 59/72] change yggdrasil description --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index b35382f..fb45372 100644 --- a/README.md +++ b/README.md @@ -177,9 +177,9 @@ But you can write your own solutions for these problems using WireGuard under th - [TINC](https://www.tinc-vpn.org/): haven't tried it yet, but it doesn't work on iOS, worst case scenario I could live - [VPNCloud](https://github.com/dswd/vpncloud): similar properties to WireGuard, with more auto-mesh features - [cjdns](https://github.com/cjdelisle/cjdns): haven't tried it yet, should I? - - [Yggdrasil network](https://yggdrasil-network.github.io/): It is lightweight, self-arranging, supported on multiple platforms and allows pretty much any IPv6-capable application to communicate securely with other Yggdrasil nodes. - [ZeroTier](https://www.zerotier.com): haven't tried it yet, should I - [MeshBird](https://github.com/meshbird/meshbird): "Cloud native" VPN/networking layer + - [Yggdrasil Network](https://yggdrasil-network.github.io/): Yggdrasil is a self-arranging IPv4/IPv6 mesh VPN (haven't tried it yet) ### VPN Setup Tools From 3f2f76cf8980c2ed94fbfe2bacada734348ce7b4 Mon Sep 17 00:00:00 2001 From: James Freiwirth Date: Fri, 24 Apr 2020 00:44:48 +0100 Subject: [PATCH 60/72] Add link to wireguardconfig.com --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 34dd5bc..5511c43 100644 --- a/README.md +++ b/README.md @@ -1083,6 +1083,7 @@ These are some GUI and CLI tools that wrap WireGuard to assist with config, depl - https://github.com/StreisandEffect/streisand - https://www.veeam.com/blog/veeam-pn-v2-wireguard.html - https://github.com/wg-dashboard/wg-dashboard + - https://www.wireguardconfig.com ### Config Shortcuts From 966781da6d8a4d845ffb782f3776b13d23fe1f90 Mon Sep 17 00:00:00 2001 From: James Freiwirth Date: Sat, 25 Apr 2020 20:37:40 +0100 Subject: [PATCH 61/72] Update README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 5511c43..cd7705d 100644 --- a/README.md +++ b/README.md @@ -365,6 +365,7 @@ Some services that help with key distribution and deployment: - https://github.com/StreisandEffect/streisand - https://github.com/its0x08/wg-install - https://github.com/brittson/wireguard_config_maker +- https://www.wireguardconfig.com You can also read in keys from a file or via command if you don't want to hardcode them in `wg0.conf`, this makes managing keys via 3rd party service much easier: From 91abe745022bae0cc1893fdf90cd822d9a87675b Mon Sep 17 00:00:00 2001 From: ruowan Date: Mon, 4 May 2020 23:10:12 +0800 Subject: [PATCH 62/72] doc update --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index cd7705d..5607503 100644 --- a/README.md +++ b/README.md @@ -231,9 +231,9 @@ A group of IPs separate from the public internet, e.g. 192.0.2.1-255 or 192.168. A way of defining a subnet and its size with a "mask", a smaller mask = more address bits usable by the subnet & more IPs in the range. Most common ones: + `192.0.2.1/32` (a single IP address, `192.0.2.1`) netmask = `255.255.255.255` - + `192.0.2.1/24` (255 IPs from `192.0.2.1`-`255`) netmask = ` 255.255.255.0` - + `192.0.2.1/16` (65,536 IPs from `192.0.2.0` - `192.0.255.255`) netmask = `255.255.0.0` - + `192.0.2.1/8` (16,777,216 IPs from `192.0.2.0` - `192.255.255.255`) netmask = `255.0.0.0` + + `192.0.2.1/24` (255 IPs from `192.0.2.0`-`192.0.2.255`) netmask = ` 255.255.255.0` + + `192.0.2.1/16` (65,536 IPs from `192.0.0.0` - `192.0.255.255`) netmask = `255.255.0.0` + + `192.0.2.1/8` (16,777,216 IPs from `192.0.0.0` - `192.255.255.255`) netmask = `255.0.0.0` + `0.0.0.1/0` (4,294,967,296 IPs from `0.0.0.0` - `255.255.255.255`) netmask = `0.0.0.0` + IPv6 CIDR notation is also supported e.g. `2001:DB8::/64` From 544689c91c81a9ef236aad5222d45ffd1a69d09f Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Thu, 7 May 2020 17:07:31 -0400 Subject: [PATCH 63/72] add docker instructions --- README.md | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) diff --git a/README.md b/README.md index 5607503..baca93c 100644 --- a/README.md +++ b/README.md @@ -1127,6 +1127,82 @@ WireGuard can be run in Docker with varying degrees of ease. In the simplest cas Setups can get somewhat complex and are highly dependent on what you're trying to achieve. You can have WireGuard itself run in a container and expose a network interface to the host, or you can have WireGuard running on the host exposing an interface to specific containers. +See below for an example of a Docker container `vpn_test` routing all its traffic through a WireGuard relay server. + +#### Example Relay Server Setup + +```yaml +version: '3' + +services: + wireguard: + image: linuxserver/wireguard + ports: + - 51820:51820/udp + cap_add: + - NET_ADMIN + - SYS_MODULE + volumes: + - /lib/modules:/lib/modules + - ./wg0.conf:/config/wg0.conf:ro +``` +**`wg0.conf`:** +```ini +[Interface] +# Name = relay1.wg.example.com +Address = 192.0.2.1/24 +ListenPort = 51820 +PrivateKey = oJpRt2Oq27vIB5/UVb7BRqCwad2YMReQgH5tlxz8YmI= +DNS = 1.1.1.1,8.8.8.8 +PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE +PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE + +[Peer] +# Name = peer1.wg.example.com +PublicKey = I+hXRAJOG/UE2IQvIHsou2zTgkUyPve2pzvHTnd/2Gg= +AllowedIPs = 192.0.2.2/32 +``` + +#### Example Client Container Setup + +In this example *all* the traffic from inside the `speedtest` container will go through the wireguard VPN. +To only route some traffic, replace `0.0.0.0/0` in `wg0.conf` below with the subnet ranges you want to route via the VPN. + +**`docker-compose.yml`:** +```yaml +version: '3' + +services: + wireguard: + image: linuxserver/wireguard + cap_add: + - NET_ADMIN + - SYS_MODULE + volumes: + - /lib/modules:/lib/modules + - ./wg0.conf:/config/wg0.conf:ro + + vpn_test: + image: curlimages/curl + entrypoint: curl -s http://whatismyip.akamai.com/ + network_mode: 'service:wireguard' +``` +**`wg0.conf`:** +```ini +[Interface] +# Name = peer1.wg.example.com +Address = 192.0.2.2/32 +PrivateKey = YCW76edD4W7nZrPbWZxPZhcs32CsBLIi1sEhsV/sgk8= +DNS = 1.1.1.1,8.8.8.8 + +[Peer] +# Name = relay1.wg.example.com +Endpoint = relay1.wg.example.com:51820 +PublicKey = zJNKewtL3gcHdG62V3GaBkErFtapJWsAx+2um0c0B1s= +AllowedIPs = 192.0.2.1/24,0.0.0.0/0 +PersistentKeepalive = 21 +``` + **Further Reading** - https://www.wireguard.com/#ready-for-containers From a61b47ec86549d8a800c48da797849dac387a657 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Sat, 9 May 2020 14:29:38 -0400 Subject: [PATCH 64/72] Add a bunch more docker info --- README.md | 45 +++++++++++++++++++++++++++++++-------------- 1 file changed, 31 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index baca93c..752502c 100644 --- a/README.md +++ b/README.md @@ -1003,6 +1003,7 @@ NAT-to-NAT connections are often more unstable and have other limitations, which - https://stackoverflow.com/questions/11819349/udp-hole-punching-not-possible-with-mobile-provider - https://github.com/WireGuard/WireGuard/tree/master/contrib/examples/nat-hole-punching - https://staaldraad.github.io/2017/04/17/nat-to-nat-with-wireguard/ + - https://golb.hplar.ch/2019/01/expose-server-vpn.html **Example** @@ -1085,6 +1086,9 @@ These are some GUI and CLI tools that wrap WireGuard to assist with config, depl - https://www.veeam.com/blog/veeam-pn-v2-wireguard.html - https://github.com/wg-dashboard/wg-dashboard - https://www.wireguardconfig.com + - https://github.com/complexorganizations/wireguard-manager + - https://github.com/influxdata/wirey + - https://github.com/apognu/wgctl ### Config Shortcuts @@ -1203,15 +1207,7 @@ AllowedIPs = 192.0.2.1/24,0.0.0.0/0 PersistentKeepalive = 21 ``` -**Further Reading** - -- https://www.wireguard.com/#ready-for-containers -- https://medium.com/@mdp/securing-docker-with-wireguard-82ad45004f4d -- https://blog.jessfraz.com/post/installing-and-using-wireguard/ -- https://github.com/cmulk/wireguard-docker -- https://github.com/activeeos/wireguard-docker -- https://github.com/ironhalik/docker-wireguard -- https://nbsoftsolutions.com/blog/routing-select-docker-containers-through-wireguard-vpn +For more details see the Further Reading: Docker section below. --- @@ -1250,6 +1246,11 @@ PersistentKeepalive = 21 - https://wiki.dd-wrt.com/wiki/index.php/The_Easiest_Tunnel_Ever - https://www.reddit.com/r/pihole/comments/bnihyz/guide_how_to_install_wireguard_on_a_raspberry_pi/ - https://jwillmer.de/blog/tutorial/wireguard-proxy-configuration +- https://www.maths.tcd.ie/~fionn/misc/wireguard.php +- https://www.linode.com/docs/networking/vpn/set-up-wireguard-vpn-on-debian/ +- https://golb.hplar.ch/2019/01/expose-server-vpn.html +- https://medium.com/@jmarhee/configuring-and-managing-routes-between-multiple-networks-with-wireguard-61ad995c887c +- https://stanislas.blog/2019/01/how-to-setup-vpn-server-wireguard-nat-ipv6/ ### Papers, Articles, and Talks @@ -1281,20 +1282,33 @@ PersistentKeepalive = 21 - https://www.veeam.com/blog/veeam-pn-v2-wireguard.html - https://github.com/wg-dashboard/wg-dashboard - https://wirt.network +- https://www.wireguardconfig.com - https://github.com/angristan/wireguard-install +- https://github.com/complexorganizations/wireguard-manager +- https://github.com/influxdata/wirey +- https://github.com/apognu/wgctl +- https://github.com/tailscale/tailscale ### Docker -- https://www.wireguard.com/#ready-for-containers -- https://medium.com/@mdp/securing-docker-with-wireguard-82ad45004f4d + - https://blog.jessfraz.com/post/installing-and-using-wireguard/ -- https://nbsoftsolutions.com/blog/leaning-on-algo-to-route-docker-traffic-through-wireguard -- https://github.com/cmulk/wireguard-docker +- https://codeopolis.com/posts/installing-wireguard-in-docker/ +- http://tiven.wang/articles/wireguard-setup-server-in-docker/ - https://github.com/activeeos/wireguard-docker +- https://github.com/cmulk/wireguard-docker - https://github.com/ironhalik/docker-wireguard +- https://github.com/linuxserver/docker-wireguard +- https://github.com/squat/kilo +- https://github.com/gravitational/wormhole +- https://medium.com/@mdp/securing-docker-with-wireguard-82ad45004f4d +- https://nbsoftsolutions.com/blog/leaning-on-algo-to-route-docker-traffic-through-wireguard - https://nbsoftsolutions.com/blog/routing-select-docker-containers-through-wireguard-vpn - https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-pudelko-vpn-performance.pdf - +- https://www.wireguard.com/#ready-for-containers +- https://discuss.linuxcontainers.org/t/solved-wireguard-in-macvlan-container-on-ubuntu-18-04/4445 +- https://www.reddit.com/r/WireGuard/comments/gdhcej/trouble_tunneling_docker_containers_through_a/ +- https://forums.unraid.net/topic/91367-partially-working-wireguard-docker/ ### Other @@ -1310,6 +1324,7 @@ PersistentKeepalive = 21 - https://www.wireguard.com/performance/ - https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/ - https://github.com/max-moser/network-manager-wireguard +- https://blog.linuxserver.io/2019/11/24/connect-an-ubuntu-client-to-opnsense-wireguard-tunnel-with-a-gui-toggle-in-gnome/ ### Discussions @@ -1321,8 +1336,10 @@ PersistentKeepalive = 21 - https://www.reddit.com/r/VPN/comments/au4owb/how_secure_is_wireguard_vpn_protocol/ - https://www.reddit.com/r/WireGuard/comments/ap33df/wireguard_what_is_so_special_about_it_and_why/ - https://www.reddit.com/r/VPN/comments/9hgs2x/what_is_the_difference_between_wireguard_openvpn/ +- https://www.reddit.com/r/WireGuard/comments/d3thxp/port_forwarding_on_the_router_with_wireguard_is/ - https://www.reddit.com/r/privacytoolsIO/comments/8l0vxt/what_do_you_think_guys_of_wireguard/ - https://community.ui.com/questions/Edgerouter-with-remote-Wireguard-access-issue/03e4f2e2-3871-437f-8632-3c5c7fb1c7a4 +- https://discuss.linuxcontainers.org/t/solved-wireguard-in-macvlan-container-on-ubuntu-18-04/4445 - https://news.ycombinator.com/item?id=20036194 - https://news.ycombinator.com/item?id=17659983 - https://news.ycombinator.com/item?id=17846387 From f20546b0470b4179ee3c00e545e262ac0c86917b Mon Sep 17 00:00:00 2001 From: Callan Bryant Date: Tue, 26 May 2020 20:05:55 +0100 Subject: [PATCH 65/72] Add dsnet to WireGuard Setup Tools dsnet is a simple command to manage a centralised wireguard VPN. Think wg-quick but quicker. PR suggested on hacker news: https://news.ycombinator.com/item?id=23299023 Thanks! --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 752502c..f373b92 100644 --- a/README.md +++ b/README.md @@ -1089,6 +1089,7 @@ These are some GUI and CLI tools that wrap WireGuard to assist with config, depl - https://github.com/complexorganizations/wireguard-manager - https://github.com/influxdata/wirey - https://github.com/apognu/wgctl + - https://github.com/naggie/dsnet/ ### Config Shortcuts From 53925cd245a63bfc2307e5b50cbd8e6568dd0003 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Fri, 29 May 2020 19:32:58 -0400 Subject: [PATCH 66/72] add docker article link --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 752502c..41e1198 100644 --- a/README.md +++ b/README.md @@ -1309,6 +1309,7 @@ For more details see the Further Reading: Docker section below. - https://discuss.linuxcontainers.org/t/solved-wireguard-in-macvlan-container-on-ubuntu-18-04/4445 - https://www.reddit.com/r/WireGuard/comments/gdhcej/trouble_tunneling_docker_containers_through_a/ - https://forums.unraid.net/topic/91367-partially-working-wireguard-docker/ +- https://saasbootstrap.com/how-to-setup-a-vpn-with-wireguard-that-only-routes-traffic-from-a-specific-docker-container-or-specific-ip/ ### Other From 51fd3554d1cdc32122eeb20d77133943f64f03c6 Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Fri, 29 May 2020 19:49:24 -0400 Subject: [PATCH 67/72] add perara/wg-manager to setup tools list --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index a3ffd51..cd782cf 100644 --- a/README.md +++ b/README.md @@ -1089,7 +1089,8 @@ These are some GUI and CLI tools that wrap WireGuard to assist with config, depl - https://github.com/complexorganizations/wireguard-manager - https://github.com/influxdata/wirey - https://github.com/apognu/wgctl - - https://github.com/naggie/dsnet/ + - https://github.com/naggie/dsnet + - https://github.com/perara/wg-manager ### Config Shortcuts From 881445d979eb5230bd050522baf08331cde6a3b9 Mon Sep 17 00:00:00 2001 From: Prajwal Koirala <16564273+Prajwal-Koirala@users.noreply.github.com> Date: Fri, 5 Jun 2020 00:21:34 -0400 Subject: [PATCH 68/72] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index cd782cf..403c344 100644 --- a/README.md +++ b/README.md @@ -1265,7 +1265,7 @@ For more details see the Further Reading: Docker section below. ### Related Projects -- https://github.com/complexorganizations/wireguard-install +- https://github.com/complexorganizations/wireguard-manager - https://github.com/subspacecloud/subspace - https://github.com/trailofbits/algo - https://github.com/StreisandEffect/streisand From 6e201ac57da191013ab947a365cd23ae7625f4f3 Mon Sep 17 00:00:00 2001 From: Prajwal Koirala <16564273+Prajwal-Koirala@users.noreply.github.com> Date: Fri, 5 Jun 2020 00:27:37 -0400 Subject: [PATCH 69/72] Update README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 403c344..6b1bc36 100644 --- a/README.md +++ b/README.md @@ -186,6 +186,7 @@ But you can write your own solutions for these problems using WireGuard under th - [Algo](https://github.com/trailofbits/algo) WireGuard setup tool - [Striesand](https://github.com/StreisandEffect/streisand) Multi-protocol setup tool - [IKEv2-setup](https://github.com/jawj/IKEv2-setup) IKEv2 server setup script + - [WireGuard-Manager](https://github.com/complexorganizations/wireguard-manager) WireGuard setup tool, all in one --- From 911dab502db2607e6e9b1336bd3db472f69e0103 Mon Sep 17 00:00:00 2001 From: vx3r Date: Wed, 10 Jun 2020 17:03:28 +0900 Subject: [PATCH 70/72] wg gen web link in WireGuard Setup Tools issue #51 --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index cd782cf..9d563f5 100644 --- a/README.md +++ b/README.md @@ -1073,6 +1073,7 @@ All of the userspace implementations are slower than the native C version that r These are some GUI and CLI tools that wrap WireGuard to assist with config, deployment, key management, and connection. + - https://github.com/vx3r/wg-gen-web - https://github.com/subspacecloud/subspace - https://github.com/corrad1nho/qomui - https://github.com/max-moser/network-manager-wireguard From 64b98cb2fafaaf3ed1da77f6a6673e9fd6dba15b Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Wed, 1 Jul 2020 21:11:40 -0400 Subject: [PATCH 71/72] add Drago to setup tools and related projects --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 436fdb2..11f62b6 100644 --- a/README.md +++ b/README.md @@ -1074,6 +1074,7 @@ All of the userspace implementations are slower than the native C version that r These are some GUI and CLI tools that wrap WireGuard to assist with config, deployment, key management, and connection. + - https://github.com/seashell/drago - https://github.com/vx3r/wg-gen-web - https://github.com/subspacecloud/subspace - https://github.com/corrad1nho/qomui @@ -1286,6 +1287,7 @@ For more details see the Further Reading: Docker section below. - https://www.veeam.com/blog/veeam-pn-v2-wireguard.html - https://github.com/wg-dashboard/wg-dashboard - https://wirt.network +- https://github.com/seashell/drago - https://www.wireguardconfig.com - https://github.com/angristan/wireguard-install - https://github.com/complexorganizations/wireguard-manager From daebf582e765786ac2ee3e53e2afce72052f0fad Mon Sep 17 00:00:00 2001 From: Nick Sweeting Date: Wed, 1 Jul 2020 21:16:56 -0400 Subject: [PATCH 72/72] add pivpn --- README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 11f62b6..71b29d6 100644 --- a/README.md +++ b/README.md @@ -158,7 +158,7 @@ Whether living behind the Great Wall of China or just trying to form a network b - handle automatically distributing & revoking keys through a central authority - allow sending raw layer-2 ethernet frames (it's at the IP layer) -But you can write your own solutions for these problems using WireGuard under the hood (like [AltheaNet](https://althea.net/)). +But you can write your own solutions for these problems using WireGuard under the hood (like [Tailscale](https://github.com/tailscale/tailscale) or [AltheaNet](https://althea.net/)). ## List of Other VPN Solutions @@ -1094,6 +1094,7 @@ These are some GUI and CLI tools that wrap WireGuard to assist with config, depl - https://github.com/apognu/wgctl - https://github.com/naggie/dsnet - https://github.com/perara/wg-manager + - https://github.com/pivpn/pivpn ### Config Shortcuts @@ -1294,6 +1295,7 @@ For more details see the Further Reading: Docker section below. - https://github.com/influxdata/wirey - https://github.com/apognu/wgctl - https://github.com/tailscale/tailscale +- https://github.com/pivpn/pivpn ### Docker