The simplest way to regain this redundancy is just to run 2 independent Pi-hole servers and set them as the primary and fallback DNS servers. However, this approach has a couple of disadvantages. The main problem is that we have no setting synchronisation between our servers. If we update the block lists on one, we have to remember to update them on the other. We also can’t guarantee which server clients will connect to, so if one is down, clients may still try to connect and then have to wait for a timeout before querying the second server. This can cause performance drops when one of the servers is offline.

Using failover to provide a highly available Pi-hole cluster

We can resolve these problems by linking our pair of Pi-hole servers into a unified failover cluster. The original idea for this came from u/Panja0 on Reddit. However, this approach doesn’t quite work on Pi-hole 5 and above as the way the data is saved changed. This article is therefore an updated version of that basic idea to remain compatible with the latest Pi-hole versions.

To accomplish our goal we need to solve 2 problems. Firstly, we need a way to keep the blocklists and settings in sync between the 2 Pi-hole servers. We then need a mechanism to monitor the servers and hand over the IP address if the primary fails. If you are unconcerned about DNS timeouts, you can skip the IP failover setup and just have 2 servers on their own IP addresses. For the greatest reliability, you will want to configure both stages.

What do we need?

You will need 2 Pi-hole servers, ideally updated to the latest version but anything greater than 5.0 should work. You can update an existing instance to the latest version by running sudo pihole updatePihole. Note that this will restart the DNS resolver. I will not cover how to set up a Pi-hole server as I have described it previously. This article is a few years old so you will probably want to use a more recent OS such as Ubuntu 20.04LTS but the installation process is more or less unchanged. For a more recent guide, you can look at this article or the Pi-hole documentation. I will assume the use of a Debian/Ubuntu based distro for this guide but it should be easily adaptable for CentOS.

You will also need a third IP address which will be shared between the 2 servers.

Synchronising Pi-hole blocklists

Pi-hole 5 no-longer stores the blocklists in plain text files. Instead they are stored in a SQLite database in /etc/pihole/gravity.db. This means we can’t use Panja0’s original method of using rsync to synchronise the list files. Instead, we use Michael Stanclift’s (vmstan on GitHub) gravity-sync script.

This script will synchronise blocklists, exclusions and local DNS records. It won’t synchronise admin passwords, upstream DNS servers, DHCP leases and statistics. We will therefore need to manually configure the admin password and upstream DNS servers to be the same on both servers. There isn’t a practical way to have DHCP on the Pi-hole so that will have to run on the router or some other device.

Preparing the Pi-hole servers

To begin with, ensure all dependencies are installed. Most will already be installed but if not, we can catch them by running:

apt update && apt install sqlite3 sudo git rsync ssh

On both servers, we will need a service account with sudo privileges. Create this account by running the following command on each server:

sudo useradd -G sudo -m pi
sudo passwd pi

On some distros (e.g. CentOS), the privileged group is called wheel instead of sudo so you may need to adjust this command.

Install Gravity-Sync on the primary Pi-hole

Pick one of the servers to act as the primary and log in to it as the pi user account. Run the installer script:

export GS_INSTALL=primary && curl -sSL https://gravity.vmstan.com/ | bash

Install Gravity-Sync on the secondary Pi-hole

Log in to the other server as the pi account and run:

export GS_INSTALL=secondary && curl -sSL https://gravity.vmstan.com/ | bash

While the installer on the primary just verifies pre-requisites, the secondary needs additional configuration as it performs the active role of replication. When prompted, provide the name of the service account on the primary, the IP address of the primary and configure password-less SSH login.

Verify connectivity and enable synchronisation

On the secondary Pi-hole, navigate in to the gravity-sync directory and run:

./gravity-sync.sh compare

This should give you output similar to the below. It will not actually perform a sync but will verify connectivity and detect if a sync is required.

If the primary already has configuration but the secondary is a fresh install you will want to ensure that the first sync is a one-way sync from the primary to the secondary. If you don’t do this, the script may detect the configuration on the secondary as newer and overwrite the primary. To force a one way sync, run:

./gravity-sync.sh pull

Finally, enable automatic synchronisation by running:

./gravity-sync.sh automate

Set an update frequency from the available options. Setting a lower frequency will increase the risk of changes not syncing but will result in reduced server load so may be more appropriate on busy servers.

Synchronisation should now be working, if you do not want to configure IP failover the setup is now complete. If you have additional servers you want to keep in sync, use the steps for adding a secondary server.

Configure IP failover

Now our Pi-hole instances are in sync, we can configure IP failover to direct traffic towards the primary when it is available and switch over to the secondary if the primary ever fails. On both servers, install the required packages:

sudo apt install keepalived libipset13 -y

Next, we need to download a script on both servers to monitor the status of the pihole-FTL service so we can fail over if it ever stops running:

sudo mkdir /etc/scripts
sudo sh -c "curl https://pastebin.com/raw/npw6tcuk | tr -d '\r' > /etc/scripts/chk_ftl"
sudo chmod +x /etc/scripts/chk_ftl

Now, we need to add our keepalived configuration. On the primary, run:

sudo curl https://pastebin.com/raw/nsBnkShi -o /etc/keepalived/keepalived.conf

and on the secondary:

sudo curl https://pastebin.com/raw/HbdsUc07 -o /etc/keepalived/keepalived.conf

We now need to edit the configuration on both servers. On each server, set the following properties:

We are now ready to start and enable keepalived. On both servers, run:

systemctl enable --now keepalived.service
systemctl status keepalived.service

You should see a status of active. If you don’t see this, you most likely have an error in your config and the status message should give you a hint as to where it is. Additionally, on the primary server, you should see that it has placed itself into the master role.

Testing Pi-hole failover

