Difference between revisions of "Configure WireGuard VPN"

From Organic Design wiki
m (Reverted edits by Nad (talk) to last revision by 127.0.0.1)
(Tag: Rollback)
(See also: Configure OpenVPN)
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{procedure
+
{{stub}}
| description = Once a [[w:VPN|VPN]] has been set up with the [[install a new VPN]] procedure, all the workstations which are connected to the same VPN connection form part of a "virtual LAN" and they can all publish and use resources shared in that LAN such as shared directories, printers and services. They all show up in the normal "network places" or equivalent even though the hosts can be located in diverse locations around the internet, and all these connections are encrypted and secure.
+
We've recently changed from [https://openvpn.net/ OpenVPN] to [https://www.wireguard.com/ WireGuard] for our VPN solution. We use a VPN so that we can be sure our local browsing traffic's private even when we're on an insecure connection like a hotel or airport. Of course there are many solutions available such as ''ProtonVPN'' or ''RiseupVPN'', but we like to be independent for our security, and also this allows us to customise the ports and locations and have higher bandwidth than a shared solution.
| role = Sysop
 
| status = in use
 
}}
 
  
== Install OpenVPN ==
+
== Server ==
OpenVPN is a full-featured SSL VPN solution which can accomodate a wide range of configurations, including remote access, site-to-site VPNs, WiFi security, and enterprise-scale remote access solutions with load balancing, failover, and fine-grained access-controls. OpenVPN is a single program that is run on both the server hosting the share, and on the clients which will be accessing it. First install it on the server an Linux clients.
+
Our server setup requires that the server is running a DNS server, if this is an Organic Design server it will already be running since we use a local caching non-forwarding DNS Server for our mail configuration, see [[Configure DNS]] for details.
<source>
 
apt-get install openvpn
 
