Tag: BSD

BSD

Using xargs

Recently I decided to update and re-tag my music collection, which had suffered at the hands of the untrained and uncaring for far too long. The album art in particular, comprised of various jpg files and scattered throughout the numerous artist and album directories, was incomplete and/or inaccurate. I decided I needed a way to quickly and efficiently remove this old album art before starting the re-tagging process. Enter xargs, a handy little utility in Linux and Unix operating systems used to construct a list of arguments for an arbitrary Linux or Unix command. xargs is a good companion for commands like find, locate and grep that output long lists of files. The general syntax for the xargs command is as follows:

xargs [option...] [command [initial-arguments]]

1	xargs [option...] [command [initial-arguments]]

Let’s take the case of the my superfluous jpg files to see how xargs might be used in practice. We’ll start by opening a terminal and using the find command to locate these jpg files. This following command should find files ending with “.jpg” anywhere within my music directory, including sub-directories, and list them to the terminal:

find ~/music -name "*.jpg"

1	find ~/music -name "*.jpg"

By the way, in this particular example I’m passing along a directory to the find command that I know in advance I have the appropriate permissions to access, in this case my home directory. However, depending on what you’re searching for and where, the find command may return “Permission denied” because it (or rather you) lack sufficient permissions to access certain directories and files. In those cases you’ll need to preface the find command with su or perhaps sudo in order to avoid these errors.

Also be aware that the locate command offers similar capabilities to find, but instead of searching through the system’s directories and files, locate searches through a pre-built database of these directories and files. locate can produce significantly faster results using less computing resource compared to find, but requires the database to be updated regularly or else the results will be inaccurate and/or incomplete. Here’s an example of how to find our jpg files using the locate command:

sudo updatedb
locate ~/music/*.jpg

1 2	sudo updatedb locate ~/music/*.jpg

Okay, let’s combine the find command we used before with xargs to quickly remove the jpg files:

find ~/music -name "*.jpg" -print0 | xargs -0 rm

1	find ~/music -name "*.jpg" -print0 \| xargs -0 rm

In this example, the find command searches through my ~/music directory and pipes to xargs a list any files ending in “.jpg”. The xargs command then splits this list into sub-lists and calls the rm command once for every sub-list. The -print0 option in the find command prints the full file name on the standard output followed by a null character. This allows file names that contain newlines or other types of white space to be correctly interpreted xargs when it uses it’s corresponding -0 option. Using xargs is more efficient than this functionally equivalent version of the find command, which must call rm once for every single file it finds:

find ~/music -name "*.jpg" -exec rm '{}' \;

1	find ~/music -name "*.jpg" -exec rm '{}' \;

Want to copy these jpg files to another directory instead removing them? The following two examples demonstrate how xargs can be used to accomplish that:

find ~/music -name "*.jpg" -print0 | xargs -0 cp -t ~/tmp

1	find ~/music -name "*.jpg" -print0 \| xargs -0 cp -t ~/tmp

find ~/music -name "*.jpg" -print0 | xargs -0 -I {} cp {} ~/tmp

1	find ~/music -name "*.jpg" -print0 \| xargs -0 -I {} cp {} ~/tmp

In the second example, the -I option tells xargs to replace the string {} with the argument list from the find command, in this case our list of jpg files. Note that not all versions of xargs support the {} syntax. No worries though, in those cases you can specify any string you’d like after -I; for example, the following variation replaces the string {} with x and will work just as well:

find ~/music -name "*.jpg" -print0 | xargs -0 -I x cp x ~/tmp

1	find ~/music -name "*.jpg" -print0 \| xargs -0 -I x cp x ~/tmp

Here’s another use for xargs – systematically setting permissions for a large number of directories or files. When assigning reasonably secure permissions directories and files it’s common to give directories a permission of 755 and files a permission of 644. Since the command we’d normally use in this situation – chmod [some permission] -R /path/to/some_directory – will assign the same permission level to the directory and the files, let’s use xargs to assign permissions selectively:

find ~/music -type f -print0 | xargs -0 chmod 644
find ~/music -type d -print0 | xargs -0 chmod 755

1 2	find ~/music -type f -print0 \| xargs -0 chmod 644 find ~/music -type d -print0 \| xargs -0 chmod 755

Using this approach, for example, we could set all the mp3 files in ~/music to read-only so that an application or script doesn’t accidentally overwrite their tag metadata:

find ~/music -name "*.mp3" -print0 | xargs -0 chmod 644

1	find ~/music -name "*.mp3" -print0 \| xargs -0 chmod 644

To verify that the permissions were set correctly let’s pass ls -l to xargs:

find ~/music -name "*.mp3" -print0 | xargs -0 ls -l

1	find ~/music -name "*.mp3" -print0 \| xargs -0 ls -l

There ya have it. A couple of examples of how to use the xargs utility, one of the most useful and the most underappreciated utilities in *nix toolbox.

Networking

Use pfSense as a NTP Server

(20170504 — The steps in this post were amended to address changes in recent versions of software — iceflatline)

In a previous post, I described how to install and setup pfSense in a home network. In this post I will describe how to configure pfSense to act as an Network Time Protocol (“NTP”) server, as well as how to configure various hosts in your network to synchronize their local clock to this server.

pfSense is a customized version of FreeBSD tailored specifically for use as a perimeter firewall and router. It can be managed almost entirely from a web-based GUI. In addition to being a firewall and routing platform, pfSense includes a long list of other features, as well as a package system allowing its capabilities to be expanded even further. pfSense is free, open source software distributed under the BSD license.

Originally designed by David L. Mills of the University of Delaware circa 1985, NTP is a protocol for synchronizing the clocks of computer systems over packet-switched, variable-latency data networks, and one of the oldest Internet protocols still in use. NTP uses User Datagram Protocol (UDP) port number 123. pfSense uses OpenNTPD, a free, easy to use implementation of NTP.

The versions for the software used in this post were as follows:

FreeBSD 11.0-RELEASE
pfSense 2.3.3-RELEASE-p1
Ubuntu 16.04.2 LTS
Windows 7 Professional (x64)

Configure OpenNTPD in pfSense

Before configuring the OpenNTP server, it’s a good idea to ensure that pfSense itself is keeping accurate time. The best way to do that is to have it synchronize its clock with one or more remote NTP servers. First though, you should make sure that the clock in the machine hosting pfSense is set to something close to accurate – if the difference is too great, pfSense will not synchronize properly with the remote NTP server.

Login to the pfSense machine using its “webConfigurator” (webGUI) interface. Navigate to System->General Setup and select the timezone that matches the physical location of the pfSense machine from among the options under “Timezone.” Next, enter the host name or IP address for the remote NTP server under “Timeservers” (Remember to add at least one DNS server under “DNS Servers” if you decide to use a host name instead of an IP address). Most likely you’ll find this field is already populated with one or more default remote NTP server(s) such as 0.pfsense.pool.ntp.org, 1.pfsense.pool.ntp.org, etc. These servers will work just fine in most cases, however you may get more accurate results if you use one of the continental zone servers (e.g., europe., north-america., oceania., or asia.pool.ntp.org), and even more accurate time if you choose to use one of the country zone servers (e.g., us.pool.ntp.org in the United States). For all of these zones, you can use the 0, 1 or 2 prefix, like 0.us.pool.ntp.org, to distinguish between servers from a particular region or country. (See the NTP Pool Project web site for more information on how to use pool.ntp.org servers). Like 0.pfsense.pool.ntp.org, these server entries will pick random NTP servers from a pool of known good ones. Also, while one NTP server is sufficient, you can improve reliability by adding more. Just make sure their host names or IP addresses are separated by a space.

Now that the pfSense machine is on its way to keeping accurate time, let’s configure its OpenNTPD server. Navigate to Services->NTP and pick which interface OpenNTPD should listen on. This will typically be the “LAN” interface. When complete select “Save.” The OpenNTPD server will start immediately, however there may a delay of several minutes before it is ready to service NTP requests as it must first ensure that its own time is accurate. That’s all there is to it. You’ll find the OpenNTPD logs under by selecting the ‘NTP” tab under Status->System Logs->NTP.

Configure Hosts

Windows

After configuring the OpenNTPD server in pfSense, let’s configure a Windows host to synchronize its local clock to this server. Right-click on the time (usually located in the lower right corner of the desktop) and select “Adjust date/time.” Select the “Internet Time” tab, then select “Change settings.” Check the “Synchronize with an Internet time server” box, enter the host name or IP address of the pfSense machine, then select “Update now.” It’s not uncommon to get error message the first time you attempt to update. Wait a few seconds and try again; you should receive a “The clock was successfully synchronized…” message.

Linux

Many Linux distributions feature two utilities to help the local clock maintain its accuracy: ntpdate and/or ntpd (Note: Linux systems using systemd-timesyncd are discussed below). The ntpdate utility is typically included in Linux distributions as a default package, but if yours does not you can install it using your distribution’s package manager, for example:

sudo apt-get install ntpdate

1	sudo apt-get install ntpdate

ntpdate typically runs once at boot time and will synchronize the local clock with a default NTP server defined by the distribution. However what if this machine isn’t rebooted often, say in the case of a server for example? And what about using the OpenNTPD server in the pfSense machine? We can address both of those issues by occasionally running ntpdate using the following command. For this and subsequent examples we’ll assume the IP address assigned to the LAN interface in the pfSense machine is 192.168.1.1:

sudo ntpdate 192.168.1.1

1	sudo ntpdate 192.168.1.1

Perhaps a more effective approach though is to use cron, a utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon. These tasks are typically referred to as “cron jobs.” A “crontab” is a file which contains one or more cron job entries to be run at specified times. You can create a new crontab (or edit an exiting one) using the command crontab -e under your user account. Because ntpdate needs to be run by the system’s root user we’ll create the crontab using the command sudo crontab -e. Here’s some example cron job entries using the ntpdate command. Note that cron will attempt to email to the user the output of the commands it runs. To silence this, you can redirect the command output to /dev/null:

#Run ntpdate every 15 minutes
#*/15 * * * * /usr/sbin/ntpdate 192.168.1.1 >> /dev/null 2>&1

#Run ntpdate every 30 minutes
#*/30 * * * * /usr/sbin/ntpdate 192.168.1.1 >> /dev/null 2>&1

#Run ntpdate at the top of every hour
# 0 * * * * /usr/sbin/ntpdate 192.168.1.1 >> /dev/null 2>&1

#Run ntpdate every three hours at the top of each hour
0 */3 * * * /usr/sbin/ntpdate 192.168.1.1 >> /dev/null 2>&1

#Run ntpdate every six hours at the top of each hour
#0 */6 * * * /usr/sbin/ntpdate 192.168.1.1 >> /dev/null 2>&1

#Run ntpdate every 15 minutes

#*/15 * * * * /usr/sbin/ntpdate 192.168.1.1 >> /dev/null 2>&1

#Run ntpdate every 30 minutes

