Welcome Back!!

In the last article regarding firewalls I gave you the links and some basic information regarding three different firewall options.  I had intended to try all three and let you know how it went but I was enjoying messing with the Endian firewall too much to lose it!  Well, I recently got bored and decided what the hell – time to try something new.  So I went to the next in the list:  pfSense.

So in this article I’ll give you a brief overview of what pfSense can do.  This article is going to be a lot more technical than the last article because to be honest – pfSense required me to be more technical than either Endian or IPCOP for what I needed.  If you do not run a DMZ at your house and are just looking for a quick, cheap firewall to turn your old computer into something useful – pfSense can do that with not a lot of work on your part, and the majority of this article will not be for you.  If you do run a DMZ – you’ll need to read this :).

So I downloaded the LiveCD installer option, printed out my port configuration page from my Endian setup, and rebooted the firewall.  It booted directly into a fully working system in just a few minutes – which is expected when using a “LiveCD”.

In the pfSense documentation it recommended to configure the firewall before installing to the hard drive so I did just that.  I logged into the website, which in my opinion is a fairly professional and clean interface, and started configuring my network cards and subnets.

Everything went pretty smoothly at the beginning and eventually I got to the point of installing to the hard drive.  This was again, totally uneventful and worked perfectly.  The installation was a little more difficult, or seemed to be, than the others I have tried (Smoothwall, IPCop, Endian) because the installer wouldn’t really do anything for you (like partition the hard drive).  I’m not too surprised by this, as this firewall is based on a BSD kernel and not Linux – which in my experience the BSD distributions tend not to be as user-friendly as their Linux counterparts.  BSD derivatives make up for it, however, (again in my experience), by being a little more stable and secure out of the box than Linux is.

To be fair, that’s usually because out of the box a BSD system has less 3rd party software, which leads again to the non-user friendliness :).  Anyway, back on point, after selecting my options for the installation I ejected the CD and rebooted into pfSense.

As advertised, it saved all my configuration details and most of my LAN worked as is.  Now I got to the point of the more difficult things like checking the firewall port forwarding and setting up my DMZ.  This is where pfSense got to be a little more difficult..

In IPCOP, it automatically asks you if you have/want an Orange interface, and then automatically configures you a nice default set of rules that allow pretty much anything out to the internet but not to your Green or Blue networks.  This works well, is point/click easy, and takes all of 10 minutes to start forwarding your ports to your DMZ and off you go.

In Endian, it also wants to know if you want a Orange network, and it also automatically configures a nice default set of firewall rules that are much more restrictive than in the IPCOP defaults.  This is good for security, and requires the admin to open up only what he or she wants.

In pfSense.. it wants to know why you want to use a third interface and tells you to go stick it.  Well ok, not really.  It is however much less intuitive.  During installation it will ask you for a LAN interface, fair enough, then it asks for an internet interface, good good, and then it just goes on to ask for “Optional Interfaces” that it duely names “OPT1, OPT2, OPT3.. etc” until you decide you’re done adding interfaces.  Once the interface is then added, you have to go into the web interface and actually enable it (because.. you may have just been adding random nonexistant interfaces for fun) and then you go to the firewall rules area and find…. nothing.  This is great for just being annoying :).

Under the pfSense firewall rules you have different tabs per interface and you do have of course a tab for the new interface but NO default rules are added.  No DNS, no web, nada.  So you get to add everything you need, including basic “make this subnet work” rules by hand.

On the other hand.. pfSense does have a rule that Endian opted to skip: The Any->Any Allow rule for your LAN network.  You know, that’s the easy rule I described in my last article that makes ipcop a great new or inexperienced user’s firewall setup.  You don’t have to mess with anything to get all of the internet at your fingertips, while securing the malicious traffic from the outside. Again this is a complete trade-off on how you want to setup your network: Access control for employee’s or children, or easy configuration with minimal fuss.

Now, Endian and pfSense each take a different road by default, but can each be made like the other due to support for bi-directional (incoming and outgoing traffic) firewalling… IPCOP on the other hand takes the easy road, with no default options to change it.  With IPCOP you have to install an addon that allows you to block outgoing traffic – again solidifying IPCOP’s role as the user-friendly easy firewall with limited advanced options (without addons).

Like IPCOP, however, pfSense comes with nearly no additional software beyond your default firewall/router/nat configuration.  It does have some advanced things: Loadbalancing with another pfSense firewall, PPoE server, etc.. but no Proxies, anti-virus, content filters, etc.  Endian came default with these.  Unlike IPCOP, however, the pfSense package/addon interface seems much simpler.  It’s already there in your menu, ready to go, just click “install” on any particular addon and it automatically fetches, installs and configures it.  Using these you can add all the missing functionality you need.  In IPCOP, this requires you to install the basic addon interface first (via a command line in SSH), and then you can browse to “Addons” in the web interface, pick an addon where you have to go download the package to your computer, then go back to the web interface and “upload” the package to IPCOP.  This whole procedure breaks the “easy” that IPCOP’s entire foundation lives on.

Going back to the port forwarding in the DMZ, I was presented with a different problem.  First, what was obvious to me but may not be to some (or most?), was that because the firewall interface is broken up by interface (LAN, WAN, DMZ) you can’t just create one bi-directional rule for port forward, but instead have to go create one rule on the WAN to allow it coming in, and one rule on the DMZ to allow it going out.

