VPNserver: Difference between revisions

From Sea of Fate
Jump to navigationJump to search
← Older edit
 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Introduction==
==Introduction==


The only host on the VPNNet is Vanilla it has an IP Address of VPNnet.5. OpenVPN was tried but it had problems with routing so Wireguard has been tried and it now works. It is possible that the routing problems were the same as was on wireguard and maybe they could have been overcome but as there is now a working Wireguard solution on Vanilla there is only a limited reason to try OpenVPN again.
The general idea of the VPN was to allow RDP access to the desktop hosts on the '''[[Remote Access Terminal | terminals]]''' network from a remote location to the '''[[Home Lab]]''' and any '''[[Virtual Machines | Virtual Machine]]''' that may be required. There may be some gain in having a Samba share to Satsuma as well as the VPN will secure the connection. There does not need to be a Internet connection through the VPN at this time so we will not add the Ip as the default route for Internet at this time, If that changes it should be fairly straight forward to add it on to the client connection. There may be other requirements at a later date.


==The Solution required==
==Reasons for choosing Wireguard over OpenVPN==
 
The only host on the VPNNet is Vanilla it has an IP Address of 192.168.130.5. OpenVPN was tried on Voavanga 192.168.130.5 but although it works it had problems with routing so Wireguard has been tried and it now works. It is possible that the routing problems were the same as was on Wireguard and maybe they could have been overcome but as there is now a working Wireguard solution on Vanilla there is only a limited reason to try OpenVPN again. The bigger and more important difference between the two is that Wireguard is designed to work in stealth mode but OpenVPN is designed to be more helpful and retry failed connection attempts. Wireguard expects the client to supply the correct signature to create the connection over UDP and if the signature is correct a connection is established but if incorrect the packets are simply dropped, so any bot trying to guess the signature will just timeout without confirming there is a live service at the IP address. OpenVPN will also reject any failed connections but it will send a reply to the client offering to attempt another handshake, while that is fine for some networks with robust attack mitigation but we would prefer the more stealthy approach of Wireguard. It is not that the edge router is any worse than any other it is simply that the consumer grade internet connection will likely black box our current IP address if there are too many probes.


The general idea of the VPN was to allow RDP access to the desktop hosts on the '''[[Remote Access Terminal | terminals]]''' network from a remote location . There may be some gain in having a Samba share to Satsuma as well as the VPN will secure the connection. There does not need to be a Internet connection through the VPN at this time so we will not add the Ip as the default route for Internet at this time, If that changes it should be fairly straight forward to add it on to the client connection. There may be other requirements at a later date.


==Installation of Wireguard==
==Installation of Wireguard==
Line 67: Line 68:
Next we have to enable ip forwarding on vanilla
Next we have to enable ip forwarding on vanilla
  sudo nano /etc/sysctl.conf
  sudo nano /etc/sysctl.conf
search for the line
search for the lines
  net.ipv4.ip_forward=1
  net.ipv4.ip_forward=1 # this probably exists but is commented out
and add it or uncomment it, then save and exit. Next we can move on to the client install
net.ipv4.conf.all.forwarding=1
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.enp6s18.forwarding=1
net.ipv4.conf.wg0.forwarding=1
and add the or uncomment them, then save and exit. they can be applied immediately with
sudo sysctl -p /etc/sysctl.conf
Next we can move on to the client install


===Client Install on Grape===
===Client Install on Grape===


We install on Grape, the desktop PC to begin with and then repeat the step with the laptop Dragonfruit. First we need to download the client software  
We install on Grape, the desktop PC to begin with and then repeat the step with the laptop Dragonfruit. First we need to download the client software the installer can be downloaded from https://www.wireguard.com/install.
 
After installing Wireguard a key pair must be generated, as it is on a Windows 11 client open a powershell window as administrator and enter the two commands
After installing Wireguard a key pair must be generated, as it is on a Windows 11 client open a powershell window as administrator and enter the two commands
  wg genkey | Out-File -Encoding ASCII client-privatekey.txt
  wg genkey | Out-File -Encoding ASCII client-privatekey.txt