#*/30 * * * * /usr/sbin/ntpdate 192.168.1.1 >> /dev/null 2>&1

#Run ntpdate at the top of every hour

# 0 * * * * /usr/sbin/ntpdate 192.168.1.1 >> /dev/null 2>&1

#Run ntpdate every three hours at the top of each hour

0 */3 * * * /usr/sbin/ntpdate 192.168.1.1 >> /dev/null 2>&1

#Run ntpdate every six hours at the top of each hour

#0 */6 * * * /usr/sbin/ntpdate 192.168.1.1 >> /dev/null 2>&1

While using ntpdate will certainly work well, the utility ntpd on the other hand is considerably more sophisticated. It continually runs, calculating the drift of the local clock and then adjusting its time on an ongoing basis by synchronizing with one or more NTP servers. By default ntpd acts as a NTP client, querying NTP servers to set the local clock, however it also can act as a NTP server, providing time service to other clients. Alas though, nothing is free, and using ntpd will result in yet one more system process that may not otherwise be running in your system, consuming both CPU and memory resources, albeit modestly.

Like ntpdate many Linux distributions include ntpd by default. If yours does not, you can install it using your distribution’s package manager, for example:

sudo apt-get install ntp

1	sudo apt-get install ntp

The installation process should add ntpd to the requisite run levels and start its daemon automatically. Now we need to configure it so that it acts as a NTP client only and not as a NTP server. After all, that’s what we’re going to use the pfSense machine for right?

ntpd is configured using the file /etc/ntp.conf. Open this file and comment out the existing ntp pool servers, then add the IP address assigned to the LAN interface on the pfSense machine. Again, we’ll assume this address is 192.168.1.1. Appending the “iburst” option to the address will provide for faster initial synchronisation. We’ll also want to comment out the NTP server-related options that allow the local machine to exchange time with other host devices on the network and interrogate the local NTP server. The remaining options can remain at their default settings:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# Specify one or more NTP servers.

# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
#server 0.ubuntu.pool.ntp.org
#server 1.ubuntu.pool.ntp.org
#server 2.ubuntu.pool.ntp.org
#server 3.ubuntu.pool.ntp.org
server 192.168.1.1 iburst

# Use Ubuntu's ntp server as a fallback.
#server ntp.ubuntu.com

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
#restrict -4 default kod notrap nomodify nopeer noquery
#restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
#restrict 127.0.0.1
#restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Enable this if you want statistics to be logged.

#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats

filegen loopstats file loopstats type day enable

filegen peerstats file peerstats type day enable

filegen clockstats file clockstats type day enable

# Specify one or more NTP servers.

# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board

# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for

# more information.

#server 0.ubuntu.pool.ntp.org

#server 1.ubuntu.pool.ntp.org

#server 2.ubuntu.pool.ntp.org

#server 3.ubuntu.pool.ntp.org

server 192.168.1.1 iburst

# Use Ubuntu's ntp server as a fallback.

#server ntp.ubuntu.com

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for

# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>

# might also be helpful.

# Note that "restrict" applies to both servers and clients, so a configuration

# that might be intended to block requests from certain clients could also end

# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.

#restrict -4 default kod notrap nomodify nopeer noquery

#restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.

#restrict 127.0.0.1

#restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if

# cryptographically authenticated.

#restrict 192.168.123.0 mask 255.255.255.0 notrust

# If you want to provide time to your local subnet, change the next line.

# (Again, the address is an example only.)

#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the

# next lines. Please do this only if you trust everybody on the network!

#disable auth

#broadcastclient

A comment about the driftfile option: this file is used to store the local clock’s frequency offset. ntpd uses this file to automatically compensate for the local clock’s natural time drift, allowing it to maintain reasonably accurate time even if it cannot communicate with the pfSense machine for some period of time.

While not required, you can run the ntpdate command one time to fully synchronize the local clock with the OpenNTPD server in pfSense, then restart ntpd.

sudo /etc/init.d/ntp stop
sudo ntpdate 192.168.1.1
sudo /etc/init.d/ntp start

sudo /etc/init.d/ntp stop

sudo ntpdate 192.168.1.1

sudo /etc/init.d/ntp start

In recent Linux releases using systemd-timesyncd, timedatectl replaces ntpdate and timesyncd replaces the client portion of ntpd. By default timedatectl syncs the time by querying one or more NTP servers once on boot and later on uses socket activation to recheck once network connections become active. timesyncd on the other hand regularly queries the NTP server(s) to keep the time in sync. It also stores time updates locally, so that after reboots monotonically advances if applicable.

The NTP server(s) used to sync time for timedatectl and timesyncd from can be specified in /etc/systemd/timesyncd.conf. By default the system will rely upon the default NTP server(s) defined by the distribution and specified by FallbackNTP= in the “[Time]” section of the file. To use the OpenNTPD server in the pfSense machine, uncomment NTP= and append the IP address assigned to the LAN interface on the pfSense machine. Again, assuming this address is 192.168.1.1:

[Time]
NTP=192.168.1.1
#FallbackNTP=ntp.ubuntu.com

[Time]

NTP=192.168.1.1

#FallbackNTP=ntp.ubuntu.com

You can specify additional NTP servers by listing their host names or IP addresses separated by a space on these lines. Now run the following command:

timedatectl set-ntp yes

1	timedatectl set-ntp yes

The current status of time and time configuration via timedatectl and timesyncd can be checked with the command timedatectl status:

$ timedatectl status
	Local time: Tue 2017-04-25 17:41:04 EDT
	Universal time: Tue 2017-04-25 21:41:04 UTC
	RTC time: Tue 2017-04-25 21:41:04
	Time zone: America/New_York (EDT, -0400)
	Network time on: yes
	NTP synchronized: yes
	RTC in local TZ: no

$ timedatectl status

Local time: Tue 2017-04-25 17:41:04 EDT

Universal time: Tue 2017-04-25 21:41:04 UTC

RTC time: Tue 2017-04-25 21:41:04

Time zone: America/New_York (EDT, -0400)

Network time on: yes

NTP synchronized: yes

RTC in local TZ: no

FreeBSD

ntpdate and ntpd are installed in FreeBSD by default, however ntpd is not configured to start at boot time.

Similar to Linux, we can run ntpdate manually as root to synchronize with the OpenNTP server running in the pfSense machine. Again, we’ll assume 192.168.1.1 is the IP address assigned to the LAN interface on the pfSense machine.

ntpdate 192.168.1.1

1	ntpdate 192.168.1.1

ntpdate can also be made to run at boot time in FreeBSD by using the sysrc command to add the following lines to /etc/rc.conf:

sysrc ntpdate_enable=YES
sysrc ntpdate_hosts=192.168.1.1

1 2	sysrc ntpdate_enable=YES sysrc ntpdate_hosts=192.168.1.1

We can also use cron under FreeBSD to run ntpdate. You can create a new crontab (or edit an exiting one) using the command crontab -e as root. The example cron job entries provided above under Linux will also work under FreeBSD.

To enable ntpd under FreeBSD, open /etc/ntp.conf and comment out the existing ntp pool servers and add the IP address assigned to the LAN interface on the pfSense machine. The remaining options can remain at their default settings:

#
# The following three servers will give you a random set of three
# NTP servers geographically close to you.
# See http://www.pool.ntp.org/ for details. Note, the pool encourages
# users with a static IP and good upstream NTP servers to add a server
# to the pool. See http://www.pool.ntp.org/join.html if you are interested.
#
# The option `iburst' is used for faster initial synchronisation.
#
#server 0.freebsd.pool.ntp.org iburst
#server 1.freebsd.pool.ntp.org iburst
#server 2.freebsd.pool.ntp.org iburst
#server 3.freebsd.pool.ntp.org iburst
server 192.168.1.1 iburst

#
# If you want to pick yourself which country's public NTP server
# you want sync against, comment out the above servers, uncomment
# the next ones and replace CC with the country's abbreviation.
# Make sure that the hostnames resolve to a proper IP address!
#
# server 0.CC.pool.ntp.org iburst
# server 1.CC.pool.ntp.org iburst
# server 2.CC.pool.ntp.org iburst

#
# Security: Only accept NTP traffic from the following hosts.
# The following configuration example only accepts traffic from the
# above defined servers.
#
# Please note that this example doesn't work for the servers in
# the pool.ntp.org domain since they return multiple A records.
# (This is the reason that by default they are commented out)
#
#restrict default ignore
#restrict 0.pool.ntp.org nomodify nopeer noquery notrap
#restrict 1.pool.ntp.org nomodify nopeer noquery notrap
#restrict 2.pool.ntp.org nomodify nopeer noquery notrap
#restrict 127.0.0.1
#restrict -6 ::1
#restrict 127.127.1.0

#
# If a server loses sync with all upstream servers, NTP clients
# no longer follow that server. The local clock can be configured
# to provide a time source when this happens, but it should usually
# be configured on just one server on a network. For more details see
# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock
# The use of Orphan Mode may be preferable.
#
#server 127.127.1.0
#fudge 127.127.1.0 stratum 10

# The following three servers will give you a random set of three

# NTP servers geographically close to you.

# See http://www.pool.ntp.org/ for details. Note, the pool encourages

# users with a static IP and good upstream NTP servers to add a server

# to the pool. See http://www.pool.ntp.org/join.html if you are interested.

# The option `iburst' is used for faster initial synchronisation.

#server 0.freebsd.pool.ntp.org iburst

#server 1.freebsd.pool.ntp.org iburst

#server 2.freebsd.pool.ntp.org iburst

#server 3.freebsd.pool.ntp.org iburst

server 192.168.1.1 iburst

# If you want to pick yourself which country's public NTP server

# you want sync against, comment out the above servers, uncomment

# the next ones and replace CC with the country's abbreviation.

# Make sure that the hostnames resolve to a proper IP address!

# server 0.CC.pool.ntp.org iburst

# server 1.CC.pool.ntp.org iburst

# server 2.CC.pool.ntp.org iburst

# Security: Only accept NTP traffic from the following hosts.

# The following configuration example only accepts traffic from the

# above defined servers.

# Please note that this example doesn't work for the servers in

# the pool.ntp.org domain since they return multiple A records.

# (This is the reason that by default they are commented out)

#restrict default ignore

#restrict 0.pool.ntp.org nomodify nopeer noquery notrap

#restrict 1.pool.ntp.org nomodify nopeer noquery notrap

#restrict 2.pool.ntp.org nomodify nopeer noquery notrap

#restrict 127.0.0.1

#restrict -6 ::1

#restrict 127.127.1.0

# If a server loses sync with all upstream servers, NTP clients

# no longer follow that server. The local clock can be configured

# to provide a time source when this happens, but it should usually

# be configured on just one server on a network. For more details see

# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock

# The use of Orphan Mode may be preferable.

#server 127.127.1.0

#fudge 127.127.1.0 stratum 10

