M0n0wall Fork SmallWall Has First Official Release

New submitter houstonbofh writes: When the m0n0wall project ended back in February, many people just did not want to lose their small and lean firewall. And now, one of the forks, SmallWall, has released it's first non-beta release. It has some small improvements to the GUI, and now has added L2TP support. The announcement with the changes can be found here. Also, a partnership with MIXTPC was announced, allowing firewalls with SmallWall preloaded to be purchased. Their web store is here.

Comments

This is not ready for prime-time

[weilawei]

User Handbook (single page) - Comming Soon!

Alright then, so there's no updated docs. I'll just click the handy link to The m0n0wall Documentation Project - Chris Buechler. Oh wait, it's a 404. Nice going guys.

Re: This is not ready for prime-time

[houstonbofh]

It was up this morning... I wonder if it might be slashdotted? Try docs.m0n0.ch for another mirror.

Re: This is not ready for prime-time

[weilawei]

The page actually exists. The link on the documentation page is incorrect. They used a relative link to something that should have been an absolute link.

href="m0n0wall-docs.smallwall.org"

Re: This is not ready for prime-time

[houstonbofh]

Thanks for the help! It works now.

so lean, many small

[fisted]

small and lean firewall

improvements to the GUI

Uh-huh.

Re:so lean, many small

[fisted]

I hope you don't mean on the client end, because that would make a ridiculous claim.

Or on the server end, because that, well, would make a ridiculous claim.

I'm not against offering a browser-or-whatever-based GUI, I just find it a stretch to call that a "small and lean" firewall.

Re:so lean, many small

[unixisc]

Quick question. Most routers can be controlled from a browser using the IPv4 address 192.168.1.1 (Belkin uses 192.168.2.1). What's the equivalent IPv6 address that can be used?

Re:so lean, many small

[fisted]

You'd normally just wait for a router advertisement (ICMPv6) message arriving for the "all link-local nodes" multicast address (ff02::1).
If you don't feel like waiting for one, send a router solicitation to the "all link-local routers" multicast address (ff02::2), the router(s) will respond with router advertisements (possibly via unicast in this case, not sure).
The router advertisement contains the (64 bit) interface identifier; the router is then reachable on the link-local unicast address fe80::.

In unix, you can query information about all this after the fact using ndp(8).

HTH

Re:so lean, many small

[fisted]

[...] on link-local unicast address fe80::<interface identifier>.

Also, bug in summary

[weilawei]

Company is MITXPC, not MIXTPC. One seemingly refers to a small form factor PC and the other to a mix of toilet paper and crap.

Re:Also, bug in summary

[buckfeta2014]

This is Slashdot. Did you honestly expect the editors to actually do their jobs?

m0n0wall, m0n0wall, pudding and pie.

[westlake]

SmallWall has at least the virtues of a meaningful name that scans well and is easy to spell and pronounce.

Re:How is this better than iptables or pf?

[PhunkySchtuff]

Because someone has already done the hard work for you.
Time to do what you want to do = 2-4 hours or more.
Time to dump an image to a CF card and boot it - 2 minutes.
Plus, if it's based on m0n0, it'll run out of the box on embedded systems like Alix and Soekris boxes, which are amazingly reliable embedded x86 systems with no moving parts. I've got Alix-based m0n0 firewalls out there that haven't been rebooted in years and they just keep going. It's also designed to run from flash media, so writes (for logs etc) are kept to a minimum.

Re:How is this better than iptables or pf?

[Anonymous Coward]

> why do I need this?

If you don't need such a thing, then please tell me how to make a Linux box with two network interfaces, one connected to a cable modem, and another to a switch that serves the rest of the household LAN, accept an IPv6 routing prefix from the cable modem and pass it along to the rest of the household LAN, and route packets to/from that LAN, and do all of the other shit people just expect to work, e.g. a DNS server which allows any computer on the LAN to look up the address of any other computer on the LAN via its hostname. I tried, but after several days of work, I gave up.

