Tag: Linux

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).

Screenshot of example network using OpenVPN server and pfSense

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:

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:

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:

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:

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:

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:

    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:

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

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:

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:

Now, open a terminal, and run the following:

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:

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:

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:

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:

* 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).

Screenshot of pfSense configuration wizard

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).

Screenshot of showing the assignment of the OpenVPN interface

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:

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

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:

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:

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

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

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.

Screenshot of OpenVPN GUI launching VPN connection with password field

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.

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:

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:

Then you can start the OpenVPN daemon as follows:

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.

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.

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.

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]”.

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).

    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:

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.

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.

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:

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:

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

Linux

Using The dd Command to Create Files of a Specific Size

Occasionally, the need arises for files of a specific size. Transferring said files between hosts, for example, can provide a quick indication of your network throughput. One easy way to build a file of a specific size is with the Data Description or dd command. The dd command is one of the original Unix utilities, used to perform low-level copying of a specified input file to the specified output file (standard input to standard output is the default) according to operands, while optionally performing conversions on the raw data. You’ll often see it used to create an image of a entire disk or the disk’s Master Boot Record, or to make a disk from an image.

Let’s open a terminal in Linux and create a file named “test-file” that’s one kilobyte (decimal units) in size:

You should see something that resembles the following output:

To create a larger file, say one megabyte or one gigabyte, replace the KB multiplicative suffix in the bs operand with MB or GB respectively:

How about a file that’s 1.5 gigabytes? You can accomplish this by adjusting the bs multiplicative suffix and the number of blocks in the count operand:

To use binary units (multiplication by a power of 2) instead of decimal units, simply drop the “B” in the bs multiplicative suffix. Let’s recreate our test file using binary units (one megabyte = 1048576 bytes):

Note for users of FreeBSD (and possibly other Unix-like operating systems), the dd command supports binary units only. For example, attempting to use bs=1MB instead of bs=1M will result in an error.

There you have it. A nice simple way to create files of a specific size for network testing or whatever your needs might be. Leave comment if you have a favorite use for the dd command.

Linux

Installing SliTaz Linux on a Hard Drive

I had the pleasure of trying SliTaz Linux recently, a small, lightweight distro available as a LiveCD/DVD or startup image. Given its minimal size, SliTaz is ideally designed to boot from a LiveCD/DVD or USB drive and then reside in system memory, allowing you to remove the boot media if desired. While extremely useful this way, I decided to try out a less ephemeral installation option. This post will describe my experience installing SliTaz on a hard drive. The software versions used in this post were as follows:

  • SliTaz GNU/Linux v3.0
  • GParted v0.5.2-9

Configuring the Hard Drive for SliTaz Installation

To begin, I download the SliTaz LiveCD Stable version ISO and burned it to a CD. Once it was up and running, I navigated to SliTaz’s built-in installation utility located at System Tools->Slitaz installer. This same utility can also be reached from the command line. The root password in either case is “root”.

SliTaz’s ncurses-based installer is nothing if not minimilistic. However, I found it quite usuable assuming you’ve had some prior experience installing linux distributions (See Figure 1). SliTaz’s documentation suggests a minimum of 120 MB of free space. However, shortly after I finished my installation I ran df -h and determined it had consumed 285.8 MB, so I would recommend a minimum of 300 MB of free space.

Screenshot of the SliTaz installer utility - initial

Figure 1

I found out quickly that the installer did lack one common feature though, a built-in partitioning tool. That meant that before I could proceed with installation, I needed a free partition ready to use, or needed to create one using Gparted (available on the SliTaz LiveCD), fdisk, or similar utility. I used Gparted to create a single primary partition (due to its deminimus size, SliTaz needs no Linux Swap partition). I verified which partitions SliTaz recognized as available by using the installer’s List menu option (See Figure 2).

Screenshot of the SliTaz installer utility - partition list

Figure 2

After determining which partition to install SliTaz and manually entering it into the installer (in my case /dev/hdc1), I moved on to format this partition. The only file system option here is ext3, but you can skip this step if you’ve previously formatted the partition using Gparted or another parition creation utiity. The installer then offered the option of creating a separate /home directory, which I declined, and then moved on to configuring the host name, as well as root and non-root account names and passwords. I was then presented with the option of installing the GRUB bootloader (See Figure 3).

Screenshot of the SliTaz installer utility - GRUB

Figure 3