Now use sysrc to add the following two lines to /etc/rc.conf. The first line enables ntpd. The second tells the system to perform a one time sync at boot time:

sysrc ntpd_enable=YES
sysrc ntpd_sync_on_start=YES

1 2	sysrc ntpd_enable=YES sysrc ntpd_sync_on_start=YES

Run the ntpdate command one time to synchronize the local clock with the OpenNTPD server in pfSense, then start ntpd.

ntpdate 192.168.1.1
service ntpd start

1 2	ntpdate 192.168.1.1 service ntpd start

Conclusion

This concludes the post on how to how to configure your pfSense machine to also act as a NTP server. The OpenNTPD service in pfSense will listen for requests from FreeBSD, Linux and Windows hosts and allow them to synchronize their local clock with that of the OpenNTPD server in pfsense. Using pfSense as a NTP server in your network ensures that your hosts always have consistent accurate time and reduces the load on the Internet’s NTP servers. Configuring Windows hosts to utilize this server is straightforward, while configuration under FreeBSD and Linux requires a bit more work.

References

Buechler, C.M. & Pingle, J. (2009). pfSense: The definitive guide. USA: Reed Media

http://www.openntpd.org/

http://www.pool.ntp.org/en/

http://www.ntp.org/documentation.html

http://support.ntp.org/bin/view/Support/WebHome

http://www.marksanborn.net/linux/learning-cron-by-example/

https://help.ubuntu.com/community/CronHowto

https://help.ubuntu.com/lts/serverguide/NTP.html

BSD

Configure FreeNAS To Be Your Subversion Repository

Recently I had the pleasure of building a Network Attached Storage (“NAS”) server based on FreeNAS. Since then, this device has more than fulfilled my initial requirements for reliable file storage and media server in my network. In a previous post, I described how I configured FreeNAS to store web files and serve as a document root for the Apache http server implemented in my Ubuntu server. Using a similar approach, this post will describe how I configured FreeNAS to host my Subversion (“svn”) repository.

Software versions used in this post were as follows:

FreeNAS v0.7.1 Shere (revision 5127)
Ubuntu Server v10.04 LTS (x64)
Subversion 1.6.6dfsg-2ubuntu1
nfs-common v1:1.2.0-4ubuntu4
portmap v6.0.0-1ubuntu2

Configuring the FreeNAS Server

I began by creating the directory svn on /mnt/files, an existing mount point on my FreeNAS server. This directory would serve as the location for my svn repository. Then I enabled the Network File System (“NFS”) service so that /mnt/files/svn could be accessed from the Ubuntu server. To do this, navigate to Services->NFS->Settings and make sure that the check box for enabling NFS is checked and specify the number of servers that will run (the default value of four should easily handle dozens of users). Now select “Save and Restart.” Next, navigate to Services->NFS->Shares and select the “+” icon, where you are presented with the configuration screen for creating a new NFS share. Enter the path to be shared; the network that is authorized to access this shared path; and, make sure that the “All dirs” checkbox selected. The remaining options can retain their defaults (See Figure 1). Now select “Add” then “Apply changes.”

Figure 1

Configuring the Ubuntu Server

In order to mount the NFS shared path without error, I needed to add a couple of packages. The nfs-common package is needed when a host acts as an NFS client, and includes a number of processes that ensure a particular NFS connection is allowed and may proceed. Also, because NFS relies upon remote procedure calls to function, the package portmap is needed in order to map RPC requests to the NFS service:

sudo apt-get install nfs-common portmap

1	sudo apt-get install nfs-common portmap

After these requisite packages were added, I created a directory to mount the NFS shared path. In this command, you must include the IP address of the FreeNAS server as well as the path to the directory created on it previously:

sudo mkdir /media/svn 
sudo mount 192.168.10.5:/mnt/files/svn /media/svn

1 2	sudo mkdir /media/svn sudo mount 192.168.10.5:/mnt/files/svn /media/svn

Then I made sure the permissions for this directory were set correctly:

sudo chmod 755 /media/svn

1	sudo chmod 755 /media/svn

Next, I added the following lines to /etc/fstab in order for the shared path to mount automatically at boot time:

###Start iceflatline

#Mount the FreeNAS directory /mnt/files/svn for use as a Subversion repository
192.168.10.5:/mnt/files/svn /media/svn nfs defaults 0 0

###End iceflatline

###Start iceflatline

#Mount the FreeNAS directory /mnt/files/svn for use as a Subversion repository

192.168.10.5:/mnt/files/svn /media/svn nfs defaults 0 0

###End iceflatline

Then I installed Subversion. The Subversion package for Ubuntu includes the Subversion client, tools to create a Subversion repository (svnadmin), and a custom protocol to make the repository I create on FreeNAS available over my network (svnserve):

sudo apt-get install subversion

1	sudo apt-get install subversion

And created an svn repository at the root of the shared path:

svnadmin create /media/svn

1	svnadmin create /media/svn

Next, I removed anonymous access to the repository and established write privileges for authenticated users. To do this, open /media/svn/conf/svnserve.conf and uncomment the following lines (Note: The svnserve.conf file is sensitive to white spaces, so make sure to not leave a space preceding the line when removing the hash (#) symbol):

anon-access = none
auth-access = write
password-db = passwd

anon-access = none

auth-access = write

password-db = passwd

Then I added myself as an authenticated user to the /media/svn/conf/passwd file:

# harry = harryssecret
# sally = sallyssecret
iceflatline = <my password>

# harry = harryssecret

# sally = sallyssecret

iceflatline = <my password>

I plan to use svn’s custom protocol for access to the repository so I need to start the svn server. One way to start it is to use the svnserve command:

svnserve -d -r /media/svn

1	svnserve -d -r /media/svn

However, I wanted the svn server to start up at boot time, as well as have stop and restart capabilities while it was running, so I created the following simple init script:

#! /bin/sh
### BEGIN INIT INFO
# Provides:          svnserve
# Required-Start:    
# Required-Stop:     
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: svnserve init script
# Description:       This file is used to start, stop, restart, 
#					 and determine status of the svn server daemon.
# Author: 			 iceflatline <iceflatline@gmail.com>
### END INIT INFO

### START OF SCRIPT
set -e
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="svnserve"
NAME=svnserve
DAEMON=/usr/bin/$NAME
# Make sure the path in DAEMON_ARGS 
# reflects the location of the svn repository
DAEMON_ARGS="-d -r /media/svn"
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the subversion package is not installed
[ -x "$DAEMON" ] || exit 0

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

# The function that starts the svnserve daemon
start() {
	start-stop-daemon --start --quiet \
	--exec $DAEMON -- $DAEMON_ARGS 
}

# The function that stops the svnserve daemon
stop() {
	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 \
	--exec $DAEMON 
}

case "$1" in
  start)
	log_daemon_msg "Starting $DESC" 
	start
	case "$?" in
		0) log_end_msg 0 ;;
		1) log_end_msg 1 ;;
	esac
	;;
  stop)
	log_daemon_msg "Stopping $DESC"
	stop
	case "$?" in
		0) log_end_msg 0 ;;
		1) log_end_msg 1 ;;
	esac
	;;
  restart|force-reload)
	log_daemon_msg "Restarting $DESC" 
	stop
	case "$?" in
	  0|1)
		start
		case "$?" in
			0) log_end_msg 0 ;;
			1) log_end_msg 1 ;; 
		esac
		;;
	esac
	;;
	status)
    status_of_proc "$DAEMON" "$NAME"  
    ;;
  *)
	echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" 
	;;
esac
exit 0
### END OF SCRIPT

#! /bin/sh

### BEGIN INIT INFO

# Provides: svnserve

# Required-Start:

# Required-Stop:

# Default-Start: 2 3 4 5

# Default-Stop: 0 1 6

# Short-Description: svnserve init script

# Description: This file is used to start, stop, restart,

# and determine status of the svn server daemon.

# Author: iceflatline <iceflatline@gmail.com>

### END INIT INFO

### START OF SCRIPT

set -e

# PATH should only include /usr/* if it runs after the mountnfs.sh script

PATH=/sbin:/usr/sbin:/bin:/usr/bin

DESC="svnserve"

NAME=svnserve

DAEMON=/usr/bin/$NAME

# Make sure the path in DAEMON_ARGS

# reflects the location of the svn repository

DAEMON_ARGS="-d -r /media/svn"

SCRIPTNAME=/etc/init.d/$NAME

# Exit if the subversion package is not installed

[ -x "$DAEMON" ] || exit 0

# Load the VERBOSE setting and other rcS variables

. /lib/init/vars.sh

# Define LSB log_* functions.

# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.

. /lib/lsb/init-functions

# The function that starts the svnserve daemon

start() {

start-stop-daemon --start --quiet \

--exec $DAEMON -- $DAEMON_ARGS

}

# The function that stops the svnserve daemon

stop() {

start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 \

--exec $DAEMON

}

case "$1" in

start)

log_daemon_msg "Starting $DESC"

start

case "$?" in

0) log_end_msg 0 ;;

1) log_end_msg 1 ;;

esac

;;

stop)

log_daemon_msg "Stopping $DESC"

stop

case "$?" in

0) log_end_msg 0 ;;

1) log_end_msg 1 ;;

esac

;;

restart|force-reload)

log_daemon_msg "Restarting $DESC"

stop

case "$?" in

0|1)

start

case "$?" in

0) log_end_msg 0 ;;

1) log_end_msg 1 ;;

esac

;;

esac

;;

status)

status_of_proc "$DAEMON" "$NAME"

;;

echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}"

;;

esac

exit 0

### END OF SCRIPT

To use the script, I saved it to my home directory as svnserve and made it executable. Then moved it to /etc/init.d:

cd ~ 
chmod +x svnserve 
sudo mv svnserve /etc/init.d/

cd ~

chmod +x svnserve

sudo mv svnserve /etc/init.d/

Then added the svnserve script to all of Ubuntu server’s multi-user run levels (2-5) and started the svn server:

sudo update-rc.d svnserve defaults && sudo /etc/init.d/svnserve start

1	sudo update-rc.d svnserve defaults && sudo /etc/init.d/svnserve start

Now, if for some reason the Ubuntu server is rebooted, the svn server will fire up automatically.

With the svn server now running, I created a root-level directory in subversion for a project called “code”:

svn mkdir svn://192.168.10.5/code

1	svn mkdir svn://192.168.10.5/code

After creating the project in subversion I can now use the standard svn commands or applications such Tortoise, RapidSVN and others to checkout the project or otherwise interact with the repository.

Conclusion

This concludes the post on how to configure a FreeNAS server for use as an svn repository. Sure, I could have installed the subversion package directly on FreeBSD, the underlying operating system for FreeNAS, but that approach adds processes that are not native to the FreeNAS implementation. By using the approach outlined in this post, I was able to place the repository on a solid, reliable and centralized storage system, and provide good logical and physical separation between the svn repository and the svn server functionality.

References

http://tldp.org/LDP/abs/html/abs-guide.html

