By default, the DHCPv6 server is enabled on the LAN interface. Check here to see if it is enabled. My appologies for this being a somewhat incomplete step, but it is disabled on my system and I am unable to see what the user interface looks like here. I hope to update this eventually.

I noticed on the forums that many people trying to set up pfSense struggle with entering their certificates properly. I will try to be as detailed as possible here.

First, if you have not done so already, we have to download the OpenVPN Config File (.ovpn) for our preferred AirVPN entry server (We will need the direct IP address of the server as DNS will not function until the VPN is up.). You can do this by logging into airvpn.org and then proceeding to https://airvpn.org/generator/ . Choose the entry server of your choice (the air entry server can be changed later whenever you need, we will focus on one for this tutorial) by selecting the corresponding check box, then scroll down and select the Direct, protocol UDP, port 443. Scroll down again and select both check boxes agreeing to the AirVPN terms of service, then click the Generate button. Once you have the config file you can open it with your favorite text editor. What you should see will look very similar as the sample ovpn config I pasted below (this one was downloaded for a windows client). The config is broken into FIVE main parts that we will need to identify for our uses.

3.) Here we will enter our settings, a descriptive name and advanced settings. Settings that go here are taken from our OpenVPN Config file, from the section highlighted YELLOW, as well as our tls-auth cert, highlighted PINK

Hardware Crypto = SET THIS BASED ON YOUR CPU’s CAPABILITY!!! NOTE: Ivy Bridge, Haswell and newer Intel Processors support RD-RAND. If you have a different CPU you will have to research if BSD Cryptodev is compatible with your processor. If you are unsure, set this to BSD Cryptodev, it should not harm anything even if not supported. If supported, this setting can (will) increase performance of your pfSense appliance.

--Tunnel Settings

IPv4 Tunnel Network = [_______] (Blank/Empty)

IPv6 Tunnel Network = [______] (Blank/Empty)

IPv4 Remote Networks = [_______] (Blank/Empty)

IPv6 Remote Networks = [_______] (Blank/Empty)

Limit Outgoing Bandwidth = [_______] (Blank/Empty)

Compression = [Disabled - No Compression ▼ ]

Topology = [ net30 - isolated /30 network per client ▼ ]

Type-of-Service = [_] (UNCHECKED!!!)

Disable IPv6 = [✔] (CHECKED)

Don't pull routes = [✔] (CHECKED)

Don't add/remove routes = [_] (UNCHECKED)

--Advanced Configuration

Advanced = (Copy and paste the following text directly into the advanced box. Anything to the right of a # symbol is "commented out" and has no effect. I have added a few settings that make the use of pfSense and tighten up security, and have left comments with descriptions of many. Some options I have left in but commented out from use for users to have handy in the event of troubleshooting and can be ignored or deleted if not desired.)

3.)Click the [ + Add ] button on the lower right for "Add selected interface"

4.) Click [ Save ]

5.) While still on the assign interfaces page, find the link for your newly created "ovpnc1" interface by "mousing over" it's name and select it. This will bring you to the configuration page for this interface.

***** NOTE: In the past, the default gateway setting was advised to be checked. This was to act as a fail-safe in the event something went wrong, all traffic would attempt to route through the VPN and have no chance of being re-routed to the clear_net. While this "works", THIS IS NOT CORRECT FROM A ROUTING STAND POINT. Trying to use it this way causes what is known as a routing loop and can quickly exhaust network buffers. This can be seen in the OpenVPN Logs when using the "verb 4" setting. It shows up as:

write UDPv4: No buffer space available (code=55)

The idea of having the VPN as the default gateway is nice on paper, but should not be used. If all other settings are correct, this is not an issue and should not be worried about. Focus instead on having all settings correct!

NOTE: By default the "Mode:" selected is "Automatic outbound NAT rule generation (IPsec passthrough included)". Below this you will see a sort list of rules that are not accessible. We need to change the "Mode:" to "Manual Outbound NAT rule generation (AON - Advanced Outbound NAT)" so that we may edit these and create new rules as needed throughout setup.

A now accessible list of rules should appear. We will delete the "Auto created rule - LAN to WAN" Since our "LAN" interface will become our "AirVPN_LAN" interface. Further, outbound NAT setup will be addressed per interface in that step's instructions.

The two rules that use "STATIC PORT: ✔" and with "ISAKMP" in their respective descriptions are the default rules for IPSEC passthrough. If you do not use IPSEC, those two rules can safely be deleted by clicking the trash/rubbish button to the right of that rule. Most people will not need these rules since we are using OpenVPN, so going forward in this guide further instructions will have those rules ommited as if they were deleted. If you do need them you can keep them, it will not hurt the setup.

5.) Click the buton shaped like a trash/rubbish can to the right of the "Auto created rule for ISAKMP - localhost to WAN" rule to delete it.

6.) Click the buton shaped like a trash/rubbish can to the right of the "Auto created rule for ISAKMP - LAN to WAN" rule to delete it.

7.) Click the buton shaped like a trash/rubbish can to the right of the "Auto created rule - LAN to WAN" rule to delete it.

To admin our firewalls to be as secure as possible, you have to take the mindset that it is going to take a bit of effort. It starts with learning how the protocols are intended to work. Put short, only ports (services) that we intend to be running should be allowed. Thankfully, pfSense makes this somewhat easy in the fact that by default EVERYTHING is blocked by pfSense unless we create a rule to allow it. I have gone out of my way to offer basic ports to enter for an "entry level" port alias that will allow you to take first steps at becoming your own personal network security admin. These ports will cover the ports (services) that clients on your networks should be allowed to use. To start off and to make this as beginner friendly as possible, the basic rules will only cover the "Well Known Ports" range of 0-1023.