Line 103: Line 109:
There should be at least three interfaces shown, the loopback, the main NIC(enp6s18) for vanilla and the VPN interface (probably wg0 as it takes the filename and uses that as the interface name) . both interfaces must be up and there must be updates in the client to go any further.
There should be at least three interfaces shown, the loopback, the main NIC(enp6s18) for vanilla and the VPN interface (probably wg0 as it takes the filename and uses that as the interface name) . both interfaces must be up and there must be updates in the client to go any further.


We should be able to ping Vanilla's IP but not the DNS name and we will not be able to ping anything outside 192.168.130.0/24 because we need to add a static route to Pfsense to reach 192.168.131.0/24. The route '''to''' the other IP domains is effectively taken care of by Wireguard because routes in to Proxmox are specified in the Allowed IPs in the [peer] section of the client config and the routes will be set by vanilla. For example, the route from Grape to 192.168.100.10 will be from 192.168.131.6 to 192.168.131.1(vanilla on wg0) to 192.168.130.5 (Vanilla on enp6s18, it's main NIC) then as Vanilla has already got it's own default route set to Pfsense on 192.168.130.1 the route continues to Pfsense and on to the Pfsense NIC on 192.168.100.0/24 then to the final destination. Grape is able to use Vanilla's routes because the MASQUERADE directive in the wg0.conf hides all of the VPN clients' IPs so Pfsense will never see them, like a NAT, from pfsense viewpoint anything coming out of the VPN is originating from Vanilla.
We should be able to ping Vanilla's IP but not the DNS name and we will not be able to ping anything outside 192.168.130.0/24 because we need to add a static route to Pfsense to reach 192.168.131.0/24. The route '''to''' the other IP domains is effectively taken care of by Wireguard because routes in to Proxmox are specified in the Allowed IPs in the [peer] section of the client config and the routes will be set by vanilla. For example, the route from Grape to 192.168.100.10 will be from 192.168.131.6(Grape's VPN IP address) to 192.168.131.1(Vanilla on wg0) to 192.168.130.5 (Vanilla on enp6s18, it's main NIC) then as Vanilla has already got it's own default route set to Pfsense on 192.168.130.1 the route continues to Pfsense and on to the Pfsense NIC on 192.168.100.0/24 then to the final destination. Grape is able to use Vanilla's routes because the MASQUERADE directive in the wg0.conf hides all of the VPN clients' IPs so Pfsense will never see them, like a NAT. From Pfsense viewpoint anything coming out of the VPN is originating from Vanilla. The return route will be a different matter in that Pfsense has no clue as to how to route packets to 192.168.131.0/24 because that network is being masked by vanilla.
 
To add a static route from Pfsense to the VPN clients go to the Pfsense web GUI. First The gateway must be added, navigate to System->Routing->Gateways and click add button.
* Interface is VPNNet
* Name is Wireguard-Vanilla
* Gateway is the IP of Vanilla
* add a description and save
Apply the change. Go to System->Routing->Static Routes and click the add button.
* Destination 192.168.131.0 /24
* Gateway is the one just created Wireguard-Vanilla
* Description is Route to WireGuard Clients
This static route is the final thing to complete to make the VPN work.
 
===Some of the Potential Problems===
 
Setting up Wireguard is quite straight forward, it is the bit around the setup that can be a source of frustration.
 
====setting up iptables====
 
IPtables can be used to accept or drop or forward packets. Unfortunately, these same rules can cause no end of problems. To help with the debug of them
* To list iptables rules: iptables -L
* To copy iptables rules to a file: iptables-save > filename.txt
* To show routes: ip route
* To set routes: ip route add [destination network/ip] via [gateway ip] dev [interface] for example To add a route to network 192.168.131.0/24 via the gateway 192.168.130.5 using the enp6s18 interface use the command ip route add 192.168.131.0/24 via 192.168.130.5 dev enp6s18
* The file /etc/sysctl.conf controls how the kernal forwards traffic
 
====Windows 11 using ns1 as Nameserver====
 
Windows 11 does not automatically append the domain name to hostname lookups when there is no domain controller so when we want to ping walnut on the terminals windows will not find it unless we use the FQDM walnut.seaoffate.net. To enable the hostname lookups to succeed we have to  "View network connections" in the start menu, open the network interface, then properties, and in the connection items find the TCP/IPv4 item and select Properties. Either type in the ip address or do the radio button to obtain IP address automatically and click Advanced. in the advanced settings select the DNS tab (if it says about the ip address being required it needs to have an ip address either as dhcp or as static to open DNS tab) Click the radio button Append these DNS suffixes (in order) and then click add to add the two domains seaoffate.net & seaoffate.local. we can clear the register this connection address in DNS but it will not matter if it is left in place. when finished click ok enough times to close all of the dialogues. Now close the wireguard connection and reopen it, this should clear any IP address that was added in to dialogs because wireguard will set them again as it re opens. Try ping ns1 in a cmd window and it should now resolve to ns1.seaoffate.net.
 
 
==Installation of OpenVPN==
 
I wanted to compare the two competing VPN solutions another VM was created call Voavanga on 192.168.130.4 (one number lower than than the Wireguard VPN server). I had heard that OpenVPN was more complicated to setup but had more options. Now that it is done I can confirm that it is indeed more complicated to setup  but not by much. The host used in both is the same specifications and as there will not be a need to host many clients it does not need to be huge.
 
===OpenVPN Disabled===
 
'''Update''', OpenVPN works and and does allow VPN connections to the network but it does not do the split DNS well in that windows does not fix the local DNS on the OpenVPN network interface. it is assumed that it would not be a problem if the entire internet was routed through the OpenVPN NIC. The other feature of OpenVPN is that it will always reply to connection requests with a handshake request and thus confirm that there is a live service at the public facing IP address regardless of whether the signature is valid. In view of these two features it has been decided to use Wireguard for remote access only and switch off Voavanga.
 
===Setup The VPN Server===
 
The setup is a bit different to Wireguard in that we have to generate our own SSL certs & keys. So we will need something to do generate them and we have chosen easyrsa. To start we need to do the standard update upgrade.
sudo apt update
sudo apt upgrade -y
Then openvpn and Easy-RSA
sudo apt install openvpn easy-rsa -y
Next we need to setup the SSL Certificate Authority
mkdir ~/openvpn-ca
cd ~/openvpn-ca
./easyrsa init-pki
./easyrsa build-ca nopass
These commands create a directory for Easy-RSA, navigates into it, initializes the PKI, and builds the Certificate Authority. Next to generate the keys
./easyrsa build-server-full server nopass ./easyrsa gen-dh
This generates the server certificate and private key, and the Diffie-Hellman parameters.
sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
sudo gzip -d /etc/openvpn/server.conf.gz
sudo nano /etc/openvpn/server.conf
Copies the sample server configuration file, unzips it, and opens it for editing.
sudo cp ~/openvpn-ca/pki/ca.crt /etc/openvpn/
sudo cp ~/openvpn-ca/pki/issued/server.crt /etc/openvpn/
sudo cp ~/openvpn-ca/pki/private/server.key /etc/openvpn/
sudo cp ~/openvpn-ca/pki/dh.pem /etc/openvpn/dh.pem
Copies the necessary certificate and key files to the `/etc/openvpn/` directory.
sudo nano /etc/sysctl.conf
Opens the system configuration file to enable IP forwarding much like we did with Wireguard
save and exit the apply the changes with
sudo sysctl -p
 
Next we need to edit the firewall.
 
Then as a final step we eanble start and chec the satus of the OpenVPN service
sudo systemctl enable openvpn@server
sudo systemctl start openvpn@server
sudo systemctl status openvpn@server
 
Next we need to install the Client
 
=== Client install ===
 
client
dev tun
proto udp  # Or tcp, depending on your server config
remote walnut.seaoffate.net 1194  # Replace with the public IP or hostname of your Proxmox host
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert dragonfruit.crt
key dragonfruit.key
remote-cert-tls server
tls-client
cipher AES-256-CBC  # Match your server config
auth SHA256        # Match your server config
compress lz4-v2    # Match your server config
verb 3

Latest revision as of 17:14, 20 February 2026

Introduction

The general idea of the VPN was to allow RDP access to the desktop hosts on the terminals network from a remote location to the Home Lab and any Virtual Machine that may be required. There may be some gain in having a Samba share to Satsuma as well as the VPN will secure the connection. There does not need to be a Internet connection through the VPN at this time so we will not add the Ip as the default route for Internet at this time, If that changes it should be fairly straight forward to add it on to the client connection. There may be other requirements at a later date.

Reasons for choosing Wireguard over OpenVPN

The only host on the VPNNet is Vanilla it has an IP Address of 192.168.130.5. OpenVPN was tried on Voavanga 192.168.130.5 but although it works it had problems with routing so Wireguard has been tried and it now works. It is possible that the routing problems were the same as was on Wireguard and maybe they could have been overcome but as there is now a working Wireguard solution on Vanilla there is only a limited reason to try OpenVPN again. The bigger and more important difference between the two is that Wireguard is designed to work in stealth mode but OpenVPN is designed to be more helpful and retry failed connection attempts. Wireguard expects the client to supply the correct signature to create the connection over UDP and if the signature is correct a connection is established but if incorrect the packets are simply dropped, so any bot trying to guess the signature will just timeout without confirming there is a live service at the IP address. OpenVPN will also reject any failed connections but it will send a reply to the client offering to attempt another handshake, while that is fine for some networks with robust attack mitigation but we would prefer the more stealthy approach of Wireguard. It is not that the edge router is any worse than any other it is simply that the consumer grade internet connection will likely black box our current IP address if there are too many probes.


Installation of Wireguard

the installation will be in three parts, four if debug is taken as a part. The first Part is to install the and configure the server, Vanilla. This will be install the software, generate the keys and write the config file. The second part will be the client install and is much the same as the server, as the software needs to be installed, the keys must be generated and the config file need to be written. The third part is the iptables config and the final part is the testing and debugging.

Server Install on Vanilla

To install Wireguard on Vanilla do 

sudo apt update
sudo apt install wireguard wireguard-tools -y

wireguard-tools is a package containing additional utilities for managing WireGuard, such as wg and wg-quick. More details can be found on the Ubuntu website. Once the two packages are installed we need to generate the public and private keys. First we do the private key with the command 

sudo wg genkey | sudo tee /etc/wireguard/server-privatekey

What this does is to use wg with genkey to generate a new Wireguard private key that will be displayed on the screen. The pipe tee will copy it to the file /etc/wireguard/server-privatekey. We can use this private key to generate the public key to match using the command 

sudo cat /etc/wireguard/server-privatekey | wg pubkey | sudo tee /etc/wireguard/server-publickey

This will pipe the private key from the file we just made to wg pubkey to be displayed on screen by the pipe tee and ten copies it to the file /etc/wireguard/server-publickey. It would probably be best to check that these two key files can be accessed before clearing the screen so do 

sudo nano  /etc/wireguard/server-publickey

and a 

sudo nano  /etc/wireguard/server-privatekey

Just to be sure that both can be accessed. The private key must be kept private so do a chmod to make it accessible to root only 

sudo chmod 600 /etc/wireguard/server-privatekey

Now to view the file or even get a listing you have to do sudo. the public key will need to be exchanged with clients so no need to keep it private. Using our newly created keys we can create a wg0.conf file in the wireguard directory. 

sudo nano /etc/wireguard/wg0.conf

In this file we will need the following information 

 [Interface]
PrivateKey = <your_server_private_key_just_generated >
Address = 192.168.130.4/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o enp6s18 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o enp6s18 -j MASQUERADE

[Peer]
PublicKey = <client_public_key_1_not yet created>
AllowedIPs = 192.168.130.6/32

[Peer]
PublicKey = <client_public_key_2 also not yet created>
AllowedIPs = 192.168.130.7/32

In the interface section we will need to paste in the private key from /etc/wireguard/server-privatekey and we will need to sudo just to access it. the IP address for the interface needs to be different from the Vanilla interface so as vanilla is on 192.168.130.5 we add the wg0 interface as 192.168.130.4/24, if qemu-guest-agent is installed when Wireguard is up and running, it should be seen in the Proxmox GUI summary. If this was to be on a production environment we would possibly have this interface on a different IP domain with more hosts and with a DHCP server running but as we will only have a few clients we will use static IPs and use the same domain because we will never have enough clients to make static IPs unmanageable and we will probably never need to use scripts to configure clients. The listen port is the port that vanilla will be listening on for connections. The postup and postdown iptables are to allow forwarding and NAT, they are mostly boilerplate code. The first line, PostUp, is two commands separated by the semicolon 

iptables -A FORWARD -i %i -j ACCEPT
  • iptables is the command line tool for managing the Linux kernel firewall
  • -A FORWARD: Appends a rule to the FORWARD chain. The FORWARD chain handles traffic that is passing through the server, not traffic destined for the server itself.
  • -i %i: Specifies the input interface. %i is a placeholder that wg-quick replaces with the name of the WireGuard interface (in your case, wg0). So, this part of the rule says: "For any traffic coming into the server on the wg0 interface..."
  • -j ACCEPT: Specifies the action to take if a packet matches the rule. ACCEPT means to allow the packet to continue to its destination.
  • In essence, this part of the PostUp rule allows traffic originating from your WireGuard clients (coming in on the wg0 interface) to be forwarded to other interfaces on your server (like eth0 to reach your LAN or the internet).

After the semicolon the second part of the command is 

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  • iptables -t nat: Specifies that we are working with the nat table, which is used for Network Address Translation.
  • -A POSTROUTING: Appends a rule to the POSTROUTING chain. This chain is processed for packets that are about to leave the server.
  • -o enp6s18: Specifies the output interface. enp6s18 is the main interface for Vanilla. This part of the rule says: "For any traffic going out of the server on the enp6s18 interface..."
  • -j MASQUERADE: This is a form of NAT that dynamically translates the source IP address of packets leaving through enp6s18 to the IP address of enp6s18 . This is crucial for allowing VPN clients (on the 192.168.130.0/24 subnet in your setup) to access networks beyond the server, such as your LAN or the internet.

The PostDown line does the opposite of PostUp. It uses -D instead of -A to delete the iptables rules that were added when the wg0 interface was brought up. This ensures that when the WireGuard interface is shut down, the forwarding and NAT rules are also removed, which is good practice to avoid unintended routing or NAT behavior when the VPN is not active.


The two peer sections will need to have the public key from the clients to be added in when they have been done and the AllowedIPs will set the iP addresses of the clients (as in /32).

Next we have to enable ip forwarding on vanilla 

sudo nano /etc/sysctl.conf

search for the lines 

net.ipv4.ip_forward=1 # this probably exists but is commented out
net.ipv4.conf.all.forwarding=1
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.enp6s18.forwarding=1
net.ipv4.conf.wg0.forwarding=1

and add the or uncomment them, then save and exit. they can be applied immediately with 

sudo sysctl -p /etc/sysctl.conf

Next we can move on to the client install

Client Install on Grape

We install on Grape, the desktop PC to begin with and then repeat the step with the laptop Dragonfruit. First we need to download the client software the installer can be downloaded from https://www.wireguard.com/install. After installing Wireguard a key pair must be generated, as it is on a Windows 11 client open a powershell window as administrator and enter the two commands 

wg genkey | Out-File -Encoding ASCII client-privatekey.txt
(Get-Content -Path client-privatekey.txt -Raw) | wg pubkey | Out-File -Encoding ASCII client-publickey.txt

The first command uses wg with the genkey option to create a private key and pipe it to the file client-privatekey.txt. The second command gets the private key from the file and pipes it to wg and wg uses the option pubkey to generate a public key and the it is piped to the file client-publickey.txt. There should now be two files in the current directory (probably c:\windows\system32) the private key must be kept private as this is used to auth the public key that will be copied to vanilla. We now create a file called Grape-Vanilla.conf so we can import the config into the client. The file should have the following details. 

[Interface]
PrivateKey = <your_client_private_key>
Address = 192.168.131.6/32
DNS = 192.168.110.11

[Peer]
PublicKey = <your_server_public_key>
Endpoint = <ip or dns to the server>:<portnumer>
AllowedIPs = 192.168.111.0/24, 192.168.130.0/24, 192.168.110.11/32, 192.168.100.0/24
PersistentKeepalive = 25

The <your_client_private_key> will be from the private key just generated on grape. The address is the Ip address that will be issued to grape when the tunnel is active and the DNS is the address of ns1 on Proxmox that will be used for this connection. In the Peer section the <your_server_public_key> will be the public key from Vanilla. The endpoint will be the route and port to the server, this could be a DNS name or IP address of Pfsense as long as it will be a route to Vanilla. The allowed IPs are the addresses that the VPN client will have access to and be sure to include the DNS server (in this case the /32 will only give access to ns1).

We also need to copy the public key from Grape to the Peer entry on the wg0.conf on vanilla, copy the public key from grape and open the wg0.conf on vanilla 

sudo /etc/wireguard/wg0.conf

Then save and close. One of the Wireguard tools that was installed on Vanilla was wg-quick and it can bring up and close down wireguard, on Vanilla bring up the wireguard interface with: 

 sudo wg-quick up wg0

There should now be an interface appear in the Proxmox GUI summary page for vanilla. we can also activate the client on grape but unless the forwarding rule on Pfsense has been created if the client the latest handshake will never be filled in. So we need to login to Pfsense web GUI and go to Firewall-NAT and create a forwarding rule to forward UDP on the port number from the [Peer] section above to vanilla for all sources with a destination of "This Firewall (self)". When saved check in the Firewall->rules->wan that the pass rule has been added above the default deny any any because by default when a NAT forwarding rule is made the accompanying firewall rule is created at the bottom of the list. When the Pfsense forwarding rule is active the wireguard application on Grape should start showing numbers in the Transfer line and it should start showing a time in the Latest Handshake line, if these are not updating check the Pfsense NAT rule and see why the UDP packets are being blocked. Assuming the connection is made there should be a new interface called whatever the .conf was called (probably Grape-Vanilla) to easily check open a cmd window on grape and do an ipconfig /all and there should be another adapter listed with some comment about WireGuard tunnel, there should also be a new IP address 192.168.131.6 as listed on the interface section of the wireguard app on grape.

Other Configs and testing

Now that the interface is up on Grape and also on Vanilla we should be able to see latest handshake update, this shows that the connection is successfully made to Vanilla, if not check the Pfsense rules as that is the most likely block. We should be able to see the interface in the cmd window of Grape as a result of ipconfig /all. We should also see the interface is made on vanilla by the Proxmox summary page for Vanilla (it will probably be hidden by the more button). Alternatively, the command is 

ip link

There should be at least three interfaces shown, the loopback, the main NIC(enp6s18) for vanilla and the VPN interface (probably wg0 as it takes the filename and uses that as the interface name) . both interfaces must be up and there must be updates in the client to go any further.

We should be able to ping Vanilla's IP but not the DNS name and we will not be able to ping anything outside 192.168.130.0/24 because we need to add a static route to Pfsense to reach 192.168.131.0/24. The route to the other IP domains is effectively taken care of by Wireguard because routes in to Proxmox are specified in the Allowed IPs in the [peer] section of the client config and the routes will be set by vanilla. For example, the route from Grape to 192.168.100.10 will be from 192.168.131.6(Grape's VPN IP address) to 192.168.131.1(Vanilla on wg0) to 192.168.130.5 (Vanilla on enp6s18, it's main NIC) then as Vanilla has already got it's own default route set to Pfsense on 192.168.130.1 the route continues to Pfsense and on to the Pfsense NIC on 192.168.100.0/24 then to the final destination. Grape is able to use Vanilla's routes because the MASQUERADE directive in the wg0.conf hides all of the VPN clients' IPs so Pfsense will never see them, like a NAT. From Pfsense viewpoint anything coming out of the VPN is originating from Vanilla. The return route will be a different matter in that Pfsense has no clue as to how to route packets to 192.168.131.0/24 because that network is being masked by vanilla.

To add a static route from Pfsense to the VPN clients go to the Pfsense web GUI. First The gateway must be added, navigate to System->Routing->Gateways and click add button.

  • Interface is VPNNet
  • Name is Wireguard-Vanilla
  • Gateway is the IP of Vanilla
  • add a description and save

Apply the change. Go to System->Routing->Static Routes and click the add button.

  • Destination 192.168.131.0 /24
  • Gateway is the one just created Wireguard-Vanilla
  • Description is Route to WireGuard Clients

This static route is the final thing to complete to make the VPN work.

Some of the Potential Problems

Setting up Wireguard is quite straight forward, it is the bit around the setup that can be a source of frustration.

setting up iptables

IPtables can be used to accept or drop or forward packets. Unfortunately, these same rules can cause no end of problems. To help with the debug of them

  • To list iptables rules: iptables -L
  • To copy iptables rules to a file: iptables-save > filename.txt
  • To show routes: ip route
  • To set routes: ip route add [destination network/ip] via [gateway ip] dev [interface] for example To add a route to network 192.168.131.0/24 via the gateway 192.168.130.5 using the enp6s18 interface use the command ip route add 192.168.131.0/24 via 192.168.130.5 dev enp6s18
  • The file /etc/sysctl.conf controls how the kernal forwards traffic

Windows 11 using ns1 as Nameserver

Windows 11 does not automatically append the domain name to hostname lookups when there is no domain controller so when we want to ping walnut on the terminals windows will not find it unless we use the FQDM walnut.seaoffate.net. To enable the hostname lookups to succeed we have to "View network connections" in the start menu, open the network interface, then properties, and in the connection items find the TCP/IPv4 item and select Properties. Either type in the ip address or do the radio button to obtain IP address automatically and click Advanced. in the advanced settings select the DNS tab (if it says about the ip address being required it needs to have an ip address either as dhcp or as static to open DNS tab) Click the radio button Append these DNS suffixes (in order) and then click add to add the two domains seaoffate.net & seaoffate.local. we can clear the register this connection address in DNS but it will not matter if it is left in place. when finished click ok enough times to close all of the dialogues. Now close the wireguard connection and reopen it, this should clear any IP address that was added in to dialogs because wireguard will set them again as it re opens. Try ping ns1 in a cmd window and it should now resolve to ns1.seaoffate.net.


Installation of OpenVPN

I wanted to compare the two competing VPN solutions another VM was created call Voavanga on 192.168.130.4 (one number lower than than the Wireguard VPN server). I had heard that OpenVPN was more complicated to setup but had more options. Now that it is done I can confirm that it is indeed more complicated to setup but not by much. The host used in both is the same specifications and as there will not be a need to host many clients it does not need to be huge.

OpenVPN Disabled

Update, OpenVPN works and and does allow VPN connections to the network but it does not do the split DNS well in that windows does not fix the local DNS on the OpenVPN network interface. it is assumed that it would not be a problem if the entire internet was routed through the OpenVPN NIC. The other feature of OpenVPN is that it will always reply to connection requests with a handshake request and thus confirm that there is a live service at the public facing IP address regardless of whether the signature is valid. In view of these two features it has been decided to use Wireguard for remote access only and switch off Voavanga.

Setup The VPN Server

The setup is a bit different to Wireguard in that we have to generate our own SSL certs & keys. So we will need something to do generate them and we have chosen easyrsa. To start we need to do the standard update upgrade. 

sudo apt update
sudo apt upgrade -y

Then openvpn and Easy-RSA 

sudo apt install openvpn easy-rsa -y

Next we need to setup the SSL Certificate Authority 

mkdir ~/openvpn-ca
cd ~/openvpn-ca
./easyrsa init-pki
./easyrsa build-ca nopass

These commands create a directory for Easy-RSA, navigates into it, initializes the PKI, and builds the Certificate Authority. Next to generate the keys 

./easyrsa build-server-full server nopass ./easyrsa gen-dh

This generates the server certificate and private key, and the Diffie-Hellman parameters. 

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
sudo gzip -d /etc/openvpn/server.conf.gz
sudo nano /etc/openvpn/server.conf

Copies the sample server configuration file, unzips it, and opens it for editing. 

sudo cp ~/openvpn-ca/pki/ca.crt /etc/openvpn/ 
sudo cp ~/openvpn-ca/pki/issued/server.crt /etc/openvpn/ 
sudo cp ~/openvpn-ca/pki/private/server.key /etc/openvpn/ 
sudo cp ~/openvpn-ca/pki/dh.pem /etc/openvpn/dh.pem

Copies the necessary certificate and key files to the `/etc/openvpn/` directory. 

sudo nano /etc/sysctl.conf

Opens the system configuration file to enable IP forwarding much like we did with Wireguard

save and exit the apply the changes with 

sudo sysctl -p

Next we need to edit the firewall.

Then as a final step we eanble start and chec the satus of the OpenVPN service 

sudo systemctl enable openvpn@server
sudo systemctl start openvpn@server 
sudo systemctl status openvpn@server

Next we need to install the Client

Client install

client
dev tun
proto udp  # Or tcp, depending on your server config
remote walnut.seaoffate.net 1194  # Replace with the public IP or hostname of your Proxmox host
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert dragonfruit.crt
key dragonfruit.key
remote-cert-tls server
tls-client
cipher AES-256-CBC  # Match your server config
auth SHA256        # Match your server config
compress lz4-v2    # Match your server config
verb 3
Retrieved from "https://wiki.seaoffate.net/index.php?title=VPNserver&oldid=1163"