The Firewall: pfSense

Page links:
Introduction

The RSP (Retail Service Provider) supplies connectivity services at Layer 2.  The school needs a Layer 3 device to actually use the connection. This could be a single computer but that would rather defeat the purpose if only one computer could access the connection.

A local firewall is the solution.  There are many options to choose from.  There are commercial solutions like Fortinet, SonicWall, Juniper or Watchguard - there are many more!  Or, if you are adventurous, prepared to learn, love DIY and have a principal who is allergic to spending more money than is necessary then there are Open Source solutions.

A great list of software based firewall solutions is here:


We settled on pfSense.  We knew others using it successfully.  It runs on old hardware.  It can run as a VM machine which meant we could play and learn without bringing down the wrath of our users upon our heads.  It also did everything that we needed:  it could run our /29 static range; it could provide an easy to use (or at least as easy to use as these things can be!) interface; it could support our web filtering needs; there is a huge support community - including paid support.  The price is very reasonable - $0.

pfSense is a customised version of FreeBSD - a Unix based operating system (which is very similar to Linux.)  Other people have thought highly enough of FreeBSD that it has been used as the foundation for a variety of other operating systems.  The most notable of these is Apple's OS-X.  pfSense is very extensible and it can do a lot more than just be a firewall.

To run it we resurrected an old server - HP ML350G4P:  dual Xenon 32 bit processors, 2GB RAM, dual NICs (it is essential to have at least two NICs - as it happens this server has 4 NICs), 3 x 72GB SCSI HDDs, CD drive.  Good quality NICs do make a difference to performance.

Remember:  the LAN IP address of the firewall is the LAN Gateway address.

As always be on the look out for other options.  It may be that setting up and running a pfSense box is too technical for you.  If your school has a SmartNet server then that server can also be a firewall for you too - and do everything else including web filtering.  Contact SmartNet if you want to consider their services.


Create a bootable pfSense CD

The first task is to get a bootable version of pfSense.  It comes as a 77MB compressed .gz file.  This needs to be unpacked to a .iso file, then burned to CD to make it bootable.  There are lots of ways to do this, including making a bootable USB stick.  It is over to you.

1.  Download pfSense:  