It appears the SliTaz installer only provides the option to install GRUB on the disk Master Boot Record. If I’d wanted to install GRUB on different partition, I would need to edit GRUB’s configuration file /boot/grub/menu.lst . Since SliTaz was the only operating system planned for this hard drive, I confirmed the GRUB location and the installer quickly installed SliTaz on my hard drive. After rebooting the system I was presented with the typical GRUB menu presenting SliTaz as the (only) operating system choice listed. However, trying to boot into SLiTaz from GRUB menu I was presented with an “Error 21” as shown in Figure 4.

Screenshot of GRUB error 21

Figure 4

Looking closely at the error message it appears GRUB thought that the partition for SliTaz was located on the first partition of drive hd2 (hd2,0). Since this was the only hard disk installed on the system during the install, I suspect it should have been assigned to the first partition of hd0 or (hd0,0). To verify, I rebooted using the SliTaz LiveCD, mounted /dev/hdc1, and looked at the GRUB device map to see what GRUB named the drive (See Figure 5).

Screenshot of SliTaz terminal - GRUB device.map

Figure 5

It appears GRUB assigned (hd0) to the drive /dev/hdc. Then I looked at GRUB’s configuration file to determine which partition was configured for the SliTaz boot partition /dev/hdc1 (See Figure 6).

Screenshot of SliTaz terminal - GRUB menu.lst

Figure 6

As I suspected, the SliTaz installer assigned /dev/hdc1 to (hd2,0), a nonexistent drive and partition. To fix this I simply changed (hd2,0) to (hd0,0) and I was back in business.

What may have occurred was that my hard drive was attached as a master on the secondary EIDE slot on the motherboard. Even though it was the only hard drive attached to the system at the time of the install, the SliTaz installer erroneously assumed it was the third and designated it as /dev/hdc. This led to the problem later when the GRUB device map did not agree with the GRUB configuration file.

Conclusion

Despite the lack of some features in the SliTaz installer and the GRUB Error 21 problem, I found installing SliTaz Linux to be a fairly straightforward affair.

References

http://www.slitaz.org/en/doc/handbook/install.html
https://help.ubuntu.com/community/GrubHowto

Networking

How to Install and Configure dnsmasq

This post will describe how to install and configure dnsmasq on a Linux- or Unix-based host. Once configured, you’ll be able to use dnsmasq to provide DNS and DHCP services in your home network.

So, why do you even need dnsmasq? Afterall, your ISP provides DNS and your home network gateway/router likely provides DHCP service for your network, right? Perhaps the best way to answer then is to explain the problem I was trying to solve. In my home network I would typically assign a static IP address to each host on my network, and then use its host file to resolve the host’s name to the IP address it was assigned. This approach allowed me to easily communicate between these hosts by simply typing their name rather than trying to remember their static IP address. However, as the number of hosts on my network started to grow, configuring static IP addresses and constantly updating the host files became unwieldy. dnsmasq solves this problem.

