Difference between revisions of "WireGuard"
m (write in 3rd person)
(→Troubleshooting: bug fixed in 0.0.20181104-5)
|Line 283:||Line 283:|
== Troubleshooting ==
== Troubleshooting ==
=== Routes are periodically reset ===
=== Routes are periodically reset ===
Revision as of 17:05, 8 December 2018
From the WireGuard project homepage:
- Wireguard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPSec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. Initially released for the Linux kernel, it plans to be cross-platform and widely deployable.
- 1 Installation
- 2 Raw usage
- 3 Specific use-case: VPN server
- 4 Troubleshooting
- 5 Tips and tricks
- 6 See also
Install the package.
Below commands will demonstrate how to setup a basic tunnel between two peers with the following settings:
|Peer A||Peer B|
|External IP address||10.10.10.1/24||10.10.10.2/24|
|Internal IP address||10.0.0.1/24||10.0.0.2/24|
|wireguard listening port||UDP/48574||UDP/39814|
The external addresses should already exist. For example, peer A should be able to ping peer B via
ping 10.10.10.2, and vice versa. The internal addresses will be new addresses created by the ip commands below and will be shared internally within the new WireGuard network. The
/24 in the IP addresses is the CIDR.
To create a private key:
$ wg genkey > privatekey
To create a public key:
$ wg pubkey < privatekey > publickey
Alternatively, do this all at once:
$ wg genkey | tee privatekey | wg pubkey > publickey
One can also create a pre-shared key for added security.
# wg genpsk > preshared
Peer A setup
This peer will listen on UDP port 48574 and will accept connection from peer B by linking its public key with both its inner and outer IPs addresses.
# ip link add dev wg0 type wireguard # ip addr add 10.0.0.1/24 dev wg0 # wg set wg0 listen-port 48574 private-key ./privatekey # wg set wg0 peer [Peer B public key] persistent-keepalive 25 allowed-ips 10.0.0.2/32 endpoint 10.10.10.2:39814 # ip link set wg0 up
[Peer B public key] should have the same format as
allowed-ips is a list of addresses that peer A will be able to send traffic to.
allowed-ips 0.0.0.0/0 would allow sending traffic to any address.
Peer B setup
As with Peer A, whereas the wireguard daemon is listening on the UDP port 39814 and accept connection from peer A only.
# ip link add dev wg0 type wireguard # ip addr add 10.0.0.2/24 dev wg0 # wg set wg0 listen-port 39814 private-key ./privatekey # wg set wg0 peer [Peer A public key] persistent-keepalive 25 allowed-ips 10.0.0.1/32 endpoint 10.10.10.1:48574 # ip link set wg0 up
Invoking the wg command without parameter will give a quick overview of the current configuration.
As an example, when Peer A has been configured we are able to see its identity and its associated peers:
peer-a$ wg interface: wg0 public key: UguPyBThx/+xMXeTbRYkKlP0Wh/QZT3vTLPOVaaXTD8= private key: (hidden) listening port: 48574 peer: 9jalV3EEBnVXahro0pRMQ+cHlmjE33Slo9tddzCVtCw= endpoint: 10.10.10.2:39814 allowed ips: 10.0.0.2/32
At this point one could reach the end of the tunnel:
peer-a$ ping 10.0.0.2
The configuration can be saved by utilizing
# wg showconf wg0 > /etc/wireguard/wg0.conf # wg setconf wg0 /etc/wireguard/wg0.conf
Example peer configuration
[Interface] Address = 10.0.0.1/32 PrivateKey = [CLIENT PRIVATE KEY] [Peer] PublicKey = [SERVER PUBLICKEY] AllowedIPs = 10.0.0.0/24, 10.123.45.0/24, 1234:4567:89ab::/48 Endpoint = [SERVER ENDPOINT]:51820 PersistentKeepalive = 25
Example configuration for systemd-networkd
[NetDev] Name = wg0 Kind = wireguard Description = Wireguard [WireGuard] PrivateKey = [CLIENT PRIVATE KEY] [WireGuardPeer] PublicKey = [SERVER PUBLIC KEY] PresharedKey = [PRE SHARED KEY] AllowedIPs = 10.0.0.0/24 Endpoint = [SERVER ENDPOINT]:51820 PersistentKeepalive = 25
[Match] Name = wg0 [Network] Address = 10.0.0.3/32 DNS = 10.0.0.1 [Route] Gateway = 10.0.0.1 Destination = 10.0.0.0/24
Endpoint with changing IP
After resolving a server's domain, WireGuard will not check for changes in DNS again.
If the WireGuard server is frequently changing its IP-address due DHCP, Dyndns, IPv6, ..., any WireGuard client is going to lose its connection, until its endpoint is updated via something like
wg set "$INTERFACE" peer "$PUBLIC_KEY" endpoint "$ENDPOINT".
Also be aware, if the endpoint is ever going to change its address (for example when moving to a new provider/datacenter), just updating DNS will not be enough, so periodically running reresolve-dns might make sense on any DNS-based setup.
/usr/share/wireguard/examples/reresolve-dns/reresolve-dns.sh, that parses WG configuration files and automatically resets the endpoint address.
One needs to run the
/usr/share/wireguard/examples/reresolve-dns/reresolve-dns.sh /etc/wireguard/wg.conf periodically to recover from an endpoint that has changed its IP.
One way of doing so is by updating all WireGuard endpoints once every thirty seconds via a systemd timer:
[Unit] Description=Periodically reresolve DNS of all WireGuard endpoints [Timer] OnCalendar=*:*:0/30 [Install] WantedBy=timers.target
[Unit] Description=Reresolve DNS of all WireGuard endpoints Wants=network-online.target After=network-online.target [Service] Type=oneshot ExecStart=/bin/sh -c 'for i in /etc/wireguard/*.conf; do /usr/share/wireguard/examples/reresolve-dns/reresolve-dns.sh "\$i"; done'
Specific use-case: VPN server
The purpose of this section is to setup a WireGuard "server" and generic "clients" to enable access to the server/network resources through an encrypted and secured tunnel like OpenVPN and others. The server runs on Linux and the clients can run any any number of platforms (the WireGuard Project offers apps on both iOS and Android platforms in addition to Linux-native and MacOS). See the official project install link for more.
On the machine acting as the server, first enable IPv4 forwarding:
# sysctl net.ipv4.ip_forward=1
To make the change permanent, add
net.ipv4.ip_forward = 1 to
A properly configured firewall is HIGHLY recommended for any Internet-facing device. Be sure to:
- Allow UDP traffic on the specified port(s) on which WireGuard will be running (for example allowing traffic on 51820/udp).
- Setup the forwarding policy for the firewall if it is not included in the WireGuard config for the interface itself
/etc/wireguard/wg0.conf. The example below should work as-is.
Finally, WireGuard port(s) need to be forwarded to the server's LAN IP from the router so they can be accessed from the WAN (ie router port forwarding).
Generate public/private key pairs for the server and for each client as explained in #Key generation. Optionally, generate a preshared key to add an additional layer of symmetric-key cryptography to be mixed into the already existing public-key cryptography, for post-quantum resistance.
Create the server config file:
[Interface] Address = 10.200.200.1/24 SaveConfig = true ListenPort = 51820 PrivateKey = [SERVER PRIVATE KEY] # note - substitute eth0 in the following lines to match the Internet-facing interface PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE [Peer] # client foo PublicKey = [FOO's PUBLIC KEY] PresharedKey = [PRE-SHARED KEY] AllowedIPs = 10.200.200.2/32 [Peer] # client bar PublicKey = [BAR's PUBLIC KEY] PresharedKey = [PRE-SHARED KEY] AllowedIPs = 10.200.200.3/32
The interface can be managed manually or by systemctl.
For example: bring the interface up by using
wg-quick up wg0 and bring it down by using
wg-quick down wg0.
# systemctl start wg-quick@wg0
Create the corresponding client config file(s):
[Interface] Address = 10.200.200.2/24 PrivateKey = [FOO's PRIVATE KEY] DNS = 10.200.200.1 [Peer] PublicKey = [SERVER PUBLICKEY] PresharedKey = [PRE-SHARED KEY] AllowedIPs = 0.0.0.0/0 Endpoint = my.ddns.address.com:51820
[Interface] Address = 10.200.200.3/24 PrivateKey = [BAR's PRIVATE KEY] DNS = 10.200.200.1 [Peer] PublicKey = [SERVER PUBLICKEY] PresharedKey = [PRE-SHARED KEY] AllowedIPs = 0.0.0.0/0 Endpoint = my.ddns.address.com:51820
If the client is a mobile device such as a phone,can be used to share the config with the client:
$ qrencode -t ansiutf8 < foo.conf
NetworkManager-wait-online.serviceand users of systemd-networkd may need to enable the
systemd-networkd-wait-online.serviceto wait until devices are network ready before attempting wireguard connection.
Routes are periodically reset
Make sure that NetworkManager is not managing the Wireguard interface:
Connection loss with NetworkManager
On desktop, connection loss can be experienced when all the traffic is tunnelled through a Wireguard interface: typically, the connection is seemingly lost after a while or upon new connection to an access point.
By default wg-quick uses a resolvconf provider such as openresolv to register new DNS entries (i.e.
DNS keyword in the configuration file). However NetworkManager does not use resolvconf by default: every time a new DHCP lease is acquired, NetworkManager overwrites the global DNS addresses with the DHCP-provided ones which might not be available through the tunnel.
If resolvconf is already used by the system and connection losses persist, make sure NetworkManager is configured to use it: NetworkManager#Use openresolv.
See Dnsmasq#openresolv for configuration.
At the time of writing (Sept. 2018), the resolvconf-compatible mode offered by systemd-resolved can still be used by wg-quick through the
PostUp hook. First make sure that NetworkManager is configured with systemd-resolved: NetworkManager#systemd-resolved and then alter the tunnel configuration:
[Interface] Address = 10.0.0.2/24 # The client IP from wg0server.conf with the same subnet mask PrivateKey = [CLIENT PRIVATE KEY] PostUp = resolvectl domain %i "~."; resolvectl dns %i 10.0.0.1; resolvectl dnssec %i yes [Peer] PublicKey = [SERVER PUBLICKEY] AllowedIPs = 0.0.0.0/0, ::0/0 Endpoint = [SERVER ENDPOINT]:51820 PersistentKeepalive = 25
"~." as a domain name is necessary for systemd-resolved to give priority to the newly available DNS server.
PostDown key is necessary as systemd-resolved automatically revert all parameters when
wg0 is torn down.
Tips and tricks
Store private keys in encrypted form
It may be desirable to store private keys in encrypted form, such as through use of. Just replace the PrivateKey line under [Interface] in the configuration file with:
PostUp = wg set %i private-key <(su user -c "export PASSWORD_STORE_DIR=/path/to/your/store/; pass WireGuard/private-keys/%i")
where user is the Linux username of interest. See theman page for more details.