</source>
 
  
== Create the TUN/TAP device ==
+
First install ''WireGuard'' which is in the default Debian repositories.
A TAP device is a virtual ethernet adapter, while a TUN device is a virtual point-to-point IP link. Most Linux systems will have these devices set up by default, but some VPS hosts such as [http://www.vpslink.com VPSLink] do not (see the [http://forums.vpslink.com/linux/116-dev-net-tun-tun-tap-bridge-disabled-please-enable-it.html issue raised in their forum] and the [http://wiki.vpslink.com/index.php?title=TUN/TAP_device_with_OpenVPN_or_Hamachi solution added to their wiki] for more detail about this). If '''/dev/net/tun''' exists then you already have TUN/TAP set up and can move on to the OpenVPN configuration, otherwise do the following to create a TUN device.
+
<source lang="bash">
<source>
+
sudo apt install wireguard
mkdir -p /dev/net
 
mknod /dev/net/tun c 10 200
 
chmod 600 /dev/net/tun
 
 
</source>
 
</source>
  
== Server configuration ==
 
We'll go for a configuration which is as close to the default ''server.conf'' example file as possible to simplify the procedure. The certificate files must be specified with full pathnames, and the protocol must be changed to TCP rather than UDP which is the default. Here's all the required settings with comments removed for brevity.
 
<source>
 
port 1194
 
proto tcp
 
dev tun
 
  
ca  /etc/openvpn/ca.crt
+
Then create a key-pair that are called ''privatekey'' and ''publickey'' in the ''/etc/wireguard'' directory.
cert /etc/openvpn/server.crt
+
<source lang="bash">
key  /etc/openvpn/server.key
+
wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey
dh  /etc/openvpn/dh1024.pem
+
</source>
cipher AES-128-CBC
 
  
server 10.8.0.0 255.255.255.0
 
push "dhcp-option WINS 10.8.0.1"
 
  
ifconfig-pool-persist ipp.txt
+
Create a config file called ''/etc/wireguard/wg0.conf'':
duplicate-cn
+
<source>
keepalive 10 120
+
[Interface]
comp-lzo
+
PrivateKey = {!SERVER_PRIVATE_KEY!}
 
+
Address = 10.{!xx!}.{!xx!}.1/24, fd{!xx!}:{!xxxx!}:{!xxxx!}::1/64
user nobody
+
ListenPort = {!51820!}
group nogroup
+
SaveConfig = true
 +
PostUp = ufw route allow in on wg0 out on {!DEFAULT_INTERFACE!}
 +
PostUp = iptables -t nat -I POSTROUTING -o {!DEFAULT_INTERFACE!} -j MASQUERADE
 +
PostUp = ip6tables -t nat -I POSTROUTING -o {!DEFAULT_INTERFACE!} -j MASQUERADE
 +
PreDown = ufw route delete allow in on wg0 out on {!DEFAULT_INTERFACE!}
 +
PreDown = iptables -t nat -D POSTROUTING -o {!DEFAULT_INTERFACE!} -j MASQUERADE
 +
PreDown = ip6tables -t nat -D POSTROUTING -o {!DEFAULT_INTERFACE!} -j MASQUERADE
 +
</source>
 +
*'''SERVER_PRIVATE_KEY''' is the content of the ''/etc/wireguard/privatekey'' file.
 +
*The IP addresses can be anything, but are best within standard non-public address spaces, and using 1 within that space for the server, then 2 for the first client, 3 for the second etc.
 +
*The port can be anything you prefer, the default for WireGuard is 51820
 +
*'''DEFAULT_INTERFACE''' is the ethernet interface connected to the internet, if you don't know this you can see it with the '''ip route list default''' command.
 +
*Only include the '''ufw''' rules in ''PostUp'' and ''PreDown'' if you're running ''ufw''.
  
persist-key
 
persist-tun
 
  
status openvpn-status.log
+
Make sure that IP forwarding is enabled for both IPv4 and IPv6 by setting both ''net.ipv4.ip_forward'' and ''net.ipv6.conf.all.forwarding'' to ''1'' in ''/etc/sysctl.conf'' and then force the configuration to update immediately:
verb 4
+
<source lang="bash">
 +
sudo sysctl -p
 
</source>
 
</source>
*The ''server'' parameter is multi-client config running as a DHCP server
 
  
=== Creating Keys ===
+
== Clients ==
There's a utility called ''easy-rsa'' in ''/usr/share/doc/openvpn/examples/easy-rsa'' which should be copied to ''/etc/openvpn/easy-rsa''. The default values for all certificates generated can be updated in the ''vars'' file. First, configure ''easy-rsa'' with the following shell commands:
+
First install ''WireGuard'' which is in the default Debian repositories, and we'll also need ''resolvconf''.
<source>
+
<source lang="bash">
cp -pR /usr/share/doc/openvpn/examples/easy-rsa /etc
+
sudo apt install wireguard
cd /etc/easy-rsa/2.0
 
mkdir keys
 
. ./vars
 
./clean-all
 
 
</source>
 
</source>
  
  
Next we'll use ''easy-rsa'' to generate a master key, a server key, a shared client key and finally we'll build the [[w:Diffie-Hellman key exchange|Diffie Hellman key exchange parameters]]. Each of the commands requires a number of questions to be answered which can all be left as their defaults (which were set up in the ''vars'' file above), except for the ''common name'' setting which we'll set to "od-server" for the master key, "server" for the server key, and "client" for a generic keys shared by all the clients (the name "client" is the default name used on the windows sample client configuration and so requires no changes, but if you prefer you may like to create a separate client key for each based on the hostnames).
+
Then create a key-pair that are called ''privatekey'' and ''publickey'' in the ''/etc/wireguard'' directory.
<source>
+
<source lang="bash">
./build-ca
+
wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey
./build-key-server server
 
./build-key client
 
./build-dh
 
 
</source>
 
</source>
  
 +
<source lang="bash">
 +
[Interface]
 +
PrivateKey = CLIENT_PRIVATE_KEY
 +
Address = 10.xx.xx.2/24
 +
Address = fdxx:xxxx:xxxx::2/64
 +
DNS = SERVER_IP # assumes server is running a DNS server
 +
PostUp = ip rule add table 200 from CLIENT_IP
 +
PostUp = ip route add table 200 default via CLIENT_GATEWAY
 +
PreDown = ip rule delete table 200 from CLIENT_IP
 +
PreDown = ip route delete table 200 default via CLIENT_GATEWAY
  
All the generated key files are in the ''easy-rsa/2.0/keys'' directory that was created above. All the files having the ''.key'' suffix are secret and should only be communicated over encrypted connections like ''SCP''. The ''ca.crt'' file belongs on the server in ''/etc/openvpn'' and all the client machines as well. The files that start with "client" or the client hostnames belong on the client machines.
+
[Peer]
 
+
PublicKey = SERVER_PUBLIC_KEY
== Client configuration ==
+
Endpoint = SERVER_IP:SERVER_VPN_PORT
=== Setting up Ubuntu workstations ===
+
AllowedIPs = 0.0.0.0/0, ::/0
First install OpenVPN and the configuration GUI using '''apt-get install openvpn network-manager-openvpn'''. The GUI adds a "VPN Connections" item to the network menu from the system tray which VPN's can be added, removed and configured from.
+
</source>
 
 
Add a new VPN and set its name (e.g. "Office LAN") and the ''gateway'' to the domain or IP address of the intranet. Set the authentication type to "Certificates (TLS)" and browse for the two ''.crt'' files and the ''.key'' file created above. Click the ''advanced'' button and tick "Use LZO compression" and set the cipher to "AES-128-CBC".
 
 
 
Currently you'll need to enter '''smb://10.8.0.1''' into a Nautilus window to gain access to the intranet shares because any NetBIOS names that are routed to the clients via DHCP are in terms of the intranets subnet not the VPN's.
 
 
 
=== Setting up on Windows workstations ===
 
Download and install [http://openvpn.net/index.php/open-source/downloads.html OpenVPN] (note that if you're using Vista you'll need at least version 2.1), this will set up a new network adapter which you should rename appropriately for example to "office-lan".
 
 
 
Copy the ''ca.crt'', ''client.crt'' and ''client.key'' files generated on the server into ''Program Files\OpenVPN\Config'' on the client. Also copy the sample client config into that directory (and call it something like ''office.opvn'') and set the '''dev-node'' parameter to the name you gave to the new network adapter, and the ''remote'' parameter to the address (domain or IP) of your server. Here's a typical windows OpenVPN client configuration file:
 
<source>
 
client
 
dev tun
 
proto udp
 
  
dev-node office-lan
+
Set permissions of the files.
remote lan.foo.com 1194
+
<source lang="bash">
 
+
sudo chmod 600 /etc/wireguard/*
resolv-retry infinite
+
sudo chmod 644 /etc/wireguard/publickey
nobind
 
persist-key
 
persist-tun
 
 
 
ca ca.crt
 
cert client.crt
 
key client.key
 
cipher AES-128-CBC
 
 
 
comp-lzo
 
verb 3
 
 
</source>
 
</source>
 
 
Right click on the VPN network icon in the system tray and select "connect", if all has been done correctly, the connection with the remote LAN should be made and an IP address obtained.
 
 
Currently you'll need to enter '''\\10.8.0.1''' into an Explorer window to gain access to the list of all available shares on the remote LAN because any NetBIOS names that are routed to the clients via DHCP are in terms of the intranets subnet not the VPN's.
 
 
You should add each share you want to have regular access to into your network places. To do this, go to "My Network Places" from the start menu, and then select "Add a network place", click next a couple of times and then enter the address where prompted, for example '''\\10.8.0.1\Documents''' and click OK, you can then enter a friendly name for the connection if you like such as "Office LAN documents". The items in your network places will remain there even after turning the computer off, but note that the VPN connection must be established before you can access them (by right-clicking the VPN network icon in the system tray and click "connect").
 
 
=== Detailed procedure ===
 
For a detailed Windows XP/Vista procedure with screenshots, see: [[Set up and configure a VPN connection on Windows XP/Vista]]
 
 
== Notes ==
 
=== Bridging/Routing ===
 
Ethernet bridging essentially involves combining an ethernet interface with one or more virtual TAP interfaces and bridging them together under the umbrella of a single bridge interface. Ethernet bridges represent the software analog to a physical ethernet switch. The ethernet bridge can be thought of as a kind of software switch which can be used to connect multiple ethernet interfaces (either physical or virtual) on a single machine while sharing a single IP subnet.
 
 
By bridging a physical ethernet NIC with an OpenVPN-driven TAP interface at two separate locations, it is possible to logically merge both ethernet networks, as if they were a single ethernet subnet. See the [http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html OpenVPN bridging information] for more detail.
 
 
=== What is the principle behind OpenVPN tunnels? ===
 
Here is a brief summary of the principle behind OpenVPN from the [http://www.ossg.ru/docs/OpenVPN/faq.html OpenVPN FAQ].
 
 
Imagine you had a direct physical wire (i.e. a long cable) connecting two computers (A and B) at different locations. On each computer there would be a /dev/longcable which would be a network device. You could route IP traffic over it, and do everything you could normally do with a network device.
 
 
Basically a tun device is like having a /dev/longcable except the OpenVPN daemon is the program that connects the /dev/longcable on computer A with the /dev/longcable on computer B so that you can use the internet rather than a real physical cable. But in this case it is called /dev/tun or whatever your OS prefers to call them.
 
 
Now the mechanism by which OpenVPN connects /dev/tun on computer A with /dev/tun on computer B is this: It simply creates an encrypted UDP connection over the internet between A and B and forwards traffic between /dev/tun on A with /dev/tun on B. Because of the clever way in which the tun and tap drivers were designed, it is possible for a program running entirely in user-space to effect this link, allowing OpenVPN to be a portable cross-platform daemon (like SSH), rather than an OS-specific kernel module (like IPSec).
 
 
The difference between a tun and tap device is this: a tun device is a virtual IP point-to-point device and a tap device is a virtual ethernet device. So getting back to the "long cable" analogy, using a tun device would be like having a T1 cable connecting the computers and using a tap device would be like having an ethernet network connecting the two computers. People who are running applications that need the special features of ethernet (which won't work on an IP-only network) will often bridge their physical local ethernet with a tap device (using a utility such as brctl on Linux), then VPN the tap device to another similar setup at the other end. This allows OpenVPN to route ethernet broadcasts and non-IP protocols such as Windows NetBios over the VPN. If you don't need the special features of ethernet (such as bridging capability), it's better to use a tun device.
 
 
Tun and tap devices can be interconnected to create a complex routing topology. Some people have created multi-node WAN networks over tap devices and actually run DHCP over the VPN so that clients can log into the virtual ethernet and request an IP address. I've even heard of people using Linux advanced routing to run OSPF (a kind of dynamic routing protocol) over the VPN WAN to allow for dynamic, fault-tolerant routing. The sky is the limit as far as the complexity of network you can build, but the basic building block is a VPN daemon such as OpenVPN connecting tun or tap devices on two different machines.
 
  
 
== See also ==
 
== See also ==
*[http://openvpn.net/index.php/open-source/faq.html OpenVPN FAQ]
+
*[[Configure OpenVPN]]
*[http://openvpn.net/index.php/open-source/documentation/install.html?start=1 OpenVPN Win32 Installation]
+
*[https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-20-04#step-3-%E2%80%94-creating-a-wireguard-server-configuration Digital Ocean's WireGuard setup procedure]
*[http://openvpn.se OpenVPN GUI for Windows]
+
*[https://github.com/angristan/wireguard-install Angristan's WireGuard installer script]
*[http://wiki.openvz.org/VPN VPN on OpenVZ] (our VPS's OS)
+
*[https://blog.ipfire.org/post/why-not-wireguard Michael Tremer, the main WireGuard critic in the field]

Latest revision as of 15:48, 24 March 2022

Cone.png This article or section is a stub. Stubs are articles that have not yet received substantial attention from the authors. They are short or insufficient pieces of information and require additions to further increase the article's usefulness. The project values stubs as useful first steps toward complete articles.

We've recently changed from OpenVPN to WireGuard for our VPN solution. We use a VPN so that we can be sure our local browsing traffic's private even when we're on an insecure connection like a hotel or airport. Of course there are many solutions available such as ProtonVPN or RiseupVPN, but we like to be independent for our security, and also this allows us to customise the ports and locations and have higher bandwidth than a shared solution.

Server

Our server setup requires that the server is running a DNS server, if this is an Organic Design server it will already be running since we use a local caching non-forwarding DNS Server for our mail configuration, see Configure DNS for details.

First install WireGuard which is in the default Debian repositories.

sudo apt install wireguard


Then create a key-pair that are called privatekey and publickey in the /etc/wireguard directory.

wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey


Create a config file called /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = SERVER_PRIVATE_KEY
Address = 10.xx.xx.1/24, fdxx:xxxx:xxxx::1/64
ListenPort = 51820
SaveConfig = true
PostUp = ufw route allow in on wg0 out on DEFAULT_INTERFACE
PostUp = iptables -t nat -I POSTROUTING -o DEFAULT_INTERFACE -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o DEFAULT_INTERFACE -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on DEFAULT_INTERFACE
PreDown = iptables -t nat -D POSTROUTING -o DEFAULT_INTERFACE -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o DEFAULT_INTERFACE -j MASQUERADE
  • SERVER_PRIVATE_KEY is the content of the /etc/wireguard/privatekey file.
  • The IP addresses can be anything, but are best within standard non-public address spaces, and using 1 within that space for the server, then 2 for the first client, 3 for the second etc.
  • The port can be anything you prefer, the default for WireGuard is 51820
  • DEFAULT_INTERFACE is the ethernet interface connected to the internet, if you don't know this you can see it with the ip route list default command.
  • Only include the ufw rules in PostUp and PreDown if you're running ufw.


Make sure that IP forwarding is enabled for both IPv4 and IPv6 by setting both net.ipv4.ip_forward and net.ipv6.conf.all.forwarding to 1 in /etc/sysctl.conf and then force the configuration to update immediately:

sudo sysctl -p

Clients

First install WireGuard which is in the default Debian repositories, and we'll also need resolvconf.

sudo apt install wireguard


Then create a key-pair that are called privatekey and publickey in the /etc/wireguard directory.

wg genkey | sudo tee /etc/wireguard/privatekey | wg pubkey | sudo tee /etc/wireguard/publickey
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
Address = 10.xx.xx.2/24
Address = fdxx:xxxx:xxxx::2/64
DNS = SERVER_IP # assumes server is running a DNS server
PostUp = ip rule add table 200 from CLIENT_IP
PostUp = ip route add table 200 default via CLIENT_GATEWAY
PreDown = ip rule delete table 200 from CLIENT_IP
PreDown = ip route delete table 200 default via CLIENT_GATEWAY

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = SERVER_IP:SERVER_VPN_PORT
AllowedIPs = 0.0.0.0/0, ::/0

Set permissions of the files.

sudo chmod 600 /etc/wireguard/*
sudo chmod 644 /etc/wireguard/publickey

See also