Step-by-step Guide On How To Setup OpenVPN From pfSense’s Web-GUI (USER/PASS Auth)



OpenVPN is the most simplest open source software out there that implements a secure virtual private networking (VPN) techniques to secure your connection, whether it be a site-to-site or point-to-point connection. It is comes built-in with pfSense router software and it’s simple to use and easy to configure. In this guide, you’ll gonna learn how to configure an OpenVPN server under pfSense’s long list of useful features and services. I will show you how you would configure a client machine to connect to the OpenVPN server, both under Windows and Linux machines. To start with this guide, you must have already

installed and configured your pfSense machine and that you already have a working local area network.

Part 1: Setting Up The Server

The first part of this guide will show you how to bring up the OpenVPN server instance using pfSense’s webConfigurator GUI. This method is by far the most easiest way to setup an VPN access server, compared to the command-line method of configuration. Take note that, version 2.1.4 release of pfSense was used for this guide.

  • Step 1: For the first step, you need to create a Certificate Authority that will be used to sign future user certificates. So whenever you create a new user certificate, this Certificate Authority shall be in charge in signing those newly created certificates. To do this, you must login to pfSense webConfigurator or admin web page, by accessing its IP address using a browser. So type in and press key. Login by supplying the correct data for the user and user-password. Upon logging in, navigate to Main Menu -> -> . Make sure you’re on the tab, to add a new CA (Certificate Authority), click on plus button. A new page should open, now fill up the necessary fields.

    This is how I did:

    • Method – Create an internal Certificate
    • Descriptive name – MyCA
    • Method – Create an internal Certificate Authority
    • Key length – 2048 bits
    • Digest Algorithm – SHA256
    • Lifetime – 3650
    • Common Name – Internal-CA

Those are the most important fields to fill up on this page. But don’t miss to fill up the Country Code, State or Province, City, Organization and Email Address. Enter what’s applicable to you. Save your settings by clicking the

button. You should see a page similar to the image shown below.


pfSense OpenVPN CA Certificate Setup - Image 1

pfSense OpenVPN CA Certificate Setup - Image 2

