[SOLVED] is opnsense based on standard FreeBSD

[bycn82]

pfSense is build on FreeBSD, but with some patches,  how about opnSense?  it is based on the standard FreeBSD 10?

[jschellevis]

OPNsense is based on FreeBSD with some patches, but we try to keep closer aligned with the FreeBSD project. There are major differences in how our build environment works compared to pfSense.

OPNsense is essentially a pkg package on top of a modified FreeBSD version.

If you would like to know more about it, please take a look at our tools repository on github. All the details on building OPNsense are provided here: https://github.com/opnsense/tools.

[franco]

Eventually, all custom patches should either go away and be replaced with a more standards-compliant way of doing things, or patches must be polished and pushed to FreeBSD. We are not there yet, but this is an important issue we do pursue.

Especially tricky is ABI issues between userland and the kernel, which is the real trouble of the legacy way as opposed to the FreeBSD way. The userland may differ on top of a unified ABI, and I think all of the work we do will live in ports and packages by then.

[bycn82]

great! i like this

[storkus]

Hi, first time here in the forum, but medium-term user of pfSense and M0n0wall (which Manuel has announced the EOL to and how I found out about OPNSense).

Anyway, I've wondered about this for YEARS and have never seen an answer: why is the project moving towards standardizing on FreeBSD rather than the security-oriented (and source of LibreSSL, pf, and probably others) OpenBSD?

[franco]

Let me try to answer this briefly and hopefully concise. You mention two things:

(1) Alignment with FreeBSD's progression, e.g. stable releases or driver updates/fixes.
(2) Alignment towards more security-oriented things, e.g. LibreSSL and pf(4) optimisations.

Neither of those things are at odds with each other. (1) is our operating system, and it'll continue to be so. The burden of carrying the base forward belongs to FreeBSD and its contributors, so that if we can quickly incorporate their work for the benefit of everyone here that is a good thing: timely stable and security updates for our community and maybe the occasional bugfix that flows back into FreeBSD.

Now, beginning with pfSense, there is a great deal happening WRT (2): pf(4) has numerous patches on top of what FreeBSD offers. A small bump here is most of these really useful patches never made it back to FreeBSD--either these patches are useful for everybody that runs FreeBSD or they are not suited for anybody in the long run. Why shouldn't they be in FreeBSD eventually? Our FreeBSD 10.1 branch also has two additional security-related fixes that have made its way into our repository with the help of HardenedBSD, see https://github.com/opnsense/src/commits/10.1

Additionally, FreeBSD's ecosystem is quite flexible in terms of shipping security updates by using ports rather than the base system. OpenSSL is the newest version 1.0.1l for us and we are actively working on bringing you LibreSSL soon. OpenSSH has also been replaced by the port and all packages are completely up to date with the current HEAD of the FreeBSD ports tree.

To conclude, if we can manage to stay standards-compliant, we can manage to bring in the latest and greatest of the work by the lovely people who help to push FreeBSD forward every single day.

Does that make sense?

[athurdent]

Hi, first time on the forum for me, too.
BTW, nice GUI, I just installed a KVM to take a quick look at OPNsense. Used the snapshot as the Sourceforge page was unavailable for me.

As a long-time OpenBSD and mid-term pfSense user, I second storkus' question.
Why try to harden and patch FreeBSD, when you can have a really pre-hardened system like OpenBSD that will always be on the lastest firewall code version?
OpenBSD always looked like the obvious choice for a firewall base system to me.

[franco]

The code for this project has been worked on for a decade and with it come certain bounds to certain OS specifications, especially WRT kernels and network performance. "Simply" using OpenBSD or any other great alternative sounds certainly appealing, but the truth is that rebuilding and/or porting the functionality takes us a year or two into the future just to retain the level that we have now. We are working towards making the project less bound to its current OS, but even that takes time and only goes so far.

The battles we will fight are numerous. The decisions to be made won't be favourited by everyone.

What seems sensible now is cleanups, pruning, refactoring, adapting to upstream changes more quickly... to make the project easier to handle and faster to fork and build upon. E.g. the adaption of the build code to use pkgng will enable others to use pkg_add and friends more easily in the future. You'll find the build process looks more like a general BSD build process now and going from one BSD to another can be achieved one script at a time.

[shaqan]

OpenBSD has one big disadvantage, it's pf is not SMP capable like FreeBSD's pf fork. By now, even their syntax is different. That's my guess but if the change of base OS were attempted, it would as good as starting from scratch. And getting less performing end product as a result

