I noticed recently that when certain house-mates turned on their computers, suddenly my internet connection would become very slow and highly unreliable – ah, the joys of Bittorrent and P2P traffic <sigh>
Rather than just trying to ban people from using these services (like that’d ever work… and anyway, BitTorrent has legitimate uses and they’re all paying towards the cost of the connection anyway, so it’s not my place to get all dictatorial) I decided to be a bit smarter: a packet-filtering system which can prioritise certain traffic whilst holding-back other types would not only allow people to run P2P software with abandon, but also keep everyone’s connection steaming along whilst hopefully improving subjective responsiveness.
I was originally going to purchase another passively cooled VIA MiniITX system and deploy Linux onto this – but then came across an alternative which is smaller, consumes significantly less power, and is much cuter: the AMD Geode-based ALIX systems from PC Engines:
This machine is a 500MHz Geode LX800 with 256Mb memory soldered directly onto the system board. It has a MiniPCI socket for optional WiFi cards, 2 USB 2.0 ports, 3 LAN interfaces (although this may not be as useful a feature as I first imagined) and a serial port which is configured by default for 38400/8/n/1.
PC Engines also make really nice anodised aluminium cases for the ALIX range:
The enclosures themselves are tiny – with a footprint just slightly bigger than a CD jewel-case and perhaps three times the depth. The construction is reassuringly solid and well engineered – there’s not even a fraction of a millimeter of space around the board once inserted and all of the ports line up perfectly (although this does make getting the serial port into the case a little fiddly…)
I went for the red one (similar to in the image above, but with an additional hole to the right of the LAN slots for the two USB connectors) which is very smart indeed – it seems a shame to shut it away in a cupboard (although this should be changing soon…)!
Several different projects offer downloadable images which can be dropped onto a Compact Flash card in order to boot a working firewall, but only a limited subset of these specifically support the (relatively new) ALIX platform. Of these, m0n0wall looked by far the best: ALIX is a first-class supported platform, the product is under active development, and it has some really nice features.
I envisaged inserting the m0n0wall between my top-level switch and my ADSL router to shape all network traffic, and yet have this act transparently so that inside clients could still access the admin interface of the router, and so that the m0n0wall could be removed if necessary without any disruption (which precludes setting the m0n0wall as the default gateway). The version 1.3 betas of the m0n0wall software do support bridging – but under 1.3b11 this didn’t work so well… I skipped 1.3b12 entirely, but on installing 1.3b13 bridging now works correctly without having to hack the PHP code which makes up the innards of the system!
One weird thing I have noticed, however, is that in 1.3b11 I was able to make persistent changes to the filesystem… whilst on 1.3b13, the filesystem is unpacked from a file on the CF card on every reboot, and so anything that needs to be patched must be done by a script which runs on startup. Admittedly, this looks as if it’s no longer required (although, as in the forum topic above, I still think that my configuration only works because the LAN interface is on a different subnet to everything else, and therefore effectively unused as well as being physically disconnected) – but I’m intrigued as to why this changed… was this a change in packaging policy after 1.3b11, or does the boot method alter depending on whether you’ve dropped an image straight onto a CF card or have upgraded from the web-interface?
One of the stand-out features of the m0n0wall software is the traffic-shaper configuration: set the upload and download speeds of your internet connection and hit the “Install” button, and it automagically sets up all all of the rules needed to filter P2P traffic in order to keep it flowing without disrupting the rest of the network. This does clear any other rules you’ve created (which is a shame, since the auto-generated rules are tagged as such in their names, so it would certainly be possible to clear only the auto-generated ones) but it makes such a potentially complex and time-consuming configuration operation so simple, it’s genius.
What would I change? There’s a few parts of the UI which aren’t applicable unless another option is first selected, and it’d be nice if these were folded by default, and I wonder whether the Traffic Shaper rules could be presented in a more compact manner: the ability to optionally fold auto-generated rules or combine the display of inbound and outbound traffic for a given port or port-range would certainly aid readability…
Like this:
Like Loading...
Related
Jul 15 2008
PC Engines ALIX-based m0n0wall
I noticed recently that when certain house-mates turned on their computers, suddenly my internet connection would become very slow and highly unreliable – ah, the joys of Bittorrent and P2P traffic <sigh>
Rather than just trying to ban people from using these services (like that’d ever work… and anyway, BitTorrent has legitimate uses and they’re all paying towards the cost of the connection anyway, so it’s not my place to get all dictatorial) I decided to be a bit smarter: a packet-filtering system which can prioritise certain traffic whilst holding-back other types would not only allow people to run P2P software with abandon, but also keep everyone’s connection steaming along whilst hopefully improving subjective responsiveness.
I was originally going to purchase another passively cooled VIA MiniITX system and deploy Linux onto this – but then came across an alternative which is smaller, consumes significantly less power, and is much cuter: the AMD Geode-based ALIX systems from PC Engines:
This machine is a 500MHz Geode LX800 with 256Mb memory soldered directly onto the system board. It has a MiniPCI socket for optional WiFi cards, 2 USB 2.0 ports, 3 LAN interfaces (although this may not be as useful a feature as I first imagined) and a serial port which is configured by default for 38400/8/n/1.
PC Engines also make really nice anodised aluminium cases for the ALIX range:
The enclosures themselves are tiny – with a footprint just slightly bigger than a CD jewel-case and perhaps three times the depth. The construction is reassuringly solid and well engineered – there’s not even a fraction of a millimeter of space around the board once inserted and all of the ports line up perfectly (although this does make getting the serial port into the case a little fiddly…)
I went for the red one (similar to in the image above, but with an additional hole to the right of the LAN slots for the two USB connectors) which is very smart indeed – it seems a shame to shut it away in a cupboard (although this should be changing soon…)!
Several different projects offer downloadable images which can be dropped onto a Compact Flash card in order to boot a working firewall, but only a limited subset of these specifically support the (relatively new) ALIX platform. Of these, m0n0wall looked by far the best: ALIX is a first-class supported platform, the product is under active development, and it has some really nice features.
I envisaged inserting the m0n0wall between my top-level switch and my ADSL router to shape all network traffic, and yet have this act transparently so that inside clients could still access the admin interface of the router, and so that the m0n0wall could be removed if necessary without any disruption (which precludes setting the m0n0wall as the default gateway). The version 1.3 betas of the m0n0wall software do support bridging – but under 1.3b11 this didn’t work so well… I skipped 1.3b12 entirely, but on installing 1.3b13 bridging now works correctly without having to hack the PHP code which makes up the innards of the system!
One weird thing I have noticed, however, is that in 1.3b11 I was able to make persistent changes to the filesystem… whilst on 1.3b13, the filesystem is unpacked from a file on the CF card on every reboot, and so anything that needs to be patched must be done by a script which runs on startup. Admittedly, this looks as if it’s no longer required (although, as in the forum topic above, I still think that my configuration only works because the LAN interface is on a different subnet to everything else, and therefore effectively unused as well as being physically disconnected) – but I’m intrigued as to why this changed… was this a change in packaging policy after 1.3b11, or does the boot method alter depending on whether you’ve dropped an image straight onto a CF card or have upgraded from the web-interface?
One of the stand-out features of the m0n0wall software is the traffic-shaper configuration: set the upload and download speeds of your internet connection and hit the “Install” button, and it automagically sets up all all of the rules needed to filter P2P traffic in order to keep it flowing without disrupting the rest of the network. This does clear any other rules you’ve created (which is a shame, since the auto-generated rules are tagged as such in their names, so it would certainly be possible to clear only the auto-generated ones) but it makes such a potentially complex and time-consuming configuration operation so simple, it’s genius.
What would I change? There’s a few parts of the UI which aren’t applicable unless another option is first selected, and it’d be nice if these were folded by default, and I wonder whether the Traffic Shaper rules could be presented in a more compact manner: the ability to optionally fold auto-generated rules or combine the display of inbound and outbound traffic for a given port or port-range would certainly aid readability…
Share this:
Like this:
Related
By Stuart • Hardware, Internet, Technology 0