dnsmasq is a small, lightweight, and easy to configure caching DNS proxy and DHCP server targeted at small or home networks. It can serve the names of local hosts which are not in the global DNS, and its DHCP server integrates with its DNS server to allow hosts with DHCP-allocated addresses to appear in the DNS along with names configured either in each host or in its configuration file. dnsmasq supports static and dynamic DHCP leases and even BOOTP/TFTP for network booting of diskless hosts. dnsmasq is opensource software and is distributed under the terms of the GPL. Supported platforms include Linux, *BSD, Solaris and Mac OS X.

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

  • FreeBSD 7.2 RELEASE and dnsmasq v2.52,1
  • Fedora v12 and dnsmasq v2.51-1.fc12
  • Ubuntu server v9.10 and dnsmasq v2.47-3_all.deb

    • Download and Install

    I chose to install dnsmasq on my Ubuntu server-based machine. However, any host on your network in which you can add one or more external nameservers to /etc/resolv.conf and some or all of your hosts in /etc/hosts, can easily be used for hosting dnsmasq.

    To install dnsmasq on a Debian-based distribution like Ubuntu:

    On Fedora-based distributions:

    And on *BSD, if you’ve installed the Ports collection:

    Or, if you would prefer to add the package:

    The dnsmasq script will be installed in /etc/init.d, symlinked from runlevels 2-5, and start automatically in a Debian-based distribution like Ubuntu. In Fedora-based distributions, the dnsmasq script is installed in /etc/init.d; however, you will need to create a symbolic link to it from the appropriate runlevel directory in order for it to start automatically at boot time. This is typically done using chkconfig command as root. The following example shows how to add the dnsmasq script to runlevels 2-5 and start dnsmasq in Fedora:

    Newer versions of Fedora, however, may require this set of commands instead:

    In *BSD, the dnsmasq script will be installed in /usr/local/etc/rc.d. To get dnsmasq to start at boot time, add the following line to /etc/rc.conf:

    Then start dnsmasq:

    Configure

    Configuring dnsmasq is straightforward. The various DHCP and DNS options can be passed via command line when starting dnsmasq, or may be set via its configuration file, dnsmasq.conf. I generally prefer to use dnsmasq’s configuration file; it’s very well commented and easy to follow.

    Let’s walk through the changes I made to the default configuration file in order to provision both DNS and DHCP service for my network. Make sure you create a backup copy of your default file before you begin.

    To start, I uncommented the following two options to force dnsmasq to filter my local network DNS queries so they did not reach the public DNS servers.

    By default, dnsmasq will send queries to any of the nameservers you define in /etc/resolv.conf, however, it will try to favor those it knows to be up. Uncommenting the following setting forces dnsmasq to use the nameservers listed in /etc/resolv.conf strictly in the order they appear. Since I had a pretty good sense of which DNS servers I wanted to use and in what order I uncommented this line:

    By default dnsmasq will listen for DNS queries on all network interfaces. I have several interfaces on my server (Hamachi, eth0, eth1, etc.), but only one that is physically connected to my local network, so I uncommented the following line in order to force dnsmasq to listen for DHCP and DNS requests on that interface only – in my case eth0. Simply repeat the line with the another interface name if you have additional interfaces you would like dnsmasq to listen to.

    The following two lines are optional; however, if used, dnsmasq will append the domain name you choose to the host names defined in dnsmasq.conf and/or /etc/hosts. I use these, but the only real benefit I saw in my network was that I was able to ping devices such as my game consoles based on the names I defined for them using the dhcp-host parameter (see below).

    To enable dnsmasq’s integrated DHCP server you’ll need to uncomment the following line and provide the range of addresses available for lease in your network, and optionally, a lease time.

    If you have a host on your network that you’d like to have receive the same IP address every lease, then uncomment the following line and provide the host’s MAC address, as well as the preferred IP address – one from the dhcp-range you defined above. For example, I like to have the computer I use most often receive the same IP address. That way I can easily forward ports to it, etc. Alternatively, I could have simply given it a static IP address and defined the name/address combination in the /etc/hosts file of the machine hosting dnsmasq.

    If your network is anything like mine you probably have devices that don’t have a host names associated with them the same way a computer does (e.g., Xbox 360). The following parameter will assign a name to these devices in dnsmasq. You’ll need to provide the devices’s MAC address and the name you’d like associated with it. Here’s an example of how I have this defined in my network:

    By default dnsmasq assumes that host running dnsmasq is your gateway/router. That wasn’t the case in my network so I needed to specify the IP address of my Cisco gateway/router in the following line:

    The DHCP server needs somewhere keep its lease database file. I simply retained the default location chosen by dnsmasq for my Ubuntu server install. Note that this default location will vary depending on which platform your using to host dnsmasq:

    Finally, you can adjust the number of entries dnsmasq will keep in its DNS cache in the following line. I retained the default of 150.

    That’s it for configuring dnsmasq.conf. Keep in mind though that the options described here really only scratch the surface. I would strongly urge you to read through dnsmasq.conf thoroughly as there are many more options available for fine-tuning dnsmasq’s numerious capapbilities. But for now let’s move on and consider two additional files, /etc/resolv.conf and /etc/hosts, that are important when configuring dnsmasq.

      resolv.conf

    dnsmasq will consult a several locations when going about the business of resolving your network’s DNS queries. These locations include its internal cache, for any queries it may have already resolved; /etc/hosts, for any static name/IP address combinations that may be defined there; and, if the DHCP server is being utilized, it will of course know from its configuration file and lease database file which IP addresses it has assigned to the hosts configured to use DHCP. When it can’t resolve DNS queries via these methods, dnsmasq will send queries to the nameservers defined in /etc/resolv.conf. You must have at least one public DNS server defined there and it’s typical to simply use the DNS server(s) provided by your ISP. Following is an example of how I have my /etc/resolv.conf file configured. Recall that I uncommented the strict-order line in dnsmasq.conf as described above so dnsmasq will utilize DNS servers in the order I have them listed here.

      /etc/hosts

    As I mentioned, dnsmasq will consult the /etc/hosts file on the host its running on when resolving DNS queries. This comes handy when there are hosts in your network that you have assigned, or would like to assign, static IP addresses to. In those cases the host name/IP address combinations can simply be added to /etc/hosts. In fact, if desired, you could elect not to use dnsmasq’s DHCP server at all and rely soley on dnsmasq’s use of /etc/hosts to resolve local IP addresses. In this respect, /etc/hosts is no different than any other host file resident on most computers except that now you only need to maintain the one file. Of course, the tradeoff is that you’ll need to configure static IP addresses on all your hosts. I settled on a hybrid approach for my network. I configured all client hosts (laptops, desktop PCs, game consoles, etc) to use dnsmasq’s DHCP server, and configured all servers and network equipment (access point, router, network printers, etc.) with static IP addresses. Here’s an example of my /etc/hosts file:

    Final Steps

    Once dnsmasq.conf, /etc/resolv.conf, and /etc/hosts are configured to your liking restart dnsmasq:

    Or, if your using *BSD:

    Make sure to disable any other DHCP servers that may be running in your network, then simply configure your hosts to use DHCP – they should recieve an IP address that’s in the range defined in dnsmasq.conf. If you’re planning on configuring some hosts with static IP addresses, set the IP address of the host running dnsmasq as the DNS server and IP address of the gateway/router as the gateway. You’ll also want to make sure to enter that host/IP address information in /etc/hosts on the host running dnsmasq. That’s it! You now have DNS and DHCP service up and running in your network.

    Now let’s run a quick test to make sure dnsmasq is caching DNS queries. The simplest to do that is to use the dig utility:

    When you look at the output from dig and find the line showing the query time. Note the time and run the command again. You should see a noticable improvement in response time indicating that dnsmasq is caching query results locally.

    Conclusion

    This concludes the article on how to install and configure dnsmasq on your Linux- or Unix-based host. As you can see, dnsmasq isn’t terribly complicated and proves to be a really nice open source package for implementing a small, lightweight caching DNS proxy and DHCP server. For a full list of all the configuration options and other information I encourage you to visit the dnsmasq web site.

    References

    http://www.thekelleys.org.uk/dnsmasq/docs/setup.html
    http://www.thekelleys.org.uk/dnsmasq/docs/FAQ

    Linux

    My Conky Configuration

    One of my favorite things about using Linux and BSD is Conky. Conky is a free, light-weight system monitor that can display nearly any information about your system directly on your desktop. Originally a fork of Torsmo, Conky’s torsmo-based code is BSD licensed. New code in Conky has been licensed under the GPL 3.0.

    Installation is easy. On a Debian-based distribution like Ubuntu:

    On Fedora-based distributions:

    And on BSD, if you’ve installed the Ports collection:

    Or if you would prefer to add the package:

    Conky is very simple to configure. Using a pre-defined set of variables in a configuration file you define what Conky should monitor and where those monitored parameters are displayed on your desktop. The look and feel of what’s displayed is highly customizable.

    On most systems the default configuration file location is /etc/conky/. There you will find the sample configuration file conky.conf. You’ll want to copy it to ~/.conkyrc and then start modifying it.

    When setting up my Conky configuration, I decided to dispense with the fancy network graphs and other eye candy that I’ve seen in so many others use and go with a more utilitarian approach. I settled on four areas for Conky to monitor:

    • System – basic system information showing kernel version, uptime, total RAM and Swap usage, etc.
    • Processor – shows the top five applications or processes based on CPU usage
    • Memory – shows the top five applications or process based on system RAM usage
    • Network – shows basic information regarding wired and wireless connections, including IP address, inbound and outbound speed, connection quality, etc.

    This minimalistic approach looks good (less “cluttered”) in my humble opinion, and provides just the information I need while not straining system resources.

    One of the many cool things about Conky is its support for the use of conditional statements within its configuration file. The ${if_existing} variable, as an example, checks for the existence of a file passed to it as an argument and will display everything between ${if_existing} and the matching ${endif}. I used this particular variable to my advantage when configuring the network monitoring section. Instead of displaying information about each wired and wireless interface, even when they weren’t up, I chose instead to display information about them only if they were up by using the existence of a particular interface (e.g., eth0) in /proc/net/route.

    Anyhoo, here’s the configuration file I’m currently using. Feel free use it as is or change it to fit your needs and taste. Post your Conky configuration in the comment section.

    And here are some screenshots:

    Screenshot of Conky running on my Crunchbang linux desktop

    Figure 1

    Screenshot of Conky running on my Crunchbang linux desktop

    Figure 2