[chol]

FreeBSD and the FreeBSD community, as a long-term base for OPNsense, is in my oppinion a very good and reasonable choice!

OpenBSD has its renown-for the good and the bad-notwithstanding its hardware-base restrictions.

[franco]

I saw OpenBSD requesting donations to push Networking Stack SMP support, which I still think is one of the main problems with OpenBSD, the diverge of pf(4) and so on. Let's see if that changes now...

[lucifercipher]

OPNSense is purely based on FreeBSD and its hardened version aka HardenedBSD which Franco is a part of . FreeBSD has its advantages just like OpenBSD does. True OpenBSD ran into Power bill funding requirements then request for funding to make PF SMP capable. But look at the history. They proudly advertise it on their website "Only two remote holes in the default install, in a heck of a long time!" Running OpenBSD for website hosting / co-location is ideal and so is their firewall. You will only need SMP if you go whacko with the traffic loads. Even non-SMP , OpenBSD's pf does a pretty well job. The top notch OpenSSL along-with few critical components that make the Internet came from OpenBSD.

With FreeBSD, you get more control and more support + documentation but then again its all a matter of choice. OPNSense using FreeBSD is best because its foundation came all the way back from m0n0wall. Plus, third party support is more in packages. For example, i wanted to have an ERP deployed on a secure OS foundation and there was FreeBSD package available on ERP website. So i had to build it from source over OpenBSD to get it going which took me an hour or two.

Like i said, its all about choices. Whatever suits you. Everyone has tried their level best to make their brand / project as successful as possible.

[franco]

I only help out the HardendBSD people with a few nitpicks and documentation improvements. So far they do an amazing job of their own.

We still have patches on top of FreeBSD but we'll get there. We have someone who converted his FreeBSD into an OPNsense by replacing base and kernel using our internal tools and it's working fine:

https://kram3r.wordpress.com/2015/07/09/opnsense-on-digitalocean-droplet/

The long run will be to simply switch your FreeBSD package repository and install opnsense and after reboot your system is up and running without further need to change the base/kernel. That'll give us the opportunity to move away from our own kernel builds and give broader support and a rich tool kit to turn OPNsense into whatever you can imagine (if you need more than what is there, that is).

[guest7876]

I only help out the HardendBSD people with a few nitpicks and documentation improvements. So far they do an amazing job of their own.

We still have patches on top of FreeBSD but we'll get there. We have someone who converted his FreeBSD into an OPNsense by replacing base and kernel using our internal tools and it's working fine:

https://kram3r.wordpress.com/2015/07/09/opnsense-on-digitalocean-droplet/

The long run will be to simply switch your FreeBSD package repository and install opnsense and after reboot your system is up and running without further need to change the base/kernel. That'll give us the opportunity to move away from our own kernel builds and give broader support and a rich tool kit to turn OPNsense into whatever you can imagine (if you need more than what is there, that is).

Franco,

what do you think the ratio of kernel patches of yours versus the **sense folks??

i believe in totally what you folks are doing for the community and its moving along nicely.

[franco]

It depends on the way you want to reach customers/users vs. how many unique selling propositions you have. If you have a 10 year run and the infrastructure to do kernel/base builds as well as the skills to improve FreeBSD before FreeBSD does, it's a valid method to satisfy less generic requirements from paying customers.

On the other hand, trying to reach a higher number of users (and the scope of FreeBSD is still a lot smaller than Linux in that regard), our vision of a simple package in the FreeBSD repository is the best option to go. It takes years to reach this, some upstream work for sure, but the long-running payoffs are a light and agile project, even after maybe 10 years.

With that being say, I saw that pfSense re-released the source code: https://github.com/pfsense/FreeBSD-src

There is a lot of IPsec improvements that are worth mentioning, although the scope of which eludes my expertise in the intricacies of the implementation. The current ration may be around 10:1, but that's not a professional analysis and I may be wrong. Fact is every patch takes you further from running on a vanilla FreeBSD. This is even more visible with ABI incompatibility and base system changes. With kernel changes you may get to be fine as none of the GUI or backend code can touch it (like a driver, relatively easy to pull in the latest updates across major FreeBSD versions), but with base system behavioural changes and output you change the backend code and that locks you out.

Long story short, both approaches are viable given that enough thought and smarts are being put into them.