pfSense 1.2: 6-month review

After spending more than 6 months running pfSense 1.2-RELEASE at the perimeter of our production environment I thought I’d do a short good/bad/ugly review of the experience to help anyone that might be considering using it. In my experience, pfSense has been a great solution. Besides being free, and fast, it has the functionality of ostensibly higher-end solutions like the Cisco PIX/ASA, or Microsoft’s ISA, with the ease-of-use of a Cyberguard SG, or Sonicwall product.

Yeah, but what about the SMB-market – does it make sense?

Our pfSense box sits at the perimeter of our LAN, protecting us from a 10MB Full-Duplex Internet connection. Like most businesses of our size we have a handful of crucial services being served up to the Internet – a stack of LOB apps, and some assorted contractor requirements that can create challenges. While it’s not quite what I'd call a zero-effort experience, everything has run very well and I’ve been quite impressed.

The Good:

The web-interface… it works well. You can do practically anything you need from it – including editing FreeBSD config files if the should arise. Also, since pfSense is based on FreeBSD, you also have the ability to SSH into the shell and work from there. But don’t let that scare you off – you probably won’t ever have the need to do so.

VPN support… pfSense supports just about everything you’d expect. It has a PPTP server built into it, and you can use a local account database, or a RADIUS server for authentication. WINS works across VPN tunnels – which is nice, and something not every PPTP server I’ve used has implemented fully. IPSec is of supported, and pfSense can serve as an end-point and seems to work okay with the Cisco stuff I’ve seen at the other ends of some of our tunnels. OpenSSL is supported… if you’ve not worked with SSL-based VPN’s before – they’re nice – especially if you have remote users who work on-site behind large corporate firewalls that block outbound PPTP, or IPSec.

Traffic… there’s a handy real-time traffic graph that you use to watch inbound/outbound traffic across the firewall. There are also a host of RRD graphs depicting things like traffic, link quality, and processor utilization over time... All handy when it comes to troubleshooting your internet connection, or engaging your ISP should they fail to meet the terms of their SLA.

The ability to do packet captures is one of my favorite features of pfSense. Besides being useful for troubleshooting issues at your office, it’s quite handy when you have pfSense deployed at client sites (yes, we’re selling it to clients). Login to the interface, and start capturing packets to see whose consuming all of your bandwidth for instance.

The Bad:

While there’s not a whole lot of “bad”- I have run into a few challenges – most of which are documented elsewhere on this site.

Hardware support... I’ve mentioned this before, and you probably know that FreeBSD doesn’t have quite as broad of hardware support as Linux or Windows. I ran into some issues with non-Intel NICs and off-brand Wireless cards which were painful. That said, I’ve run into issues with Broadcomm NICs and HP-branded NICs on windows servers before too – so take that with a grain of salt. It’s just a data point and not intended to discourage you. If you're just throwing a box together from spare parts – remember to use Intel NICs that are on the FreeBSD hardware list and you’ll be fine.