Normally this would create double the work, if it weren’t for a hidden specialty that pfSense has and I will get to in a minute.  Second, after spending an hour banging my head against the wall and searching through pages of forum posts online trying to figure out why my port forwards still weren’t working for my DMZ.. I found a post that explained you needed to actually add specific NAT rules for each port as well.

Holy Hell pfSense, so let’s get this right: what you can do in one rule in Endian and IPCOP, takes 3 rules in 3 different pages for pfSense?!? One in Firewall->NAT, one in Firewall->Rules->WAN, and one in Firewall->Rules->DMZ – AND they are all different.  So basically, if I have 20 rules in Endian for 20 ports I need to forward – then doing it this way would have taken 60 bloody rules!  To be fair, if you do the NAT one first it has a checkbox that will automatically create a rule for the WAN – but still, that’s just nonsense!

Now, not all servers need this: Web servers for example don’t need to get “out” port 80 due to the nature of the stateful firewall – it allows “responses” from your webserver to the client; however mail servers on the other hand obviously need to get “out” port 25 to talk to other mail servers – my example of 60 represents a “worst case scenario”.

So how do we get around this?  You learn about Aliases!!!

That one word right there makes me ignore all pfSense’s faults and want it to have my children.  I’m sure other firewalls do this, but I cannot recall IPCOP or Endian having this option anywhere..and I think it should be on every firewall ever invented.  Normally, when someone says the word “Alias” a normal network guy, like me, is going to think Interface or IP Aliases for an interface.  Meaning that, if I have 5 static IP addresses to the internet, then my red interface needs to respond to 5 different ips.  This is a normal interface Alias – You have your primary one, then 4 additional ones all on the same card.  This is not a pfSense Alias.

pfSense has created a way for you to make groups of either IP addresses OR ports!  So, if I have 2 servers in my DMZ, both requiring a different set of ports (as each server is a server with a different function, like Mail and Web) – we’ll say each server takes 10 ports to function to fit in with my example of 20 above.  I can go into the Firewall->Aliases screen, create a new alias of ports, list all 10 ports for server 1 and call it “Server1Ports”.  I then create another one and list all 10 ports for Server 2, and of course call it Server2Ports.  I then go into Firewall->WAN and create my incoming rule, but now instead of having to specify specific destination ports in 10 different rules I simply put “Server1Ports”, and the IP of Server 1 into the destination box, and it even auto-completes for me!  That’s just cool.  So now my 20 rules on 3 screens, just became 2 rules on 3 screens: One for each server.  6 rules instead of 60! For servers that don’t require an outbound rule to be made, it’s actually even simpler since the NAT rule will create a WAN rule for you – You manually create 1 rule to allow as many ports into your server as you need.

As complicated as all that is – once you understand it, it’s actually less work than creating a DMZ in Endian and IPCOP.  The same idea works for aliasing IP addresses.  Say you have 2 webservers, and each require the same ports to be open, you just make yourself a “WebServerPorts” alias with the ports, and a “WebServers” alias with both webservers ips, and voila!  3 rules later (remember, 1 for each interface+NAT) and you have all the right ports going to both the right servers.  That is simply awesome.

To be fair, I believe the reason for the difference in these 2 methods of doing things is actually a difference in underlying OS: BSD vs Linux.  More specifically – their respective firewalls.  PF allows for the creation of “lists” and pf will automagically create the rules for you – whereas in iptables every one must be done one at a time.  However, there is no reason an interface, especially a web interface, could not be written to emulate this sort of functionality and simply extrapolate what the user puts into aliases into a different iptables command for the server.  So, while I understand that it’s likely the underlying technology that drives these methods – I find it to be no excuse.  Everyone should have Aliases.

Speaking of underlying technology – pfSense has it’s flaws.  For example, you cannot access your DMZ’s website from within the LAN by going to the external IP address.  Check here.  (Note: This is implemented in pfSense now using Nat Reflection). I had no problems doing this in both Endian and Ipcop, so I’m not sure if this is an iptables thing or what – but now I have to maintain two DNS’s.  The primary one that the world uses to get my public ip address – plus I have to use pfSense’s and create one that points to the “internal” ip of the DMZ server.  So every domain name I have I have to create twice.  That gets annoying.

Now we’ve reached the end – My conclusion.  The way I see pfSense is this, for an average user that is contemplating buying a Linksys router, or using an old PC they have in the house – pfSense could work just fine.  I personally don’t think the interface is quite as refined and easy to follow for a beginner as Endian or Ipcop, but it requires little setup after installation for a simple LAN to Internet configuration.  Where I think pfSense shines, however, is in it’s ability for a completely advanced configuration to be done completely through the web interface.  From assigning static NAT addresses, to the several diagnostic interfaces in the site it just makes doing complicated things a little easier.  Unfortunately, that kind of granularity in the interface also makes some of the more simple things more complicated, meaning that unless you have a desire to learn at least a little abount firewalling, you are probably better off going with IPCOP or Endian.

For now, since pfSense is so far the only firewall I’ve gotten an actual Full Tunnel VPN to work properly (which means complete client browsing through the tunnel) using only out of the box tools – I’ll be keeping it for a while.  If I change, I’m sure you’ll be some of the first to know ;).

Keep your network locked!