This[0] change is interesting for home deployments of IPv6: If your ISP changes advertised prefixes occasionally (which mine does), it was until now not practical to assign/use addresses with fixed host suffixes, e.g. for internal services, because you couldn't write firewall rules using those addresses (part of the address could just change and there's no automatic update of the rules).
The change now enables you to write firewall rules that use a placeholder for the ISP-assigned prefix. The rules should update automatically after a prefix change.
(What has always worked is using the fc00 or fd00 address spaces for local fixed assignments, but pfSense has had problems with that setup as well in my experience)
That's good, but it's so frustrating that ISPs can't just give out a permanent address range for the lifetime of a subscription. Imagine if your telephone number changed occasionally. It's ridiculous. Some are continuing to charge for a "static IP address" under IPv6 as if they are scarce or cost them anything to implement.
I believe it's more of a) some carrier-grade routers basically not supporting static IPv6 unless IPv4 is also static (don't ask why it's like that, some NOCs also deal with buggy CG and CPE firmware in general) b) deliberately done, because in those countries privacy concern in residential connections is paramount.
While the phone number analogy does make sense on the surface, I have to agree, I don’t want my IP to be static for privacy reasons.
It’s not a great barrier, but I don’t want the bare minimum skills advertiser, hacker, MPAA consultant, web store, or whoever being able to easily rely on this IP being me.
Yes. There are tracking cookies, and fingerprinting, and whatever, but the bar being set this higher is better than lower.
The phone analogy makes sense until you realize you’re actively calling everyone all the time, and the callerid shouldn’t be easily readable. It’s not like phones at all really.
In residential connections, every marketer will just figure out that particular AS gives /64 (or /56 or /48) and bundle them up, like how they use IPv4 address to track families.
Indeed, stuff like IP blacklists, tracking, etc should never consider anything smaller than a /64, because it's trivial for the target to change its IP within that space just with SLAAC.
About damn time. Now if only they would fix their completely broken Dynamic DNS update implementation so I wouldn't need to write a cron job to make it work properly...
> If your ISP changes advertised prefixes occasionally (which mine does), it was until now not practical to assign/use addresses with fixed host suffixes, e.g. for internal services
This is actually one of the use cases where 'private addresses' make sense: when you don't have a static assignment but need static addressing.
In the IPv4 it's very unlikely that you'll get a static address unless from ARIN/RIPE/etc (or pay US$ 25+/IP on the open market), so we have everyone using 10/8 with NAT. It's quite easy for someone to get a statically assigned IPv6… unless you're a home user. So if you want static address, use the IPv6 equivalent of 10/8, ULA:
The interface portion of the IPv6 address (right-most 64b) stays the same, and only the prefix (left-most 64b) gets shuffled as they pass through the gateway.
I'm really stuck between deciding on which. opnsense claims it's concerned about code quality and separating logic from the UI. Sounds great (and means that pfSense must really suck in terms of code quality and security if they aren't doing that) but then following the link to the PHP framework they use you get:
> A full-stack PHP framework delivered as a C-extension!
I mean, I've can't even begin to imagine how insecure that awful combination of insecure by default languages is.
Yes, it's no Rust, but so what? You'll be dealing with a locked-down box in most/all situations, stuff won't be accessible to other than the sys admin (unless you misconfigure it).
I can't really comment on the quality of the code, my reason for going opnsens over pfsense is mainly because the company that owns pfsense seem to be real asshats.
OPNSense replaced a lot of the old PHP that was in pfSense after it forked. So if PHP is a concern for you, you could argue that's OPNSense's PHP is better than pfSense's PHP.
OPNSense also splits front-end into the MVC and control layer, as well as the back-end between the control layer and the configuration daemon which is written in python.
All of the actual packet processing and daemons are C or C++, essentially the standard packages you'd find in FreeBSD.
Whether PHP or C is more secure depends on who wrote it.
I'm not a PHP programmer so I can't assess the quality of the code myself but do we know objectively that OPNSense's PHP is better than pfSense? That seems like a big assumption that just because it's been rewritten it's more secure or "better"
I do because I've worked with the code. It's not 100% beter or something like that, but the Phalcon framework does impose quality requirements to work with it effectively. It also has immutable facilities loaded as an extension (for speed benefit but also means you can't actually mess with the framework at runtime).
While I haven't really done any hardcode PHP work after PHP5 came out, there are plenty of ways to do it wrong, and a few ways to do it right. One thing is separation of concerns and encapsulation to the point where a fault in PHP can only mess up the PHP part and not the external system PHP calls into to ask for configuration changes.
Currently, a lot of the old pfSense code has been removed and replaced with code in the MVC framework, but it's a lot of work, and the team behind open-source OPNSense isn't huge. It will take time to cover it all.
If it helps, about a year ago I was replacing a UniFi setup at home and I was trying to decide with pfSense or OPNsense. After poking at both in VMs for about a week I settled on OPNsese.
My main reasons were that it did everything I wanted pfSense to do, something about the UI felt a bit smoother to me, and it didn't have the smarmy/wonky feeling that pfSense does (aggressive company behavior, closed-ish stuff, and then post-switch the Wireguard stuff happened).
I'm running this on a Protectli FW4B and have been quite happy. It's still doing exactly what I wanted, updates have been good, a bug I reported got fixed quickly, and it's... just working.
Also, by going to open hardware (and not the Netgate stuff I was originally thinking of) I can switch to another platform (eg: Untangle, OpenBSD) if desired.
But, for the forseeable future, OPNsense seems to be working just fine. <shrug>
I moved entirely. It was mostly the GW that I didn't like. The primary bug was when they changed the maximum SSID length from 32 (standard) to 31 and I could no longer edit my network.
Then there was just some various other quirkyness/weirdness, and I happened to get out just before the big security breach was disclosed.
I ended up going to a Ruckus R610 AP that I got via eBay running the Unleashed OS, and it's outstanding. Coverage is so good I no longer need my old AP + extra mesh'd one.
For switching I'm just using an old TP-Link that I had laying around.
UniFi seemed really neat at first, but then it just felt... overwraught. I don't need single-pane-of-glass monitoring of a ton of stuff for my home network. I don't want to run a management software server just for my home network. I do want something robust, but I don't want to worry about it, and I want to be able to piecemeal upgrade it. A small PC running OPNsense + a solid AP + just whatever for switching does exactly that.
(I'm not a homelab-type person... If I want that I use VMs, or my employer's hardware. I want my home network to be a solid, reliable utility that requires little maintenance. I don't want to be tweaking my home network after my day job.)
PHP is already written in C and can be quite secure when following best practices (as with any language), so I'm not sure why an additional PHP extension written in C would be a red flag?
Note that Phalcon is a PHP extension (not a C extension) that provides new functionality available in the PHP runtime. This is roughly equivalent to a Ruby gem with a C extension, like Nokogiri.
> I've can't even begin to imagine how insecure that awful combination of insecure by default languages is.
Phalcon was at one point moderately well-regarded, though it's fallen out of favor for a wide variety of reasons, mostly the PHP development style moving on. I say this because as near as I can tell, Phalcon has had an entire single CVE in its entire decade plus of active development.
Casual anti-PHP bigotry isn't just uninformed, its harmful.
Opnsense has been far more consistent with their upgrade releases.
Migration is really a complete reinstall and rebuild of your rules. I took a backup of my physical pfsense box and restored it to a VM then reinstalled opnsense on the physical hardware. With the pf box running in a vm I could just reference it while creating new rules.
I think someone made a script to load a pfsense backup onto an opnsense instance but I really think you’re better off with a clean slate.
OpenBSD is also my go to. The only caveat I'll throw out is when I upgraded to gigabit internet I discovered OpenBSD on the protectli FW4B couldn't keep up. In fact in iperf benchmarks it pushed ~300 Mb/s to FreeBSD's 600 Mb/s. Considering all the work done on Linux's network stack I plan to try it next to see if I can squeeze any more out of the hardware.
Just means anyone who wants to try OpenBSD should spec something a little more powerful than that appliance.
I don’t know if it would fix your problem, but pf on FreeBSD is SMP-enabled unlike OpenBSD’s. You have to deal with using the “old” pf.conf syntax though.
I've been looking to replace the ancient, used, power hungry, overbuilt 2U rack server I'm currently using for PfSsense with something lighter (ditto my Proxmox server, incidentally). Last I used OPNsense it had issues with the NICs in whatever it was I put it on that caused it to frequently drop connections. Is there any recommended hardware for OPNsense?
I have used a low power Qotom Intel-based mini pc with 4 NICs running Opnsense since version 18.x. I bought it off Amazon for 300 USD and it runs like a charm. It currently serves my 1Gbps fibre connection with significant amount of simultaneous workloads without a sweat. Only downside is in the older models the Qotom bios will not get past POST if no screen is plugged in, so you will need either a screen when you reboot or a stump VGA cable with a resistor built in.
Apart from this, I can highly recommend it.
Seconded. These are my default choice for pfsense (and probably opnsense in the future).
Only issue I've had is that if it's a J1900 Celeron CPU, ensure you have the machine set to boot via UEFI before installing. (IIRC there's an open issue for FreeBSD installations failing to legacy boot on J1900 boards.)
You are going to run into that issue with literally any OS or distro you choose. If you don’t want to spend 30 seconds typing a search for i210 (or insert chipset) then you should buy one of the appliances that opnsense sells. Just expect to pay a premium to be lazy.
> You are going to run into that issue with literally any OS or distro you choose.
PfSense offers a range of hardware they support, which disproves your assertion by itself without even mentioning companies like Apple and System76.
> one of the appliances that opnsense sells. Just expect to pay a premium to be lazy.
I'm totally willing to pay a premium to be lazy. Where did I imply otherwise? If OPNsense offers hardware these days then why didn't anyone just say so?
> PfSense offers a range of hardware they support, which disproves your assertion by itself without even mentioning companies like Apple and System76.
That disproves nothing. If you want to build your own system you need to research hardware if you want to have a pain free deployment.
> I'm totally willing to pay a premium to be lazy. Where did I imply otherwise? If OPNsense offers hardware these days then why didn't anyone just say so?
This forum is generally filled with people who want to build their own. As for why nobody mentioned they sell hardware: probably because they sold hardware from the beginning and it’s advertised all over their site?
> That disproves nothing. If you want to build your own system you need to research hardware if you want to have a pain free deployment.
Again, I said nothing about building my own.
> This forum is generally filled with people who want to build their own.
This forum is generally filled with people with a lot of qualities. For instance, there are a lot of people here who buy Apple products, which are very much not in the spirit of building one's own. Your assumption doesn't make a lot of sense to me.
> As for why nobody mentioned they sell hardware: probably because they sold hardware from the beginning and it’s advertised all over their site?
That's fair, I haven't looked at their site in ages because the last time I used OPNsense was after the very initial split and to my recollection there was no hardware then.
OPNsense NIC compatibility seems mostly down to FreeBSD compatibility since it's built on the latter. So you can look at guides for FreeBSD itself or other systems based upon it. For example, STH's rundown of "Top Picks for FreeNAS NICs" [0] applies pretty well to OPNsense as well. The short version is that Intel and Chelsio have excellent support, though for just 1 GbE not really any reason to get anything but Intel. STH recommends Chelsio for 10GbE+ and from my limited testing that matches my experience pushing OPNsense as well. The main thing I encountered you should be aware of is that OPNsense (at least as of the current version 21.x) does not enable the Chelsio driver (cxgbe) by default so you need to add the loader to have it recognized. See the FreeBSD man page cxgbe(4) [1], you can add that in the Web GUI via System > Tunables.
Alright, let me rephrase this since people are misunderstanding:
Does the OPNsense project recommend or endorse any specific models of low-power all-in-one computer hardware for running OPNsense? And if no, is there any specific thing the community would recommend?
I don't want to spend hours on research or build something on Newegg. I want to by a complete piece of hardware that I install OPNsense on and know that I won't have to worry about hardware compatibility.
PS: Apparently OPNsense offers their own appliances these days just like PfSense does.
I use a few of these, they work great. Although I personally run Linux on them, I don't see any reason why OPNSense wouldn't work, as it's essentially just an x86_64 system:
I've been using one of these for over 5 years as a home router, it's been very stable, not a single issue, only reboots have been for OS upgrades. Very nice little boxes. Had to put it together initially (think the heat sink and nvme and case) but that was straight-forward. Has supported everything I've needed over the years.
My obligatory “PFsense is a terrible childishly run project that took out a domain in their competition’s name and made a derogatory website about them before being shouted down” comment.
From the link:
“ Some of you may have come across OPNsense.com a domain that until September 21, 2017 was home to a controversial website with content targeted to harm our open source project.
On the fore mentioned date we filed a complaint with WIPO, the World Intellectual Property Organization to try and stop this website from being operated.
Until our legal action we were unable to determine the owner of the domains as it was registered using Domains By Proxy, LLC, however we believed the site was created by a pfSense enthusiast who had gone a step too far.
Much to our surprise we received an email on September 26, 2017 stating that the owner of this domain was in fact Jamie Thompson, Rubicon Communications dba Netgate also known for the competing pfSense project.”
Ever since cmb sold to netgate the Pfsense project has been run by people who I suspect are working hard to find a way to stop releasing open source versions.
FYI, my observations as an outsider are the project went through three phases of owners:
BSD Perimeter is owner and starts open source fork creating open source releases = CMB and Scott as founders.
Electric Sheep Fencing ownership is a result of CMB taking more of the day to day while Scott bows out and Netgate starts funding things / sinking hooks in. Open source continues to be important and CMB is in charge for the most part.
Netgate ownership completes obtaining full ownership / gets their hooks into every bit of the project. We see annoying screen about licensing and they start nonsense with OPNSense to flex their tiny muscles.
FYI netgate hardware isn’t bad and you get stellar support for what is currently an open source product but they have worked hard to fracture the hard won trust CMB had been building up in the community.
I remember when pFsense removed the pfsense-tools.git from github because people were creating forks from pfSense.. looks like somebody got the open source thing totally wrong:
Definitely. Their aim has always been to figure out ways to squeeze the software for money. It partially makes sense as they built the company and expenses first and now have to monetise that. Yet nobody asked for it.
With pfSense "plus" they published that they will only work on that paid product and mostly ignore the open source stuff, only do the essential requirements. It's essentially just a marketing gateway into their closed products. At that point you might as well buy any other mature closed product... there are many and from a closed source commercial product perspective they are all better than wat netgate produces, including commercial VyOS without a gui.
I've wanted to go that way for some time, the real problem is that it's basically impossible to hand that off to another net/sysadmin. Imagine walking onto a new job, and they hand you a yubikey and say "here's your keys, the old guy whiteboxed everything with Debian and BSD. Have fun!"
Unfortunately, the only time CLI wins out in networking is when there's a cert to dangle in front of people. As much as I want to do things the "right" way, part of that equation is handing projects off to other people to maintain...
Unfortunately, the only time CLI wins out in networking is when there's a cert to dangle in front of people.
I'm not sure what world you live in, but in the Cisco world I don't know anyone who does anything beyond the trivial in the various 'GUIs'.
part of that equation is handing projects off to other people to maintain
Yes, and I don't know anyone who would hire a Cisco engineer that wasn't fully conversant with the CLI. The idea that something we've been doing, successfully, for decades (handing a text Cisco config to the next engineer) is "basically impossible" is...interesting...and unsupportable in my experience. As is the implied "GUIs are always easier to understand and reason about".
As does OpenBSD - VLANs and IPSec on the OpenBSD CLI are simpler than you think! Personally I think it's simpler and easier to use than even pfSense.
Point is still valid through. Especially compared to some overly-complicated implementations, the pfSense web UI for VLAN and IPSec can be a better alternative.
Linux + nftables (nft) also isn't a bad choice. I just replaced all my iptables scripts with nftables equivalents and it was actually a pretty enjoyable experience. Some highlights of nft over bash scripts with iptables commands:
1.) Your firewall scripts are now atomic (if using nft as your interpreter instead of bash), so either the entire ruleset gets applied, or nothing does.
2.) There's a nice declarative form of the nft syntax which I prefer (vs a more imperative style which we're all used to with pf (in the BSD world), or iptables)...both forms are executed atomically when the nft interpreter is used.
3.) The presence of an actual 'include' statement makes it possible to break your fw scripts up into multiple files, for better organization and readability. This also all gets executed atomically.
Of course. I wanted to move off of pfSense, but I wanted to roll my own. I tried to build something similar with NixOS but learning all the ins and outs of Nix got a bit overwhelming for a device whose config changes rarely. I ended up just grabbing OPNsense, installing it, copying my configs over, and it’s been a solid 48 hours since.
Can confirm. I recently set it up and ran into an issue with my ISP’s DHCP implementation. There was a pull request for PfSense from like 4 years ago that helped with the issue but remained open. The OPNSense developer I talked to merged a modified fix within a very short time and is even helping others test their broken PfSense systems.
I've been using pfSense for many years, generally happy with it. The wireguard fiasco made sense to me when I saw some former colleagues involved (including 1 I hired at a previous gig, and one I interviewed before he joined the co). Instead of taking their loss, admitting they screwed up, they tried FUD. This ... was in line with what I experienced in the past. Extremely unprofessional.
Thanks to them, several years ago I swore off FreeBSD. The tech may be ok/good, the baggage of personalities and egos is not worth it though. After seeing this, and at least the two of them associated with pfSense, I've now started looking for replacements for pfSense.
I've been thinking of OPNsense, though the whole FreeBSD bit bugs me (code/OS is fine, personalities/egos less so). Linux "equivalents" sort of exist, though reading through the various fora for them suggests similar ego/personality issues.
I'm not sure its bad enough to go back to dedicated firewall/router appliances (most are terrible and closed source). If there is a simple way to convert my pfSense config to a OPNsense config, this is likely to be the first step I take.
I'd love to hear other people's experience converting away from pfSense.
I don't follow; why would you swear off FreeBSD because a derivative product misbehaved? Would you swear off all Linux distros because Ubuntu did something bad?
The issue wasn't that the product misbehaved. The issue was the personalities/ethics of the people involved are grating/questionable at best. Having worked with them, I honestly question their judgements.
Since one or more of these people are or have been core committers on FreeBSD, this makes me question that project's judgement.
Wireguard’s founder, Jason Donenfeld, reviewed Wireguard implementation in Pfsense/FreeBSD. The review was very negative, with numerous pointers to critical (sometimes childish) security flaws.
Why would someone use a router operating system with such strongly negative review from a respected security specialist?
A minimal Linux installation is an option, if your firewall is simple.
The implementation got pulled from FreeBSD and a new implementation have been made by contributors including Donenfeld, though it will likely not end up in mainline FreeBSD before the next release.
I've been quietly nibbling away at making my own "router distro" since PFsense's wireguard fiasco
I never much liked PFsense as a project. It feels very convoluted, and the hardware they sell (I was an early adopter of the then-new SG1000 appliance) is laughably exaggerated in its capabilities
But the Wireguard event is where they went from "incompetent" to "malicious" in my eyes
I ordered a Rasberry Pi 4 compute module and this accompanying ethernet breakout kit after seeing a review from Jeff Geerling (Raspberry Pi accessory mad scientist) and am currently waiting for it to arrive https://www.dfrobot.com/product-2242.html
I know I could just use something like OpenWRT, indeed I do have a lot of respect for the OpenWRT project. But I feel that the distro is more geared toward, well, routers. Devices with maybe 32 megs of flash storage and a slow MIPS CPU. Not a moderately powerful ARM machine with 8 gigs of RAM and gigabytes of SD or eMMC storage
In 2014 I decided that what I wanted most out of my house router was ongoing software updates from the distro, and that I would be willing to pay more for the hardware in exchange.
For seven years, then, I've had a mini-ITX x86-64 box with a small SSD, 4GB RAM, and 5 gigabit NICs running Debian Stable. It's been upgraded in place and I see no reason why the upgrade to Bullseye in a month or two won't go as smoothly.
I think a Pi4 is roughly comparable in computation capacity, perhaps less so in I/O -- but what I've got is clearly overkill, anyway.
That's effectively my current setup, some random Dell i3-4310 machine. But it's just overkill as hell for a basic router on a 100 megabit internet link
The Pi one can apparently saturate a gigabit iperf test without issue, so it sounds like a great replacement and rainy day project
I've been using them for years w/out any issue. I just run standard Debian stable as well, with a few tweaks to make it more friendly for a read-only operating environment (to prevent wearing out the flash memory).
I’m very happy with my Proxmox x86 host running OpenWRT x86 in a container. It works beautify. I love how fast it is to take a backup/snapshot to try out new configurations and rollback in case of issues. The same host runs plenty of other services like home assistant.
I had pfSense working before OpenWRT but wanted wireguard so I made the switch.
Maybe look at Vyos? It is what I switched to after leaving pfSense. Linux based and cli only. Based on Debian, you can escape the router cli to get a plain Debian terminal and use apt to install whatever you want if you care to.
from what I remember, CM4 provides more functions and I/Os than you can get from Pi4. Just put it in the specialized motherboard (some boards have specific features to supplement CM4).
I strongly recommend you to watch Jeff Geerling YouTube channel, you will see the why it is beneficial to use CM4 over Pi4.
USB ethernet gets bogged down with interrupts if you start pushing lots of packets through it
The board I linked is the Pi's ethernet as eth0 and a Realtek gigabit NIC over PCI-E 1x as eth1 (instead of USB3 which is what the Pi 4 uses the PCI-E for)
As a result it can do a full gigabit of traffic with minimal overhead
I really miss m0n0wall (https://en.m.wikipedia.org/wiki/M0n0wall). A really minimalist firewall distribution based on FreeBSD. I used to deploy it to my clients’ as an easy to use firewall and router on Soekris Engineering embedded x86 systems. Very compact and efficient.
People here are linking to pfSense's past misbehavior wrt OPNsense. I used to use pfSense knowing about that but not caring. But what motivated me to switch to OPNsense was much more basic:
If you're using pfSense CE you're using an EOL product, so you should move to OPNsense just for that reason alone.
Those two posts try to convince you that CE is still relevant and will still get releases, but read carefully and you realize any changes to CE will either be by third parties or those that were part of the base FreeBSD system and thus were upstreamed to FreeBSD anyway. All the actual development work will be for Plus, and the design of Plus is sufficiently divergent (UI backend rewritten from PHP to golang apparently) that you can't backport the work to CE either.
Plus will be free for home use (and hopefully remain so), but won't be open source. Not that CE is all that open source either, but at least you can read and modify the PHP scripts in your installation.
Another reason people stayed off OPNsense was that it was based on HardenedBSD instead of FreeBSD, however that changed a few months ago so that should no longer be a concern.
After what netgate pulled with Wireguard and their continuing abrasiveness towards the community I'm moving everything to Opnsense. I get that netgate has challenges earning enough money to stay alive - but they sure are picking ham fisted ways to do it :p
Long term pfSense user here (4+ years). I have followed the discussion for pfSense issues in recent months, and overall agree.
However, I think the situation is a little bit more nuanced towards the context pfsense is used: If you have open WAN ports, for hosting services, I would avoid pfSense as it is now. If you have a fully closed WAN, with several mechanisms added to block local access (VLANs etc.), then the difference between OPNSense/pfSense is really not that obvious. Even if you have a OpenVPN Server on a single port, lets say UDP, it is possible to add HMAC, 2-Factor-Auth etc. in pfSense, too. So the security risks atm still seem rather low in this use context.
pfSense currently just has a bit better support for packages. pfblockerng-devel, radius server for 2FA, Telegraf etc. Those are not available in OPNsense yet. Using pfblockerng-devel GeoIP lists, I can add an extra layer of security, allowing only certain countries to even reach my OpenVPN port.
There is no guarantee that OPNSense is any better, other than the mentality aspect. It is a critical project and I am hoping to make the hop as soon as possible. At the moment, given my use case, I still feel that there is some time.
107 comments
[ 0.32 ms ] story [ 212 ms ] threadThe change now enables you to write firewall rules that use a placeholder for the ISP-assigned prefix. The rules should update automatically after a prefix change.
(What has always worked is using the fc00 or fd00 address spaces for local fixed assignments, but pfSense has had problems with that setup as well in my experience)
[0]: https://redmine.pfsense.org/issues/6626
It’s not a great barrier, but I don’t want the bare minimum skills advertiser, hacker, MPAA consultant, web store, or whoever being able to easily rely on this IP being me.
Yes. There are tracking cookies, and fingerprinting, and whatever, but the bar being set this higher is better than lower.
The phone analogy makes sense until you realize you’re actively calling everyone all the time, and the callerid shouldn’t be easily readable. It’s not like phones at all really.
In residential connections, every marketer will just figure out that particular AS gives /64 (or /56 or /48) and bundle them up, like how they use IPv4 address to track families.
This is actually one of the use cases where 'private addresses' make sense: when you don't have a static assignment but need static addressing.
In the IPv4 it's very unlikely that you'll get a static address unless from ARIN/RIPE/etc (or pay US$ 25+/IP on the open market), so we have everyone using 10/8 with NAT. It's quite easy for someone to get a statically assigned IPv6… unless you're a home user. So if you want static address, use the IPv6 equivalent of 10/8, ULA:
* https://en.wikipedia.org/wiki/Unique_local_address
Then you NTPv6:
* https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Tr...
* https://datatracker.ietf.org/doc/html/rfc6296
* https://docs.netgate.com/pfsense/en/latest/nat/npt.html
The interface portion of the IPv6 address (right-most 64b) stays the same, and only the prefix (left-most 64b) gets shuffled as they pass through the gateway.
> A full-stack PHP framework delivered as a C-extension!
I mean, I've can't even begin to imagine how insecure that awful combination of insecure by default languages is.
But, looking at: https://docs.opnsense.org/development/architecture.html It seems that it's mostly just the frontend that's php, or am I missing something?
> I mean, I've can't even begin to imagine how insecure that awful combination of insecure by default languages is.
What is inherently insecure about PHP? Or Phalcon? Do they have vulnerabilities that other C programs don't have?
C programs are often exposed to classes of vulnerability owing to weaker safety guarantees see[2]
[1] https://wiki.php.net/cve
[2] https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
https://ubuntu.com/security/notices/USN-5006-1
OPNSense also splits front-end into the MVC and control layer, as well as the back-end between the control layer and the configuration daemon which is written in python.
All of the actual packet processing and daemons are C or C++, essentially the standard packages you'd find in FreeBSD.
Whether PHP or C is more secure depends on who wrote it.
While I haven't really done any hardcode PHP work after PHP5 came out, there are plenty of ways to do it wrong, and a few ways to do it right. One thing is separation of concerns and encapsulation to the point where a fault in PHP can only mess up the PHP part and not the external system PHP calls into to ask for configuration changes.
Currently, a lot of the old pfSense code has been removed and replaced with code in the MVC framework, but it's a lot of work, and the team behind open-source OPNSense isn't huge. It will take time to cover it all.
My main reasons were that it did everything I wanted pfSense to do, something about the UI felt a bit smoother to me, and it didn't have the smarmy/wonky feeling that pfSense does (aggressive company behavior, closed-ish stuff, and then post-switch the Wireguard stuff happened).
I'm running this on a Protectli FW4B and have been quite happy. It's still doing exactly what I wanted, updates have been good, a bug I reported got fixed quickly, and it's... just working.
Also, by going to open hardware (and not the Netgate stuff I was originally thinking of) I can switch to another platform (eg: Untangle, OpenBSD) if desired.
But, for the forseeable future, OPNsense seems to be working just fine. <shrug>
I also had a very frustrating ARP bug where ARP broadcasts wouldn't work across mesh'd APs (https://www.reddit.com/r/UNIFI/comments/ghs4bg/arp_for_clien...).
Then there was just some various other quirkyness/weirdness, and I happened to get out just before the big security breach was disclosed.
I ended up going to a Ruckus R610 AP that I got via eBay running the Unleashed OS, and it's outstanding. Coverage is so good I no longer need my old AP + extra mesh'd one.
For switching I'm just using an old TP-Link that I had laying around.
UniFi seemed really neat at first, but then it just felt... overwraught. I don't need single-pane-of-glass monitoring of a ton of stuff for my home network. I don't want to run a management software server just for my home network. I do want something robust, but I don't want to worry about it, and I want to be able to piecemeal upgrade it. A small PC running OPNsense + a solid AP + just whatever for switching does exactly that.
(I'm not a homelab-type person... If I want that I use VMs, or my employer's hardware. I want my home network to be a solid, reliable utility that requires little maintenance. I don't want to be tweaking my home network after my day job.)
Note that Phalcon is a PHP extension (not a C extension) that provides new functionality available in the PHP runtime. This is roughly equivalent to a Ruby gem with a C extension, like Nokogiri.
Phalcon was at one point moderately well-regarded, though it's fallen out of favor for a wide variety of reasons, mostly the PHP development style moving on. I say this because as near as I can tell, Phalcon has had an entire single CVE in its entire decade plus of active development.
Casual anti-PHP bigotry isn't just uninformed, its harmful.
How does security patching compare?
Migration is really a complete reinstall and rebuild of your rules. I took a backup of my physical pfsense box and restored it to a VM then reinstalled opnsense on the physical hardware. With the pf box running in a vm I could just reference it while creating new rules.
I think someone made a script to load a pfsense backup onto an opnsense instance but I really think you’re better off with a clean slate.
Kind of a pain, sure, but I felt better knowing it was a fresh build and everything was where it should be.
Just means anyone who wants to try OpenBSD should spec something a little more powerful than that appliance.
Only issue I've had is that if it's a J1900 Celeron CPU, ensure you have the machine set to boot via UEFI before installing. (IIRC there's an open issue for FreeBSD installations failing to legacy boot on J1900 boards.)
In all cases I’d double check the individual chipset by doing a quick search on the forums whether you decide to go pf or opn.
PfSense offers a range of hardware they support, which disproves your assertion by itself without even mentioning companies like Apple and System76.
> one of the appliances that opnsense sells. Just expect to pay a premium to be lazy.
I'm totally willing to pay a premium to be lazy. Where did I imply otherwise? If OPNsense offers hardware these days then why didn't anyone just say so?
That disproves nothing. If you want to build your own system you need to research hardware if you want to have a pain free deployment.
> I'm totally willing to pay a premium to be lazy. Where did I imply otherwise? If OPNsense offers hardware these days then why didn't anyone just say so?
This forum is generally filled with people who want to build their own. As for why nobody mentioned they sell hardware: probably because they sold hardware from the beginning and it’s advertised all over their site?
Again, I said nothing about building my own.
> This forum is generally filled with people who want to build their own.
This forum is generally filled with people with a lot of qualities. For instance, there are a lot of people here who buy Apple products, which are very much not in the spirit of building one's own. Your assumption doesn't make a lot of sense to me.
> As for why nobody mentioned they sell hardware: probably because they sold hardware from the beginning and it’s advertised all over their site?
That's fair, I haven't looked at their site in ages because the last time I used OPNsense was after the very initial split and to my recollection there was no hardware then.
----
0: https://www.servethehome.com/buyers-guides/top-hardware-comp...
1: https://www.freebsd.org/cgi/man.cgi?query=cxgbe&sektion=4
Does the OPNsense project recommend or endorse any specific models of low-power all-in-one computer hardware for running OPNsense? And if no, is there any specific thing the community would recommend?
I don't want to spend hours on research or build something on Newegg. I want to by a complete piece of hardware that I install OPNsense on and know that I won't have to worry about hardware compatibility.
PS: Apparently OPNsense offers their own appliances these days just like PfSense does.
https://www.pcengines.ch/apu2.htm
Ref: https://opnsense.org/opnsense-com/
From the link: “ Some of you may have come across OPNsense.com a domain that until September 21, 2017 was home to a controversial website with content targeted to harm our open source project.
On the fore mentioned date we filed a complaint with WIPO, the World Intellectual Property Organization to try and stop this website from being operated.
Until our legal action we were unable to determine the owner of the domains as it was registered using Domains By Proxy, LLC, however we believed the site was created by a pfSense enthusiast who had gone a step too far.
Much to our surprise we received an email on September 26, 2017 stating that the owner of this domain was in fact Jamie Thompson, Rubicon Communications dba Netgate also known for the competing pfSense project.”
FYI, my observations as an outsider are the project went through three phases of owners:
BSD Perimeter is owner and starts open source fork creating open source releases = CMB and Scott as founders.
Electric Sheep Fencing ownership is a result of CMB taking more of the day to day while Scott bows out and Netgate starts funding things / sinking hooks in. Open source continues to be important and CMB is in charge for the most part.
Netgate ownership completes obtaining full ownership / gets their hooks into every bit of the project. We see annoying screen about licensing and they start nonsense with OPNSense to flex their tiny muscles.
FYI netgate hardware isn’t bad and you get stellar support for what is currently an open source product but they have worked hard to fracture the hard won trust CMB had been building up in the community.
https://marc.info/?l=pfsense-dev&m=139336551027270
https://forum.netgate.com/topic/66157/pfsense-tools-missing-...
With pfSense "plus" they published that they will only work on that paid product and mostly ignore the open source stuff, only do the essential requirements. It's essentially just a marketing gateway into their closed products. At that point you might as well buy any other mature closed product... there are many and from a closed source commercial product perspective they are all better than wat netgate produces, including commercial VyOS without a gui.
The creater of Wireguard said it was bad with buffer overruns and they got angry for being called out.
https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
The software seems to be the default open source firewall / router network admins go to, but it seems like a ticking time bomb to me.
They also seem to be pivoting to a closed source firewall / router project so this will result in less work going in.
Unfortunately, the only time CLI wins out in networking is when there's a cert to dangle in front of people. As much as I want to do things the "right" way, part of that equation is handing projects off to other people to maintain...
I switched to OpenBSD/pf from pfsense and I have more peace of mind needing to maintain a small handful of commented config files.
Can you elaborate how GUI will be better ?
At least with CLI and plain text configs I have "#" so all configs are self documented and committed to git repository.
I'm not sure what world you live in, but in the Cisco world I don't know anyone who does anything beyond the trivial in the various 'GUIs'.
part of that equation is handing projects off to other people to maintain
Yes, and I don't know anyone who would hire a Cisco engineer that wasn't fully conversant with the CLI. The idea that something we've been doing, successfully, for decades (handing a text Cisco config to the next engineer) is "basically impossible" is...interesting...and unsupportable in my experience. As is the implied "GUIs are always easier to understand and reason about".
Point is still valid through. Especially compared to some overly-complicated implementations, the pfSense web UI for VLAN and IPSec can be a better alternative.
1.) Your firewall scripts are now atomic (if using nft as your interpreter instead of bash), so either the entire ruleset gets applied, or nothing does.
2.) There's a nice declarative form of the nft syntax which I prefer (vs a more imperative style which we're all used to with pf (in the BSD world), or iptables)...both forms are executed atomically when the nft interpreter is used.
3.) The presence of an actual 'include' statement makes it possible to break your fw scripts up into multiple files, for better organization and readability. This also all gets executed atomically.
Overall I found it to be an enjoyable experience.
Thanks to them, several years ago I swore off FreeBSD. The tech may be ok/good, the baggage of personalities and egos is not worth it though. After seeing this, and at least the two of them associated with pfSense, I've now started looking for replacements for pfSense.
I've been thinking of OPNsense, though the whole FreeBSD bit bugs me (code/OS is fine, personalities/egos less so). Linux "equivalents" sort of exist, though reading through the various fora for them suggests similar ego/personality issues.
I'm not sure its bad enough to go back to dedicated firewall/router appliances (most are terrible and closed source). If there is a simple way to convert my pfSense config to a OPNsense config, this is likely to be the first step I take.
I'd love to hear other people's experience converting away from pfSense.
Since one or more of these people are or have been core committers on FreeBSD, this makes me question that project's judgement.
There is. You just back up your pfSense config, and then restore it into OPNsense.
See https://news.ycombinator.com/item?id=25894420
Why would someone use a router operating system with such strongly negative review from a respected security specialist?
A minimal Linux installation is an option, if your firewall is simple.
It's a perfect-balance of power and simplicity. It doesn't have a web interface but is just a nice way configure Linux' built-in networking features.
It doesn't consume any extra resources and will run anywhere Linux does.
I never much liked PFsense as a project. It feels very convoluted, and the hardware they sell (I was an early adopter of the then-new SG1000 appliance) is laughably exaggerated in its capabilities
But the Wireguard event is where they went from "incompetent" to "malicious" in my eyes
I ordered a Rasberry Pi 4 compute module and this accompanying ethernet breakout kit after seeing a review from Jeff Geerling (Raspberry Pi accessory mad scientist) and am currently waiting for it to arrive https://www.dfrobot.com/product-2242.html
I know I could just use something like OpenWRT, indeed I do have a lot of respect for the OpenWRT project. But I feel that the distro is more geared toward, well, routers. Devices with maybe 32 megs of flash storage and a slow MIPS CPU. Not a moderately powerful ARM machine with 8 gigs of RAM and gigabytes of SD or eMMC storage
For seven years, then, I've had a mini-ITX x86-64 box with a small SSD, 4GB RAM, and 5 gigabit NICs running Debian Stable. It's been upgraded in place and I see no reason why the upgrade to Bullseye in a month or two won't go as smoothly.
I think a Pi4 is roughly comparable in computation capacity, perhaps less so in I/O -- but what I've got is clearly overkill, anyway.
The Pi one can apparently saturate a gigabit iperf test without issue, so it sounds like a great replacement and rainy day project
https://www.pcengines.ch/apu2.htm
I've been using them for years w/out any issue. I just run standard Debian stable as well, with a few tweaks to make it more friendly for a read-only operating environment (to prevent wearing out the flash memory).
I had pfSense working before OpenWRT but wanted wireguard so I made the switch.
I appreciate the interest though!
I'm probably going to roll some sort of minimal Gentoo based system and then just augment it as-needed from there
I strongly recommend you to watch Jeff Geerling YouTube channel, you will see the why it is beneficial to use CM4 over Pi4.
The board I linked is the Pi's ethernet as eth0 and a Realtek gigabit NIC over PCI-E 1x as eth1 (instead of USB3 which is what the Pi 4 uses the PCI-E for)
As a result it can do a full gigabit of traffic with minimal overhead
It seems that all the big ones - Google, Facebook, Cloudflare...all use BPF on Linux for everything.
https://blog.cloudflare.com/cloudflare-architecture-and-how-...
https://www.ipfire.org/
https://vyos.io/
- https://www.netgate.com/blog/announcing-pfsense-plus
- https://www.netgate.com/blog/pfsense-plus-pfsense-ce-dev-ins...
If you're using pfSense CE you're using an EOL product, so you should move to OPNsense just for that reason alone.
Those two posts try to convince you that CE is still relevant and will still get releases, but read carefully and you realize any changes to CE will either be by third parties or those that were part of the base FreeBSD system and thus were upstreamed to FreeBSD anyway. All the actual development work will be for Plus, and the design of Plus is sufficiently divergent (UI backend rewritten from PHP to golang apparently) that you can't backport the work to CE either.
Plus will be free for home use (and hopefully remain so), but won't be open source. Not that CE is all that open source either, but at least you can read and modify the PHP scripts in your installation.
Another reason people stayed off OPNsense was that it was based on HardenedBSD instead of FreeBSD, however that changed a few months ago so that should no longer be a concern.
> There will be CE releases after 2.6, but unlike Plus, they’ll be done when they’re ready, not on a regular cadence.
pfSense currently just has a bit better support for packages. pfblockerng-devel, radius server for 2FA, Telegraf etc. Those are not available in OPNsense yet. Using pfblockerng-devel GeoIP lists, I can add an extra layer of security, allowing only certain countries to even reach my OpenVPN port.
There is no guarantee that OPNSense is any better, other than the mentality aspect. It is a critical project and I am hoping to make the hop as soon as possible. At the moment, given my use case, I still feel that there is some time.