pfSense OpenVPN CA Certificate Setup - Image 3

  • Step 2: While still on the tab, add another certificate by clicking the plus button. This process is similar to the steps you took under Step 1. But this time, you’ll be creating a for OpenVPN Server. Click the add button again and fill up the necessary fields like so:
    • Method – Create an internal Certificate
    • Descriptive name – MyOpenVPN-Server-Cert
    • Certificate authority – MyCA
    • Key length – 2048 bits
    • Digest Algorithm – SHA256
    • Certificate Type – Server Certificate
    • Lifetime – 3650
    • Common Name –

    Note: Substitute the values with your own data. Fill up the other fields; Country Code, State or Province, City, Organization and Email Address. Then to save your settings. You should see a page similar to the image shown below. Reference Image:

    CA Certificated Created

  • Step 3: The third step you should take is to create a new user account for the VPN client to use. While still on page, do the next step below. Navigate to Main Menu -> -> . Reference Image:
    OpenVPN Setup - Step 3

    You should be now at the

    page. On this page, create a new user by clicking plus

    button, you should be taken to a new page where you should enter the details of the new user account. Fill up the


    fields twice, Full name, Expiration date (blank = no expiration). In my case, I named my first user account as


    Note: Remember to create a corresponding certificate for this user.

    Tick the check-box next to

    dialog. It should expand and let’s you fill the necessary fields to create a new user certificate.

    Fill up the

    field. Make it similar with your user account name. In my case, I named my first VPN user account as

    , while I put

    as my certificate

    . Fill up

    , but this should be automatically filled showing an entry that you’ve previously made from step 1, the Certificate Authority (CA). So in this case,

    should show up here. Select a

    for the certificate, in my case I chose


    Reference Image:

    OpenVPN Setup - Step 3b

    Finally, save your settings by clicking the

    button. You should see a screen similar to the image shown below.

    Reference Image:

    OpenVPN Setup - Step 3c

  • Step 4: Next you should install the from the package manager page. Take the next steps below. Navigate to main menu -> -> -> . You should see a list of available packages. Now scroll further down below and look for the package name . To install the package, click the add button and you should be taken to a new sub-page. Click the button to start the installation. You should see a screen similar to this one. Reference Images:
    pfSense OpenVPN Setup - Step 4a

    pfSense OpenVPN Setup - Step 4b

    pfSense OpenVPN Setup - Step 4c

    pfSense OpenVPN Setup - Step 4d

    You’ll have a hint about the progress of the install process by watching your screen. Upon successful installation, you should see a message


  • Step 5: While still logged in, navigate to main menu then


    . Reference Image:

    pfSense OpenVPN Seteup - Step 5a

    You should be now on the OpenVPN Server page, now click the

    tab, to start a wizard-assisted configuration. A new page should open, entitled

    . On this page, select


    , then click

    . Reference Image:

    pfSense OpenVPN Setup - Step 5c

    On the next page, choose a Certificate Authority (CA). Select the CA you’ve previously created from step 1 of this guide. In this case, it’s the

    . Click Next to continue. The next page should ask you to choose a Server Certificate. You had created this already from step 2 above, and in this case it’s the

    . In case you named it like you wished, then choose that entry as your server certificate. Then click Next when done.

    The next page contains a long list of field set. The first field set that you should see is the

    field set. This is how I filled those up. General OpenVPN Server Information:

    • Interface = LAN
    • Protocol = UDP
    • Local Port = 1194
    • Description = MYOpenVPN-Server-LAN

    Note: The Interface settings is typically set to WAN, but if you have a Dynamic IP address, your VPN connection will break if your IP address changes. So it’s better to set it to LAN if you only intend to use OpenVPN within your Local Area Network.

    For a site-to-site implementation of OpenVPN, Interface should be set to WAN. Cryptographic Settings:

    • Cryptographic Settings = Enable authentication of TLS packets – CHECKED
    • Generate TLS Key = Automatically generate a shared TLS authentication key = CHECKED
    • DH Parameters Length = 2048
    • Encryption Algorithm = AES-256-CBC (256-bit)
    • Hardware Crypto = No Hardware…

    Tunnel Settings:

    • Tunnel Network =
    • Redirect Gateway = Force all client generated traffic through the tunnel = CHECKED
    • Local Network = > Note: Leave Local Network blank if you don’t want to add a route to your LAN, using this VPN tunnel.
    • Concurrent Connections = 10
    • Compression = CHECKED

    Client Settings:

    • Dynamic IP = CHECKED
    • Address Pool = CHECKED

    Note: Other fields that were not mentioned here, were left blank. After filling those necessary fields, click next to advance to the next page. The next page should be the

    . This is what I did to this page.

    • Firewall Rule = CHECKED
    • OpenVPN Rule = CHECKED

    After doing the above step, click NEXT and then finally, click FINISH. You should be taken back to the Server` tab.

    At this point, you’ve already configured a working OpenVPN Server in pfSense. Next step will be to export your user config files for your chosen VPN client. A client could be a Windows machines, Android Devices, Mac or Linux machines. You need to export the client configuration file by downloading the file from pfSense’s webConfigurator page, using OpenVPN Client Export utility. Read Part 2 of this guide to learn how to export your configuration files for specific VPN clients.

Part 2: Client Config Files Export & Client Connection

Now that you’ve set up an OpenVPN Server, it’s for you to test it and let your chosen client machine connects to it. This part of the guide has sub-parts, broken according to client types. So you will learn how to connect from Windows and Linux based machines.

Connecting From Linux Clients

For this guide, I’m going to show you how you would connect from a Linux-Mint-based machine.

  • Step 1: Login to pfSense webConfigurator and navigate to main menu, then go to -> -> tab. You should be now on the Client Export Utility page.

    This is how I’ve set up my client before exporting it for my Linux Mint machine:

    • Remote Access Server = MyOpenVPN-Server-LAN UDP:1194 > Note: This is the name of the OpenVPN server instance that you’ve configured from step 5 above, under General OpenVPN Server Information -> Description. If you named it otherwise, then it should appear from the drop-down menu.
    • Host Name Resolution = Interface IP Address
    • Verify Server CN = Automatic – Use verify-x509-name (OpenVPN 2.3+) where possible
    • Use Random Local Port = CHECKED
    • Certificate Export Options = Use a password to protect the pkcs12 file contents or key in Viscosity bundle – CHECKED

    Then enter your desired password.

    This is an additional password on top of your pfSense user-password. And that’s it. I left other fields untouched. Scroll further down below ’till you reach the

    block. Look for the user-name you wish to export this configuration from.

    Under the

    column, click

    text link just below the

    text. It should let you download the configuration files in ZIP format. Choose the location where you want to save it and keep note of this. Save the file and extract it after. You should find three files similar to the ones listed below:

    • vpn-user-name.ovpn
    • vpn-user-name-tls.key
    • vpn-user-name.p12

    Note: vpn-user-name should be your OpenVPN account user-name that you were exporting from.

  • Step 2: For this step, I think it’s better to teach you this by showing a video guide. So watch this video guide on how to connect from Linux Mint 17. Make sure you have the package installed on your Linux Mint 17 instance. You won’t see the OpenVPN Import dialog if you haven’t installed this yet. To install this package, open a terminal and type: And proceed with the steps shown from the video guide.

Connecting From Windows Clients

Connecting to pfSense-based OpenVPN server from a Windows client is very straight-forward. I decided to show you a quick video guide on how to do this. Windows XP was used in the guide, but it’s also applicable to Windows Vista/7/8. Prior to exporting the configuration file, make sure you have set following from the Client Export utility page: Host Name Resolution = Interface IP Address

  • Verify Server CN = Automatic – Use verify-x509-name (OpenVPN 2.3+) where possible
  • Use Random Local Port = CHECKED
  • Certificate Export Options = Use Microsoft Certificate Storage instead of local files
  • Certificate Export Options = Use a password to protect the pkcs12 file contents or key in Viscosity bundle – CHECKED

Watch the mini-video guide:

That’s a Wrap

I hope you now know how to setup your OpenVPN server. It’s not that difficult really when you set it under pfSense, since it takes care all the tasks involve during your VPN setup. Creating your client certificate is done in no time, just point and click and you’re done. Thanks to pfSense! But if you still having issues with your setup, please feel free to ask about it and put your comments below. Till next time, and hope you enjoyed this guide.

151 total views, no views today

Poor Man’s Proxmox Cluster




Networking I had written this elsewhere before, but thought I would share it on my own site as well. The idea here is to create a Proxmox VE cluster with limited resources, in particular a lack of a private network / VLAN. We address this by creating a virtual private network using a lightweight VPN provider, namely Tinc.

You could use something else, like OpenVPN or IPSEC. The former is a bit on the heavy side for the task, whilst the latter may not have all the features we need. Specifically, Tinc allows us to create an auto-meshing network, packet switching and use multicast. Multicast will be needed to create a Proxmox VE cluster, whilst the virtual switching ensures packets will eventually be routed to the right server and VM.


Create an additional vmbr

By default there should already be a vmbr0 bridge for Proxmox.  We will need to create – or modify – an additional vmbr, which in this example we name vmbr1.


Warning: on many systems, vmbr0 bridge is used to make your server accessible over the public network – so do not edit that unless absolutely required!

You also need to think of what private IP block you would like to use, and assign each Proxmox VE server an IP from within that private IP block. For example, I use the IP range (which is and a netmask of The 192.168.15.x range I assign to the Proxmox VE servers, whereas the 192.168.14.x range I assign to containers / VMs. Using that IP range, you would change the /etc/network/interfaces file as following:

You can force the changes using:

You will need to do this on each server, taking care to select a different IP address. Keep it simple, start at, and increment the last number for each new server.


The next step would be installing Tinc and configuring it in such a way that Proxmox VE can use multicast over that virtual private network.

So on the server, install Tinc with:

Next, create a directory where the configuration for the VPN will reside (you can have multiple configurations as such):

Next, we create a basic configuration, which tells Tinc to use a “switch” mode and what this server’s “name” is. For sake of simplicity, use the hostname for the “name” (use uname -n to determine it):

The “ConnectTo” is currently left blank, but will be important once you have setup the other servers.  More on this later.

Then we create a server-specific configuration. Note that the filename is the same as specified in “Name =” above.

Obviously you should replace the “Address” line with the actual public IP address of your server.

Now we need to create a public/private key. The private key will remain exactly that: private. The public key will be appended to the file we just created (/etc/tinc/vpn/hosts/server1), which will eventually be distributed to the other servers.

It will ask you to confirm two file locations. The default should be correct (with the last/2nd one the file as mentioned above).

Now we need an up/down script, to do some post configuration of the network when the VPN comes up (or goes away). This is a simple copy & paste, provided you have setup vmbr1 as outlined earlier:

What the above does, is add the VPN tunnel to the vmbr1 bridge. Furthermore, it allows multicast messages over vmbr1. It also sets the use of masquerading, to allow a VM on a private IP to communicate successfully with the outside world – it will use the IP address of vmbr0 to do so.

Then, you need to tell Tinc that the contents in the “vpn” sub-directory should be started whenever it starts:

You will need to do this on each server that needs to be part of the VPN. In addition, the files within the directory /etc/tinc/vpn/hosts/ needs to be distributed to all servers (so that all servers have the files from the other servers). Its simple enough to script this, if you want to go that route, but that’s beyond the scope here.

As mentioned earlier, you will need to edit the /etc/tinc/vpn/tinc.conf and provide the name of another server in the “ConnectTo” setting that was previously left blank.  Which server you chose is entirely up to you, and you could chose a different one for each server – remember that Tinc is auto-meshing, so it will connect all servers over time.

Note: without making that change to /etc/tinc/vpn/tinc.conf, Tinc will not know what to do so you will not have a working VPN as a result.

Once you have edited the configuration as outlined, (re)start Tinc using the following command:

And test your network by pinging another node on its private IP, ie:

Note I use the “-c3″ here, to limit the amount of pings. If the VPN was not configured correctly, or a firewall is interfering, you may otherwise end up with a large number of “Host or destination is unreachable” errors.

Forcing the private IP address

We need to force Proxmox VE, or more specifically Corosync, to use the private IP addresses rather than the public IP address.  This because the multicast needs to be done over our virtual private network.

The easiest, but also the “dirtiest” method is to simply change the /etc/hosts, which I will outline here.

The first step is to ensure that the /etc/hosts file is read before attempting to do a full DNS lookup:

Next edit the /etc/hosts file, by commenting out the original line, and adding our own:

Make sure that the private IP address matches the one you assigned to vmbr1 (double check with ifconfig vmbr1).

Again, this is a “dirty” method and you may want to use your own DNS server instead that resolves IPs for a local network (say, “server1.servers.localnet”).

At this stage, reboot the server to ensure the changes get picked up and everything works as expected (that is, your server comes back up online – hmm!).

Create the cluster

If you do not yet have a cluster configured, you need to create one first. So pick a particular server that you would like to consider as a “main server” and perform the following:

Where <arbitrary-name> is something of your own choosing. Keep the name short and simple, without spaces or other funny characters.

The “main server” is a loose term really, as any server within the cluster can manage other servers. But use it as a consistent starting point for adding other servers to the cluster.

You can check if things are working correctly with:

In particular, you’d want to make sure that the “Node addresses:” portion is the private IP address as on vmbr1.

Adding servers to the cluster

Adding a server (node) to the cluster will need a little preparation. Specifically, because we use private IP addresses for the cluster, we need to force other nodes to do the same when trying to contact another node. In other words, if server1 wants to contact server2, it should use the 192.x range instead of the public IP address.

So, based on the above example, on server1 we need to add a line to the /etc/hosts like this:

Note the double “>>” brackets. If you use a single “>” one, you overwrite the entire file with just that line. You’ve been warned.

And on server2, we need to make sure server1 can be contacted using its private IP as well, so on that server, we perform:

All of this can be made much fancier with your own DNS server and bindings, but again, this is beyond the scope and goes on the assumption you don’t mind doing this for the 2, 5 or 10 servers or so you may have. If you have a few hundred, then I wouldn’t expect you to be looking at a “Poor Man’s” setup.

On the server that you will be adding to the cluster, make sure that you can successfully ping that private IP address of the “main server”.

If tested OK, then still on that server (thus the one that isn’t yet part of the cluster), type:

Where “server1″ is the “main server” (the one on which you first created the cluster). It will ask you for the root password for SSH for server1, and then does its thing with configuration.

Note: If you have disabled password-based root logins using SSH, you may have to temporarily enable it. Using SSH keys would be a preferred method over passwords.

After this has been done, the node should automatically on your web-based GUI and can be verified from the CLI using:

If the nodes show up in the “pvecm nodes” command and GUI, then you have successfully created the cluster.

Note: A note about a 2-node cluster and quorum can be found here.

Containers and VMs

You can now create containers and VMs that can be migrated between the nodes.

You can either assign the private IP address directly (venet, only on OpenVZ containers) or as a network device (veth) attached to vmbr1.

The private IP address should be within the range of your specified netmask on vmbr1. So going by the above example of using, that’s anything between and Make sure the IP isn’t already used by another VM or a node (see initial notes, re 192.168.14.x for VMs).

If you fire up the VM, its private IP address should be ping-able from any server, and from within the container / VM, you can ping any private as well as public IP address (the latter thanks to masquerading configured with the tinc-up script). If this is not the case, the network configuration was not done correctly.

Final notes

You should now have at least one container / VM with a private IP address. Its good and well if this VM doesn’t need to be accessed from the outside world, but if you want to give it such access, you will need to use NAT on the server. This will instruct the node that incoming traffic on a particular port will need to be forwarded to a particular VM.

For example, TCP port 25 on is forwarded to VM on IP

Note that this is just a simple guide to help you get started. More importantly, it doesn’t include any basic security measures such as a firewall (there are other articles about a firewall for Proxmox on this site [here and here], which I will update when I can).


1,273 total views, no views today