You should now be able to reach the Pi-hole interface on the virtual IP we configured previously (e.g. http://192.168.1.20/admin). In the top right corner of the interface it will show the hostname and you should see that it is the primary server. To check that failover is working, shut down the primary server. If you reload the page you should see that the hostname in the top right has changed to the name of the secondary.

You can also test DNS requests using nslookup. The following script will make a DNS lookup every second, allowing you to verify that you receive responses even if the primary is offline:

while true; do
nslookup davidshomelab.com [virtual IP of Pi-hole cluster]
sleep 1
done

If you shut down pihole1 while this script is running you should see that DNS lookups are not interrupted. There may be a brief moment of interruption at the exact moment that the failover occurs but it should resume within around a second.

The post Pi-hole failover using Gravity Sync and Keepalived appeared first on David's Homelab.

Many larger homes end up using multiple separate access points with a mix of repeaters. This results in a confusing mix of networks with devices connecting to a sub-optimal AP, causing weak signal. UniFi resolves this by managing all access points from a central controller and treating them as a single network. This saves you having to join your devices to several different networks and allows the APs to intelligently hand devices off to each other as you roam around the house. This ensues that you are always communicating with the AP that has the strongest signal.

UniFi can act solely as an access point without performing NAT. This means that unlike mesh WiFi systems which are traditionally used to expand coverage in a home setting, you shouldn’t run in to communications issues between wireless and wired devices in your home.

Why not another product?

While there are plenty of other good products on the market, there are several reasons why UniFi is a strong contender. When compared to other commercial solutions, UniFi hardware is priced very reasonably and is widely available from consumer outlets. This means you don’t need to procure hardware through trade-specific distribution networks. One other advantage is the simplicity of setting up devices. Once you have the controller set up, you can add new devices by adding them to the network. They will appear in the dashboard and can you can easily configure them in just a few clicks.

For me, the flexibility around the controller software is the key selling point. Some providers require you to buy an expensive hardware controller in addition to the APs. Other systems can only be managed from the cloud which some people may view as a security risk. The UniFi controller can instead be installed on any Windows, Mac or Ubuntu PC (or VM), allowing you to run it on hardware you already have. That’s not to say that you can’t run it in the cloud or have a dedicated controller. UniFi provide various models of CloudKey(paid link) for users who wish to avoid the effort of building their own controller. The basic model will be sufficient for any home or office with fewer than a couple of dozen managed devices. Additionally, while not owned by UniFi, the HostiFi company offers cloud hosted controllers requiring no on-premisies management hardware.

Setting up the UniFi controller on Ubuntu

While the controller software can be installed on any PC, a dedicated server will simplify management. Windows and Ubuntu are both supported but Ubuntu is preferred due to its lack of licensing costs and smaller footprint. The instructions provided here are for Ubuntu Server 20.04. While an LTS version of Ubuntu Server is preferred, any recent version of Ubuntu Server or Desktop can be used.

The system requirements depend on the number of managed devices but 1 CPU core, 2GB of RAM and 25GB of storage should be enough in most cases. The UniFi controller software isn’t in the main Ubuntu repos so we need to add the correct repo. We must also install the GPG keys so the repo is trusted:

echo 'deb https://www.ui.com/downloads/unifi/debian stable ubiquiti' | sudo tee /etc/apt/sources.list.d/100-ubnt-unifi.list
sudo wget -O /etc/apt/trusted.gpg.d/unifi-repo.gpg https://dl.ui.com/unifi/unifi-repo.gpg 

Next, update the apt cache and install the UniFi controller along with its prerequisites:

sudo apt update && sudo apt install ca-certificates openjdk-8-jdk apt-transport-https unifi -y

Once the install is finished, check that the service is running:

systemctl status unifi.service

If the service shows as failed or not running, restart the service with:

sudo systemctl restart unifi.service

Configuring the UniFi controller

Check the status again and verify that the service is running. Once everything is up and running, open a web browser and go to https://[server&/#8217;s IP address]:8443. You will need to accept the self-signed certificate warning.

Next, chose a name for your controller and accept the terms and conditions.

On the next screen, sign in with your UniFi account. If you want to be able to access your controller through Unifi’s cloud enter your login details here.

If you want to keep your controller local to your network, set up a local account, click “Switch to Advanced Setup”. Uncheck both checkboxes and set up a local username and password.

On the next screen, leave auto backup and network optimisation enabled.

Installing on an Ubuntu server is one of the simplest and cheapest ways to deploy the UniFi controller.

If you already have your devices, you can now choose to set them up. If you are just setting up the controller in preparation for receiving the devices, you can add them later.

Enter a WiFi network name and password. If you plan to have multiple SSIDs you can add the rest later, just enter your primary one here.

Finally, confirm your settings and set your location and time zone.

The wizard will redirect you to the main dashboard and your network will be set up.

There is plenty more you can do with UniFi hardware such as having multiple SSIDs on separate vlans, captive portal and MAC address based vlan assignments. Come back soon for more guides.

The post UniFi Controller Setup on Ubuntu 20.04LTS appeared first on David's Homelab.

Install the Zabbix Proxy plug-in

In the pfSense management console, go to System > Package Manager > Available Packages and search for “zabbix-proxy”. You will see multiple different versions. Unlike the agent, the proxy must be the same version as the server so select the appropriate one for your server. In this case we will install zabbix-proxy5.

Connect the proxy to the server

In the pfSense console go to Services > Zabbix Proxy 5.0 and configure the proxy. Set the server to the IP address or hostname of the Zabbix server and the hostname to whatever you will call the proxy within the Zabbix console. The other options can be left as default but can be modified if desired. For example, if you only want the proxy to listen on one interface, set the listen IP to the pfSense IP address for the interface you want to listen on. If you have a large number of proxies you can increase this value to reduce load on the server but doing so will increase the propagation time for any changes you make to your setup.

While testing or for small deployments you may wish to lower the config frequency from the default of 1 hour. This value determines how often the proxy will contact the server to get the current configuration, including the hosts to monitor and the data it is supposed to collect.

Finally, enable the service and save the settings.

Now the proxy is configured it is time to tell the server where to find it. From the Zabbix console, go to Administration > Proxies. Click “Create proxy” to add the new proxy. Enter the name (this is the hostname you configured in the proxy) and the IP address of the proxy.

Once you have added the proxy, reload the page and check that the proxy shows up in the list and it has a “last seen” value. If all is well and the listing shows something similar to the below, the proxy is set up and we are ready to configure hosts to talk to it.

Configure the proxy to monitor hosts

Configuring an agent to use a proxy is very similar to configuring it to talk to the server directly. For this example I will modify the CentOS host described in my post on configuring Zabbix agents to get it to talk via the proxy.

Log in to the server and open /etc/zabbix/zabbix_agent.conf. Edit the Server and ServerActive values to the IP address or hostname of the Zabbix proxy and save and close the file. Restart the Zabbix agent:

systemctl restart zabbix-agent.service

Now log in to the Zabbix console and go to Configuration > Hosts and select the host you want to monitor via the proxy. In the host settings, click the drop-down next to “Monitored by proxy” and select the proxy you have configured the host to talk to. Click “Update” to save your settings.

When you return to the hosts list you will probably see that the host appears to be offline. This is because the proxy will not find out that it is meant to be monitoring the host until the next time it syncs its settings with the server. If you have set a reasonable update frequency you will just need to wait for that period of time and it should start to appear and collect data automatically.

If you need to force the proxy to update immediately, log in to pfSense and go to Status > Services and restart the zabbix_proxy service. When the service starts up this will force a config sync and you should see the host come online within a couple of seconds after the service restarts.

The post Install Zabbix Proxy on pfSense to Monitor Hosts in Remote Sites appeared first on David's Homelab.

For this example, I have a pfSense firewall with a WAN IP address of 10.100.4.48 and will be forwarding traffic on TCP port 80 to a web server inside the LAN with an IP address of 192.168.1.10. This process can be used to forward any port or protocol supported by pfSense but in most cases you will just want to forward specific UDP or TCP ports.

Limitations of port forwarding

While port forwarding is a useful tool to expose a small number of services, you can only forward a port to a single host so if you have two web servers and you want them both to listen on port 443 you will not be able to use port forwarding and will need to use a reverse proxy. You will also need at least one public IP address. A lot of home ISPs use Carrier Grade NAT to work around the shortage of IPv4 addresses, meaning that a single public IP address is shared between multiple customers. In this setup neither port forwarding nor reverse proxy can be used.

Creating the port forwarding rule

From the pfSense console, open Firewall > NAT. As we just want to forward a specific port, we stay in the Port Forward tab and click the Add button to create a new NAT rule. As this is our first rule it doesn’t matter whether we add it to the top or bottom of the list but if you have multiple rules set to apply to different source IP addresses, bear in mind that the rules are evaluated from top to bottom so order them appropriately.

In the settings for our policy, leave the interface set to WAN and the protocol set to TCP as this is a web server. If you are planning to expose a UDP service like WireGuard then set the protocol to UDP instead.

If you only have a single public IP address, you will leave the Destination as WAN Address. This will be the address that clients connect to so if you have multiple public IP addresses you could set this to be a secondary IP address.

We now need to set the destination port that clients will connect to. In this case we will pick port 80 so clients won’t need to specify the port number.

Configure the host and port to redirect to. This will be the server IP address and port, in this case 192.168.1.10 on port 80.

Scroll to the bottom and save the rule. Verify that the rule looks correct and click “Apply Changes”.

You will now need to test the port forwarding rule. Connect to a different network such as a mobile hostspot and browse to your router’s public IP address. If everything is working, you should see the redirected web page, in this case the Apache default web page but if you already have a service set up, you should see that page instead.

If your WAN IP address is static, you are done at this point but if, like most home internet connections, you have a dynamic IP address, you will want to configure dynamic DNS to make sure you don’t lose access if your WAN IP address changes.

Dynamic DNS configuration

Dynamic DNS is a service by which the pfSense can detect that its IP address has changed and send a notification to the Dynamic DNS provider to update the DNS record. pfSense supports a lot of Dynamic DNS services, some are free, others require subscriptions. For this example I will use no-ip but if you already have an account with another supported service you can use that instead.

Go to https://www.noip.com/, select the domain name and suffix you want and click Sign Up.

Set your email address and password on the signup page and click “Free Sign Up”. You’ll need to activate your account by clicking the link they will email to you. Then you can configure the account in pfSense. Go to Services > Dynamic DNS in the pfSense web interface and click the Add button to add a Dynamic DNS client.

Enter the Dynamic DNS provider, the configured hostname and your login credentials. Some providers use API tokens instead of usernames and passwords so if using a different provider, check the notes on the screen to work out what details you need to enter.

Scroll to the bottom and click “Save”. You should see the cached IP matching your current public IP address and showing in green.

As before, connect to a different network and check you can access your web service using the hostname you have configured. Now if your public IP address changes, pfSense will automatically update the DNS record so the hostname will still work.

The post Publish Internal Web Services to the Internet with pfSense Port Forwarding and Dynamic DNS appeared first on David's Homelab.

pfSense provides a package called pfBlockerNG which allows for advanced and dynamically updating blocking rules based on blocklists or GeoIP data. It also supports DNS blocking so can fully replace Pi-hole if you choose to enable this feature.

Installing pfBlockerNG

From your pfSense admin interface, go to System > Package Manager > Available Packages and search for “pfBlockerNG”. Install the development version (pfBlockerNG-devel) as it is just as stable and has newer features including the ability to choose from pre-selected blocklists.

Once the package is installed, you will see an entry for pfBlockerNG in the Firewall menu at the top of the page. This is where we will configure the blocking settings.

When you first open pfBlockerNG, you will be taken to a setup wizard which will give you a basic configuration. Following the steps in the wizard will give you a basic configuration, blocking outbound access to a small number of known malicious IPs and adding some basic DNS blocklists. Click “Next” to begin the wizard and accept the warning that completion of the wizard will wipe all settings. In this case we have not configured anything so it doesn’t matter but bear that in mind if you try to run it again once everything is set up.

Tell pfBlocker which interfaces are inbound and which are outbound and click “Next”. Normally your WAN interface will be inbound and LAN will be outbound but if you have multiple interfaces configured you may wish to select more than one for each of these sections. This can be done by holding down the Ctrl key while clicking on the interfaces you wish to add. If you want to exempt an interface from blocking, don’t identify it as either inbound or outbound.

You will next need to configure the web server for DNS blocking, this is the page that you will be redirected to when you try to access a blocked page. Most likely you can leave the default settings in place but if the IP address or ports are already in use on your network change them to something else.

On the final screen, click “Finish” to apply the configuration.

Managing Blocklists

From the pfBlockerNG interface, select the Feeds tab. You’ll see the list of predefined feeds. These are publicly available blocklists that pfBlockerNG is configured to periodically synchronise with. Based on the default settings in the wizard, you will see that almost all of the blocklists in the PRI1 group are enabled. These have fairly broad coverage but aim to avoid false positives so there is a higher chance they will miss genuine threats. You can also choose to enable additional blocklists by clicking the + icon on the right of the relevant line or enable an entire group by clicking the + icon for that group. There are several general groups that can also be enabled, these are PRI2-5. Generally speaking, the lower the number, the more it tries to avoid false positives so if you enable the more restrictive lists (PRI3 and above), be prepared for some sites to break which will require some troubleshooting and possibly whitelisting of the false positives. You can also find groups aimed at blocking specific types of malicious or undesirable traffic such as email or forum spam or Tor nodes. The feeds also contain similar lists for IPv6 although these are less extensive as there is generally less IPv6 traffic and DNS blocklists, all can be enabled in the same way.

As an example, I will enable blocklists in the PRI3 group. Scroll down to the group header and click the + icon next to the group name.

You will then be taken to the settings page to add the rule. By default the list is added in a disabled state and all the feeds that are part of it are also disabled so some configuration is needed. Set the name and description of the list if you like or just leave the defaults set. You’ll also need to decide which of the blocklists to enable. From the drop-down, select which option you want for each list. In most cases you will choose either “OFF” if you don’t want to use the list or “ON” if you do. You can also select “HOLD” if you want to download the list once but exclude it from automatic updates. If you want to enable everything, click the “Enable All” button at the bottom of the list. In this case I will enable all of them apart from Shunlist as this is a premium list which requires an API key to use.

Next, scroll down to the Settings section and choose the action you want to take when an IP address is matched. You can choose to permit, deny or match and also whether the rule is matched for inbound or outbound traffic. Most likely you will want to apply the rule to both inbound and outbound connections. You will also want to consider whether you want to immediately start blocking traffic or you just want to match the traffic in your logs for a while before enabling blocking. For this example we will immediately start blocking both inbound and outbound. We will also keep logging enabled to make troubleshooting easier although on busier networks you may wish to disable this to reduce disk activity and improve performance.

Scroll to the bottom of the page and click “Save IPv4 Settings” to apply the changes.

This process is the same for IPv6 and DNS blocklists, just add the alias group, select the lists you want to enable and choose the action to be taken when an item is matched.

GeoIP Blocking

GeoIP data can be useful to allow blocking of specific regions. This will not be useful in all situations as obviously not all regions are entirely malicious. However, if all your expected traffic comes from specific geographic reasons there is no point allowing traffic from other regions as this exposes additional risk with no real benefit. In most cases you will only want to block inbound access based on GeoIP data, this will allow internal users to access sites all over the world but block inbound access from regions you do not expect traffic from.

GeoIP blocking relies on the MaxMind GeoIP database. While the database is free to use, it does require a MaxMind account and an API key. Go to the MaxMind sign-up page and create an account. Once you have your API key, go to the IP section of the pfBlockerNG menu and enter the license key. Save the settings to enable access to the GeoIP database.

Now go to the GeoIP tab and select the blocking rules you want to enable. In this example, I will block all traffic from all regions except Europe. This means that I will be able to access my internet exposed resources from Europe but they won’t be accessible from any other region. Obviously this is a very broad brush approach and should not be your only line of defence but may be a useful way of blocking traffic from regions where you never expect legitimate traffic to originate. It will not be appropriate if you are expecting worldwide access to the network (for example, if you are running a website or exposing internal resources for a company with a worldwide presence.)

DNS Blocking

Most of the work to enable DNS blocking is already done, we’ve already configured some basic blocklists and I have described the process of adding additional ones. You’ll just need to make sure that your devices are configured to use pfSense as their DNS server. If you are using a standard pfSense configuration then this will already be set but if you have configured an alternative DNS server such as a Pi-hole you will need to check the DNS configuration on pfSense and tell client devices to use it. Go to Services > DNS Resolver > General Settings and check that the DNS resolver is enabled.

Now go to System > General Setup and check that external DNS resolvers are configured as these will be required to forward DNS requests that aren’t blocked. If you have another internal DNS server configured such as a FreeIPA server, use that as the upstream resolver, if not, use a public DNS provider such as Google DNS.

Finally, go to Services > DHCP Server and select all the interfaces for which you want to enable blocking and check that nothing is listed under DNS servers.

If you have configured static DNS on any servers you will need to update them manually, set them to pfSense’s IP address.

Troubleshooting

While you shouldn’t see too many issues as long as you don’t get too adventurous with your block lists, situations may arise where legitimate services get blocked. Sometimes this is genuinely a false positive but it may also be an indicator that a legitimate site has been hacked and is currently sending malicious traffic so care should always be taken before whitelisting. As the blocklists are updated fairly often, these issues can often be transient but if you do ever need to whitelist something, go to Firewall > pfBlockerNG > Reports > Alerts. Look in the list of recent blocks and click the + icon next to the offending item to create a whitelist entry for it.

The post Block Malicious IPs in pfSense appeared first on David's Homelab.

Configure your server

FreeIPA server can be installed on the same distros that the client can be installed on, these are CentOS, RHEL, Fedora, Debian and Ubuntu. For this tutorial I will be using CentOS 8. It is not recommended to run any other software on a FreeIPA server so you should spin up a fresh VM to dedicate to this task. You’ll need to provision at least 4GB of RAM for the installer to succeed although this can usually be lowered to about 2GB after installation is complete unless this is a large deployment where the server is expected to be handling a large number of requests.

Preparation

To begin with you will need to choose a domain name. Take some care over choosing this as it will not be possible to change it later. If you own a domain name you can use a subdomain of that or if you’d prefer to make up a name use a non existent tld such as .lan. I’ll use internal.davidshomelab.com in my example so substitute references to it for your chosen domain name. Once you have chosen the name, append it to the hostname of your server using the hostnamectl command:

hostnamectl set-hostname ipa1.internal.davidshomelab.com

We will also need to set a static IP address for our server to allow the clients to find it. This can be done either by setting a static lease in DHCP or manually setting a static IP in the server. To set a static IP using nmcli on the server run the following commands:

nmcli con show

This will return a list of connection profiles and the interfaces they are assigned to. In my case, the connection profile is called “System \ eth0”. Once you know which connection you wish to modify run the following commands to disable DHCP, set a static IP, set a default gateway and configure DNS:

nmcli con mod System\ eth0 ipv4.address 172.16.24.5/24 (change this to the actual IP you plan to use)
nmcli con mod System\ eth0 ipv4.gateway 172.16.24.1 (change this to your actual default gateway)
nmcli con mod System\ eth0 ipv4.dns 8.8.8.8
nmcli con mod System\ eth0 ipv4.method manual
nmcli con up System\ eth0

The IPA server installer will expect to be able to resolve this name before you have configured the server to be a DNS server so make an entry for it in /etc/hosts in the following format:

172.16.24.5    ipa1.internal.davidhshomelab.com    ipa1

Install the FreeIPA server package

Unlike previous versions of CentOS, installing FreeIPA on CentOS 8 requires enabling the idm AppStream module to access all the packages we will need. Do this by running the following command:

yum install @idm:DL1

Now install the freeipa-server packages. The DNS and Bind packages are not strictly necessary and can be omitted if you don’t want to use integrated DNS. However, FreeIPA depends heavily on DNS for its operation so not doing this will result in a lot of manual DNS updates in a separate server to keep everything working correctly.

yum install freeipa-server ipa-server-dns bind-dyndb-ldap

Once all the packages are installed, run the setup utility. There are several options you can pass to to the utility via the command line but you will be prompted for any options that are required but you have not specified. The only command we will pass is the one to configure FreeIPA as a DNS server:

ipa-server-install --setup-dns

The setup utility will then prompt you for the information it needs to configure FreeIPA. If there is a default option it will be shown at the end of the prompt in square brackets. If you are happy with this default you can just hit return without typing it out. The prompts are as follows:

You should now see output similar to the below. Check the details are all as you expected and then type “yes” and hit return to begin the configuration.

The IPA Master Server will be configured with:
Hostname:       ipa1.internal.davidshomelab.com
IP address(es): 172.16.24.5
Domain name:    internal.davidshomelab.com
Realm name:     INTERNAL.DAVIDSHOMELAB.COM
The CA will be configured with:
Subject DN:   CN=Certificate Authority,O=INTERNAL.DAVIDSHOMELAB.COM
Subject base: O=INTERNAL.DAVIDSHOMELAB.COM
Chaining:     self-signed
BIND DNS server will be configured to serve IPA domain with:
Forwarders:       8.8.8.8
Forward policy:   only
Reverse zone(s):  24.16.172.in-addr.arpa.
NTP pool:       pool.ntp.org
Continue to configure the system with these values? [no]: 

The script will then set up your server using the information you have given. It can take a little while to set up so take a break for a while and come back later. If the installation fails you will need to uninstall the already configured components before you will be allowed to start again. If this happens, fix whatever the issue was and run the following commands to restart the installation:

ipa-server-install --uninstall
ipa-server-install --setup-dns

Once the install is completed, run the following commands to open the required ports in the firewall:

firewall-cmd --add-service=http --add-service=https --add-service=ldap --add-service=ldaps --add-service=kerberos --add-service=dns --add-service=ntp --add-service=kpasswd --permanent
firewall-cmd --reload

Go to the server’s IP address in a web browser and accept the certificate warning. Log in with the username “admin” and the password we set previously. If all is well, you should see something like the screenshot below. We see we currently only have the single default admin account but we have menus to manage users, hosts, groups etc.

Add a user

In most cases you will not want to use the built in admin user for daily use so let’s go ahead and create a separate user account. Click the “Add” button to add a new user. Set a login name, a full name and a password. If not specified, the Class and GID fields will be filled automatically. Once the user is added you can click on their username in the list to edit more detailed settings such as their address and contact details

One setting you will probably wish to amend is to make your user a member of the “admins” group. This will give you permission to add PCs to the domain and make changes to FreeIPA without needing to be logged in as the admin user. To do this go to User Groups, click Add and move admins from “available” to “prospective”. Click Add to confirm the changes.

You will probably want some users to have sudo permissions on client hosts. To do this, go to Policy > Sudo > Sudo Rules and click Add. The sudo policy settings gives a lot of flexibility in terms of allowing users sudo access to specific hosts, to run specific commands or to impersonate specific uses. However, for the sake of simplicity we will give ourselves full administrative rights over all hosts in the domain. Accordingly, we will name our policy something descriptive like “Full Sudo Access”. Once in the policy editor change the following settings:

Once you have configured the policy to your liking, scroll back to the top and click “Save” to apply it. Repeat the process to create as many users and access policies as you need.

Finally, check your user creation has worked by logging in to the server as your new user and running the following command:

sudo -i

If the username in the prompt changes to “root” after doing this and entering your password then you know that the account creation and sudo policy have worked and you are ready to begin adding hosts to your domain.

Adding clients

Before we add a client we will need to make sure it is using our FreeIPA server as its DNS server. This can be done either by setting a static DNS server on the host or by editing the DHCP settings for our network. However you choose to do it, ensure that the host can resolve the domain name of the FreeIPA server before proceeding. You can do this using nslookup, ping or attempting to log in via SSH.

Install FreeIPA client software

As with the server, I will be installing on CentOS 8 but any RHEL or Debian derived distro will follow roughly the same process. As FreeIPA will automatically detect the domain settings based on the system hostname convert the hostname to a fully qualified domain name using the following command with adjustments for the hostname of the client and the domain name you have chosen:

hostnamectl set-hostname ipaclient1.internal.davidshomelab.com

Install the client software by running the following command:

yum install freeipa-client

As with the server packages this will pull in a lot of packages and will take some time to install. Once it is complete we are ready to join the host to the domain by running:

ipa-client-install --mkhomedir

By appending –mkhomedir to the command, we tell FreeIPA to automatically create a home directory for users when they log in to the server. Do not select this option if you want to mount remote home directories from an NFS server. I’ll save instructions on that for a future article but if you want to try it, you’ll want to be looking for Automount in the Network Services section of the control panel.

If you get a prompt saying discovery was successful then it shows your DNS is set up correctly. If not, double check you can ping the IPA server and try again. Say yes to configuring Chrony with the server’s pool address. This is optional but will help to ensure time stays in sync. Enter the pool address we set for the server. In this case, pool.ntp.org. You will then be presented with a summary of the settings and asked if you wish to proceed. If they all look correct, type “yes” and hit return.

You will then be asked to enter the credentials of a user authorised to add computers to the domain. If you set your user to be a FreeIPA admin you can use your own credentials. If not, use the built in admin account.

The script will show output similar to the following while it is running and will hopefully say the installation was successful at the bottom:

Successfully retrieved CA cert
    Subject:     CN=Certificate Authority,O=INTERNAL.DAVIDSHOMELAB.COM
    Issuer:      CN=Certificate Authority,O=INTERNAL.DAVIDSHOMELAB.COM
    Valid From:  2020-03-08 23:06:58
    Valid Until: 2040-03-08 23:06:58
Enrolled in IPA realm INTERNAL.DAVIDSHOMELAB.COM
Created /etc/ipa/default.conf
Configured sudoers in /etc/authselect/user-nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm INTERNAL.DAVIDSHOMELAB.COM
Systemwide CA database updated.
Hostname (ipaclient1.internal.davidshomelab.com) does not have A/AAAA record.
Missing reverse record(s) for address(es): 172.16.24.51.
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring internal.davidshomelab.com as NIS domain.
Client configuration complete.
The ipa-client-install command was successful

You can now check you can log in as a domain user to the host and add any other hosts you need to add. Of course there is much more you can do with FreeIPA such as adding users and hosts to groups and creating policies to apply to those groups, configuring automatic mounting of NFS shares and issuing certificates to authenticate internal resources. Come back for future articles on how to do these.

The post Manage Users and Permissions Across Multiple Linux Hosts appeared first on David's Homelab.

Should I use client certificates?

For the best security you should use client certificates. The main drawback, particularly for enterprise deployments is distributing the certificates as they have to be generated on the firewall and then passed to the client device. As the certificates are owned by the user, not by the device, it is not enough to configure the VPN on a device and then allow any user to log in with their credentials to access the VPN, the certificate will need to be added for each user account wishing to access the VPN from a given device. pfSense has tools to make this deployment a bit easier but the level of administrative overhead will still be the main consideration in deciding whether to use client certificates. For this guide I will describe the steps required to set up OpenVPN with client certificates but will mention when a step needs to be modified or omitted if you choose not to use them.

Configure OpenVPN Server

Create a Certificate Authority

As OpenVPN is based around OpenSSL, it requires at least the server to have a certificate. If you are planning to use client certificates you will need a CA to issue them. From the pfSense dashboard, go to System > Cert. Manager > CAs and click Add to create a new CA. Enter a descriptive name to help you identify what the CA is called and a common name which will appear on the certificates. The rest of the settings can be adjusted if required but the defaults should provide a reasonable balance between security and performance for most use cases. By default the CA lifetime is set to 3650 days (10 years) which is reasonable for a CA but can be adjusted if desired. If you wish you can also include location and organisation data but this is entirely optional.

Once you save, you should see your OpenVPN Client Access CA in your list of Certificate Authorities, you can now use this CA to sign the certificate we will use for our OpenVPN server. From the Cert. Manager screen, go to Certificates and click Add/Sign. You will now need to provide a descriptive name for your certificate, provide a common name for the certificate and change the Certificate Type to Server Certificate. All other values are optional. The common name should be the public (WAN) IP address of your firewall or, if you have a DNS record pointing at that IP, you can use that as well. This name must match up with the host identifier that clients will use to connect in otherwise you will get warnings about certificate errors. If you would like the certificate to work for multiple domain names or for either the domain name or IP address, you can add other Alternative names at the bottom of the page. If the user accesses the VPN via any of the specified names they will be treated as equivalent to using the common name.

Install Client Export package

pfSense provides a package called openvpn-client-export which creates preconfigured OpenVPN profiles for you to download containing all the VPN settings and the user certificate if one is used. For Windows users it also allows you to download an OpenVPN client installer which will automatically install the OpenVPN client application and configure it with the VPN settings. This step is optional as you could configure the client settings manually but in most cases, doing it will simplify deployment.

From the pfSense dashboard go to System > Package Manager > Available Packages and search for the openvpn-client-export package. Click the Install button to install it.

Configure the VPN server

Go to VPN > OpenVPN > Servers and click Add. On this page we will set all the settings for the server side of the OpenVPN connection. The page is broken down in to several sections and the following subheadings describe the options in each section.

General Information

The only required change in this section is to change the Server Mode to one of the Remote Access options. I will use Remote Access SSL/TLS + User Auth but if you do not plan to use client certificates you can just stick with User Auth. The settings on this page will be the same whichever option you choose. The other setting you may wish to change is the listening port. By default OpenVPN listens on port 1194 in either UDP or TCP mode. You can change the port if you wish, either based on personal preference or if you are on a network which blocks VPN traffic or outbound ports. In these cases you may wish to use a port which is almost never blocked such as 53/UDP (DNS), 123/UDP (NTP) or 443/TCP (HTTPS) as these ports are almost never blocked. That said, you should use UDP if you can due to an issue called TCP Meltdown which can occur when tunnelling a TCP connection over another TCP connection. The issue occurs when one TCP connection detects an issue in the connection and compensates either by resending a packet or re-routing. As this then introduces an unexpected delay in the traffic it can then cause the other TCP connection to detect an issue and also attempt to retransmit packets which is then detected as a fault by the underlying connection and so on. This significantly reduces the performance of the tunnel and should be used as a last resort in situations where no UDP ports can be used. Finally, you should set a descriptive name so you can identify the VPN tunnel later. This is particularly useful if you have multiple tunnels configured.

Cryptographic Settings

Most of these settings can be left as default for a typical setup. The only one which needs to be changed is the Server Certificate. Use the one we configured previously. Additionally you may wish to not use a TLS key. The TLS key is a shared key used to authenticate control packets, meaning unauthenticated packets can be immediately dropped. If you are using the client export package you have no reason to disable this but if you want to configure the clients manually this may become an additional administrative complication that you might not want. Finally, if your hardware supports it, enable hardware crypto acceleration to speed up the VPN and reduce load on your CPU

Tunnel Settings

Here we define the network configuration for the traffic inside the tunnel. Our only required settings are the IPv4 Tunnel network and IPv4 Local Network(s). The IPv6 tunnel network and IPv6 Local Network(s) are also required if we want to send IPv6 traffic across the tunnel but these are not covered here. The tunnel network is the network that the members of the tunnel will use. The first usable address in the range will be used by the server and any other addresses will be available to be handed out to clients. The tunnel network will need to be in a private address range and it must be a range that is not used by other networks that the firewall has access to as this would cause routing conflicts. It is also advisable to not use a common range such as 192.168.0.0 as this is likely to cause conflicts on the client side if you are connecting in from networks which may use this range. We will use the range 172.16.45.0/24 in this example.

The IPv4 Local Networks are networks that pfSense has access to which you would like to make available to devices on the VPN. In most cases this will be your LAN but if you have multiple interfaces configured on your pfSense you may want to expose some or all of these over the VPN tunnel. You can use commas to separate multiple local networks.

You may also want to optionally use the gateway redirection settings to force all traffic to go through the VPN, not just the traffic destined for your LAN. This may be useful when you are using untrusted public WiFi to ensure all your traffic goes through your home or office internet connection.

Client settings

Most client settings can be left at their default values for most configurations. If you are running your own DNS internally, whether on pfSense itself or on another DNS server on your network, you will probably want to push this DNS server to your clients so they can access internal resources using domain names instead of IP addresses. For Windows networks you may also want to enable the settings to block DNS leakage, force update the DNS cache and enable NetBIOS over the VPN if it is required.

Once all settings are entered, hit Save and you should see your new VPN server in the list of available OpenVPN servers.

Add firewall rules

To finalise the server setup we need to create two firewall rules. Firstly, we need to allow traffic on port 1194/UDP to access the WAN interface of the firewall, then we need to allow traffic connecting over the VPN to access our LAN network.

Go to Firewall > Rules > WAN and add a rule with the following settings:

If you elected not to run your VPN server on port 1194 you will need to set the port range to “other” and manually enter the port number unless you are using another well known port such as DNS (53) in which case you can just select that option.

Next, go to the OpenVPN tab and create a rule. For the purposes of this exercise we will allow all traffic passing through the VPN to be forwarded but if you wanted to selectively allow traffic (e.g. can access web services on server2, files on server5 and DNS on server10 but can’t access anything else) you can of course create a more restrictive rule set here.

Adding a user

Our OpenVPN server is now fully set up but at present cannot be used as no users have been granted access to it. To do this we will need to create a user. Go to System > User Manager and add a user. You will need to configure a username and password as per the picture below. The other settings can be left as default although if you are only planning to grant the user temporary access you may want to set the account to expire automatically when access is due to be revoked.

Once the user is created, if you are using user certificates to authenticate you will need to create a certificate for the user. In the user list, select pen icon next to the user you have created to edit it. Scroll down to the User Certificates section and click “Add”. Set the Common Name to match the username and leave all other settings as default. Repeat these steps for any other users you need to add.

Configure Client Settings

The easiest way to configure client settings is to use the openvpn-client-export package we installed earlier. Go to VPN > OpenVPN > Client Export. At the bottom of this there is a section called OpenVPN Clients. In this section you will see a list of available users whose configuration we can export.

In the Export column we see various options for configuration export. For most devices, the inline configurations will be used. These are text files containing the server settings, certificates and private keys which will be needed to configure the VPN. These can be loaded in to an OpenVPN client and will appear as an available connection. For Windows PCs which do not have OpenVPN already installed, you can use the Windows Installer options to download an executable installer which will install the OpenVPN software and preconfigure it for use by that user.

Windows setup

For Windows 7, 8 or 10 and their corresponding server versions you will want to use the 2.4.8 branch of OpenVPN client. For Windows XP or Vista (shown as win6 in this interface) you will need the older 2.3.18 branch (also, upgrade your PC). Download the installer you want and transfer it to the target PC. Download the correct installer and copy it to your target PC. The installer behaves like any standard Windows installer, just run it, click the “install” button and follow the prompts.

Once installed, open the OpenVPN GUI App from the start menu and log in with the username and password you configured. The first time you run this you will need to allow OpenVPN through the firewall which will require admin rights but these should not be needed for subsequent connections.

Once the handshake is complete the VPN should be connected. You can verify this by moving to a different network, either public WiFi or a mobile hotspot and opening your firewall’s LAN IP address in a web browser. If everything is working you will see the pfSense login page.

The post Remotely connect to your network using OpenVPN and pfSense appeared first on David's Homelab.

Preparing to update

The most important thing to do before updating is to create a backup. There are a few ways this can be done, if you are running Nextcloud in a virtual machine you can just create a snapshot of the VM. If you are running on a physical server, the two things you need to back up are the webroot and the database.

The first step is to enable maintenance mode, this stops users from logging in to Nextcloud and reduces the risk that anything will change while you’re running the backup, leaving the installation in an inconsistent state in the event that you need to restore. You can enter maintenance mode by running the following command:

sudo -u www-data php /var/www/html/nextcloud/occ maintenance:mode --on

Note that this must be done as the user the web server runs as. The above command will work for Ubuntu but if you are using a different distribution the web server user might not be “www-data” so you will need to adjust accordingly. If you are unsure, run ls -l /var/www/html/nextcloud and see who owns the files. Additionally the occ program is in the Nextcloud webroot so if you have installed Nextcloud somewhere other than /var/www/html/nextcloud you will also need to adjust this part of the command

Once you have run this command go to your Nextcloud URL in a browser and verify that logins have been disabled. You will see a warning that the host is in maintenance mode.

You can now run the following commands to back up your files and database. As before, take note to adjust any file paths or usernames:

sudo tar -czf NextCloud-backup-$(date -I).tar.gz /var/www/html/nextcloud/

The above command will create a compressed archive of your full Nextcloud install directory and place it in your current working directory. If you wish you can offload this file to another system using rsync or sftp but as long as it is not created inside /var/www/html/nextcloud the installer shouldn’t touch it so it should be safe.

We now run the next command to back up our database to a file in the current directory:

sudo mysqldump --single-transaction -u[username] -p[password] [databse name] > NextCloud-db-$(date -I).sqlbak

If you have set up your Nextcloud installation using my previous guide your username and database name will probably both be “nextcloud” but if your setup is different you will need to adjust accordingly. Additionally, if your database is not running on localhost you will need to specify the database location using the -h [hostname] flag. If the command is successful you should see a file in your current directory with a .sqlbak extension. This is a text file containing all the MySQL commands you would need to recreate the database in its current form. If a restore is needed, you will need to drop and recreate the existing database and then pipe the sql commands into the MySQL client as follows:

sudo mysql -u[username] -p[password] -e "DROP DATABASE nextcloud"
sudo mysql -u[username] -p[password] -e "CREATE DATABASE nextcloud"
sudo mysql -u[username] -p[password] [db_name] < [backupfilename].sqlbak

Installing the update

Now our files and database are safely backed up, we can proceed with the update process. The easiest way to do this is via the web interface, meaning we will need to disable maintenance mode:

sudo -u www-data php /var/www/html/nextcloud/occ maintenance:mode --off

Now when we go to the web page we see that functionality has returned to normal and we will be able to log in. You will need to log in as the admin user to perform the update so if you normally work as a non admin user (you should be doing this) you will need to log out and back in as the admin.

Click your user icon in the top right corner to go to the settings page. From here you will need to go to the “Overview” screen and click “Open updater”

From the update screen you will be able to install the update. For the most part the installation is automatic and it will show you the steps it is taking and warn you if there are any problems which need manual intervention. You most likely won’t have any issues but if you do you should be able to find a solution on Google or leave me a comment and I will do my best to assist.

If all goes well you will see a screen similar to the one below. You will then be asked if you wish to keep maintenance mode active. As we want to use the web based updater to finish the update, select “no” for this.

You will then be taken to a screen with a list of the apps that need to be updated. As we are updating to a new major version there will be a lot of apps in this list. Just click “Start Update” to begin the installation. Note that at the bottom of the list you will see a list of incompatible apps which will be disabled if you go ahead with the update. If you rely on any of these apps you should not proceed with the update and should instead restore your Nextcloud deployment from the backups we created.

Once complete you will be given the option to view a detailed log of the installation process or just continue to your new Nextcloud installation. If everything has gone well with the update, you should be returned to the main login screen or your main home screen if you are already logged in. The look and feel of Nextcloud 17 is very similar to Nextcloud 16 as most of the changes focus on additional performance and security improvements. For the full list of changes, check out this article on the Nextcloud blog.

The post Updating Nextcloud to 17.0.2 appeared first on David's Homelab.

Choosing your hardware

Of course, while the software may be free you will still need some hardware to run it on. pfSense can run on any x86 64-bit PC although you will probably want to choose one with at least 2 network interfaces, one for WAN and one for LAN (if you have a vlan capable switch it is possible to use a device with only one network interface but this is an advanced configuration which is not covered here). Additionally, if your current router also serves as a wireless access point, you will either want to use hardware which includes a wireless antenna or purchase a dedicated access point.

In terms of hardware, it can really be anything as long as it has an x86-64 CPU, so you can use an old PC, a virtual machine, or purchase a dedicated firewall appliance. pfSense is owned by Netgate and you can buy a range of firewalls directly from them preloaded with pfSense. Many other manufacturers also make small PCs with multiple network interfaces designed for this purpose. Searching for “firewall PC” on Amazon should give you a variety of options. One thing to note when using older or cheaper CPUs is that you should at least choose one with AES-NI support. AES-NI is a set of hardware instructions in modern (since 2010) CPUs designed to speed up AES cryptographic operations which will provide a significant performance boost when using VPNs. AES-NI is expected to become a required feature in a future release of pfSense so if using an older or low-cost CPU check that it supports it or you may find yourself locked out of future upgrades.

Installing the software

Download the pfSense ISO from https://www.pfsense.org/download/, choose the AMD64 architecture and select a mirror near your location. If you are installing on physical hardware you will now need to write the ISO to a USB key. On macOS or Linux you can use the following command to do this:

sudo dd if=/path/to/iso of=/dev/sdX bs=1M ; sync

On Windows you can use a tool like Rufus or Etcher to do this. Etcher also supports macOS and Linux and may be preferable for users who are less comfortable with the command line. If you are installing on a VM you can skip this step.

When you boot from the USB key or ISO you will be taken to the pfSense installer. The installation is very simple, just accept the license, select “install”, select a keymap and decide how you want to partition and format your disk. Here you get two automatic partitioning options, you can select either the ZFS or UFS file systems. You also have the option to manually create partitions or even open a system shell for more advanced configurations. For the sake of simplicity we will use “Auto (UFS)”. pfSense will now install and prompt you to reboot to the console.

Before we can access the web interface we will need to do some configuration on the console, this involves creating any necessary vlans (if you have decided to use a single network interface and a vlans to separate your LAN and WAN networks you will want to say “yes” to this”), and we will also need to assign interfaces to their required zones.

As we are not using vlans in this tutorial we select “n”, then choose which interface will be WAN and which will be LAN as in the picture below.

pfSense will now configure itself and take you to the default prompt. From here we have various options for managing the firewall from the console. These include shutdown/reboot, reassign interfaces, change IP addresses, restoring configuration from backups and accessing a system shell for advanced functionality. Generally, however, we will be configuring pfSense from the web interface. On a PC connected to the LAN interface, go to https://192.168.1.1/ and accept the warning about the self signed certificate.

You should now be greeted with a login screen. Enter the default credentials (Username: admin Password: pfsense). You will now arrive at the setup wizard. After clicking next through the licensing page you will be prompted to set a hostname, domain name and DNS servers. Feel free to leave the hostname and domain name as default or change them if you would prefer something different. You can also pick any DNS servers you like. I have chosen 8.8.8.8 (Google DNS) as primary and 1.1.1.1 (Cloudflare DNS) as the backup. If you are running local DNS on your network and want pfSense to be able to resolve local hostnames then enter the IP address of your internal DNS server instead.

You will then be prompted to set an NTP server and timezone. Leave the NTP server as default and select the correct timezone for your location.

Next you will need to configure your WAN interface. The settings for this will depend on your ISP and at this point it is probably worth checking the configuration of your current router and copying the settings exactly. If you are setting this up behind another router, either to segment a particular subnet or just for testing then DHCP or Static will be the correct option depending on whether the WAN IP address changing would cause problems for what you’re trying to do.

One pair of options to note right at the bottom of the page are “Block RFC1918 Private Networks” and “Block Bogon Networks”. RFC1918 private networks are networks which are not allocated to devices on the internet and should only be used behind NAT. These are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. For the most part these should be blocked but if your WAN interface has an IP address in these ranges (e.g. if it is behind another firewall that is doing NAT) you will need to allow this traffic. Bogon networks are other networks which should never be seen passing between networks. These include localhost IP addresses, link-local addresses and ranges which have not yet been assigned. It is almost always safe and desirable to block these.

Next we configure our LAN IP address. If you are happy with the 192.168.1.0/24 range then leave this as it is, if you would prefer a different range then set it here. Note, once you apply the setting you will need to access the web console on the new IP address you have set.

Finally, set a secure admin password and reload the firewall config to apply everything we have just set up. Once the config is reloaded we are taken to the main dashboard where we can see information about the system and, if everything has worked correctly, you should now have a functioning internet connection through your pfSense.

Housekeeping and final steps

While this guide aims to get you to the point of having a functioning internet connection through pfSense with advanced topics saved for future guides, there are a couple of additional steps which are worth taking to fix odd issues and perform basic optimisations. All of these are optional but depending on your setup, may be worthwhile.

Change the default management port

By default the pfSense admin interface listens on all interfaces (including WAN) on port 443/tcp. Don’t worry, this doesn’t mean that people can access your pfSense from the internet, there are firewall rules in place to stop that. However, it does mean you may run in to problems if you want to forward port 443 to another device on your network (e.g. if you plan to run a web server behind it). We can change the port to something else by going to System > Advanced > Admin Access and setting a custom value for “TCP Port”. Once set, you will need to specify this port number when accessing the admin interface so, for example, if you set it to 8443 you would need to access your web console by going to https://192.168.1.1:8443/

Prefer IPv4

At present there is a bug in pfSense where the package manager will hang if it tries to connect over IPv6. If you have IPv6 enabled on your network, you should go to System > Advanced > Networking and select the option to prefer IPv4 over IPv6. Note that this setting only affects pfSense so any devices on your LAN will still be able to connect over IPv6 and will select a default IP version based on their own internal settings.

Enable hardware crypto acceleration

As mentioned previously, pfSense will perform cryptographic operations much faster with AES-NI. We can see the current AES-NI status from the dashboard under “CPU Type”

Here we can see pfSense has detected that the CPU supports AES-NI but it is set to inactive. It can be enabled in System > Advanced > Miscellaneous by setting “Cryptographic Hardware” to “AES-NI CPU-based Acceleration”

The post Upgrade your network with a pfSense firewall appeared first on David's Homelab.

So why WireGuard? Yes, I know that it is still in beta and hasn’t had any significant security auditing but it provides several advantages for this type of setup. Firstly, it is a lot simpler to configure than OpenVPN or IPSec as it doesn’t require any PKI and uses shared keys in a way which will be familiar to OpenSSH users. WireGuard also doesn’t need to recreate the tunnel whenever the connection is lost so you can roam between different networks without having to restart the connection. This is particularly handy on mobile phones where you might want to route some traffic such as DNS (pi-hole) over a VPN so you have ad-blocking regardless of the network you are connected to.

While I like WireGuard for personal devices or for site-to-site VPNs I won’t pretend it’s perfect for everything. WireGuard doesn’t support DHCP or allow username and password logins for the VPN, it has to be configured on a per-device basis and therefore might not be the ideal choice for corporate remote access VPNs. Additionally its newness and lack of security auditing make it a poor choice if you need it to protect highly sensitive information.

Setup

Preparing your network environment

If you do not have too many network services already set up which would be impacted by an IP address change and your network uses a common subnet such as 192.168.0.0/24, 192.168.1.0/24 it is worth adjusting your DHCP settings on your LAN to use a more uncommon subnet. This is because when you connect in from a public network your endpoint’s local IP will probably be in one of these ranges, leading to an address conflict. i.e. if your PC tries to access 192.168.1.20, your PC may route this down the tunnel or try to access that host on its local network (e.g. coffee shop WiFi). While it is possible to work around this using static routes it is a pain so, if possible, try to use an uncommon subnet on your home LAN.

Preparing your WireGuard endpoint

I will be demonstrating the setup using a CentOS 7 server and Ubuntu 18.04 client but the majority of steps can be adapted for any other Linux distribution with a little effort so if you plan to use a different distribution or even Windows or macOS for your server many of the instructions should be applicable.

From your fresh CentOS 7 install, run yum -y update to install any available updates

Install WireGuard from Copr by running the following commands as root:

curl -Lo /etc/yum.repos.d/wireguard.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo
yum install epel-release
yum install wireguard-dkms wireguard-tools

If installing on another distribution, instructions for installing on basically anything can be found on WireGuard’s website.

Configuring your server

We will be configuring our tunnel using the wg-quick script which comes as part of the wireguard-tools package. This tool reads a config file from the /etc/wireguard directory by default so this is where we will place our config file. Make the directory and change the permissions so it can only be accessed by the root user:

mkdir /etc/wireguard
chmod 700 /etc/wireguard
cd /etc/wireguard

We now need to generate our private and public keys for the server. These act similarly to SSH keys in that the private key will only be stored on the server and the public key will be copied to the peer configuration for all of the clients. The public key from the client will in turn be copied to the peer configuration on the server. To generate a keypair run the following command as root:

wg genkey | tee private.key | wg pubkey > public.key

This will give us two files called private.key and public.key containing the respective keys which can be added to the config files.

We now create a config file for the tunnel. When the tunnel is active the interface name will be taken from the name of the config file so wg0.conf will result in an interface called wg0. Name the file however you like according to your preferred interface name but note that the name must end with .conf for wg-quick to detect it. Open the config file in your preferred text editor and enter the following basic configuration. I have added comments above each line to explain what it does:

[Interface]
# This is the virtual IP address, with the subnet mask we will use for the VPN. Note that this must not be on our LAN subnet and should be an uncommon subnet to avoid address conflicts
Address = 10.125.37.1/24
# The PostUp instructions are commands to be run when the VPN tunnel is activated, in this case we configure forwarding of traffic across the tunnel and enable NAT on eth0 (if you are using a different interface change this value)
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 instructions are instructions to be run when the tunnel is deactivated. In this case we simply delete the firewall rules we created when the connection is brought up.
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
# This is the port the server will listen on, use any unused port for this as there is not an official one
ListenPort = 51845
# Copy the private key you saved to /etc/wireguard/private.key
PrivateKey = [your private key]

As our server will be acting as a router, we will need to enable IPv4 forwarding by running the following command:

sysctl net.ipv4.ip_forward=1

To make this change persistent across reboots we also need to add the following line to /etc/sysctl.conf

net.ipv4.ip_forward=1

Finally, open port our chosen port in the firewall:

firewall-cmd --permanent --add-port=51845/udp
firewall-cmd --reload

We can now test our configuration by running the following commands:

wg-quick up wg0
wg show

If all is well, wg show should output something like this:

[root@wg wireguard]# wg show
interface: wg0
  public key: ljDbmpp6GLMigE19i4gRqzypnQ29ptZT91N0Lyt3pBg=
  private key: (hidden)
  listening port: 51820

We can now take the interface down by running wg-quick down wg0 and begin configuring our first client

Configuring a client

Much like the server, we begin by installing the WireGuard packages. For Ubuntu this is done by running:

sudo add-apt-repository ppa:wireguard/wireguard
sudo apt-get update
sudo apt-get install wireguard

We will also need to install resolvconf as it is not installed by default on Ubuntu

sudo apt install resolvconf

Like on the server we create our /etc/wireguard directory, lock down the permissions and create our public and private keys:

mkdir /etc/wireguard
chmod 700 /etc/wireguard
cd /etc/wireguard/
wg genkey | tee private.key | wg pubkey > public.key

Again, we make our wg0.conf file using the following template:

[Interface]
# Use an address on the same subnet as our server
Address = 10.125.37.20/24
# Set a port to listen on. This can match the listen port on the server but it doesn't have to
ListenPort = 51845
# The private key you just generated
PrivateKey = [key from private.key]
# If you want to use a specific DNS server for this connection specify it here, multiple servers can be specified by separating them with commas
DNS = 10.100.4.20

Again, we can bring the interface up using wg-quick and check if wg-show produces output to check our configuration.

Making the hosts talk to each other

We now have WireGuard interfaces on each host that are ready to accept connections so it is time to tell them about each other. For this we need to inform each endpoint the other’s public key and IP address by adding a [Peer] section to wg0.conf on each host.

For the server our wg0.conf file should now look like:

[Interface]
Address = 10.125.37.1/24  # This is the virtual IP address, with the subnet mask we will use for the VPN
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
ListenPort = 51820
PrivateKey = [server private key]
[Peer] # client 1 ## it is advisable to make a comment by each peer to say what it refers to as the list of peers quickly becomes confusing once several have been added
PublicKey = [client public key]
AllowedIPs = 10.125.37.20/32

One important point to note here is that the subnet in the peer file refers to all the IP addresses which can be routed via that peer so if the peer only has a single IP address it must be entered as a /32 regardless of what subnet the peer believes itself to be on. If you wanted to configure a site to site VPN you would specify a range here and enable IP forwarding on both ends of the tunnel.

We now edit the wg0.conf file on the client to tell it about the server:

[Interface]
Address = 10.125.37.20/24
ListenPort = 51845
PrivateKey = [client private key]
DNS = 10.100.4.20
[Peer] # server
Endpoint = wireguard.mydomain.com:51845
PublicKey = [server public key]
AllowedIPs = 0.0.0.0/0

As the client will be initiating the connection we must set an endpoint. This can just be an IP address but as you most likely have a dynamic IP address on your home network your best option is to set up dynamic DNS and use the hostname as your endpoint. If your endpoint is behind a NAT (it probably is), make sure to set up port forwarding on your gateway to send connections on port 51845 to your WireGuard server.

Additionally, you will notice that the AllowedIPs for the client is not a single host. This is because we want to route multiple IPs via our tunnel. In this case we will be routing all traffic through the tunnel but you can specify only certain networks by entering a comma separated list (e.g. 192.168.20.0/24,10.100.4.0/24,10.125.37.20/24). If you only want certain networks to be routed via the tunnel make sure that the network your tunnel endpoints are part of is part of the list otherwise it won’t work. In this case this is 10.125.37.20/24.

Testing the connection

If all has gone to plan our connection should now be correctly configured, we can now bring the interface up at both ends by running the following command on the server and then on the client:

sudo wg-quick up wg0

If we now run wg show on the client or the server we should see something like the following:

interface: wg0
  public key: WMZmhRHmrIQSJ+szXnuhtnH9twSA+6YJe7ADluXyq3E=
  private key: (hidden)
  listening port: 51845
  fwmark: 0xca6c
peer: ljDbmpp6GLMigE19i4gRqzypnQ29ptZT91N0Lyt3pBg=
  endpoint: wireguard.mydomain.com:51845
  allowed ips: 0.0.0.0/0
  transfer: 0 B received, 888 B sent

If we now ping our server we should get responses and see the transfer statistics in wg show increasing. We should also be able to access network resources on the LAN side via our tunnel. Assuming all has gone to plan, you now have a VPN which can protect your data when connecting from untrusted networks and allow you to access resources on your home network.

Running WireGuard as a service

wg-quick comes with a built in systemd service, you can easily configure WireGuard to start on boot by running:

systemctl enable wg-quick@wg0.service

If you have called your interface something other than wg0 adjust your service name accordingly

The post Access your home network from anywhere with WireGuard VPN appeared first on David's Homelab.