(For other versions see eg http://mirror.optus.net/pub/pfSense/downloads/ - eg use the "memstick" version to get a .img file to use with a USB stick.)

2.  Use eg WinRAR to decompress the .gz file and extract the .iso file:


3.  Use eg PowerISO to burn the .iso image to a CD suitable for booting



Install pfSense

The next task is to actually install pfSense from CD.  You need to make your CD drive the bootable drive - later change the bootable drive back to yur usual hard disk drive.  Generally this is done in the BIOS settings.

With the boot process under way you can really just follow your nose and accept all the defaults.  If something fails during the installation you may need to restart it and choose an option during the installation process to turn off ACPI. Others have documented the actual installation process fully so start here:


The important thing is to work out which NIC is the LAN interface and which one is the WAN interface.  This might require a "trial and error" approach.  Once you have assigned the LAN interface a static IP address within your own local IP range, make sure that one NIC is cabled to your local LAN and the other to the RSP's device.  If you cannot browse to the IP address of the LAN interface then try swapping the cables over.

You can use the pfSense console screen to assign IP addresses - or do this via the web interface if you prefer.  The initial configuration will have to be done via the text based console screen but it is all easy and it guides you through things.

Another good option for those schools running VMWare is to install a virtual machine that can run on ESX / ESXi.  It also runs on VMWare Workstation - this can be an excellent sandpit area for playing with the capabilities of pfSense. 

Simply use the .iso file with VMWare to make a virtual machine.


Configure pfSense - Initial Setup

The web interface to pfSense is able to do nearly everything.  From your LAN browse to it's local IP address.  The default username is "admin" and the password is "pfsense" - you can change this on the "System" "User Manager" menu.

You should also define upstream DNS servers, the time zone and NTP server details.  Do this via the "System", "General Setup" menu.  You can also name the host and enter the domain that it is associated with if you wish, then manually enter the host details into your own local DNS server's zone for your domain too.


As with all things make backups.  You can backup the entire configuration to an XML file and restore it if necessary.  Use the "Diagnostics" "Backup/Restore" menu.


Configure pfSense - Gateways and Interfaces

At Mt Aspiring we called the "WAN" interface "FIBRE" as we originally had two other WAN interfaces.  The terms "WAN" and "FIBRE" are used interchangeably to describe the same interface on this web site.

The first step is to correctly configure your "Gateway" and "Interfaces":

1.  Choose "System", "Routing".  On the "Gateways" tab click the "+" icon to add a new gateway - this will be the "Ethernet IP - Telecom Platform" IP address - for Mt Aspiring it is 122.56.103.94:


When you click "+" make a new gateway make as shown below:


Critical things:
  • Interface - Choose the "WAN" (or as we called it "FIBRE") interface
  • Name -  give it a name
  • Gateway - enter the IP address given to you by your RSP - we use the "Ethernet IP - Telecom Platform" or 122.56.103.94
  • Default Gateway - if this is the only gateway (it probably is) then tick the "Default Gateway" box - it is a good idea to do this anyway.  
  • Monitor IP - If you want to monitor that the connection is up you can use any static public IP address that is pingable - but be aware that the IP address owner might not be too keen on that!  Because our Telecom provided gateway connection is not on the local Cisco, but resides in the Telecom core, the actual gateway address 122.56.103.94 can be used as the Monitor IP address.  We use the actual gateway address as the Monitor IP and not what is in this example screen image.
  • Advanced - nothing is needed in the "Advanced" section
  • Descriptive name - it is always nice to give things a descriptive name too
When you click "Save" you also have to apply the changes afterwards too - it is fairly obvious:


Next define the actual WAN interface details - use the "Interfaces" menu.  You might need to "(assign)" an interface first if that has not been done:


Once the "interface" is assigned use the "Interfaces" menu and select the WAN interface:


Critical things:
  • Enable - Duh!  You must enable the interface
  • Description - name it eg WAN or FIBRE or something that reflects what this interface connects to.  
  • Speed and Duplex - as this interface will connect to the RSP device and that device (as stated by the RSP) needs 100/Full duplex choose that from the pull-down "Speed and Duplex" section.  
  • IP Address - set the IP address to be the "Ethernet IP - Customer" address as supplied by the RSP - for Mt Aspiring that is 122.56.103.95.  One small failing of pfSense is that it does not support /31 point-point subnets so choose /30 instead.  It does mean that you will not be able to reach who ever has the other half of the /30 public subnet. Hopefully that is a bug that pfSense will resolve in a future release. (It may be that you need a /29 mask in some cases too.)  
  • Gateway - choose the Gateway address as defined earlier - the  "Ethernet IP - Telecom Platform" 122.56.103.94. 
Save and apply the changes.


The LAN interface (ie the gateway device for hosts on your network) also needs to be configured:


Notice that there is no "Gateway" defined on the LAN interface.


Configure pfSense - Outbound Firewall Rules

By default everything is blocked inbound.  That was simple.  More later on inbound connections via the FIBRE interface. 

For the moment start with the outbound firewall rules.  The list below is from "Firewall", "Rules" then the "LAN" tab is designed with our specific needs in mind.  We needed to allow outbound access for our VC unit ("VC.100" rule - see the details in the "Video Conferencing" section) and manage devices that could have unrestricted outbound access like photocopiers (for scan-to-email) or the deputy principal's HTC Android phone (so he could play scrabble with his mates.)  We also wanted to manage access to certain IP addresses or domains, yet block access to anything else unless users had defined a proxy.  It is important to get this right as the school does not want to be on the receiving end of a copy right infringement notice.

You can use the "?" in the purple circle at the top right of a screen to get help on a topic or start here:




The rules are processed top to bottom so the order of the rules is important.

pfSense makes it easy to manage groups of similar things using "Aliases".  In the above example "DriectOut", "IP Destinations" and "Domain Destinations" are all "Aliases".  
  • "DirectOut" defines internal IP adresses (that are either static or have a DHCP reservation) that are permitted to go directly to the internet on all ports/protocols.
  • "IP Destinations" defines IP addresses that any internal host can access.
  • "Domain Destinations" defines a DNS entry eg "update.microsoft.com" that any internal host can access.
To create an "Alias" use "Firewall", "Aliases".  You can create an alias for hosts, networks, ports, URLs or a URL Table.

Like most places in pfSense use the "+" to make a new entry.  "e" lets you edit, "x" will delete a rule.  Where applicable you can select a rule and then use the "<" button to move the selected rule before that rule.  All logical.


This example is for a collection of "Hosts":


"Hosts" can also be FQDN hostnames:


"Networks" are useful for defining not just individual IP addresses but also whole subnets:


... which brings us back to the individual LAN firewall rules mentioned earlier - so here is the detail (except for the VC.100 rule - more on that in the "Video Conferencing" section).

Direct Outbound Rule:  This uses an Alias in the "Source" field:


IP Destinations Rule:  This is similar to the above rule except that the "Destination" uses the alias name.  The "Domain Destinations" rule works the same way:




The next rule is a tricky one.  It is associated with a NAT (Network Address Translation) rule and it is designed to make sure that users who have set the correct gateway IP but not defined a proxy IP cannot get direct access to the internet. Even though it is an outbound rule the following rule has been created under "Firewall", "NAT", "Port Forward" as a special linked rule - it is the bottom rule - "Block all except permitted".

(This rule may not be doing what is actually intended - ie to pass all traffic to the squid proxy but at least it is having the intended effect of stopping outbound access if proxies are not defined!  This will be explored some more and there may be updates to this rule soon.)


The actual rule is:


Critical things:
  • Interface - LAN:  we need to check what is happening on the LAN interface
  • Protocol - TCP/UDP:  we need to look for either of TCP or UDP traffic.  (We should probably add rules for other protocols too!)
  • Destination - the "not" box is ticked because we want to block anything that is not directed at where our Squid proxy is located.  In this case our Squid proxy will be at the same IP address running as a service so we use the IP address of the LAN interface
  • Destination port range - we want to redirect any port going outbound that we have not previously permitted so the from to range is 1 - 65535.
  • Redirect target IP - send things to the Squid proxy IP
  • Redirect target port - and on the Squid proxy send it to the Squid port 3128
  • Filter rule association - choose "Create new associated filter rule" and then when you re-edit it later you will see the name you have associated with it - in this case "Rule NAT Block all except permitted" (which is what is in the "Description" field). 
The automatically created firewall rule is:


Finally anything that gets through the rule set is permitted so pass it to the FIBRE gateway:


Nothing to it was there!


Configure pfSense - Inbound Firewall Rules:  NAT

If you thought outbound rules were complex then it will be a pleasant surprise to see how easy inbound NAT (Network Address Translation, otherwise known as a "pinhole") is.

We used IP addresses from our /29 public IP range.  You could use the IP address "Ethernet IP - Customer" too.  

To use addresses from the /29 range we first have to define them to pfSense as "Virtual IP Addresses" (look on the "Firewall" menu):


Looking in detail at the rule "Moodle NAT to MAC3":


It is possible to define the entire subnet in one hit by choosing "Network" rather than "Single address" in the "Type" box. We chose to define them individually as a "Single Address" as
  • a /29 range means we "only" have 8 addresses
  • in the "Description" we can say what each address will be used for
There are 4 different types of addresses depending on what you want to NAT to. "CARP and "IP Alias" are useful if you want to NAT to something that is on the firewall itself.  A full description is at:


Once the virtual IPs are created they are easy to use because they have been statically routed by Telecom to be behind the "Ethernet IP - Customer" address of 122.56.103.95.

Our "NAT:Port Forward" rules (at time of writing) look like:


The detail of the port 80 rule to our Moodle server is:


The critical parts are:
  • Interface - FIBRE 
  • Protocol - TCP/UDP
  • Destination - Type: choose the previously defined "Virtual IP Address"
  • Destination port range - HTTP - but use what ever you need
  • Redirect target IP - use the internal IP of the server hosting the service
  • Redirect target port - that will usually be the same as the Destination port range - but you can split things up if you want and run a split port NAT by having different destinations and targets
  • NAT reflection - use system default
  • Filter rule association - Pass
How easy was that?!