It's a mess. There's at least seven separate pieces of software which have to work together to get it done, but none of them seem to have been designed to pass along relevant information to each other, forcing you to write and debug cludgy scripts that detect when things need to change, read status files for one program and generate config files for another, then restart whichever daemons need to be restarted. The kernel does routing obviously, but there's a separate router advertisement daemon, a caching DNS server, DHCPv4 client, a DHCPv4 server, a DHCPv6 client, a DHCPv6 server, and yes, all of those DHCP things are separate processes, and you have to coordinate their activity with each other and other software, e.g. the DHCPv6 server must give out addresses within the routing prefix obtained by the DHCPv6 client, and must not offer leases that are greater than the remaning lease time on the DHCPv6 client's lease.

Note that I didn't even mention iptables. The firewall is the easy part. In fact, it's bloody trivial compared to the rest.

With some scripting, I think I had all of the DHCP BS sorted out, but figuring out how to make the DNS work proved impossible, and so I gave up and installed pfSense in a virtual machine.

Yes, in theory Linux should be able to do what a router does, but in reality, making it do so requires a hell of a lot of work. ...and that's why you need projects like this: They've done that work for you.

Re:How is this better than iptables or pf?

[PhunkySchtuff]

Hey, you forgot to write your own web-based interface so that even a complete nufty can edit firewall rules nat port mappings etc ;-)

To the people who tagged this story...

[toadlife]

...about a fork of one of the most popular (and awesome) FreeBSD-based firewall distros with the tag 'linux'...kindly die in a fire.

Thank you.

Re:How is this better than iptables or pf?

[unixisc]

I actually had missed the news that the M0n0wall project was over. But even if it is, one of its derivatives is pFsense. What is pFsense missing that makes people want to fork M0n0wall?

On the stuff you describe, from what I have followed, the support of both M0n0wall and pFsense for IPv6 has been rather behind, compared even to Linux, and definitely way behind that of FreeBSD. It would seem to me that if someone wants to do a full fledged implementation of an IPv6 firewall/router OS, a good starting point would be TrueOS 10.x. It is PC-BSD sans the UI, just the CLI, and one could write the interfaces that enable multi-homing as well the other things you mentioned. How good is the IPv6 support on the last M0n0wall (which FBSD version is it based on?) and the latest pFsense?

On the DHCP processes that you mention, DHCP4 and DHCP6 are completely different, so there is absolutely no synchronization that one has to do b/w them: in fact, one only needs both of them active in a dual-stack environment. Also, if this is M0n0wall, which is a FreeBSD derivative, you'd have PF, not IPtables.

OPNsense

[unixisc]

The successor project to M0n0wall is OPNsense. To cite the project objectives