That being said, this step is going to require some user interaction as not everyone will have the same needs. Some people won't need an FTP port allowed on the local network, and some people might need IMAPS open on a local network if they have their own email server. Add or remove ports to these rules as needed. I fully encourage discussion in the forums so common services can be brought to everyones attention and added to the list.

With or without that discussion, here is some basic info on ports and their assignments. I encourage anyone not already familiar to read up on the subjects of:

THIS WILL BE THE MOST CHALLANGING PART OF THIS GUIDE, YET THIS IS ONLY A BASIC SECURITY PRECAUTION! I will offer an advanced port alias section soon that will also cover controlling the "Registered Ports" port range of 1024 - 49151.

Step 5, Part 2 - A: "LAN_SERVICE_PORTS" Alias

LAN Service ports are ports that clients on our network will be allowed to connect to on the local network. These connections DO NOT leave the firewall to the outside internet.

You will need to include ports for any service you have on your LAN (Local Area Network) that falls within the "Well Known Ports" range of 0-1023.

enforce the policy based routing (tell outbound traffic to go through the VPN)

and define allowed outgoing networks and services/ports.

To redirect all DNS and NTP requests on the interface, we actually have to create two port forwarding rules. Those rules have an option to automatically create an associated firewall rule with them, which we will take advantage of. We will start with the port forward rules, then create the rest of the firewall rules manually.

Step 6-D: First AirVPN_LAN Firewall Rule

"AirVPN LAN DNS REDIRECT"

The first AirVPN_LAN firewall rule is actually a port forward + associated firewall rule that will redirect all DNS requests on this interface to the DNS server of our choice. In the interests of the majority of AirVPN users and for the purposes of this guide, this rule will force all users on this interface to use the DNS Resolver and hence the servers we entered on the general settings page(AirVPN's DNS), even if they have a manually configured or hard coded DNS.

The Second AirVPN_LAN firewall rule is actually a port forward + associated firewall rule that will redirect all NTP requests on this interface to the NTP server of our choice. This rule will redirect all NTP requests to pfSense even if the client/device has a hard coded NTP server programmed.

*NOTE: You should have two default firewall rules as well as the two associated NAT rules from our DNS and NTP redirection rules already set. The two default rules are the “anti-lockout rule” and a “default allow LAN to any” rule. Do not touch the anti-lockout rule. DELETE THE "DEFAULT ALLOW LAN TO ANY" RULE AT THIS TIME.

*NOTE: You should have two default firewall rules already set. The “anti-lockout rule” and a “default allow LAN to any” rule. Do not touch the anti-lockout rule. You can either delete or edit the default allow rule, it is up to you. If you are unsure of what you are doing, just delete it and create new rules from scratch.

NOTE: Here we will set a system wide DNS which the Resolver (Unbound) will use in forwarding mode using AirVPN’s internal DNS servers.

With this method all requests to the built in DNS in pfSense, including requests from pfSense itself, will go through AirVPN’s DNS. To use this method you MUST use direct entry IP addresses in the openvpn configuration as your pfSense appliance will not be capable of resolving a domain name prior to the VPN tunnel being up.This method also means that if the VPN is down, there will will be no DNS resolution for any client on the system, even ones not using the VPN, unless an alternate DNS is handed to it via DHCP or manually programmed. Alternate DNS servers, inside or outside of the VPN, can be configured in the DHCP section on a per interface basis or more finely on a static DHCP reservation and with corresponding firewall rules and outbound NAT if it is needed.

1.) Go to: System / General Setup

http://192.168.1.1/system.php
-or-
https://192.168.1.1/system.php

and set as follows:

NOTE 1: You may set the hostname and domain to whatever you like, however if you do not know what this does, leave it alone

Here we will test to see if domain names are resolving from the DNS servers we entered on the General Setup page. We will do this using the built in feature of the firewall.

1.) Go to: Diagnostics > DNS Lookup

http://192.168.1.1/diag_dns.php
-or-
https://192.168.1.1/diag_dns.php

Set as Follows:

Hostname or IP = [ airvpn.org ]

2.) Click [ Lookup ]

3.) Verify the results:

Hostname or IP = [ airvpn.org ] = 5.196.64.52

If 5.196.64.52 was returned it is resolving correctly. Feel free to resolve as many sites as you wish! This is a useful tool to keep in mind as well.

That's it! You should now have a functional connection to AirVPN! Just plug your ethernet cord, switch or wireless access point into the AirVPN_LAN port and you are off and running! I hope this guide helps you! Don't forget to back up your settings you just spent all this time setting up!

Share this post

Link to post

I had some oddities with system tunables when going the upgrade route, but when I did a clean install everything worked well, beyond well. I did not restore all settings. I restored my aliases, but manually programmed everything else. I feel it was worth it.

There were some buggy issues on 2.2.6 with the DNS Resolver not taking the settings that were input all of the time, this seems to be fixed in 2.3. That bug carried over on upgrades, but is non existent with the clean install.

I cannot stress how much I recommend upgrading for all of the security and performance upgrades this offers.

Share this post

Link to post

I had some oddities with system tunables when going the upgrade route, but when I did a clean install everything worked well, beyond well. I did not restore all settings. I restored my aliases, but manually programmed everything else. I feel it was worth it.

There were some buggy issues on 2.2.6 with the DNS Resolver not taking the settings that were input all of the time, this seems to be fixed in 2.3. That bug carried over on upgrades, but is non existent with the clean install.

I cannot stress how much I recommend upgrading for all of the security and performance upgrades this offers.

how are you testing for the DNS bugs? problems with system tunables that are important? at this point I'm hesitant to do a clean install.