Don't load images (icons) from a public web server, put the images into the local pfSense web server. It should not be necessary to have internet access to use the pfsense web GUI on a private network.
I also had some very bad experience with pfense performances in a virtual environment.
Under Proxmox any kind of network load have an abnormal impact on cpu load, often almost freezing the host.
On esx it's a bit better but at the cost of low throughput.
From what I've read it's an issue with offload/checksum with FreeBSD.
After lots of digging on the subject I gave up and switched to VyOS for my proxmox cluster. It doesn't have a nice web panel but the load of the host is now barely noticeable.
4-5 years ago I used pfsense as internet gateway and vpn for point to point in an office with probably 20-30users.
We had it clustered between a VM (on ESXi) and a physical appliance on alix (if I recall correctly, or another of the supported sff appliances). The VM was rock solid while the appliance from time to time was experiencing issues (stuck/memory exhausted I think) up to the point that DHCP lease were not released anymore and the office was de facto unable to work.
I think at the end we just kept the VM running alone.
I don't on my FreeBSD hosts and haven't had any problems, but I think it depends on the drivers you have installed. On all my production servers I use standalone Intel NICs w/ the Intel drives; pfSense may be using something else depending on the configuration. FWIW, pfSense has been basically stock FreeBSD + software/skin for the past couple of years.
I've used pfSense in VirtualBox for years, as VPN-gateway VMs. I'm posting from a VM that hits the Internet through three VPNs in a nested chain. Each pfSense VM uses just ~70MB.
There's not an appliance per se but you can just install it to a virtual machine. I was running a 1 CPU, 256MB instance with a 100mbs line and noticed no issues - ESX running on Core i7-920
I really thought they had a blog post somewhere or maybe a tweet or something stating they were planning to support a vm, but I'm failing to find the link. Maybe I'm remembering incorrectly. In any case, they do have a forum section dedicated to virtualization:
Just use OpenBSD. They are the upstream developer of pf anyway.
pfsense uses FreeBSD's fork of pf, which is years out of date. They forked in order to add multithreading, ostensibly for performance. But the diff is too complicated to keep rebasing on top of upstream, so they're stuck with a pf from 2009.
Here are a few resources to get you started. You'll learn plenty about routing!
Compared to Linux, OpenBSD is starkly minimal. It can be a little bewildering when common programs seem to be missing, but the man pages are outstanding. And the system is very simple and reliable. Config files are almost comically short. My /etc/hostname.re0 config is just five bytes: `dhcp\n`.
I appreciate pfSense offering something that's better than the average firewall, but I really wish they would just build it on top of the latest release of OpenBSD.
OpenBSD and pf really is the best. As noted above, FreeBSD has wandered off into the weeds with pf for no good reason. There have been so many improvements to pf since 2009 that I wouldn't even consider using something that old.
I used pfSense years ago when I was first learning firewalls. These days the best GUI for me is no GUI but a CLI, but some people don't want to take the time to build a firewall. Granted, once you know how to do it, it doesn't take that much time to build a firewall, but it does take time to understand what you're doing and why. But really, not that much time, considering the aggravation it can save you down the road.
Dunno about Linux but OPNsense forked off them a while back. Can't speak about the rest but I know that fq_codel is supported because I use that myself.
(Frankly, I switched away from pfSense because I like the OPNsense developers and surrounding community better. I'm more confident that if they haven't already addressed those defects, they will soon or they'll welcome patches that do.)
I was going to say ipfire, which is particularly interesting to me because of grsec built in, which is awesome.
That being said, if you haven't already, it's time to start learning NFTables and skip right to the chase.
Personally, I tend to not like abstracting firewalls away via guis or other methods like firewalld. It's more work sure, but I understand whats going on and have better control.
You probably know, but pfsense is mostly just a nice UI on top of built in networking support in BSD. Linux network support has a lot more features on top of that.
You can do more than pfsense with a plain old Linux box but it takes some dense reading to learn to manipulate the traffic control and routing tables yourself.
The reason why most open source router distributions with a UI are pretty basic is because everyone doing things sufficiently advanced knows how to manipulate the network stack directly and only needs command line
"You can do more than pfsense with a plain old Linux box but it takes some dense reading to learn to manipulate the traffic control and routing tables yourself."
That's why having a nice UI adds already a lot of value :).
I wanted something under Linux and I ended up trying a combination of Shorewall and its Webmin plugin to have something similar, but a more holistic solution would be interesting.
Not to mention that PFSensenormalizes a lot of management. It provides an easy mechanism to queue changes and apply them, lof when changes were made and what the changes were, etc.
In a previous job we used to deploy OpenBSD firewalls to provide site-to-site VPNs. We switched to PFSense because management was easier when you have 10-20 of them to deal with, and multiple people might have access.
That said, we definitely would have preferred an equivalent interface on top of OpenBSD instead of FreeBSD. There were some differences in the CARP implementation in FreeBSD that made some features of CARP we relied on with OpenBSD unavailable in FreeBSD, and thus PFSense.
I wish there were better UI based ditros but the value is kinda limited since people doing the really advanced stuff know Linux specific networking like qdisks and iptables.
You pretty much learn the commands while reading about how the stuff works. I've seen a ton of horribly configured psfense boxes because it exposes all this functionality to people that honestly shouldn't have it and don't know what they're doing.
It's like regedit for networking. If you know enough about the registry to be fooling with it you don't really need a UI but it's nice to have
> Web panel allows root code execution on the device (every XSS is full RCE!)
I assume this is only true in the context of authenticated sessions within the web panel, right? If that's the case, is there really a lot of damage an attacker could do with RCE in an authenticated session that they couldn't already do with admin access in the portal? I could be wrong, but it seems the security implications would be roughly the same just by virtue of providing a web admin tool with the ability to perform almost any superuser-level action.
Yes, RCE allows an attacker to install a permanent bot/rootkit/whatever. XSS and CSRS can allow the attacks to occur silently. Put them together and you can get hacked just by browsing the web, without ever realizing it.
If I remember correctly, the web panel allows installing packages from custom repository sources. I'm not saying that's inherently secure (it obviously makes other vulnerabilities much more critical), but how is it realistically different from arbitrary RCE within authenticated sessions?
I agree that CSRF and XSS vulnerabilities - when combined with superuser-level access of any kind - are basically "game over" for security, but from what I've seen, pfSense has been reasonably quick to patch any such vulnerabilities in the past. XSS, while still applicable, is less likely in a system where very little third-party content is rendered in the browser. When it comes to CSRF, I believe most security-conscious administrators keep things like pfSense web sessions limited, logging out before resuming any other browsing (or better, using it only from a separate browser profile). That doesn't solve those issues, but it can limit the attack surface.
Not trying to defend pfSense's security as a whole; I'm just pointing out that RCE is somewhat irrelevant when we're talking about a tool that already allows so much access anyway. One should essentially treat a pfSense admin session as if it were a web-based root shell (because it essentially is that).
A web admin tool that can perform superuser actions is - and probably always will be - less secure than other alternatives. Security-conscious people understand that, and will skip tools like pfSense in high-risk environments. But for many others, those risks are reasonable to accept for the added convenience.
There is actually work going into 2.4 that should further rectify the situation.
pfSenseHelpers.js (https://github.com/pfsense/pfsense/commit/f0136b178022cf3b04...) now contains code that intercepts clicks on anchor tags with the attribute "usepost" set. The target URL and the GET arguments are extracted from the event href attribute, and these are used to compose a new, temporary form with the previous arguments inserted as POST parameters.
Here is a simple example:
Before:
<?php
$id = $_GET['id'];
if ($_POST) {
if (!save_config($id)) {
$input_errors[] = "Something broke";
}
}
?>
<a type="button" href="system_something.php?id=<?=$id?>&user=<?=$pconfig['user']?> >
<i class="fa fa-save></i>
<?=gettext("Save")?>
</a>
After:
<?php
$id = $_POST['id']; // $_GET was changed to $_POST
if ($_POST['save']) { // The generic if ($_POST) is now if ($_POST['save'] to detect when the form is being saved
if (!save_config($id)) {
$input_errors[] = "Something broke";
}
}
?>
<!-- The "usepost" attribute is added to the anchor -->
<a type="button" href="system_something.php?id=<?=$id?>&user=<?=$pconfig['user']?> usepost>
<i class="fa fa-save></i>
<?=gettext("Save")?>
</a>
Most of the GUI is being converted to use these, and the result should be in pfSense software release 2.4.
Why isn't `$id` HTML-escaped before being echoed in an HTML attribute context? That's a potential XSS vector. Slightly more difficult to exploit when pulled from `$_POST`, but still a problem.
I don't mean to be combative, but when providing an example of how you're planning to mitigate vulnerabilities, it seems unwise to use code that contains an easily avoidable XSS vuln. I love pfSense and have used it for years, but this sort of thing doesn't inspire confidence.
Understood. It wasn't provided in the example, because it is not a user-entered item and is rarely displayed on the screen. It is typically an index. In other cases (perhaps) because people who originally wrote it knew no better.
(There is a lot if "isnumeric()" stuff used around $id. I inherited this codebase.)
I also happily use OpenBSD on my firewall. Every year or two I'm tempted by pfSense, and each time I'm scared away by the thought of running PHP on my firewall, and other security issues as outlined so well in this thread by lima [1].
The one thing I most envy is pfSense's multi-WAN failover support. I have a USB LTE modem plugged into my firewall. OpenBSD can see the device, I can use it as my default gateway for Internet access, etc. However, I only want to use it when my primary ISP is down, for some definition of "down" (e.g., major packet loss). I want the firewall to detect this condition; switch to the LTE modem as the egress interface/default route; reload a different pf.conf, tuned for the LTE modem; restart ospfd, ospf6d, and rtadvd; and then watch the primary interface until it recovers, at which point the firewall reverts to its primary config and restarts the routing daemons again.
It appears that pfSense supports this scenario out-of-the-box, via "gateway groups" and multi-level tiers [2]. OpenBSD does not -- its multi-WAN support is intended for load-balancing, and/or assumes a carrier-grade routing environment using BGP or equivalent. People have asked for help with this scenario on the OpenBSD mailing lists, and the answer is usually, "this is what ifstated is for, write a script"; which is fine, I guess, but it would be nice if everyone who wanted to do this didn't have to write their own bespoke solution.
Speaking of which, does anybody here do this with their OpenBSD firewall and has a nice, clean, well-documented example of how it works? I once trawled through the pfSense source code to see how they do it, and their implementation was all wrapped up in a bunch of PHP. Yuck!
the bespoke part is "what is your definition of down?". is it 10% packet loss? is it physical loss of link? is it something else? is it a combination? is it 15 seconds of $X or a full minute?
My solution to this is to have my servers' console plugged into a separate switch and LTE router than their ethernet cards so not only do I have a redundant WAN, but a redundant router and switch as well.
I recently switched to nftables on Linux and the syntax is great, you should give it a go.
I wrote a blog post demonstrating my server configuration.
Shameless plug: https://stosb.com/blog/explaining-my-configs-nftables/
Does nftables support packet tagging/policy filtering ala pf's "tag" keyword [1]? It's so nice to tag a packet as "trusted" once it has passed an input filter, and then just pass trusted packets on outbound interfaces based solely on the tag.
For example, on my OpenBSD firewall I can write the following simple rules to restrict outbound Internet access to a specific set of IP addresses or networks:
# internal_if is the LAN-facing interface; isp_if is the ISP-facing interface, i.e., the Internet.
match in log on internal_if from <internet_allowed_networks> tag OUTBOUND
pass in log quick on internal_if tagged OUTBOUND
...
pass out log on isp_if inet tagged OUTBOUND nat-to (isp_if) static-port
The tags are sticky, so that you can apply multiple tags to packets and sort through the tags later in the pipeline.
If nftables supports something like this, I'll probably make the switch, as I prefer Linux in every other way to OpenBSD.
I'm not familiar with the pf "tag", and I gtg so I don't have time to read more, but it seems very similar to "mark"[1].
It essentially lets you mark a packet with a tag (if memory serves it's a 32 bitmap you can do whatever bitwise/assignment operations to). I used it in the beginning, but then I managed to find cleaner ways to do what I was doing.
For me nftables changed the game for linux firewalls. From the almost incomprehensible mess that was iptables we now have a clean language that lets me be quite DRY, and is easy to work with.
nftables "mark" would behave like pf "tag" if you can filter a packet further downstream based on the value of the mark. (It looks like the mark functionality is also present in iptables.)
If people are using marks for policy-based firewalls a la tag in pf, it doesn't look like a particularly common practice, based on a quick Google search. Anyway, it's a start. Thanks for the pointer.
There's a page somewhere on the nftables wiki that shows all the operations you can do, but you essentially can bitmask and compare, or just compare and do something based on the result of that conditional, so I guess exactly what you want.
pf's syntax is much easier to reason about than, for instance, iptables.
I find myself writing tiny little scripts to emit iptables syntax from something resembling a pythonic-pf, just because I make fewer mistakes when dealing with it.
Netgate/pfSense has been notoriously anti-community, with their own co-founder attacking other projects, including a recent fork called OPNSense.
They've also been very hostile towards the OpenBSD developers, and project. Despite the fact they've effectively built a business on OpenBSD innovations, like pf and CARP, even incorporating the name 'pf' into their trademark having not contributed a bit of code.. n̶o̶r̶ ̶a̶ ̶d̶i̶m̶e̶ (but perhaps some hw).
But feel free to keep using it.. no need to take my word for it.
They took much more than they have given (which the source code licence allows them to do, even if it's morally wrong). Claiming they never gave anything at all is incorrect.
> They took much more than they have given (which the source code licence allows them to do, even if it's morally wrong).
I don't want to start a flame war, but if the BSD license allows for them to do this, why is it morally wrong?
That is - how can you complain when the license explicitly allows for this? If you (not you personally, of course - but the OpenBSD project) didn't want this to happen, then the license would need to be changed to prevent it.
Of course then, companies wouldn't be as willing to use the code, as we tend to see with the GPL.
But if companies are just going to take the code, modify it, and not contribute the changes back (or contribute little back), where's the loss by using another license?
If the loss is "but the code then won't be used in the greater ecosystem", why complain when it is?
Again - I'm not trying to cause a flame war; everybody has their license and needs. I'm just trying to understand why there is complaints when code isn't contributed back under the BSD license, when it explicitly allows for this.
Furthermore, I am wondering if there is anything we can do about it, that doesn't cause the kind of ire to rise when the GPL is invoked instead. Perhaps there isn't a solution, but I'd love to hear ideas on the subject.
There is a difference between forcing what you believe to be right onto others via legal means, and wanting people to do the right thing because it is moral to do so.
And yet there are many thriving GPL projects, running on billions of devices worldwide, from routers to servers. GPL has created an environment where Netgear and Linksys collaborate on developing the same pieces of software, not due to morals, but due to it being the best option for themselves. Same with IBM and many other companies working on GPL sofware.
> not due to morals, but due to it being the best option for themselves
Indeed, and this is why the same thing happens in the BSD world. There are many examples of large and small companies, competitors, working on the same parts of FreeBSD.
Enlightened companies contribute to Free and Open Source software because it's in their best interest, not directly because of the license. Conversely, there are countless examples of companies who don't think it's in their interest, and willfully violate the GPL.
I think the contributions under discussion here are monetary, not code, so the GPL doesn't have much to do with this. pfSense is open source, so the code is available.
Personally I find antagonizing non-contributing users more morally objectionable than the non-contribution.
Of course I'm speaking generally, I don't know the backstory here so there might be some other things causing the bad blood. But I would prefer we as a community would not attack people/companies just for not contributing.
> I don't want to start a flame war, but if the BSD license allows for them to do this, why is it morally wrong?
I can legally walk down the street cursing at everyone I meet. I can try to learn things about people, and then use that to make them feel terrible. I can start a business that intentionally preys on people in bad situations in ways that will make them worse off.
I'm allowed to do all that. I believe doing any of them are varying degrees of morally wrong.
One should never confuse law and morality. They are not the same, and what's worse than confusing them is trying to make them the same.
I think a more apt analogy would be if you buy me a "free beer" and I drink it, then you're upset because I didn't buy you a "free beer" in exchange. If the beer wasn't meant to be free, then don't license it as "free beer".
The specific claim was not that pfSense merely used the technology, but also that they were hostile to a variety of community projects, including OpenBSD itself.
> I don't want to start a flame war, but if the BSD license allows for them to do this, why is it morally wrong?
Because laws and moral codes differ. As an absurd example, it is legal (in most countries?) to cheat on your spouse, but it's not considered morally okay (otherwise it wouldn't be called "cheating").
Behavior is one thing, but what is so wrong about "taking" more than "giving"? Isn't the development of a firewall distribution, and the provision of professional services around it, a good service in itself?
Kind of like Greg Hartman fussing about Canonical not doing kernel contributions, as if that's the sole metric for being a Linux distro.
Please don't remove your post. Pointing out these issues is very important, and making one donation should not indemnify people who behave in this way.
Eh, I wouldn't use the response to OpnSense against them. I tried the first few "releases" and walked away screaming (this was before I ever used pfSense). Lost configurations, routing issues, locked out of the interface, stability problems, and more. But it looked pretty, right?
Uhh, you got on the wrong ship if you think Ubiquiti has nothing to defend, your employer is a constant and consistent GPL violator[1], and due to the constant failures and overpromisiong on features (TDMA in particular) alongside the serious supply chain issues Ubiquiti has had over the past decade, your major customers are dumping your hardware en mass[2].
I don't see Solar or IoT cameras/switches/power strips saving Ubiquiti either, the fiber CPE might buy your company a few months of runway, if supply issues don't strangle it tho.
You mean "glad you no longer have to make excuses for your inability to lead the project into the future."
The recent changes in direction and actual tackling the hard problems has not gone unnoticed by me / others in the community. Kudos to the current team.
Hilarious, brand new account with one post. Another Jim sock account or one of his minions, they have a ton of them all over the Internet spewing garbage.
Anyone who's actually paid attention to the history wouldn't respond with that vitriol.
I used pfSense for a long time and ultimately the conclusion was it was a 75% solution. It made those 75% things pretty easy to set up and configure. But once you needed something from the 25% you had to dig into the BSD configuration and now had to deal with how that interoperated with the pfSense stuff. Better to just bite the bullet and configure BSD (or linux for some things it does even better) from scratch and get exactly what you want and need.
I can't say enough good things about pfSense. I'm running three of 'em and would gladly trash my Checkpoint firewalls to use pfSense, if our parent company didn't mandate them.
I've run it on everything from tiny, Atom-based machines to kitted-out HP DL385s, and even on ESXi virtual machines. It works great in all scenarios.
Happy user here. I have used this exclusively for the past eight years. It's gotten better as it's got more commercial – better UI, more polished plugins, better features, etc.
Agree. I've been running pfSense on HP thin client (T5740[1] with expansion module + gigabit dual port ethernet NIC) and was pretty happy. Cost to me was about $60 for fully working firewall/router.
We've had a lot of success with pfSense. BGP works, IPSEC works, most things work quite well with no headaches. My previous employer used a Watchguard firewall and to be honest pfSense was a much better experience all around.
Except for cloud VOIP. Neither 8x8 nor Shoretel worked worth a darn through this firewall. We even paid for the gold support and opened more than one support case with no luck. It appeared to be a RTSP issue, SIP didn't have any trouble. And it was intermittent. Most of the time it would work, occasionally it would not. Eventually we replaced pfSense with a Cisco router for our phones and it worked fine.
I always had this question - can something like pfsense be built on linux with comparable performance or is there something inherent to the whole stack that makes this effective?
I have always wondered if building pfsense on a modern linux kernel + selinux + BPF with something like nginx/lua scripting (for addon packages) would make more sense.
I would say it's nice enough for more than just "small" stuff. Depending on your definition of "small", I guess.
I'm running a VyOS machine (old desktop with a couple of NICs) which handles the traffic for our Copenhagen office. That's ~15 CI boxes, and 30 people. This is on a 100/100 connection.
For Ubiquiti, I'm a fan. I helped our co-working space setup a network on another floor, and we used an EdgeRouter Lite to handle the 200/200 connection. The ERL handles it without breaking a sweat. That's for 60 people on a daily basis.
For another building, I just finished setting up an ERPro (the 8-port rack-mounted version). It's again on a 200/200 connection, and for roughly 150 people on average, with a maximum around 300-500.
At home, I have an ERPoE, which handles my home lab just perfectly. I'm only on a 100/100 uplink at the moment, but will be upgraded to 1000/500 soon, and I know the ERPoE will handle that just fine as well (thank you hardware offloading ;)). 5 VLANs with full firewalling and routing between them, native IPv6 with prefix delegation, mDNS proxying between VLANs, OpenVPN handled by the router. I could do a lot of this with OpenWRT on an Archer C7, but the ERPoE is simply miles ahead.
The UI is nice for newcomers, and the CLI is amazing. I fell in love with the CLI on VyOS, and am very happy to see the same in the UBNT products. For $100, they are amazing devices. VyOS is my go-to choice when I need to have a virtual router.
are you talking about vyos or ubiquiti. Im not sure what the relationship is between them - could you talk about what's so amazing for a complete first timer?
VyOS is just software. So nothing to purchase there. It's what I use when I need either a virtual router, or want to use commodity hardware to act as a router. It's great to throw in ESXi or another hypervisor, or even EC2. It comes with all features you might need (probably), and because it's fairly standard Linux (Debian based), making it do extra things isn't very hard.
The ERL is $100, and comes with Ubiquiti's EdgeOS, which is largely based on VyOS (or something like that), and simply adds a (decent) web UI, and hardware offloading. This means that the ERL which runs on a dual core 700Mhz MIPS CPU can route 1Gbit/s, and not even break 30% CPU utilisation.
Where VyOS shines is when you need to cobble together a bunch of things. If you just need a pure firewall, I would probably stick with pfsense, as that is, after all, what it is good at. VyOS only offers iptables with some lipstick (which is well enough for a Swiss-army knife setting)
I guess VyOS would run on that box. I can't see specs, nor know what network chipset it is rocking, but I don't see why not.
What's 'more sense'? It seems like you're willing to rewrite and recreate existing and perfectly viable solution to a problem purely because the underlying OS is not Linux. In my world it doesn't make ANY sense - while you'll be doing all of that, I'd be already working on something else, after using existing solution to this particular problem and moving on. However, if you do have a justification for wanting Linux solving your problem, then it seems you might have different problem than 'a firewall appliance' and in such case it may have some sense ;)
Wanting pf or something pf-like on a non-BSD-based OS is not an unreasonable request, especially considering how awful it is to work with, say, iptables in the Linux world. Having a Linux-native pf would likely be highly desirable when Linux is already required in one's setup for other reasons (for example, if Docker is a dependency for what one's trying to do).
That said, my own general preference is to use OpenBSD (which means having immediate access to pf plus all the other goodies like relayd/httpd, OpenSMTPD, etc.) in all possible situations, and only resort to some other OS (like GNU/Linux) when actually necessary; thus, I can't really relate to a need for things to be the other way around :)
Chances of Linux-land adopting a NIH tech: .000001%.
They could have used kqueue, but didn't. They could have used accept_filters, but didn't, they could have adopted jails instead of creating i've lost count of how many "container" technologies, but didn't.
So basically they will toss iptables eventually and write something similar but not quite as good as pf.
The Unix world in general would be very grateful to see Linux adopt current tech rather than constantly reinventing the wheel in a "its just good enough unfortunately" incompatible way.
> could have adopted jails instead of creating i've lost count of how many "container" technologies
The "many technologies" are mostly user-level wrappers though. What actually happened in the kernel: they've added unshare(2) early on, but it only isolated filesystem mounts at first. Later they started gradually adding more things for it isolate: network, PID, IPC and users. The "users" part arrived really late and is kinda bad… that's why for a very long time you weren't supposed to give people root in a docker container, and I think it's still not recommended. That's quite hilarious, considering that jails' main purpose literally was "containing root", and it fucking worked great since the early 2000s.
> they will toss iptables eventually and write something similar but not quite as good as pf
There are over 500,000 pfSense installations in the wild. The creation of a company around pfSense has allowed them to offer real support and hire developers to improve everything from the UI to massive improvements to network stack/firewall and even IPSEC performance. These changes get pushed upstream to FreeBSD, everyone wins.
Nice, glad to see changes getting pushed upstream! It's was interesting to hit the site for the first time in many years and see how much had changed and how the project has grown!
I wonder what other projects I used to use have grown this much :)
There are two FreeBSD committers on staff (one second, the other ports), the author of the O'Reiley book on git, the guy who rewrote the GUI, and three others.
Several have really deep telecommunications equipment / router vendor experience.
Plus gnn, whom, as you say is a consultant. If we're going to include him, we should include Patrick Kennedy, who has done work on libuinet for us.
They target the market that can get them the money i guess I don't really have a problem with that since they make the best firewall/router software i ever used.
It's been a few years like that, most likely a combination between someone getting fired and starting a fork (OPNSense) which risks fragmentation (and maybe a bit more competition), and the company behind pfSense needing a bit more return on their investment.
In the long run, it doesn't matter all that much, pfSense is still 'free' as in beer, and you can still get to the sources, and forking is still possible. Only protection of the name 'pfSense' as a brand has gotten somewhat more intense.
On top of that, they are powered by their hardware sales and service subscriptions, of which the former is probably a more important source of income. It seems they either 'are' netgate, or are a subsidiary, and also partner with ADI engineering. Some hardware seems almost purpose built for pfSense, like that tiny uFW micro firewall, or the modified Turbot board (Intel) with two Gigabit Ethernet NIC's. There also seems to be a uBMC in the works, a somewhat 'universal' BMC with IPMI etc. running BSD as well, most likely pfSense-based. I suppose those would be commercially interesting but not that much consumer-oriented but more the bigger ODM's and OEM's since it requires a bit more integration. So those hardware things are a lot more 'commercial' than the software project ever was. I suppose that naturally overflows into pfSense itself.
Currently, pfSense seems to have been 'branded' as a 'community edition'. There doesn't seem to be a 'commercial edition' anywhere yet, but I can imagine a model similar to GitLab where you have a common core and a paid version with enterprise extras. It also seems to be showing the serial number or platform UUID in the web interface, I guess that's somehow going to be tied into the non-community version of pfSense to use with an activation system for the 'more-than-community' version.
I do believe that there is already at least a special version for VMWare on their 'market' or whatever it's called, and a possibly modified version that runs on the pfSense or netgate branded hardware since it needs special software support to function due to it not being simply a 'standard x86 PC'. The uFW is ARM, so a working ARM version of pfSense is out there too!
Notice: a lot of this is just observation and speculation on my part, but it might help you dig for clues on the interwibble.
You know what's open source and works great as a firewall (also based on pf)?
OpenBSD.
No, seriously. Don't bother picking a third-party repackage of pf, when you can actually get the a secure OS built by people who actually put security above everything else. If you care about security, there's no reason to go elsewhere.
A fan of pfSense, I've used/deployed it a number of times to customers, and for some previous employer bits. Current version doesn't have an API, but is fine for what I do with it.
I did see people hating on it here, and while I cannot/will not speak to their specific issues, I look at it as a much better tool than the integrated hardware units you can buy online for ~$100USD, with also integrated back-doors, courtesy of the development effort.
I know perfectly well that I could build what I need using IPtables ... but have you used IPtables? I'm a CLI guy, and heck ... I want a GUI for IP tables ...
I've not yet played with the nftables, and frankly, I am looking for a generally simpler model of putting some of these things together. pfSense does a pretty good job of this.
One note on the php on the stack ... yeah, this is a concern for me as well. So I don't generally expose the admin access to the interwebs. And I lock that aspect down pretty hard (only specific addresses are allowed to even connect to the admin port). This isn't perfect, but its far better than setting up a web port, and suddenly presenting the pfSense gui out (yeah, this sorta happens by default if you don't move the gui to a different port, and do some other config).
This all said, it is pretty good for what it does, and a few of my previous customers have bought the support for it directly from the team.
I use pfSense as a vitual machine to firewall/NAT off my vitual environment. It works great. I am running it on KVM/QEMU and handing off the PCI device to the pfSense VM. Great for managing my environment through VPN.
I've also used this in a retail chain in DC/MD/VA. Each location used pfSense for site-site VPN (OpenVPN). We also used the asterisk package to handle VoIP.
Is this 'pf' like the BSD firewall? Anyone more familiar with the space want to provide some detail?
Edit: yeah it is:
> The pfSense project is a free network firewall distribution, based on the FreeBSD operating system with a custom kernel and including third party free software packages for additional functionality.
Yep, basically a really nice web interface and management system for configuring a pf-driven firewall.
You can click your way to high availability with sub 5-second failovers (even including NAT state synchronization) in a morning starting from no pfsense or bsd knowledge.
We use pfSense at a client of mine and it's great. I didn't have any prior experience with it but I only spent a couple of nights setting everything up. We use it to manage firewall rules and as DHCP server for 2 VLANs.
We've used it for about a year now. Had several power outages. The pfSense box is still running like a champ, no problems whatsoever.
Turns out my client actually wanted an email spamfilter though, but our mail is hosted in another country so I had a little trouble explaining why our internal pfSense couldn't help us there. Oh well.
I've been using PFSense both at various workplaces and at home for many years now, it's seriously fantastic. Feature rich, rock solid and good 3rd party packages.
Unless your needs are extreme in which case you will have networking experts making choices the linux networking subsystem is actually quite good both in terms of tooling and performance.
I experimented with Vyatta which was based on Debian - open source fork now used by Ubiquity networks in their devices, and pfsense a couple of years ago and I found plain linux on its own delivers better performance. The recent series of Ars articles on building your own router confirm this with some benchmarks [1]
Been using pfsense for a while now, and with CARP and system redundancy, firewalling, and twin ipsec tunnels to AWS, it's been great and hugely reliable.
Ironic. I just did the reverse. Moved from years of Meraki to pfSense (or Palo Alto Networks at another company). The Meraki WAP's are mostly great, their switches are fine, but their "gateway" devices are terrible. The performance is horrible and their internal tests have proven as much. If you need more than 150mbps consistently, Meraki is going to bite you in the ass.
I don't have such experience. I tried to configure IPSec and IKEv2 in pfSense following the instructions and it never worked with a Windows client. There are a lot of questions related to this on the forums without a concrete/canonical answer.
I like pfSense but I chose it to easily configure usually complex networking stuff, not a DHCP or DNS. We are trying now to configure IKEv2 on an Ubiquiti device using UniFi with a load balancer and doesn't seem to be trivial.
When did you try the IPSec/IKEv2 in pfsense? Prior to, I think, 2.4 you had to go into the registry and do some hack to get around certificate limitations. It's no longer necessary and setup was a breeze for me (and the registry hack worked for me as well). I loosely followed: https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2
Yeah, but that's mostly because IPSec supports so damn many authentication methods, cipher settings, etc.
I've had to integrate with several telcos via IPSec (mobile money processing), and it's always fun to try and figure out what they're saying when all they can do is describe the [incredibly generic] settings in the Cisco ASA WebUI.
Then you finally figure out the ipsec.conf settings to make it work, and they come back to you a month later asking for a copy of your file to give to another company who's trying to integrate.
Sure, how much are you going to pay us? Oh, nothing? Well, I remember how much help you gave us when we were banging our head on the wall trying to figure it out. So, hire competent people and figure it out yourself!
No API means no automation, no Chef/Puppet/Ansible/Salt or other kind of scripts. Everything in the head of the person who clicked through the web interface.
Usually when people mention they run pfSense it means, "I heard pfSense is good for security so I use it". If I get that impression in an interview, GG. IMO it's an easy litmus test for netsec/secops roles. If you can't write a pf rule, there are probably bigger issues. OpenBSD is the way to go.
I also think the pfSense CEO has a massively inflated ego and pays little homage to the roots of his software. Does pf really need a GUI?
- Web panel allows root code execution on the device (every XSS is full RCE!)
- Everything runs as root
- No ASLR or other hardening flags because FreeBSD
- Lots of XSS and CSRF opportunities (probably got better with the new UI)
- Did not replace SSL certificate after Heartbleed (on packages.pfsense.org!)
- No package signing, either (not sure if this is still true with pkgng)
- Did not even have SSL on packages.pfsense.org until one or two years ago
I'm also missing the fq_codel queueing discipline on my home network (prevents bufferbloat).
I still use it since it's awesome, but I hope their security posture has improved since.
Most of the commercial vendors are even worse, but still.