The newest offspring, OPNsense (https://opnsense.org), aims to continue the open source spirit of m0n0wall while updating the technology to be ready for the future. In my view, it is the perfect way to bring the m0n0wall idea into 2015, and I encourage all current m0n0wall users to check out OPNsense and contribute if they can.
Manuel Kasper

His idea to have a web-based GUI to control all aspects of the firewall has become the standard for many open source and commercial solutions.

The single XML file to store its entire configuration is another example of the miracles Manual brought to life.

So is SmallWall in any way related to OPNsense?

Re:OPNsense

[houstonbofh]

If you read his final notice at http://m0n0.ch/wall/freeze_ann... you will see more then OPNsense.

Hello,

as announced earlier, the m0n0wall mailing list and forum are now frozen. This is the final message, and I would like to take the opportunity to thank all those who have sent me emails with kind words and expressions of gratitude. They were too numerous for me to reply to individually, but they were all very much appreciated!

There have been some questions on what the way forward is for current m0n0wall users. If you are happy with the current feature set of m0n0wall and just need a security patch, bug fix, hardware compatibility update or minor improvement now and then, there are two nascent projects started by former m0n0wall developers/users that may have something for you: SmallWall and t1n1wall.

For a more feature-rich alternative that is still based on FreeBSD and has the same roots, both pfSense and OPNsense (which is a fork of the former) are excellent choices. They have higher hardware requirements than m0n0wall, but on the other hand, a lot of new embedded hardware has recently become available, with 2 GB or more of memory and 1 GHz or faster CPUs, at a similar price as earlier platforms. It makes sense (pun intended) to use these additional resources - something that m0n0wall hasn't been particularly good at in recent times. Just keep that in mind for your next hardware upgrade.

Farewell, fellow m0n0wall enthusiasts.

- Manuel
28 February 2015

Both SmallWall and t1n1wall.com are lean, and purpose built firewalls that do only one thing. They are not kitchen sink applications. They are meant to plug into web filters, not to be web filters.

pfSense, and OPNsense are extensible firewalls with a plug in architecture. While expandable, they are more complex and heavier weight. A good example is to compare traffic shaping between them... M0n0wall, SmallWall and t1n1wall will win that contest hands down!

Re:OPNsense

[toddestan]

One thing to compare is the hardware requirements for running OPNsense versus m0n0wall or SmallWall. OPNsense requires essentially a fairly modern computer, whereas I run m0n0wall currently on a 15+ year old 600Mhz P3 (which spends about 90% of its time twiddling its thumbs). I'm guessing that almost no one who was running m0n0wall is able to install OPNsense on the same hardware, as the requirements for OPNsense would be extreme overkill for m0n0wall.

That does bring up an interesting question about the MIXTPC boxes. My understanding is that m0n0wall will only use one core in a multi-core system, a few tens of MB of disk space, only and certainly won't use more than 128MB of ram. The MIXTPC boxes will still work, but even the cheapest one at $250 is way more than you'll need.

Re:OPNsense

[houstonbofh]

One thing to compare is the hardware requirements for running OPNsense versus m0n0wall or SmallWall. OPNsense requires essentially a fairly modern computer, whereas I run m0n0wall currently on a 15+ year old 600Mhz P3 (which spends about 90% of its time twiddling its thumbs). I'm guessing that almost no one who was running m0n0wall is able to install OPNsense on the same hardware, as the requirements for OPNsense would be extreme overkill for m0n0wall.

That does bring up an interesting question about the MIXTPC boxes. My understanding is that m0n0wall will only use one core in a multi-core system, a few tens of MB of disk space, only and certainly won't use more than 128MB of ram. The MIXTPC boxes will still work, but even the cheapest one at $250 is way more than you'll need.

You are correct in that any modern box is overkill. But there is really no new hardware that is any cheaper... And SmallWall can use more than 128 meg of ram, as some tables live in ram and can grow large in heavy use environments. But I have seen very few boxes use more the 512 meg.
As to multi-core, that is on the roadmap. It will be easier to support when the base is moved to FreeBSD 10.1 in the future.

OPNSense not really M0n0Wall successor

[storkus]

OPNSense is more of a fork of pfSense and competes with that project. In fact, OPNSense was pretty much born of the fact that the pfSense developers made their development tools proprietary-licensed and pissed off some 3rd party developers as well as scaring a larger group of people that the whole project might become closed-source. SmallWall keeps the tiny aspect of M0n0Wall as a firewall and little else while *Sense are network security appliances, Asterisk servers, and pretty much anything else you want--something Manuel never liked. All of these and more trace their origin to M0n0Wall so, technically, they're all successors.

None of these are as small as *WRT distros and they still to this day only run on x86 and x64, but you get OpenBSD's packet filter (claimed by most to be superior to Linux's) bolted onto FreeBSD (for better hardware support?) and a BSD license if that matters to you.

Re:OPNSense not really M0n0Wall successor

[houstonbofh]

None of these are as small as *WRT distros and they still to this day only run on x86 and x64, but you get OpenBSD's packet filter (claimed by most to be superior to Linux's) bolted onto FreeBSD (for better hardware support?) and a BSD license if that matters to you.

Also, good luck getting a *wrt to give gigabit sustained transfers. :) SmallWall and m0n0wall on modern hardware can give 900meg sustained transfers all day, and can do some hefty encryption on the side if needed for IPSEC.

As to the projects that owe allegiance to m0n0wal, and the people that learned there... This is a quick peek at some of those people... http://www.smallwall.org/histo...

Re:How is this better than iptables or pf?

[houstonbofh]

I actually had missed the news that the M0n0wall project was over. But even if it is, one of its derivatives is pFsense. What is pFsense missing that makes people want to fork M0n0wall?

It is not what it is missing, but what it has... m0n0wall was (and SmallWall is) smaller, and leaner. Less services means less attack vectors. It is also easier to configure correctly for novices. But the big thing is that some people are fundamentally against "kitchen sync" appliances where everything is on one box. Sometimes, separation of jobs is a very good thing.

I am not saying pfSense is bad. It is a good system, and Chris is a good guy. But I prefer solutions where the components do one thing, and do it well.