Configure WireGuard VPN
|
Configure WireGuard VPN Organic Design procedure |
Contents
Install OpenVPN
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.
apt-get install openvpnCreate the TUN/TAP device
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 VPSLink do not (see the issue raised in their forum and the 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.
mkdir -p /dev/net
mknod /dev/net/tun c 10 200
chmod 600 /dev/net/tunServer 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.
port 1194
proto tcp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
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
duplicate-cn
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 4- The server parameter is multi-client config running as a DHCP server
Creating Keys
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:
cp -pR /usr/share/doc/openvpn/examples/easy-rsa /etc
cd /etc/easy-rsa/2.0
mkdir keys
. ./vars
./clean-all
Next we'll use easy-rsa to generate a master key, a server key, a shared client key and finally we'll build the 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).
./build-ca
./build-key-server server
./build-key client
./build-dh
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.
Client configuration
Setting up Ubuntu workstations
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.
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 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:
client
dev tun
proto udp
dev-node office-lan
remote lan.foo.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
cipher AES-128-CBC
comp-lzo
verb 3
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 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 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.