https://help.ubuntu.com/community/Subversion

BSD

Configure FreeNAS To Store Your Apache Web Files

(20140208 – This post has been amended to provided an updated version of the Apache directive — iceflatline)

Over this past summer I had the pleasure of cobbling together a few spare parts in order to build a Network Attached Storage (“NAS”) box based on FreeNAS. This device has more than fulfilled my initial requirements for reliable file storage and media server in my network. This post will describe how I configured this FreeNAS box to store web files and serve as a document root for the Apache http server implemented in my Ubuntu server. This approach places my local web files on a solid, reliable and centralized RAID 5 disk storage system, and provides good logical and physical separation between file storage and file server functionality.

The versions for the software used in this post were as follows:

FreeNAS v0.7.1 Shere (revision 5127)
Ubuntu Server v10.04 LTS (x64)
Apache v2.1.14
nfs-common v1:1.2.0-4ubuntu4
portmap v6.0.0-1ubuntu2

Configuring the FreeNAS Server

I began by creating the directory www on /mnt/files, an existing mount point. This directory would serve as my new Apache document root. Then, I enabled the Network File System (“NFS”) service in FreeNAS so that /mnt/files/www could be accessed from the Ubuntu server. To do this, navigate to Services->NFS->Settings and make sure that the check box for enabling NFS is checked and specify the number of servers that will run (the default value of four should easily handle dozens of users). Now select “Save and Restart.” Next, navigate to Services->NFS->Shares and select the “+” icon, where you are presented with the configuration screen for creating a new NFS share. Enter the path to be shared; the network that is authorized to access this shared path; and, make sure that the “All dirs” checkbox selected. The remaining options can retain their defaults (See Figure 1). Now select “Add” then “Apply changes.”

Figure 1

Configuring the Ubuntu Server

To configure the Ubuntu server I needed to add a couple of packages in order to mount the NFS shared path without error. The nfs-common package is needed when a host acts as an NFS client, and includes a number of processes that ensure a particular NFS connection is allowed and may proceed. Because NFS relies upon remote procedure calls to function, the package portmap is also needed to map RPC requests to the NFS service:

sudo apt-get install nfs-common portmap

1	sudo apt-get install nfs-common portmap

Next, I created a directory so I could mount the NFS shared path. Here you must include the IP address of the FreeNAS server as well as the directory created on it previously:

sudo mkdir /media/www 
sudo mount 192.168.10.5:/mnt/files/www /media/www

1 2	sudo mkdir /media/www sudo mount 192.168.10.5:/mnt/files/www /media/www

In order for the shared path to mount automatically at boot time, I added the following lines to the /etc/fstab file:

###Start iceflatline

#Mount the FreeNAS directory /mnt/file/www for use as an Apache document root
192.168.10.5:/mnt/files/www /media/www nfs defaults 0 0

###End iceflatline

###Start iceflatline

#Mount the FreeNAS directory /mnt/file/www for use as an Apache document root

192.168.10.5:/mnt/files/www /media/www nfs defaults 0 0

###End iceflatline

I made sure the directory permissions were set correctly, and modified the owner and group associated with /media/www so that the Apache http server could access it:

sudo chmod 755 /media/www
sudo chown www-data -R /media/www
sudo chgrp www-data -R /media/www

sudo chmod 755 /media/www

sudo chown www-data -R /media/www

sudo chgrp www-data -R /media/www

Then edited the /etc/apache2/apache2.conf file, adding an alias for /media/www and a directory directive to the end of the file:

###Start iceflatline

#Alias and directive for FreeNAS directory /mnt/file/www
Alias /www “/media/www”
<Directory “/media/www”>
Options None
AllowOverride None
Require all granted
</Directory>

###End iceflatline

###Start iceflatline

#Alias and directive for FreeNAS directory /mnt/file/www

Alias /www “/media/www”

Options None

AllowOverride None

Require all granted

</Directory>

###End iceflatline

I created an index.html file and moved it to /media/www to test the above configuration, and made sure the file permissions were set correctly:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
  <body>
    <h1>
      The FreeNAS document root works!
    </h1>
  </body>
</html>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">

<html>

<body>

<h1>

The FreeNAS document root works!

</h1>

</body>

</html>

sudo chmod 644 /media/www/index.html

1	sudo chmod 644 /media/www/index.html

Finally, I restarted the Apache http server:

sudo /etc/init.d/apache2 restart

1	sudo /etc/init.d/apache2 restart

Conclusion

This concludes the post on how to configure a FreeNAS server as an Apache document root, providing a reliable way to store your web files, while at the same time utilizing the Ubuntu and Apache servers for what they do best – serving up those files.

Networking

Secure Remote Access To Your Home Network Using pfSense and OpenVPN

(20180430 – The steps in this post were amended to address changes in recent versions of software. Minor editorial corrections were also made — iceflatline)

In my previous post, I described how to install and setup pfSense in a home network and offered some configuration recommendations based on my own experiences. In this post, I will describe how to set up Virtual Private Network (“VPN”) access in pfSense using OpenVPN. Once configured, you’ll be able to use an OpenVPN client in Windows or Linux to securely access your home network remotely using either X.509 PKI authentication (public key infrastructure using X.509-based certificates and private keys) or pre-shared private key authentication.

pfSense (i.e., “making sense of packet filtering”) is a customized version of FreeBSD tailored specifically for use as a perimeter firewall and router, and can be managed entirely from a web-based or command line interface. In addition to being a firewall and routing platform, pfSense includes a long list of other features, as well as a package system allowing its capabilities to be expanded even further. pfSense is free, open source software distributed under the BSD license.

OpenVPN is a lightweight VPN software application supporting both remote access and site-to-site VPN configurations. It uses SSL/TLS security for encryption and is capable of traversing network address translation devices and firewalls. The OpenVPN community edition is free, open source software and portable to most major operating systems, including Linux, Windows 2000/XP/Vista/7, OpenBSD, FreeBSD, NetBSD, Mac OS X, and Solaris. It is distributed under the GPL license version 2.

The versions for the software used in this post were as follows:

easy-rsa for Ubuntu, easy-rsa_2.2.2-2_all.deb
OpenVPN for Ubuntu, openvpn_2.4.4-2ubuntu1_amd64.deb
OpenVPN for Windows, 2.4.6
pfSense 2.4.3
Ubuntu Server 18.04 LTS
Windows 7 Professional

OpenVPN Authentication

Before walking through the steps necessary to configure the OpenVPN server in pfSense and OpenVPN client software in Windows and Linux, let’s discuss the differences between the two methods used by OpenVPN in most situations to authenticate peers (clients and servers) to one another: X.509 PKI and pre-shared private keys.

In the X.509 PKI authentication method, the private keys of the peers are kept secret and its public key made publicly available via “certificates” based on the ITU-T X.509 standard. The goal of a certificate is to certify that a public key belongs to the person or entity claiming to be its owner, or more accurately, the person/entity owning the corresponding private key. To achieve this certification, a certificate is signed by an authority that can be trusted by everyone: the Certification Authority (“CA”). In OpenVPN, a CA certificate and its corresponding private key is generated locally, as well as individual certificates and private keys for the OpenVPN server (located in pfSense in our case) and each OpenVPN client. The CA and its associated private key are then used to sign the server and client certificates during the process of generating them. Then, when a VPN session is established, both server and client will authenticate the other by, among other things, verifying that the certificate each presents to the other was signed by the CA.

The X.509 PKI method has a number of advantages compared to the pre-shared key approach. First, the server only needs its own signed certificate and private key – it doesn’t need to know anything about the certificates associated with the client(s), only that they were signed by the CA certificate. Second, because the server can perform this signature verification without needing access to the CA private key, the CA key can be stored somewhere safe and secure. Finally, individual clients can be disabled simply be adding their certificates to a CRL (“Certification Revocation List”) located on the server. The Certification Revocation List allows compromised certificates to be selectively rejected without requiring that the entire PKI be rebuilt. This is the primary reason that X.509 PKI is considered the preferred method for implementing remote client access using OpenVPN – the ability to revoke access to individual machines. Alas though, there are some issues to be considered when using this approach. One of course is the integrity of the CA private key, which ensures the security of the PKI. Anyone with access to the this key can generate certificates to be used to gain VPN access to a network, so it must be kept secure and never distributed to clients or servers. Another is that creating and managing OpenVPN certificates and private keys may be a bit tedious, particularly if all you want to do is setup personal VPN access to your home network.

In the pre-shared key authentication method, a single static 2048-bit private RSA key is generated and copied to the OpenVPN server and client. This shared key approach is typically used for site-to-site connections involving, say, two pfSense machines located at a main office and a remote office, with one acting as the OpenVPN server and the other as the client. However, it also offers the simplest setup for getting a VPN connection to your network up and running quickly with minimal configuration. There are some shortcomings with this method though that should be considered before using it. First, it doesn’t scale terribly well. Each client needing VPN access must have a unique OpenVPN server and TCP or UDP port defined in pfSense. This can be a pain to manage as the number of clients grows. This pain can be blunted a bit if you issue the same shared key to each client, but if the key is compromised, a new key must be generated and securely provided to the OpenVPN server and all clients. Another problem with this method is that these keys exist in plaintext on each OpenVPN client (it also exists in plain text in pfSense but presumably access to that machine is further restricted) resulting in security that’s perhaps less than desirable.

In summary then, the X.509 PKI method offers scalability and arguably better security, but may be cumbersome for some to setup and manage; while the pre-shared key method is easier to setup, and likely just fine for implementations with a limited number of remote VPN clients. The remainder of this post will discuss how to configure a VPN using either method, but you’ll need to determine which approach best meets your needs.

Installing OpenVPN

OpenVPN comes pre-installed in pfSense so we’ll begin by installing OpenVPN on Windows and Linux, then use it to generate the necessary client and server keys and certificates. OpenVPN provides a set of batch files/scripts based on OpenSSL collectively called “easy-rsa” that will make the task of generating these certificates and keys much easier. To help explain the steps involved, we’ll generate the following certificates and keys:

ca.key
ca.crt
pfsense.key
pfsense.crt
bob.key
bob.crt
static-bob.key

Then we’ll copy these keys to the machines that need them and put them to work to create an OpenVPN connection to a home network that uses the subnet 192.168.10.0/24. Doing so will involve creating another subnet, 192.168.20.0/24, for our OpenVPN server and clients, and designating UDP port 13725 for the OpenVPN server to use to listen on for incoming VPN requests (See Figure 1).

Figure 1

Installing OpenVPN and creating certificates and keys in Windows

OpenVPN for Windows is available from OpenVPN community downloads. During the install, accept the existing default options, and ensure that “EasyRSA 2 Certificate Management Scripts” is selected. The “Advance” section provides some usability options which you can select/deselect based on your preferences. Once installed, OpenVPN will associate itself with files having the .ovpn extension.