FTP Support... The FTP protocol is just plain clunky. It’s been around for decades, and every vendor has a different way of implementing it. There is no security – passwords and data traverse the internet unencrypted – in short, it’s kind of a mess. Pfsense has passive FTP support, and an FTP proxy. In our deployment, we have users who complain about not being able to connect to our FTP site when in the office (i.e. looping out and back in). I understand why they would want to do this (even if from a technical perspective, it doesn't make much sense), but in order to support outbound FTP you need to run the pfSense FTP proxy. Turning that on breaks the ability to loop-out and come back in for FTP which can be frustrating (and yes, a split-DNS configuration would resolve this).


The Ugly:

PPTP... Good and Ugly? Yes indeed. There are some ugly parts to the PPTP support in this version of FreeBSD and pfSense. Like the FTP protocol, PPTP isn’t great. But, like FTP, PPTP is perceived by many to be easy to use and support, and thus is still widely in use. The problem with PPTP support… which is actually highlighted on the pfSense web site is... “there is a pf limitation that stops any outbound PPTP connections from working if the PPTP Server on pfSense is enabled. This is a known issue with no known work around.” Which really means that if you enable the PPTP server on pfSense, internal users supposedly can’t VPN out to a remote PPTP server. In my experience, this is not entirely true. You can turn-on the PPTP server on pfSense, and internal users can often connect to remote PPTP servers. What I mean by “often” is… I’ve found that among our customer base, most have firewall appliances running PPTP servers, and we no have problems connecting to them. Further, we’ve had no problem connecting to any Microsoft PPTP servers (including those running on 2000, 2003, and 2008). Finally, we can connect to nearly all of our Cyberguard SG series firewalls that have PPTP servers. But there are a few of those that we can’t connect to via PPTP. I’ve compared models and firmware revisions, but don’t see any consistency between those units which I can point to as the cause. We’re able to work around this given the small number of clients that were having problems PPTPing into, but it is irritating, and might be a show-stopper for some IT service providers that work in the SMB market.

PPTP continued… There’s another limitation in the version of FreeBSD that pfSense is using which limits the number of simultaneous outbound connections to a given PPTP server to just 1 connection. This means that you can VPN into a client site which lives at a given IP, but if someone else behind pfSense tries to VPN into that exact same remote IP, he/she will not be able to establish a second session. In other words, you can have thousands of simultaneous outbound PPTP connections going on, but you cannot have more than one connection to the same remote IP at a given time. While this is rarely an issue – it does come up from time to time and it may be a show-stopper for some IT service providers.

The good news on the “ugly” front is that both PPTP and FTP are being worked on by for the next release due in 2009 and promising… “Better PPTP and FTP handling in NAT. The PPTP fixes will allow multiple outbound connections to the same external PPTP server using a single public IP. Details of that issue on the Features page on the website under PPTP/GRE NAT limitation”. I’ve been monitoring what’s going on with pfSense 1.3 Alpha – and have it running on a firewall at home, but it’s under continuous development and not production ready. One notable improvement is the configurable dashboard which gives you status and highlight information.

Is it “just work” easy?

I don’t think pfSense necessarily meets the zero-thought, “just work” criteria. If you’re building a box, instead of buying one, then no – it requires some limited thought to find a supported mix of FreeBSD hardware, then you have to install, configure, and use the product. Is it more difficult to configure than something like a Sonicwall, or Cyberguard Snapgear, or other similar appliance? Only because you have to build-it… otherwise, the software and features of the interface are excellent and, in many ways exceed those of the prior-mentioned solutions.

Does it make sense for SBS-sized networks?

Given that the infrastructure business on the low-end is evaporating, selling pfSense into that market might not be a good fit, or make sense… but from a technical standpoint, or if you’re looking more at that middle tier from 50 – 250 users and up, than I think pfSense is a great fit. As I mentioned, I like it so much that I use it at home and keep up with the 1.3-ALPHA updates.

pfSense: Link List

Wrapping up my series of pfSense posts (see here for the entire series), the below link list is a collection of posts and articles that helped me along the way. As I mentioned before, pfSense really exceeded my expectations. Throughout the effort I've been impressed , and continue to learn though the active community (see the forum, and #pfsense on Freenode). If you're interested in pfSense, but are put-off by Open Source or products without paid-support, check out Centipede Networks for hardware and support-based offerings around pfSense.

Random knowledge about pfSense (good for getting started).
NIC Duplex settings (media and mediaopt settings not taking effect)
Dual DSL System
MultiWAN Configuration
More than 16 concurrent PPTP VPN connections
PCI Wireless NIC
Configuring the captive portal
OpenVPN Overview for pfSense
OpenVPN on port 443

pfSense: Associate with a wireless access point

Getting pfSense to associate with a wireless AP can be a bit confusing. It looks like a lot more has been integrated into the web interface since earlier releases, but it might not be completley obvious how to make the association happen. .

1. Add a NIC from the supported list... the 3com 3CRDAG675B that I used worked well and was detected right away by the FreeBSD.
   
2. Next, add the new interface (Interfaces>Assign), name it, and enable it. If you're not seeing it, then it's probably not being detected by FreeBSD.
   
3. You can see a list of local APs by clicking status>wireless
4. Under Wireless Configuration, put it in Infrastructure Mode (BSS). Then set the SSID to the SSID of the AP you identified in step 3 in order to associate with. Then set the IP (or DHCP) configuration.
5. If it has encryption enabled, make sure you set that correctly as well.
6. Check and see if it has associated properly: Status, Interfaces
7. The status should now read "assoicated", and it should have the IP you configured it with in step 4. You'll then begin to see In/out packets listed if you refresh the page.
   

pfSense: OpenVPN overview

There's a really good tutorial available on the pfSense wiki that I followed to get OpenVPN working properly. It walks you though configuration, creating the certificates, installing the client, etc. That said, if you don't have any prior experience with OpenVPN, or your only VPN experience is PPTP, then there are some things to keep in mind using with pfSense and OpenVPN.

As of pfSense 1.2-RELEASE, connection management to OpenVPN is based on certificates (or a pre-shared key) generated by OpenVPN tools that you install on your local workstation. Unfortunately there is no key-management built-into this release of pfSense, making the concept of “user or connection management” a bit of a challenge.

You download the OpenVPN source, and create certificates from your workstation, and then add the certificates into pfSense. You can then revoke certificates using the certificate revocation list (CRL) from the pfSense management console (VPN>OpenVPN>CRL). And this works just fine. The problem with it is that it doesn't scale very well. For instance, most of my clients are running XP Pro, or Vista. All have Active Directory in place, and existing user accounts. For me to deploy OpenVPN throughout my organization, or throughout our client's organizations, it would be a substantial task. We'd have create certificates for all users, deploy OpenVPN GUI clients via a script to our XP Pro systems, and then use scripts or GPO's to push out certificates on a per-user basis. So right now, the lack of key management within the interface is a limiting factor – well that, and the infrastucture we have to deploy to make OpenVPN just work, in the same way the our existing solution just works. For now, we'll plan to use OpenVPN selectively for employees that need to connect from sites where outbound PPTP ports are being blocked.

That said, I understand that OpenVPN is a priority for the pfSense team and that it's likely we'll see some improvements around key-management in the near future.

pfSense: Configure captive portal

The captive portal in pfSense lets you provide restricted internet access to guests via a web-portal that prompts them to type a username and password. It looks and feels very similar to what you find in Wi-Fi hotspots, hotels, business centers, and coffee shops around the world.

In short, here’s how it works… you configure the captive portal in pfSense, hang some open access points off of it, and have pfSense hand out IP’s to anyone who connects. Guests (contractors, stakeholders, etc.) arrive at your office, see the open AP’s and associate with them. They get an IP, and as soon as they try to browse the internet, DNS resolves their request to a portal for authentication. They authenticate, and now they can access the internet… segmented off of your business LAN.

Now, this isn’t quite the same thing as NAP, but beyond pfSense there’s no infrastructure investment, a limited configuration effort, and it makes life better for everyone.

Configuration in pfSense is pretty straightforward. There’s a video tutorial on the wiki, and my short how-to below.

In pfSense do the following:

1. Interfaces>Add new interface
2. Interfaces>OPT1 (new interface)
3. Optional Interface Configuration>Enable
4. IP Configuration>Assign an IP address on a new subnet (e.g. 192.168.177.1/24)
5. No gateway – allow it to use the next hop, then save.
6. Services>Captive Portal
7. Enable Captive Portal, On.
8. Put in the appropriate interface (e.g. OPT1)
9. Assign a hard timeout that’s appropriate
10. Use Local User Manager (or RADIUS if you’d prefer), save. Click Users, add a guest account.
11. Services>DHCP server, and switch to the correct interface tab. Have it hand out IP’s in a range that makes sense… 192.168.177-192.168.177.250. Click Save.

You’re good to go… just hook up a test system to the captive portal segment, and verify connectivity.

pfSense: media and mediaopt settings are not taking effect

I did run into a small problem my first time through with the 10MB Full-duplex change on my WAN interface. At the time I was using some generic NIC (non-Intel), and found that the XML setting change wasn’t taking effect, even through a reboot. I ended-up needing to SSH into the box, open a shell, and execute the following command:

ifconfig dc0 media 10baseT/UTP mediaopt full-duplex

Where dc0 was my WAN interface (click Status, Interfaces to verify you’re setting the right interface address). If you find yourself in this situation though – go back and check to see what type of NIC you have. I would suggest replacing it with an Intel NIC, or at the very least something else on the FreeBSD list of supported ethernet devices.

pfSense: Editing /conf/config.xml file

The ISP's internet conenction runs on port expecting a 10MB Full-duplex device to be plugged into it. The WAN interface on our PFSense box is a 10/100 NIC, which when uplinked without making any configuration changes, I found that I was only getting about 25% of the capacity I was expecting. The only way to force the WAN interface to 10MB/Full-duplex is via the /conf/config.xml file. There are two way to edit this… one is using vi from SSH.

To enable SSH do this from the PFSense web-interface:
Click System>Advanced>Secure Shell, Enable Secure Shell

Even if you prefer to use the PFSense web-interface to edit your config.xml file (make a backup copy first), the shell came in handy a few times throughout my configuration process. The other option to edit the config file is using the editor in the PFSense web-interface.

The editor is available here:
Diagnostics>Edit File. The Load/Save path is “/conf/config.xml”.

Scroll down until you find the tag. Then remove the lines that start with <media/> and <mediaopt/> and replace them with ones that say this:

<media>10baseT/UTP</media>
<mediaopt>full-duplex</mediaopt>


Then click Save. You can check to see if this took effect by clicking Status, Interfaces. The WAN interface should now read “10baseT/UTP ”. This change should take effect immediately – if not, give the box a reboot (Diagnostics>Reboot System).

Firewall: pfSense exceeds my expectations

We recently upgraded our internet connection; going from a strained half-duplex DSL connection for our rapidly growing business, to a 10Mb full-duplex, SONET-based fiber optic connection. So the question naturally becomes – will the existing firewall support the new internet connection (unfortunately it won't), and what type of firewall should we get.

Like most of you, I’ve had the chance to work with a wide range of firewall products… everything from the typical SMB-fare… like Sonicwall and Snapgear, to products such as the Cisco PIX/ASA, Checkpoint appliances, and others (Microsoft ISA of course). What do I like? Well, it really depends on the situation. In general, I’m a fan of Cyberguard’s Snapgear line for the SMB-segment. In my current situation though, the need was for something that we could get up and running in short order, was very configurable, supported connection failover, had some good built-in graphing and logging… and that wasn’t very expensive. That last requirement is important – no need to burn through budget on overhead when we could be investing in something else that would drive revenue.

So, after looking at the usual suspects we added products from Fortigate, Astaro, and pfSense to the list. Having just been through the evaluation exercise, I really think Astaro has a slick product – but fully configured it’s expensive. pfSense on the other hand is an open-source project (based on FreeBSD) that more closely meets our needs. Specifically, it does everything our existing firewall does – except it does most of it better. It’s free. It has RRD-based graphing, which I’m a fan of (replacing the tapped NTOP-based monitoring solution I had in-place). It also has some nice features that we're already taking advantage of, including the captive portal, traffic shaping, and one-touch add-ons (like IDS - though we're not doing this on the firewall yet).

The initial deployment went off without incident, and I’m in the process of putting together a warm spare - which may end up being a backup for Active-Passive failover. I plan to post more of the learning’s that came out of working with pfSense in my test environment in the near future.