OPNsense Forum
Archive => 15.1 Legacy Series => Topic started by: BrianLloyd on February 16, 2015, 05:51:57 pm
-
Manuel Kasper, the developer of m0n0wall, has announced that the m0n0wall project has ended and has recommended that everyone using m0n0wall transition to OPNsense. Many people using m0n0wall are using hardware substantially inferior to what is recommended for OPNsense, i.e. single-core 32-bit processors, less RAM, CF or other slower flash media for booting than SSD, etc. Also, many are using SBCs from Alix or PC Engines as network appliances. So this brings up some questions:
- Can this class of hardware even run the i386 version of OPNsense? Performance may not be up-to-par but will it even work, making transition to OPNsense possible without a fork-lift upgrade of existing hardware. This would allow a two-phase upgrade, i.e. make it run now then make it run better later.
- If so, can the install i386 images be used as "boot and run" images or are they just installers?
- if they are only installer images, is there a run image available?
Thank you for your forbearance. There are a lot of us out there running m0n0wall and it looks like we will be coming over here and joining you. I am looking forward to a long and fruitful relationship ... once I manage to make the transition.
Thank you in advance.
Brian Lloyd
brian@lloyd.aero
-
Greetings,
I came here for the same reason. I love m0n0wall, have been using it on an alix2d3 ( http://pcengines.ch/alix2d3.htm ) for years and I'd like to avoid switching to a Linux based firewall applicance if at all possible. As BrianLloyd mentioned, these embedded platforms need some special attention, like having 256 MB RAM (some only 128), having no VGA or other display out but only serial, flashing the OS directly onto a CF card and booting that. Is such a variant planned for OPNsense? If so, I'd be interested in testing images for embedded platforms on my Alix Board and contribute that way if I can.
Regards
-
Good morning Brian and others,
we are a bit stunned following the announcement of Manuel and are challenged to rethink our positioning regarding hardware limitations and currently distributed image flavours. We went for the previous sweet spot: a more or less complete distribution based on FreeBSD's image standards built for a broad network appliance focus based on newer Intel/AMD hardware. Fortunately, Deciso has been in the embedded business for years, so there is a lot of room for realignment. :)
(1) I would say yes. The only critical issue that I see is low RAM and too small a SD card (our install is about 600 MB without additional packages). We can try to work on 128 RAM support when bigger issues like FreeBSD 10.1, LibreSSL migration and embedded images/installations are out of the way. I would say the time frame here is in a month or two.
(2) We've already decided to bring back direct disk images with the proper tweaks. I also know that an outside contributor is helping out in that regard. In the meantime all the media is installation disks. You can, however, install from a live stick on another system to a plugged hard disk. Here are some tweaks to run in embedded mode:
https://forum.opnsense.org/index.php?topic=9.msg24#msg24
(3) It'll be available soon. I can't give an ETA right now though.
One of the advantages of the installer approach is the ability to adapt to the target system as opposed to building fixed SD card images. We've been thinking about using the installer in a chroot to flash SD cards or fake a card to produce an image.
To reiterate: we already have serial support as a default option, so what is really missing is the ability to produce direct disk images. We are worried about low RAM (128 MB), and must ask for at least 1G of install space.
In all of this we'd appreciate a bit of time to adapt and your participation in requirements a.k.a. how far are you willing to go with us.
Cheers,
Franco
-
Thank you for the reply, Franco. Nice to meet you.
I don't think that install space is the issue. Most of the boards just use CF or SD flash storage. A couple gigs is no issue because CF and SD storage is cheap. RAM is more of an issue because most of the current appliances in the field are 256MB with single-core processors (AMD Geode) and are not upgradable.
I just looked at the PC Engines web site and their AMD G series T40E APU board actually looks like it will meet the current OPNsense requirements, i.e. AMD-64, dual-core, 2GB RAM -- $130 for the board. An extra $20 buys you a 16GB SSD that plugs into one of the mini-PCI express slots. Hmm, and it will boot from USB.
Just no video. So making it initially configurable entirely from a serial port with a shell would be nice as would having a load-image already tweaked for one of these SBCs. That would turn this into an appliance for a lot of people, thus making the transition from m0n0wall to OPNsense pretty straight forward.
FYI: http://www.pcengines.ch/apu.htm
-
Thank you for the reply, Franco. Nice to meet you.
Nice to be met, Brian. :)
I don't think that install space is the issue. Most of the boards just use CF or SD flash storage. A couple gigs is no issue because CF and SD storage is cheap. RAM is more of an issue because most of the current appliances in the field are 256MB with single-core processors (AMD Geode) and are not upgradable.
That is good to hear. 256 MB I have a good feeling about. I'd have to get one or two of those boards soon so that I don't make promises that we can't keep though. So far, there were a couple of success stories with those embedded boards so things are looking good by default.
I just looked at the PC Engines web site and their AMD G series T40E APU board actually looks like it will meet the current OPNsense requirements, i.e. AMD-64, dual-core, 2GB RAM -- $130 for the board. An extra $20 buys you a 16GB SSD that plugs into one of the mini-PCI express slots. Hmm, and it will boot from USB.
Just no video. So making it initially configurable entirely from a serial port with a shell would be nice as would having a load-image already tweaked for one of these SBCs. That would turn this into an appliance for a lot of people, thus making the transition from m0n0wall to OPNsense pretty straight forward.
FYI: http://www.pcengines.ch/apu.htm
Certainly a neat platform, although I can imagine lots of SOHO users would like to save a bit of cash and go for a lighter model instead. Coming from the industry, the pricing really is what it comes down to. So, again, we will see how far we can lower the specs even though that doesn't mean it won't go lower with a bit of tweaking or external contributions we are more than willing to incorporate in our releases.
Cheers,
Franco
-
I suspect that if it must compete economically with existing residential or SOHO appliances, you are going to lose anyway. Linksys, Netgear, et al, own that space. A platform that will run OPNsense (as you have described the current platform) is a LOT more expensive. But an appliance such as the PC Engines Alix or APU board puts the system around $200 which competes really well in the space between consumer (e.g. Linksys) and enterprise Cisco/Juniper offerings.
So, we just need a way to get it onto an Alix or APU board and make it run.
Do you need help in acquiring hardware?
-
Good afternoon gentlemen. :)
We were all stunned by Manual's announcement. And I cam over looking at your project immediately. And while it looks cool and is doing interesting things, there are several places were it diverges considerably from the old m0n0wall philosophy.
Now before I start, understand that this is not an attack on your project. I like it and want it to do well. It is an observation on how it does not fit many of my personal use cases, and how I think it would be a poor fit if crammed in.
1) I have a lot of production firewalls on old terminal servers with AMD Geode CPUs, and 128 meg of ram with 125 meg flash. Ouch...
2) The traditional view of m0n0wall was a small and lean firewall that did one thing and did it well. Seeing a section on packages and jails is not in that direction... :o
Seeing this, and not seeing Manual reconsider I set up www.smallwall.org to see if there was another way forward. Right now it is just a potential project, and if OPNsense can fill the need, it can fade away with no loss... But, I think the philosophies are very divergent, and it may be better to have two projects with some shared resources and developers, then to try and make one shoe fit on every foot.
Way back in the dawn of time (around 2005-2007) pfSense was a "friendly fork" of m0n0wall. A lot of the key developers were in both projects. Chris was very active in m0n0wall development, and his website supported a number of m0n0wall mods. Somewhere along the line, it got less friendly, but that is not to say that it can not work now.
If there is a SmallWall and a OPNsense, there is no need to converge them. But developments on one can go to the other, and back. Also, there is no need to "undo" things from OPNsense to fit them into a small build... I encourage anyone here to go sign up to the SmallWall forums while we hash out where (and if) we want to go. There is no reason that we can not have two projects that both leverage each other to make for better solutions for all.
-
For me the main reason to leave m0n0wall was the interest in running it virtual.
I'm a home user/hobbyist (with a job as sysadmin) and the lack of a newer FreeBSD as basis was holding me back.
Right now I dont have a hypervisor running yet, but hoping to do so this year.
Both pfSense en OPNsense in their current versions allow me to run on free Hyper-V very nicely.
But, both are also too big for what I need. Potentially anyway, as I can turn off the services I dont need, and drive space is of no concern to me.
For home usage I don't packet inspection, proxy, captive portals, etc. I need a firewall and router.
That is how I've set up pfSense atm, and trying OPNsense this weekend.
So, for me right now it doesn't matter too much which one I run. But perhaps someone could give me an insight on why I should run one or the other?
-
I'm in a similar boat to others in this thread. I've been using Monowall for almost 10 years.
My hardware is a Soekris Engineering net6501-70 (1.6 Ghz Intel Atom CPU, 2GB RAM, 4GB SLC SSD, 4 ethernet ports). I really can't see a reason to require more hardware than that for OPNsense.
Can the OPNsense folks please make a build that will function fine within these specs, as Monowall does so effortlessly?
Thanks in advance.
*B
-
For me the main reason to leave m0n0wall was the interest in running it virtual.
I'm a home user/hobbyist (with a job as sysadmin) and the lack of a newer FreeBSD as basis was holding me back.
People keep saying this, but the basis is not the problem. There are m0n0wall images with ESXi vmxnet3 drivers and images with KVM Virtuo drivers. I am sure we can get m0n0wall / SmallWall to work on HyperV in the 8.x branch, and that will be a lot faster than rebasising. :)
-
But if the basis has support build in as where you need to hack it into older basis versions, what is the point?
Plus all the other benefits of running a newer basis. Assuming there are other benefits of course.
To me it seems like a waste of time if you want to build a package (like OPNsense is doing) and not rebuild the basis.
-
Because I can add drivers for one platform in one day. Doing an entire basis takes a lot more. :) However, you are right in that we need to stay current. It adds ALL the drivers for nics, video, and more...
I was just saying we might be able to fix your problem sooner than you think.
-
I understand, and that would be nice. I remember when I got the net6501-30 and the NICs wouldn't work.
You, or someone else, fixed that by adding in the correct drivers.
-
We are thinking about moving from m0n0 to OPNsense too.
We had a go moving to pfSense a year ago but we dropped it and returned to m0n0 after reading their PHP scripts, it was a horror show, nobody tight on security would ever code that way.
It also looked like the pfSense team is in "cash out" mode and is now focused on the $ instead of theirs users, so it is great to hear someone else felt the same about pfSense and decided to do something about it, please promise you guys will never turn arrogant (I am looking at the pfSense team). ;)
-
Let's just say we are completely arrogant about not being arrogant. ;)
But seriously, what is a project--especially an open source project--without a community to listen to and build upon?
Sure, we have put in a bit of effort to get this project bootstrapped, but now that we've been here for just over 50 days, it really matters that we've had the privilege of a kind user base who is willing to help test and let this project progress beyond what we could have achieved alone. There are endorsements like Manuel's, countless bug reports, feature requests and proactive mentions of the work that we have done all around the web. We have plans for the next year, but they mean nothing in the face of what our community looks like in 6 months or maybe less. We'll have to shift and adapt while maintaining just a couple of core principles: open, easy, fast, secure *and* fun. We believe these values are not exclusive.
All I can say is there is more to learn and grow and hopefully we have shown how we want to do it. :)
Franco
-
We had a go moving to pfSense a year ago but we dropped it and returned to m0n0 after reading their PHP scripts, it was a horror show, nobody tight on security would ever code that way.
This can be a problem with what I call "kitchen sink" applications, with open plugin architecture. They focuse on features and not security. That is why so many people stuck with m0n0wall over the years. It only tried to do one thing.
It also looked like the pfSense team is in "cash out" mode and is now focused on the $ instead of theirs users, so it is great to hear someone else felt the same about pfSense and decided to do something about it, please promise you guys will never turn arrogant (I am looking at the pfSense team). ;)
This is another problem I have seen with open source apps over the years. Someone decided to monetize, and things go downhill fast. pfSense is just the latest, but Untangle, Nagios, Elastix and FreeNAS also have had similar problems. So this is a good thing to look at. Do they have a plan for later?
But lastly, remember that there is no rush. Your m0n0wall system is still quite stable and will be fine for quite a while. Also the m0n0wall developers did not all retire with Manuel. I have been talking with a few of them, and while we are impressed with OPNsense, many of us do not feel it truly addresses the m0n0wall segment. (Others do, and my join the project) But take some time and look at the various alternatives. There is no rush.
Disclaimer: Yes, I am behind one of the potential alternatives at www.smallwall.org so may be slightly biased. :)
-
Disclaimer: Yes, I am behind one of the potential alternatives at www.smallwall.org so may be slightly biased. :)
We appreciate diversity of opinion. I can see that not all the m0n0wall folks are happy. It may be an impossible feat to bring everybody under a single roof.
-
One can also not expect for the OPNsense people to just alter their course just because the former lead of m0n0wall said he thinks people need to move over here.
-
Let's just say we are completely arrogant about not being arrogant. ;)
But seriously, what is a project--especially an open source project--without a community to listen to and build upon?
Sure, we have put in a bit of effort to get this project bootstrapped, but now that we've been here for just over 50 days, it really matters that we've had the privilege of a kind user base who is willing to help test and let this project progress beyond what we could have achieved alone. There are endorsements like Manuel's, countless bug reports, feature requests and proactive mentions of the work that we have done all around the web. We have plans for the next year, but they mean nothing in the face of what our community looks like in 6 months or maybe less. We'll have to shift and adapt while maintaining just a couple of core principles: open, easy, fast, secure *and* fun. We believe these values are not exclusive.
All I can say is there is more to learn and grow and hopefully we have shown how we want to do it. :)
Franco
That is a great attitude to have, keep up the good work, we'll be following OPNsense closely and help out when we can. ;)
We appreciate diversity of opinion. I can see that not all the m0n0wall folks are happy. It may be an impossible feat to bring everybody under a single roof.
OPNsense has many exciting features, but right now, there is a large group of m0n0wall refugees out there looking for a new shelter, so this is like a humanitarian problem, lol.
Perhaps there can be a "OPNsense Lite" approach? A bare minimum version of OPNsense that doesn't do much more than m0n0wall? Many existing m0n0wall users will transit in droves just for the OS/SSL bug patches and new drivers alone (us included).
The problem with pfSense is that, there is always a large group of users who only require the most basic functions, but once they install pfSense and see the 10 menus with 100 options, they think "screw this, I am not going to spend a month to learn and tweak everything and risk breaking something", pfSense ended up trying to be everything for everybody and lost many would-be users.
With a "Lite" version, OPNsense won't suffer the same fate as pfSense, no matter how feature rich OPNsense become in the future, the "Lite" version will keep reminding people that, at its core, OPNsense is still a no-nonsense firewall/router.
Also, once the first step of transition is made, it'll be easy to encourage them to try the more advanced version, for example, in the settings page of the "Lite" version, there can be some advance setting fields that are greyed out, with the text "This feature is available in the Normal/Advance version <URL>" next to it.
-
With a "Lite" version, OPNsense won't suffer the same fate as pfSense, no matter how feature rich OPNsense become in the future, the "Lite" version will keep reminding people that, at its core, OPNsense is still a no-nonsense firewall/router.
Also, once the first step of transition is made, it'll be easy to encourage them to try the more advanced version, for example, in the settings page of the "Lite" version, there can be some advance setting fields that are greyed out, with the text "This feature is available in the Normal/Advance version <URL>" next to it.
I like the idea a lot. We have all build overrides in place in the config folder of our tools.git:
https://github.com/opnsense/tools/tree/master/config/current
This means ports, their options, the source binaries to be installed, the kernel to be built. Even the core/GUI repository could be replaced. However, things start to get rough around the edges. While it is perfectly safe to start with this, the projects will diverge quickly in terms of the core.git. We might be able to stay on track with the tools.git, src.git and ports.git.
So here it seems that there should be a "core-lite.git" or something along with the proper overrides in the tools.git.
Reasons for that are different approaches to GUI and compartmentalisation, we want to use python in the backend--that adds at least 50 MB to the image. We want manual pages, examples and such to be retained and not strip the base system down to something that simply runs for users. For one it does not help development, and OTOH, it prevents users from exploring the inner workings of their systems. These things are pure opinions, please don't hold me against them.
To conclude, you guys could strip down the system, remove features and still ride most of the eco system drive with OPNsense. Maybe there is a better solution mid or longterm, but as far as those things go they tend to diverge rather than converge.
PS: I really like this productive discussion. Thank all of you for your time. (No, the discussion isn't over ;) )
-
Why not build it more modular? Select the features you want on a base system.
Start with a Lite version and just add in what you want.
And if done right, you only see the optional packages in the menu after you activated them from a advanced part of the configuration.
For example, in my case a Lite version with firewall, router, DNS forwarder, DHCP and DynDNS would be enough.
And I think for most home users it will be. (If there are packages that really are needed and I missed them, they should be in too of course)
I don't care about setting up point to point VPN tunnels or DPI, and I doubt most people would who are like me.
-
I like the idea a lot. We have all build overrides in place in the config folder of our tools.git:
https://github.com/opnsense/tools/tree/master/config/current
This means ports, their options, the source binaries to be installed, the kernel to be built. Even the core/GUI repository could be replaced. However, things start to get rough around the edges. While it is perfectly safe to start with this, the projects will diverge quickly in terms of the core.git. We might be able to stay on track with the tools.git, src.git and ports.git.
So here it seems that there should be a "core-lite.git" or something along with the proper overrides in the tools.git.
Reasons for that are different approaches to GUI and compartmentalisation, we want to use python in the backend--that adds at least 50 MB to the image. We want manual pages, examples and such to be retained and not strip the base system down to something that simply runs for users. For one it does not help development, and OTOH, it prevents users from exploring the inner workings of their systems. These things are pure opinions, please don't hold me against them.
To conclude, you guys could strip down the system, remove features and still ride most of the eco system drive with OPNsense. Maybe there is a better solution mid or longterm, but as far as those things go they tend to diverge rather than converge.
PS: I really like this productive discussion. Thank all of you for your time. (No, the discussion isn't over ;) )
Glad to be helpful. ;)
The more I think about it the more I think "keeping it simple" is more of a psychological thing rather than a data size thing.
Sure some people stick to m0n0wall because they are using very low performance hardware, but the majority of them run m0n0wall on standard hardware, they just don't trust/like Linux and they want a simple interface, less options means less things to learn and go wrong, they don't really care how many components there are under the hood as long as they don't see them.
Large USB sticks/CF/SD cards are cheap these days, so personally I don't mind having a "Lite" version even if it is 2G/3G/4G, I'll be happy as long as I know that the guys behind it are taking a "keep it simple" approach.
From a programmer's point of view, perhaps "Lite" version means ripping most of the guts out of the system, but from a basic user's point of view, sometimes "Lite" version just means having a simple menu, you know, sometimes you just want 15 buttons on your remote instead of 150.
Of course, this is just one man's opinion, I am sure you guys know what you're doing. ;)
-
I understand what Lee is saying and I appreciate it. m0n0wall has served me really well in both small business and personal environments for about 10 years now.
But I always wanted something a little more with m0n0wall than I ever quite got. I got the feeling that pfSense might be going in the right direction but it just didn't feel "polished" enough. OPNsense seems like it might be the right vehicle.
The key to serving a wider range is making it modular. OPNsense with modular functionality that you can turn on or off seems like the right answer. Want a bare-bones firewall that will run nicely on a PC-Engines Alix or a Soekris board? Include only the modules you need and use it. Want everything? Throw in the kitchen sink and run a bigger board with more RAM and persistent storage (disk) to hold it all. Having exactly the same code base for both means that you don't spread your development resources quite as thinly. (I think that competing projects that overlap is wasteful. Work together on a common code-base and reap the rewards.)
And WRT hardware, well, hardware doesn't last forever. If you have hardware that has served you for 10 years, you have gotten one hell of a good run out of it. There is no shame in retiring it and moving up. The new PC Engine APU board costs the same as the Alix board and Soekris boards before them. It has a LOT more memory and processing power for that price. It feels OK to me to say, "Time to retire that hardware and move up." After all, you could afford that price point for hardware before. We are not talking about a hardware price going up (unless one goes with a PC mobo).
In the mean time, my home router/firewall just happens to be a PC mobo (Celeron-based) with 512MB RAM and a 4GB CF for booting. I plan to pull out and save the m0n0wall CF and try the i386 version of OPNsense. I can plug in a graphics card and keyboard and load from a USB flashdrive. If it works and I can duplicate my m0n0wall functionality, I have made the initial transition. If not, I just plug the CF with m0n0wall on it back in and I am back up-and-running with m0n0wall. If I *can* make the transition, I will probably get a PC-engines APU board to try to make an OPNsense router/firewall "appliance" and retire my old Celeron-based box. I'm hoping that Franco, et al, will make a bootable version of OPNsense available to facilitate that process.
I'll let you know what happens.
-
I think I'm slowly understanding what is being yearned for.
So we just happen to pull in a proxy and IPS into the base install, but, OTOH, rebuild a clean plugin system to make it possible to bring back "packages". That's all pretty neat, but....
One particular case of interest is PPTP, which a lot of people said it should be killed. While that may be true, it is still the base of internet connectivity for whole countries, so killing it is out of the question.
Instead, how about making a plugin of that so everyone is happy? Splitting off base functionality and wrapping it up so that if we split off enough of those pieces we'll end up with the proposed lite version and simply need to make sure the lite version addresses at least all of the SOHO needs.
Is this what you guys suggest we should do? To be frank, I find that approach very appealing after giving it the benefit of the doubt.
-
I think I'm slowly understanding what is being yearned for.
So we just happen to pull in a proxy and IPS into the base install, but, OTOH, rebuild a clean plugin system to make it possible to bring back "packages". That's all pretty neat, but....
One particular case of interest is PPTP, which a lot of people said it should be killed. While that may be true, it is still the base of internet connectivity for whole countries, so killing it is out of the question.
Instead, how about making a plugin of that so everyone is happy? Splitting off base functionality and wrapping it up so that if we split off enough of those pieces we'll end up with the proposed lite version and simply need to make sure the lite version addresses at least all of the SOHO needs.
Is this what you guys suggest we should do? To be frank, I find that approach very appealing after giving it the benefit of the doubt.
Yup, that is it.
pfSense got it wrong by having way too much stuff on their base install, when basic users use it and see the huge menu, they keep thinking "What the hell is that doing here? And what is this? I don't need this, it probably has a wrong default setting and has bugs or something", pfSense looks like a bunch of crap duct taped together, the messy design makes security conscious users feel uneasy.
Seeing only exactly what you need = trust = loyalty, that is how m0n0wall built its cult.
If OPNsense can pull that off, plus the bonus of the newest drivers and OS security updates that m0n0wall lacks, plus a plugin system for edge use cases, it'll be unbeatable (and guarantees a smooth transition from m0n0wall to OPNsense).
-
Disclaimer: Yes, I am behind one of the potential alternatives at www.smallwall.org so may be slightly biased. :)
We appreciate diversity of opinion. I can see that not all the m0n0wall folks are happy. It may be an impossible feat to bring everybody under a single roof.
Oh yes! :)
On the other hand, why should everyone be under one roof? Can you imagine if there was only one type of house for everyone? (And how ugly that designed by comity thing would look?) :) Sometimes you need different houses, but that is no reason they can not be good neighbours. I think if you try and serve both the small and the full featured, you may have more trouble then you think. When the classic "ram is cheap" runs up against ram soldered on the motherboard, for example. :) But with two houses that often work together (as pfSense and m0n0wall were in the early years) both projects benefit quite a bit.
But as several others have posted, simple can be good either way. When there are too many choices, it is overwhelming. For an example, compare the traffic shaper in m0n0wall to the one in pfSense. Having a light install can only help. In m0n0wall we actually had several features that could not be found in the GUI on purpose. By the time you needed them, you had learned enough to be ready for them. :)
-
I will open by saying that I think the possibility of having a slim embeddable installation of OPNSense is very important especially to transitioning m0n0wall users and I would love to see it! Perhaps a poll of desired hardware configurations and features is in order?
For now I am in the "virtualized" category so I have no trouble running with a relatively large amount of disk, RAM, and CPU. The biggest "feature" outside of basic firewall functionality for me is a rock solid OpenVPN client, as I use it for work everyday, currently with pfsense.
Cheers to the lively discussion here. I am so glad to see an organization picking up the m0n0wall/pfsense project in a responsible, open way!
-
Cheers to the lively discussion here. I am so glad to see an organization picking up the m0n0wall/pfsense project in a responsible, open way!
Keep in mind that OPNsense is not the only option. There is still pfSense, and www.smallwall.org (http://www.smallwall.org) is aiming to just continue where m0n0wall left off with minor changes. (And a beta was just released with l2tp support) There is also one other I am aware of that has not been officially announced, but is allong the same lines as SmallWall.
And choice is good. If a tad overwhelming when you first open a new GUI. :)
-
Probably too late to this conversation, but the great thing about M0n0wall's smallness wasn't that it would run on hardware X, or that it would run with only Y gigs of RAM, or that the menus were less threatening. It was that M0n0wall's minimalist approach met most needs--basic and advanced--while maintaining a minimal attack surface. Less attack surface == more sleep == fewer heart attacks. The memory and CPU savings were just gravy.
From the specs, OPNsense looks more like a full-blown BSD distro than a network appliance. If the rest of FreeBSD is coming along for the ride anyway, why even roll a new distro? Why not just make it an optional package inside FreeBSD?
I am really curious as to how Manuel sees OPNsense as a replacement for M0n0wall???
-
Don't get me wrong, I like the development of OPNsense.
Just to mention, the spirit of Manuel continues also in the m0n0wall fork of Andy White. Tiniwall follows the idea of low resources embedded boards like PC engines WRAP.
http://t1n1wall.com
Jakob
-
OPNsense has many exciting features, but right now, there is a large group of m0n0wall refugees out there looking for a new shelter, so this is like a humanitarian problem, lol.
Lol, like that!
Perhaps there can be a "OPNsense Lite" approach? A bare minimum version of OPNsense that doesn't do much more than m0n0wall? Many existing m0n0wall users will transit in droves just for the OS/SSL bug patches and new drivers alone (us included).
Franco mentioned something like stripping down the base install of OPNsense by selectable packet, i.e. option out big-BIND (for a smaller) or Squid-proxy or WiFi+Captive portal blob, if I am not mistaken.
The problem with pfSense is that, there is always a large group of users who only require the most basic functions, but once they install pfSense and see the 10 menus with 100 options, they think "screw this, I am not going to spend a month to learn and tweak everything and risk breaking something", pfSense ended up trying to be everything for everybody and lost many would-be users.
Exactly, plus the GUI is crowded and deep. It will need huge man-years only to explain all the basic firewall configurations over and over via forum, mailing-list to the normal users...
Our project's developers recently did add toggle switches for advanced/basic options to the GUI, which shows the right way in which OPNsense will go in the future.
With a "Lite" version, OPNsense won't suffer the same fate as pfSense, no matter how feature rich OPNsense become in the future, the "Lite" version will keep reminding people that, at its core, OPNsense is still a no-nonsense firewall/router.
Exactly!! And, again, if I am not mistaken, the developers showed understanding and awareness of this, so I see forward to it - it should show up in the future. It is a question of time, number of developers and community strength.
-
Your m0n0wall system is still quite stable and will be fine for quite a while. Also the m0n0wall developers did not all retire with Manuel. I have been talking with a few of them, and while we are impressed with OPNsense, many of us do not feel it truly addresses the m0n0wall segment. (Others do, and my join the project)
As I see it, to push the remaining m0n0wall code-base to FreeBSD10.1 or later to 11 would be a huge block of work and the conclusion was, that time is running fast, very fast away from the m0nowall/FreeBSD-8 base, while the alignment to stable, peer reviewed & secureFreeBSD10 base is done here with the developers of OPNsense anyway, which is backed by industry and a potential huge user base.
Because I can add drivers for one platform in one day. Doing an entire basis takes a lot more. :) However, you are right in that we need to stay current. It adds ALL the drivers for nics, video, and more...
I was just saying we might be able to fix your problem sooner than you think.
Yes! Make it so! Maybe use the OPNsense base?
Plus, there are new drivers for new hardware, many new WiFi drivers and (more secure) WLAN support in FreeBSD, but also only in the new distributions.
Security also goes up with FreeBSD 10 or 11 .
Idea: merge development power and establish a light NanoBSD version out of OPNsense, that would fit the legacy m0n0wall user-base with their reliable older or smaller hardware and have it all more secure and up to date!
At least I feel the need for a rush to develop, test install a new firewall, like Manuel advised!
-
With a "Lite" version, OPNsense won't suffer the same fate as pfSense, no matter how feature rich OPNsense become in the future, the "Lite" version will keep reminding people that, at its core, OPNsense is still a no-nonsense firewall/router.
Also, once the first step of transition is made, it'll be easy to encourage them to try the more advanced version, for example, in the settings page of the "Lite" version, there can be some advance setting fields that are greyed out, with the text "This feature is available in the Normal/Advance version <URL>" next to it.
I like the idea a lot. We have all build overrides in place in the config folder of our tools.git:
https://github.com/opnsense/tools/tree/master/config/current
This means ports, their options, the source binaries to be installed, the kernel to be built. Even the core/GUI repository could be replaced. However, things start to get rough around the edges. While it is perfectly safe to start with this, the projects will diverge quickly in terms of the core.git. We might be able to stay on track with the tools.git, src.git and ports.git.
So here it seems that there should be a "core-lite.git" or something along with the proper overrides in the tools.git.
I have seen a web-based build config tool with OpenWRT router images some years ago. I did configure my router build online via web-interface, specifying platform, radio drvers, code-base (stable, snapshot..) and got it build with a remote serve. I got an email notifiv=cation if the image was build with or without errors and a download link.
I do not know the downsides of this, but jused it to just build my images and testing stuff for the small plastic WRT type routers/firewalls, then.
May this be an idea for exactly tailored embedded / NaonBSD images of OPNsense in the future?
To conclude, you guys could strip down the system, remove features and still ride most of the eco system drive with OPNsense. Maybe there is a better solution mid or longterm, but as far as those things go they tend to diverge rather than converge.
PS: I really like this productive discussion. Thank all of you for your time. (No, the discussion isn't over ;) )
Yes, exactly my idea/thinking. So, in my oppinion, with all due respect, it would be fantastic if all the legacy m0nowall developers would join our alingnment with stable FreeBSD 10 code!
Also, this would mean more fun in development, for it is always nicer and more inspiring, if people work together, create, envision, merge, just make things happen in a group of like-minded people! And, eventually, meet from time to time.
The potential is there, for my gut feeling is that pfSense shows signs to head for big iron/$ and enterprise and the m0nowall code-base is fading out, unfortunately, again with all due respect. And there is no shame in leting established senior codes retire in dignity and go on with new and more exciting streams. This is how things go, one would say.
-
Probably too late to this conversation, but the great thing about M0n0wall's smallness wasn't that it would run on hardware X, or that it would run with only Y gigs of RAM, or that the menus were less threatening. It was that M0n0wall's minimalist approach met most needs--basic and advanced--while maintaining a minimal attack surface. Less attack surface == more sleep == fewer heart attacks. The memory and CPU savings were just gravy.
That's one of the key aspects of the work we have been doing, stripping code and software where we can, exchanging older solutions for newer ones, rewriting subsystems for easier access and maintenance, removing over 40 custom patches from the project because we do not trust them and ourselves, the FreeBSD devs have a far better grasp on those things. If something gets in the way and needs customisation, we're most likely not thinking hard enough.
From the specs, OPNsense looks more like a full-blown BSD distro than a network appliance. If the rest of FreeBSD is coming along for the ride anyway, why even roll a new distro? Why not just make it an optional package inside FreeBSD?
That's the ultimate goal. The road, however, is long and winding. Writing such a package from scratch takes a few years, so why not fork good work and realign accordingly? A lot of bitrot prevented us from making that FreeBSD package in the first place. That's normal when the project's goal doesn't change, but with OPNsense it did. Making a package in FreeBSD requires support for pkgng, which we introduced in January with our first release ever. You see, the questions you have align with the work that we've already done, but there is more to be done to reach that goal. It takes time and won't happen overnight. Maybe in time for 16.1.
I am really curious as to how Manuel sees OPNsense as a replacement for M0n0wall???
You'll have to ask him or read again how he talks about the open source spirit and the future of embedded systems. If it's not what you desire, t1n1wall or smallwall are worth checking out.