Transitioning from m0n0wall to OPNsense

[BrianLloyd]

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

[Madonkadonk]

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

[franco]

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

[BrianLloyd]

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

[franco]

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

[BrianLloyd]

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?

[Lee Sharp]

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... 

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.

[weust]

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?

[bradley]

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

[Lee Sharp]

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.

[weust]

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.

[Lee Sharp]

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.

[weust]

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.

[Packet]

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). 

[franco]

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