Now we’re ready to generate the various certificates and keys. Open a command prompt and change folders to C:\Program Files\OpenVPN\easy-rsa\. Run the following batch file, which will copy the file vars.bat.sample to vars.bat. Note that this will overwrite any preexisting vars.bat file:

init-config.bat

1	init-config.bat

Open the file C:\Program Files\OpenVPN\easy-rsa\vars.bat and take a look at the values associated with the variables KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL. Assigning values to these variables helps speed the process of generating the various certificates and keys by initializing these common variables when the various easy-rsa batch files are invoked. You may leave them at their default values or change them if desired, however, don’t leave any blank. Now, make sure you’re at C:\Program Files\OpenVPN\easy-rsa\, then run the following batch files:

vars.bat
clean-all.bat

1 2	vars.bat clean-all.bat

Running this sequence of commands for the first time will create the folder C:\Program Files\OpenVPN\easy-rsa\keys\, which serves to hold the certificates and keys we generate (Note that you can define the location of this folder using the variable KEY_DIR in vars.bat). You may receive a message indicating that “The system cannot find the file specified”, however this message can safely be ignored. Also note that from now on, each time you run this sequence to create new certificates and keys, any existing certificates and keys in the keys folder will be deleted.

Okay then, let’s generate the CA certificate and CA private key. The only value which must be explicitly entered when requested is for the variable “Common Name”, which is set to “openvpn-ca” in the following example. An optional “Organization Unit Name” and “Name” value is also requested and may be modified if desired:

C:\Program Files\OpenVPN\easy-rsa>vars.bat
C:\Program Files\OpenVPN\easy-rsa>build-ca.bat
Generating a 4096 bit RSA private key
...........................................................................++++++
...................................++++++
writing new private key to 'keys\ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:
State or Province Name (full name) [CA]:
Locality Name (eg, city) [SanFrancisco]:
Organization Name (eg, company) [OpenVPN]:
Organizational Unit Name (eg, section) [changeme]:
Common Name (eg, your name or your server's hostname) [changeme]:openvpn-ca
Name [changeme]:
Email Address [mail@host.domain]:

C:\Program Files\OpenVPN\easy-rsa>

C:\Program Files\OpenVPN\easy-rsa>vars.bat

C:\Program Files\OpenVPN\easy-rsa>build-ca.bat

Generating a 4096 bit RSA private key

...........................................................................++++++

...................................++++++

writing new private key to 'keys\ca.key'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [US]:

State or Province Name (full name) [CA]:

Locality Name (eg, city) [SanFrancisco]:

Organization Name (eg, company) [OpenVPN]:

Organizational Unit Name (eg, section) [changeme]:

Common Name (eg, your name or your server's hostname) [changeme]:openvpn-ca

Name [changeme]:

Email Address [mail@host.domain]:

C:\Program Files\OpenVPN\easy-rsa>

Navigate to C:\Program Files\OpenVPN\easy-rsa\keys\, you should see the newly minted CA certificate (ca.crt) and CA private key (ca.key) files.

Next, we’ll generate a certificate and private key for the OpenVPN server that resides in pfSense. Here we’ll need to pass a text string to the batch file when invoking it. That text string then becomes the name for the server’s certificate and private key. In this example, we’ll use the text string “pfsense”. As in the previous step, most values will be automatically initialized by vars.bat. Once again, the value for Common Name must be explicitly entered, which we’ll set to “pfsense” to match the name of the server key. This batch file will also seek to define some additional optional attributes, including the “challenge password”, used in certificate revocation, which we’ll leave blank, and the “company name”, which you may fill in if desired. Finally, you’ll be asked to sign the server’s certificate using the CA certificate. Review the server certificate carefully, then select “y” to sign and then to commit the signature:

C:\Program Files\OpenVPN\easy-rsa>vars.bat
C:\Program Files\OpenVPN\easy-rsa>build-key-server.bat pfsense
Generating a 4096 bit RSA private key
.......++++++
...........................++++++
writing new private key to 'keys\pfsense.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:
State or Province Name (full name) [CA]:
Locality Name (eg, city) [SanFrancisco]:
Organization Name (eg, company) [OpenVPN]:
Organizational Unit Name (eg, section) [changeme]:
Common Name (eg, your name or your server's hostname) [changeme]:pfsense
Name [changeme]:
Email Address [mail@host.domain]:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
WARNING: can't open config file: /etc/ssl/openssl.cnf
Using configuration from openssl-1.0.0.cnf
Loading 'screen' into random state - done
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :PRINTABLE:'CA'
localityName          :PRINTABLE:'SanFrancisco'
organizationName      :PRINTABLE:'OpenVPN'
organizationalUnitName:PRINTABLE:'changeme'
commonName            :PRINTABLE:'pfsense'
name                  :PRINTABLE:'changeme'
emailAddress          :IA5STRING:'mail@host.domain'
Certificate is to be certified until Jan 18 16:03:14 2022 GMT (3650 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

C:\Program Files\OpenVPN\easy-rsa>

C:\Program Files\OpenVPN\easy-rsa>vars.bat

C:\Program Files\OpenVPN\easy-rsa>build-key-server.bat pfsense

Generating a 4096 bit RSA private key

.......++++++

...........................++++++

writing new private key to 'keys\pfsense.key'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [US]:

State or Province Name (full name) [CA]:

Locality Name (eg, city) [SanFrancisco]:

Organization Name (eg, company) [OpenVPN]:

Organizational Unit Name (eg, section) [changeme]:

Common Name (eg, your name or your server's hostname) [changeme]:pfsense

Name [changeme]:

Email Address [mail@host.domain]:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

WARNING: can't open config file: /etc/ssl/openssl.cnf

Using configuration from openssl-1.0.0.cnf

Loading 'screen' into random state - done

Check that the request matches the signature

Signature ok

The Subject's Distinguished Name is as follows

countryName :PRINTABLE:'US'

stateOrProvinceName :PRINTABLE:'CA'

localityName :PRINTABLE:'SanFrancisco'

organizationName :PRINTABLE:'OpenVPN'

organizationalUnitName:PRINTABLE:'changeme'

commonName :PRINTABLE:'pfsense'

name :PRINTABLE:'changeme'

emailAddress :IA5STRING:'mail@host.domain'

Certificate is to be certified until Jan 18 16:03:14 2022 GMT (3650 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

Data Base Updated

C:\Program Files\OpenVPN\easy-rsa>

Finally, let’s generate our client certificate and key following steps similar to the ones we used above for creating the server certificate and key. This time, however, the text string we pass to the batch file will become the name for the client certificate and key. In this example, we’ll use the text string “bob”, and set the Common Name value to be the same. Review the client certificate carefully, then select “y” to sign and then to commit the signature. You’ll need to run this same batch file for each client you want to grant VPN access to – and remember, you’ll need to use a unique key name/Common Name combination for each one:

C:\Program Files\OpenVPN\easy-rsa>vars.bat 
C:\Program Files\OpenVPN\easy-rsa>build-key.bat bob
Generating a 4096 bit RSA private key
...........................++++++
....++++++
writing new private key to 'keys\bob.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:
State or Province Name (full name) [CA]:
Locality Name (eg, city) [SanFrancisco]:
Organization Name (eg, company) [OpenVPN]:
Organizational Unit Name (eg, section) [changeme]:
Common Name (eg, your name or your server's hostname) [changeme]:bob
Name [changeme]:
Email Address [mail@host.domain]:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from openssl-1.0.0.cnf
Loading 'screen' into random state - done
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :PRINTABLE:'CA'
localityName          :PRINTABLE:'SanFrancisco'
organizationName      :PRINTABLE:'OpenVPN'
organizationalUnitName:PRINTABLE:'changeme'
commonName            :PRINTABLE:'bob'
name                  :PRINTABLE:'changeme'
emailAddress          :IA5STRING:'mail@host.domain'
Certificate is to be certified until Jan 18 16:14:39 2022 GMT (3650 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

C:\Program Files\OpenVPN\easy-rsa>

C:\Program Files\OpenVPN\easy-rsa>vars.bat

C:\Program Files\OpenVPN\easy-rsa>build-key.bat bob

Generating a 4096 bit RSA private key

...........................++++++

....++++++

writing new private key to 'keys\bob.key'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [US]:

State or Province Name (full name) [CA]:

Locality Name (eg, city) [SanFrancisco]:

Organization Name (eg, company) [OpenVPN]:

Organizational Unit Name (eg, section) [changeme]:

Common Name (eg, your name or your server's hostname) [changeme]:bob

Name [changeme]:

Email Address [mail@host.domain]:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Using configuration from openssl-1.0.0.cnf

Loading 'screen' into random state - done

Check that the request matches the signature

Signature ok

The Subject's Distinguished Name is as follows

countryName :PRINTABLE:'US'

stateOrProvinceName :PRINTABLE:'CA'

localityName :PRINTABLE:'SanFrancisco'

organizationName :PRINTABLE:'OpenVPN'

organizationalUnitName:PRINTABLE:'changeme'

commonName :PRINTABLE:'bob'

name :PRINTABLE:'changeme'

emailAddress :IA5STRING:'mail@host.domain'

Certificate is to be certified until Jan 18 16:14:39 2022 GMT (3650 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

Data Base Updated

C:\Program Files\OpenVPN\easy-rsa>

To further protect OpenVPN access, you may wish to password-protect the client’s private key. To do this we’ll need use the build-key-pass.bat batch file. When used you’ll be prompted to to enter a password that will be used in conjunction with generating the private key. Now, anyone (including you) wishing to use this key when starting the OpenVPN connection will need to enter the correct password.

That’s it for installing OpenVPN and building your X.509 PKI in Windows. If you plan to use the pre-shared private key authentication method, you need only to generate a single RSA key that will be used in both the OpenVPN server and client(s). In this example, we’ll use “static-bob” as the key file name and place it in the same folder our other certificates and keys are located:

cd c:\Program Files\OpenVPN\easy-rsa\keys\
openvpn --genkey --secret static-bob.key

1 2	cd c:\Program Files\OpenVPN\easy-rsa\keys\ openvpn --genkey --secret static-bob.key

Installing OpenVPN and creating certificates and keys in Linux

If you’ve been following the installation and configuration of OpenVPN under Windows to this point, the steps used under Linux will seem familiar. To begin, download and install OpenVPN and easy-rsa using the distribution’s package manager. Using the Debian-based Ubuntu as an example:

sudo apt-get update
sudo apt-get install openvpn easy-rsa

1 2	sudo apt-get update sudo apt-get install openvpn easy-rsa

Now copy the OpenVPN scripts used to generate the various certificates and keys into a new directory:

sudo mkdir /etc/openvpn/easy-rsa
sudo cp -R /usr/share/easy-rsa/* /etc/openvpn/easy-rsa/

1 2	sudo mkdir /etc/openvpn/easy-rsa sudo cp -R /usr/share/easy-rsa/* /etc/openvpn/easy-rsa/

Then make a symbolic link to latest version of openssl.cnf contained in /etc/openvpn/easy-rsa. In this example the latest version is openssl-1.0.0.cnf:

cd /etc/openvpn/easy-rsa/
ln -s openssl-1.0.0.cnf openssl.cnf

1 2	cd /etc/openvpn/easy-rsa/ ln -s openssl-1.0.0.cnf openssl.cnf

We’re now ready to generate the various certificates and keys. Start by opening the file /etc/openvpn/easy-rsa/vars with your text editor and take a look at the variables KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL. Assigning values to these variables in vars helps speed the process of generating the various certificates and keys by initializing these common variables in the various easy-rsa scripts. You may leave them at their default values or change them if desired, however, don’t leave any blank.

Change to the root user:

sudo su

sudo su

Now, open a terminal, and run the following:

cd /etc/openvpn/easy-rsa/
source vars && ./clean-all

1 2	cd /etc/openvpn/easy-rsa/ source vars && ./clean-all

Running this sequence of commands for the first time will create the directory /etc/openvpn/easy-rsa/keys/, which will hold the certificates and keys we generate (Not that you can define the location of this directory using the variable KEY_DIR in vars). Also note that from now on, each time you run the clean-all script any existing certificates and keys in the keys directory will be deleted.

Okay then, let’s generate the CA private key and CA certificate. The build-ca script uses the “Organization Name” value as the default value for “Common Name”; however, we’ll change this to “openvpn-ca” in the following example. Values for “Organization Unit Name” and “Name” will also be requested and may be modified if desired:

root@ubuntu-vbox:/etc/openvpn/easy-rsa# source vars && ./build-ca
Generating a 2048 bit RSA private key
.....................................................................+++
..................+++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:
State or Province Name (full name) [CA]:
Locality Name (eg, city) [SanFrancisco]:
Organization Name (eg, company) [Fort-Funston]:
Organizational Unit Name (eg, section) [MyOrganizationalUnit]:
Common Name (eg, your name or your server's hostname) [Fort-Funston CA]:openvpn-ca
Name [EasyRSA]:
Email Address [me@myhost.mydomain]:
root@ubuntu-vbox:/etc/openvpn/easy-rsa#

root@ubuntu-vbox:/etc/openvpn/easy-rsa# source vars && ./build-ca

Generating a 2048 bit RSA private key

.....................................................................+++

..................+++

writing new private key to 'ca.key'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [US]:

State or Province Name (full name) [CA]:

Locality Name (eg, city) [SanFrancisco]:

Organization Name (eg, company) [Fort-Funston]:

Organizational Unit Name (eg, section) [MyOrganizationalUnit]:

Common Name (eg, your name or your server's hostname) [Fort-Funston CA]:openvpn-ca

Name [EasyRSA]:

Email Address [me@myhost.mydomain]:

root@ubuntu-vbox:/etc/openvpn/easy-rsa#

Now, if you navigate to /etc/openvpn/easy-rsa/keys/, you should see the newly minted CA certificate (ca.crt) and CA private key (ca.key) files.

Next, we’ll generate a certificate and private key for the OpenVPN server that resides in pfSense. Here we’ll need to pass a text string to the script when invoking it. That text string then becomes the name for the server’s certificate and private key. In this example, we’ll use the text string “pfsense”. As in the previous step, most values will be automatically initialized by the file vars. We’ll leave the Common Name value at the default “pfsense” to match the name of the server key. This script will also seek to define some optional attributes, including the “challenge password”, which we will leave blank, and the “company name”, which may be filled in if desired. Finally, you’ll be asked to sign the server’s certificate using the CA certificate. Review the values in the server certificate carefully, then select “y” to sign and then to commit the signature:

root@ubuntu-vbox:/etc/openvpn/easy-rsa# source vars 
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys
root@ubuntu-vbox:/etc/openvpn/easy-rsa# ./build-key-server pfsense
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys
Generating a 2048 bit RSA private key
..................................................................................+++
...............................................................................................................+++
writing new private key to 'pfsense.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:
State or Province Name (full name) [CA]:
Locality Name (eg, city) [SanFrancisco]:
Organization Name (eg, company) [Fort-Funston]:
Organizational Unit Name (eg, section) [MyOrganizationalUnit]:
Common Name (eg, your name or your server's hostname) [pfsense]:pfsense
Name [EasyRSA]:
Email Address [me@myhost.mydomain]:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
Can't open /etc/openvpn/easy-rsa/keys/index.txt.attr for reading, No such file or directory
139782511055296:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:74:fopen('/etc/openvpn/easy-rsa/keys/index.txt.attr','r')
139782511055296:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:81:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :PRINTABLE:'CA'
localityName          :PRINTABLE:'SanFrancisco'
organizationName      :PRINTABLE:'Fort-Funston'
organizationalUnitName:PRINTABLE:'MyOrganizationalUnit'
commonName            :PRINTABLE:'pfsense'
name                  :PRINTABLE:'EasyRSA'
emailAddress          :IA5STRING:'me@myhost.mydomain'
Certificate is to be certified until Apr 26 14:22:07 2028 GMT (3650 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
root@ubuntu-vbox:/etc/openvpn/easy-rsa#

root@ubuntu-vbox:/etc/openvpn/easy-rsa# source vars

NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys

root@ubuntu-vbox:/etc/openvpn/easy-rsa# ./build-key-server pfsense

NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys

Generating a 2048 bit RSA private key

..................................................................................+++

...............................................................................................................+++

writing new private key to 'pfsense.key'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [US]:

State or Province Name (full name) [CA]:

Locality Name (eg, city) [SanFrancisco]:

Organization Name (eg, company) [Fort-Funston]:

Organizational Unit Name (eg, section) [MyOrganizationalUnit]:

Common Name (eg, your name or your server's hostname) [pfsense]:pfsense

Name [EasyRSA]:

Email Address [me@myhost.mydomain]:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Using configuration from /etc/openvpn/easy-rsa/openssl.cnf

Can't open /etc/openvpn/easy-rsa/keys/index.txt.attr for reading, No such file or directory

139782511055296:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:74:fopen('/etc/openvpn/easy-rsa/keys/index.txt.attr','r')

139782511055296:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:81:

Check that the request matches the signature

Signature ok

The Subject's Distinguished Name is as follows

countryName :PRINTABLE:'US'

stateOrProvinceName :PRINTABLE:'CA'

localityName :PRINTABLE:'SanFrancisco'

organizationName :PRINTABLE:'Fort-Funston'

organizationalUnitName:PRINTABLE:'MyOrganizationalUnit'

commonName :PRINTABLE:'pfsense'

name :PRINTABLE:'EasyRSA'

emailAddress :IA5STRING:'me@myhost.mydomain'

Certificate is to be certified until Apr 26 14:22:07 2028 GMT (3650 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

Data Base Updated

root@ubuntu-vbox:/etc/openvpn/easy-rsa#

Finally, let’s generate our client certificate and key following steps similar to the ones we used above for creating the server certificate and key. This time, however, the text string we pass to the script will become the default name for the client certificate and key. In this example, we’ll use the text string “bob”, which will also become the default value for the Common Name. Review the client certificate carefully, then select “y” to sign and then to commit the signature. You’ll need run the this same script for each client you want to grant access to – and remember, you’ll need to use a unique key name/Common Name combination for each one:

root@ubuntu-vbox:/etc/openvpn/easy-rsa# source vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys
root@ubuntu-vbox:/etc/openvpn/easy-rsa# ./build-key bob
Generating a 2048 bit RSA private key
....................................................................................................................................................+++
................+++
writing new private key to 'bob.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]:
State or Province Name (full name) [CA]:
Locality Name (eg, city) [SanFrancisco]:
Organization Name (eg, company) [Fort-Funston]:
Organizational Unit Name (eg, section) [MyOrganizationalUnit]:
Common Name (eg, your name or your server's hostname) [bob]:bob
Name [EasyRSA]:
Email Address [me@myhost.mydomain]:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :PRINTABLE:'CA'
localityName          :PRINTABLE:'SanFrancisco'
organizationName      :PRINTABLE:'Fort-Funston'
organizationalUnitName:PRINTABLE:'MyOrganizationalUnit'
commonName            :PRINTABLE:'bob'
name                  :PRINTABLE:'EasyRSA'
emailAddress          :IA5STRING:'me@myhost.mydomain'
Certificate is to be certified until Apr 26 14:29:26 2028 GMT (3650 days)
Sign the certificate? [y/n]:
CERTIFICATE WILL NOT BE CERTIFIED
root@ubuntu-vbox:/etc/openvpn/easy-rsa#

root@ubuntu-vbox:/etc/openvpn/easy-rsa# source vars

NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys

root@ubuntu-vbox:/etc/openvpn/easy-rsa# ./build-key bob

Generating a 2048 bit RSA private key

....................................................................................................................................................+++

................+++

writing new private key to 'bob.key'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [US]:

State or Province Name (full name) [CA]:

Locality Name (eg, city) [SanFrancisco]:

Organization Name (eg, company) [Fort-Funston]:

Organizational Unit Name (eg, section) [MyOrganizationalUnit]:

Common Name (eg, your name or your server's hostname) [bob]:bob

Name [EasyRSA]:

Email Address [me@myhost.mydomain]:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Using configuration from /etc/openvpn/easy-rsa/openssl.cnf

Check that the request matches the signature

Signature ok

The Subject's Distinguished Name is as follows

countryName :PRINTABLE:'US'

stateOrProvinceName :PRINTABLE:'CA'

localityName :PRINTABLE:'SanFrancisco'

organizationName :PRINTABLE:'Fort-Funston'

organizationalUnitName:PRINTABLE:'MyOrganizationalUnit'

commonName :PRINTABLE:'bob'

name :PRINTABLE:'EasyRSA'

emailAddress :IA5STRING:'me@myhost.mydomain'

Certificate is to be certified until Apr 26 14:29:26 2028 GMT (3650 days)

Sign the certificate? [y/n]:

CERTIFICATE WILL NOT BE CERTIFIED

root@ubuntu-vbox:/etc/openvpn/easy-rsa#

To further protect OpenVPN access, you may wish to password-protect the client’s private key. To do this simply run the build-key-pass script instead instead of build-key. You will be prompted to enter a password that will be used in conjunction with generating the private key. Now, anyone (including you) wishing to use this key will need to enter the correct password.

That’s it for installing OpenVPN and building your X.509 PKI in Linux. If you plan to use the pre-shared private key authentication method instead, you need only to generate a single RSA key that will be used in both the OpenVPN server and client(s). In this example, we’ll use “static-bob” as the key file name and place it in the same directory our other certificates and keys are located:

cd /etc/openvpn/easy-rsa/keys/
openvpn --genkey --secret static-bob.key

1 2	cd /etc/openvpn/easy-rsa/keys/ openvpn --genkey --secret static-bob.key

* Note: when you’re finished using easy-rsa make sure to exit out of being the root user.

Configuring OpenVPN: X.509 PKI Authentication

Now that we’ve installed OpenVPN client software in Windows and Linux, and generated the various certificates and keys, let’s move on and discuss how to configure these clients and the OpenVPN server in pfSense for VPN access into our home network using the X.509 PKI authentication method. Before we do though, now would be a good time to move the file ca.key to a secure location. Recall, that the privacy of this key is what ensures the security of your entire OpenVPN PKI.

OpenVPN Server configuration in pfSense for X.509 PKI authentication

To configure the OpenVPN server in pfSense for X.509 PKI authentication, we’ll start by importing the server certificate and private key we created, as well as our CA certificate.

Log into your pfSense box’s “webConfigurator” interface and navigate to System->Cert. Manager->CAs. To import a new CA, select the “+ Add” icon. Add a name for your CA (e.g., “OpenVPN Server CA #1”) under “Desriptive name”, then click on the drop down list under “Method” and ensure that “Import an existing Certficate Authority” is selected. Carefully and securely copy the contents of the ca.crt file from the machine you generated it on and paste it into the “Certificate data” field, then select “Save”.

Now, navigate to System->Cert. Manager->Certificates and select the “+ Add/Sign” icon to import a new certificate and its private key. Ensure that “Import an existing Certificate” is selected under Method”, then add a name for your certificate (e.g., “OpenVPN Server Cert #1”) under “Descriptive name”. Carefully and securely copy the contents of the pfsense.crt file from the machine you generated it on and paste it into the “Certificate data” field, and the contents of pfsense.key into the “Private key data” field. Finish by selecting “Save”.

The information you copy from your pfsense.crt and pfsense.key files will no longer appear in these fields after you select Save. Rest assured, however, that they are stored in pfSense. In fact, you will find them stored as server1.cert and server1.key respectively, along with server1.ca, in /var/etc/openvpn after the OpenVPN server is created.

Next we’ll configure the various OpenVPN server parameters. Navigate to VPN->OpenVPN->Server and click on the “+ Add” icon to add a new OpenVPN server (See Figure 2).

Figure 2

Most of the parameters will be left at their default settings, however the following will need to be configured:

Server mode – We’re using the X.509 PKI authentication method for this example so we should select “Remote Access(SSL/TLS)” here.

Local port – This is the logical port that the OpenVPN server will listen on for VPN connections. To help improve security, we’ll avoid using OpenVPN’s default port 1194 and use port 13725 instead.

Description – Enter a description here for your reference. This field is optional but helpful.

TLS Configuration – Using this feature is beyond the scope of this post so for now uncheck “Use a TLS Key”. If you would like to learn more about using TLS authentication, consult the hardening OpenVPN security section of the OpenVPN documentation.

Peer Certificate Authority – Ensure that the CA you imported under System->Cert. Manager->CA (e.g., “OpenVPN Server CA #1”) is selected here.

Server certificate – Ensure that the certificate you imported under System->Cert Manager->Certificates (e.g., “OpenVPN Server Cert #1”) is selected here.

DH Parameter Length – Change this setting to “2048 bit” to match the default DH key length OpenVPN uses to generate the keys and certificates.

Encryption Algorithm – Set this to “AES-256-GCM”, a good strong algorithm that also matches the default NCP algorithm.

IPv4 Tunnel Network – This is the IPv4 subnet from which the OpenVPN server will assign IP addresses. The server will automatically assign the first host address from this subnet to itself, while the remaining host addresses will be used for remote VPN clients. Our example VPN network will use subnet 192.168.20.0/24 so enter that here.

IPv4 Local Network(s) – This is the subnet that will be accessable from the VPN; in other words, your home network’s subnet. Our example home network has the subnet 192.168.10.0/24 so enter that here.

Compression – Setting this parameter will result in compressing the traffic traversing your VPN connection, making more efficient use of your available bandwidth. LZO and LZ4 are different compression algorithms, with LZ4 generally offering the best performance with least CPU usage. Let’s use “LZ4 Compression v2 [compress lz4-v2]”.

In addition to the parameters above, there are several others you might be interested in depending upon your specific requirements. These are optional, but may help improve your OpenVPN experience:

Dynamic IP – This setting allows connected clients to retain their connections if their IP address changes.

Provide a default domain name to clients – This setting allows you to specify a domain name to be assigned to your VPN clients. You should enter the same domain name you entered in the “Domain” field under System -> General Setup.

DNS Server enable – This setting allows you to specify one or more DNS servers to be used by the OpenVPN clients while connected. If you’re using pfSense as your DNS forwarder, then enter the pfSense LAN IP address here, else enter the IP address(s) of the DNS servers you entered in the “DNS servers” fields under System -> General Setup.

NTP Server enable – This setting allows you to specify the NTP server(s) to be used by the OpenVPN clients while connected. If you’re using pfSense as your NTP server then enter the pfSense LAN IP address here, else enter the IP address(s) of the DNS servers you entered in the “DNS servers” fields under System -> General Setup.

NetBIOS enable – If you need Microsoft’s NetBIOS protocol then selecting this will ensure it is propogated over your VPN connection.

Verbosity level – I suggest changing this to “3 (Recommended)” to reduce the number of log entries.

When you’re finished making changes, select “Save” at the bottom of the page to complete the configuration.

Next, we’ll need to create two new firewall rules to allow our incoming OpenVPN connection to pass through to the OpenVPN server on the port it’s listening on. First, navigate to em>Firewall -> Rules, select the “Add” icon to add a rule to the bottom of the list and define following parameters:

Action: Pass
Interface: WAN
Protocol: UDP
Destination: WAN address
Destination port range: Custom 13725 To Custom 13725
Description: OpenVPN

When you’re finished making changes, select “Save” and “Apply Changes”.

Now navigate to Firewall -> Rules -> OpenVPN, select the “Add” icon and define following parameters:

Protocol: Any
Description: OpenVPN

Finally, we’ll need to add the openvpn() interface, which pfSense automatically creates when it enables the OpenVPN server. Navigate to Intefaces -> Assignments and add this interface, then select “Save” (See Figure 3).

Figure 3

OpenVPN client configuration in Windows for X.509 PKI authentication

To configure your Windows OpenVPN client for X.509 PKI authentication, copy the client certificate and key, as well as the CA certificate from C:\Program Files\OpenVPN\easy-rsa\keys\ to C:\Program Files\OpenVPN\config\. You’ll recall these files were bob.crt, bob.key, and ca.crt.

Next, we need to create an client configuration file so our OpenVPN client knows how to connect to the server. Fortunately, OpenVPN includes a sample client configuration file so we don’t have to create one from scratch. Copy the file C:\Program Files\OpenVPN\sample-config\client.ovpn to C:\Program Files\OpenVPN\config\. You can rename the file if desired, however, make sure to retain the *.ovpn extension. Open this file in your text editor and modify the remote line so that it specifies either the FQDN (“Fully Qualified Domain Name”) or WAN IP address of your pfSense box, followed by the port number the OpenVPN server is listening on, which in our case is port 13725:

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote <the-FQDN-or-WAN-IP-address-of-your-pfSense-box> 13725

# The hostname/IP and port of the server.

# You can have multiple remote entries

# to load balance between the servers.

remote <the-FQDN-or-WAN-IP-address-of-your-pfSense-box> 13725

We need to modify the cert and key lines so they point to our certificate and key file names:

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca ca.crt
cert bob.crt
key bob.key

# SSL/TLS parms.

# See the server config file for more

# description. It's best to use

# a separate .crt/.key file pair

# for each client. A single ca

# file can be used for all clients.

ca ca.crt

cert bob.crt

key bob.key

Since we’re not using a TLS key in this configuration let’s disable this feature. Comment out the line tls-auth ta.key 1:

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# If a tls-auth key is used on the server

# then every client must also have the key.

;tls-auth ta.key 1

We also need to tell the client which cryptographic algorithm to use. This should match the algorithm we configured in the OpenVPN server. Assuming you used the AES-256-GCM algorithm there then modify the cipher line so that it looks like the following:

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
cipher AES-256-GCM

# Select a cryptographic cipher.

# If the cipher option is used on the server

# then you must also specify it here.

cipher AES-256-GCM

Since we’ve enabled LZ4 v2 compression in the OpenVPN server let’s ensure that algorithm is also used in the client:

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
compress lz4-v2

# Enable compression on the VPN link.

# Don't enable this unless it is also

# enabled in the server config file.

compress lz4-v2

Finally, let’s uncomment the auth-nocache parameter to strengthen security a bit:

# Configuration can cache passwords in memory. 
# Use the auth-nocache option to prevent this.
auth-nocache

# Configuration can cache passwords in memory.

# Use the auth-nocache option to prevent this.

auth-nocache

Now we’re ready to make our first OpenVPN connection. First, if you’re using Window’s firewall, make sure it is configured to allow VPN traffic to pass to/from the TAP-Windows adapter installed by OpenVPN. Now, open the Windows Start menu and select “OpenVPN”, then “OpenVPN GUI”, The OpenVPN GUI will launch and automatically minimize to the task tray. Right-click on the icon and select connect. If you elected to use a password to protect the client private key you’ll be asked to enter that password before OpenVPN will proceed with the connection (See Figure 3). After the OpenVPN client connects with the server in pfSense, the GUI will once again minimize to the task tray. Now try to ping the IP address of a host on the home network’s subnet. If the ping succeeds, congratulations! You’re now securily connected through your pfSense box to your home network using OpenVPN and X509 PKI authentication.

Figure 4

By the way, there are a couple of other ways you can start your OpenVPN connection in Windows. You can simply right click on an OpenVPN configuration file and selecting “Start OpenVPN on this config file.” You can also start it by using the command openvpn at a command prompt – you’ll need to be in the folder c:\Program Files\OpenVPN\config for this to work (else make the appropriate adjustments to your PATH environmental variable). Using the F4 key will terminate the connection.

OpenVPN client configuration in Linux for X.509 PKI authentication

To configure your Linux OpenVPN client in Linux for X.509 PKI authentication, move the client certificate and key files, as well as the CA certificate from /etc/openvpn/easy-rsa/keys/ to /etc/openvpn/. You’ll recall these files were bob.crt, bob.key, and ca.crt.

cd /etc/openvpn/
sudo mv easy-rsa/keys/{bob.crt,bob.key,ca.crt} .

1 2	cd /etc/openvpn/ sudo mv easy-rsa/keys/{bob.crt,bob.key,ca.crt} .

Next, we need to create a client configuration file so our OpenVPN client knows how to connect to the server. Fortunately, OpenVPN for Linux includes a sample configuration file so we don’t have to create one from scratch. Copy the file /usr/share/doc/openvpn/examples/sample-config-files/client.conf to /etc/openvpn/. You can rename the file if desired, however, make sure to retain the *.conf extension. Now open this file in your text editor and make the same changes as descibed above for the OpenVPN client configuration file in Windows. Remember to save your changes. Now we’re ready to make our first VPN connection. Open a terminal and use the following commands, replacing client.conf with the name of your configuration file if you changed it:

cd /etc/openvpn/
sudo openvpn client.conf

1 2	cd /etc/openvpn/ sudo openvpn client.conf

If you elected to use a password to protect the client private key, then you’ll be asked to enter that password before OpenVPN will proceed with the connection, which will end with a “Initialization Sequence Completed” message. Now, open another terminal, and try to ping the IP address of a host on the home network’s subnet. If the ping succeeds, congratulations! You’re now securily connected through your pfSense box to your home network using OpenVPN and X509 PKI authentication.

To simplify troubleshooting, it’s best to initially start the OpenVPN client from the command line as described above. However, once you know it can reliably connect to the server, then you can start it as a daemon. However, if you’ve elected to password protect the client key (e.g., bob.key) when generating it using the ./build-key-pass script, you may need to first add the password to some type of Linux password agent. For example, to add the password to Ubuntu’s password agent systemd-tty-ask-password-agent:

iceflatline@ubuntu-vbox:~$ sudo systemd-tty-ask-password-agent
Enter Private Key Password: ***********************

1 2	iceflatline@ubuntu-vbox:~$ sudo systemd-tty-ask-password-agent Enter Private Key Password: ***********************

Then you can start the OpenVPN daemon as follows:

sudo service openvpn start

1	sudo service openvpn start

When executed, OpenVPN will scan for any configuration files (i.e. *.conf) in /etc/openvpn/, and will attempt to start a separate daemon for each one it finds.

Configuring OpenVPN: Pre-shared Private Key Authentication

Having previously gone through the steps necessary to configure the OpenVPN server and clients for OpenVPN access into our home network using the X.509 PKI authentication method, it’s time now to discuss how to configure these same components for OpenVPN access using pre-shared private key authentication. Once again, to help explain the steps involved, we’ll assume there is an existing home network that is currently using the IP subnet 192.168.10.0/24; we’ll use the subnet 192.168.20.0/24 for our VPN; and, we’ll designate UDP port 13725 as the port the OpenVPN server will listen on (See Figure 1).

OpenVPN server configuration in pfSense for pre-shared private key authentication

Log into your pfSense box’s “webConfigurator” interface navigate to VPN->OpenVPN->Server and click on the “+ Add” icon to add a new OpenVPN server (See Figure 2). Most of the options will be left at their default settings, however the following will need to be configured:

Server mode – We’re using the pre-shared private key authentication method in this example so we should select “Peer to Peer (Shared Key)” here.

Description – Enter a description here for your reference. This field is optional but helpful.

Shared Key – Uncheck the “Automatically generate a shared key” box and then carefully and securely copy the contents of the static-bob.key file from the machine you generated it and paste it into the provided field.

Encryption algorithm – This is the cipher that OpenVPN will use to secure your VPN traffic. Since GCM encryption algorithms can’t be used with shared key server mode let’s use AES-256-CBC.

IPv4 Tunnel Network – This is the subnet from which the OpenVPN server will assign IP addresses. The server will automatically assign the first host address from this subnet to itself, while the remaining host addresses will be used for remote VPN clients. Our example VPN network will use subnet 192.168.20.0/24 so enter that here.

IPv4 Remote network(s) – This is the subnet that will be accessable from through the VPN; in other words, your home network’s subnet. Our example home network has the subnet 192.168.10.0/24 so enter that here.

Verbosity level – I suggest changing this to “3 (Recommended)” to reduce the number of log entries.

When you’re finished making changes, select “Save” at the bottom of the page to complete the configuration.

Action: Pass
Interface: WAN
Protocol: UDP
Destination: WAN address
Destination port range: Custom 13725 To Custom 13725
Description: OpenVPN

When you’re finished making changes, select “Save” and “Apply Changes”.

Now navigate to Firewall -> Rules -> OpenVPN, select the “Add” icon and define following parameters:

Protocol: Any
Description: OpenVPN

OpenVPN client configuration in Windows for pre-shared private key authentication

To configure your Windows client for pre-shared private key authentication, copy the key file static-bob.key from c:\Program Files\OpenVPN\easy-rsa\keys\ to c:\Program Files\OpenVPN\config\. Now we need to create an client configuration file so our OpenVPN client knows how to connect to the server. Since OpenVPN for Windows doesn’t include a sample client configuration file for the pre-shared private key authentication method, we’ll use the following, which is based on the sample static-home configuration file included with the OpenVPN installation in Linux. Copy and paste this text into your text editor and modify the remote line so that it specifies either the FQDN (“Fully Qualified Domain Name”) or WAN IP address of the pfSense box, followed by the port number the OpenVPN server is listening on, which in our example case is port 13725. The secret line specifies the name of our static key file, which in our case is static-bob.key. Save the file as client.ovpn and copy it to c:\Program Files\OpenVPN\config\. You can rename the file if desired, however, make sure to retain the *.ovpn extension:

### README
#
# Date:
# Description: Client configuration for shared private key authentication
# Author:
# Process(s): openvpn
# Configuration: 
#
### START OF CONFIGURATION

# '#' or ';' may be used to delimit comments.

# Use a dynamic tun device.
# OpenVPN also supports virtual
# ethernet "tap" devices.
;dev tap
dev tun

# Our OpenVPN peer is the OpenVPN server in our pfSense box
remote <the-FQDN-or-WAN-IP-address-of-your-pfSense-box> 13725

# 192.168.20.1 will be our OpenVPN server endpoint
# 192.168.20.2 will be our local OpenVPN endpoint
ifconfig 192.168.20.2 192.168.20.1

# The route to our local network
route 192.168.10.0 255.255.255.0

# Add a route to our home network subnet
route 192.168.10.0 255.255.255.0

# Our pre-shared private key
secret static-bob.key

# Compression to use
compress lz4-v2

# Cipher to use
cipher AES-256-CBC

# Send a UDP ping to remote once
# every 15 seconds to keep
# stateful firewall connection
# alive.  Uncomment this
# out if you are using a stateful
# firewall.
; ping 15

# Uncomment this section for a more reliable detection when a system
# loses its connection.  For example, dial-ups or laptops that
# travel to other locations.
; ping 15
; ping-restart 45
; ping-timer-rem
; persist-tun
; persist-key

# Log file verbosity
verb 3

# Configuration can cache passwords in memory. 
# Use the auth-nocache option to prevent this.
auth-nocache

### README

# Date:

# Description: Client configuration for shared private key authentication

# Author:

# Process(s): openvpn

# Configuration:

### START OF CONFIGURATION

# '#' or ';' may be used to delimit comments.

# Use a dynamic tun device.

# OpenVPN also supports virtual

# ethernet "tap" devices.

;dev tap

dev tun

# Our OpenVPN peer is the OpenVPN server in our pfSense box

remote <the-FQDN-or-WAN-IP-address-of-your-pfSense-box> 13725

# 192.168.20.1 will be our OpenVPN server endpoint

# 192.168.20.2 will be our local OpenVPN endpoint

ifconfig 192.168.20.2 192.168.20.1

# The route to our local network

route 192.168.10.0 255.255.255.0

# Add a route to our home network subnet

route 192.168.10.0 255.255.255.0

# Our pre-shared private key

secret static-bob.key

# Compression to use

compress lz4-v2

# Cipher to use

cipher AES-256-CBC

# Send a UDP ping to remote once

# every 15 seconds to keep

# stateful firewall connection

# alive. Uncomment this

# out if you are using a stateful

# firewall.

; ping 15

# Uncomment this section for a more reliable detection when a system

# loses its connection. For example, dial-ups or laptops that

# travel to other locations.

; ping 15

; ping-restart 45

; ping-timer-rem

; persist-tun

; persist-key

# Log file verbosity

verb 3

# Configuration can cache passwords in memory.

# Use the auth-nocache option to prevent this.

auth-nocache

If you would like to specify a domain name to be assigned to your VPN client, add the following line to your client configuration file. You should enter the same domain name you entered in the “Domain” field under System -> General Setup.

dhcp-option DOMAIN <em>your-domain-name>

1	dhcp-option DOMAIN <em>your-domain-name>

If you would like to specify the DNS server(s) to be used by your OpenVPN client while connected, add the following line to your client configuration file. If you’re using pfSense as your DNS forwarder, then specify the pfSense LAN IP address here, else specify the IP address(s) of the DNS servers you entered in the “DNS servers” fields under System -> General Setup.

dhcp-option DNS <your-DNS-IP-address>

1	dhcp-option DNS <your-DNS-IP-address>

Now we’re ready to make our OpenVPN connection. First, if you’re using Window’s firewall, make sure it is configured to allow VPN traffic to pass to/from the TAP-Windows adapter installed by OpenVPN. Now, open the Windows Start menu and select “OpenVPN”, then “OpenVPN GUI.” The OpenVPN GUI will launch and automatically minimize to the task tray. Right-click on the icon and select connect. After the OpenVPN client connects with the server in pfSense, the GUI will once again minimize to the task tray. Now try to ping the IP address of a host on the home network’s subnet. If the ping succeeds, congratulations! You’re now securily connected through your pfSense box to your home network using OpenVPN and pre-shared private key authentication.

OpenVPN client configuration in Linux for pre-shared private key authentication

To configure your Linux OpenVPN client in Linux for pre-shared private key authentication, copy the key file static-bob.key from /etc/openvpn/easy-rsa/keys/ to /etc/openvpn/. Then, copy the sample configuration file discussed above in the Windows section to /etc/openvpn/ (Alternatively you can use the sample configuration file included with OpenVPN for Linux. See /usr/share/doc/openvpn/examples/sample-config-files/static-home.conf). You can rename the file if desired, however, make sure to retain the *.conf extension. Now, open the file in your text editor and make the appropriate changes to the remote and secret lines as discussed above for the Windows configuration file. Remember to save your work.

Now we’re ready to make our VPN connection. Open a terminal and use the following commands, replacing client.conf with the name of your config file if you changed it:

cd /etc/openvpn/
sudo openvpn client.conf

1 2	cd /etc/openvpn/ sudo openvpn client.conf

sudo service openvpn start

1	sudo service openvpn start

Now, open another terminal, and try to ping the IP address of a host on the home network’s subnet. If the ping succeeds, congratulations! You’re now securily connected through your pfSense box to your home network using OpenVPN and pre-shared private key authentication.

Conclusion

This concludes the post on how to configure secure remote access to your home network using pfSense and OpenVPN. Two methods are typically used by OpenVPN to authenticate the server and remote clients to one another: X.509 PKI or pre-shared private keys. The X.509 PKI method offers scalability and arguably better security, but may be overkill for those that want single-user VPN access to their home network. Conversly, the pre-shared key method does not scale well beyond one or two users, but is easier to setup and likely just fine for a small network with a limited number of remote VPN clients. For a full list of all the configuration options and other information I encourage you to visit the OpenVPN community software web site.

References

http://www.openvpn.net/index.php/open-source/documentation.html