Now that I'm calmer, I'll address the other points. Bear in mind, these
are my opinions, you may not agree and that is fine. :)
On Wed, Apr 07, 2004 at 05:59:06PM +0200, Manuel Kasper wrote:
> Dan Goscomb <dang at cashcade dot co dot uk> (a good friend and former colleague
> of Richard Morrell's from SmoothWall) sent me a list of suggestions
> (attached), so if anybody needs some ideas for development on
> m0n0wall, there should be plenty now. :)
> - Manuel
> Interface Assignment
> Not everyone has sis cards... the WAN and LAN should be automatically set to available interfaces
so there is at least some chance that they can access the system on a default IP
> address by just booting up and plugging in a cable.
This would indeed be nice, but how do you know which one to make into WAN
> Config Wizard
> Should be run on first boot, similar to the SonicWall method. A step-by-step initial configuration
of the system IP address, type, etc. As you connect to the admin interface, if
> no configuration has been set, it should not show the standard pages until the wizard has been
I'm not a fan of wizards as I see all too often someone goes through a
wizard and then assumes everything will be just right, and never pay
attention to any of the details. The devil is in the details. If there
is a wizard, having the option to skip it would be essential I think.
> Auto-apply option
> I find i keep forgetting to press the "Apply Changes" button and so keep wondering why its not
working properly. Maybe an option so that changes are automatically applied rather
> than having to apply them manually.
That happened to me once. I think the statement that "changes haven't
been applied yet" could perhaps stand out more. Doing an auto-apply
might not be the best thing though, as when adding multiple hosts to the
dns forwarder or the dhcp server, that's a lot of extra processing. On a
cdrom/floppy based system, this would be painfully slow I think. Perhaps
making auto-applies be an option in the general setup would help with
both sets of viewpoints. Or perhaps just making the text more obvious.
When I first installed my car alarm with keyless entry, I set the thing
off many times by unlocking the door with the key and hopping in
forgetting there was an alarm on it. I put black electrical tape over
the key hole as a visual clue. This helped to break me out of my habit.
Eventually the tape fell off, but I haven't set the alarm off since I did
> Seeing as there is no shell on the system, some other tools are very important to check if the
firewall is working properly. These are as follows:
> * Traceroute
> * ARP Cache
> * TCP connect
> * Packet Trace
> * nslookup
Traceroute would indeed be nice. arp -a can be run via exec.php. I
think status.php gives much of the other useful stuff. Perhaps adding
arp -a output to status.php would be useful. nslookup was deprecated
a long time ago.
> A very important feature if you ever want it to become a proper appliance... all large companies
require failover! This can be easily integrated with the use of FreeVRRPd
This would be a nice feature, although not a requirement for the target
of home and SOHO environments. I personally like the approach the
openbsd people have taken to solve this problem (which was recently
discussed on this list).
> Attack rules
> Specific attacks should have individual log rules so they can be identified and reported... people
want nice things to look at, not just raw logs! I think you were also looking
> for a function for another LED somewhere... welcome to your answer, this is what its used for on a
I'm not clear how useful this would be. It almost sounds like snort type
behavior... and that's already been hashed to death on this list.
> Static Routes
> This is very good... but took me a while to work out that i had to add specific outbound NAT rules
to use them! The m0n0wall i use here supports traffic for a large number of subnets (a /21,
> 2 /22s and 2 /24s). Either the default NAT rule needs changing to any traffic entering the LAN
interface destined for the outised world passes, or a warning message needs to be
> set when you add routes to the LAN interface.
I haven't used the static routing features of m0n0wall, so can't speak on
> Firewall Rules
> The default rule for each interface should be shown... people MAY want to change it to allow, you
never know! Even if not, its reassuring to have a red cross there at the bottom
> of your list! Also, all available interfaces, whether they have rules or not, should be shown in
this list... its confusing to have to add a rule for the WAN interface by click
> the + button under the LAN interface area!
The current placement of the single '+' is indeed a bit misleading. I
think it would be simple to clarify its purpose, but I'm not a php person
nor a UI design person
> Server NAT is in the wrong place... this should be under the network configuration page on each
interface as an alias option. Ideally it wouldn't be present at all, and would
> automatically which interface the new IP should be bound to upon adding an incoming NAT rule. Make
it easier for them to understand!
> Instead of enabling advanced outbound NAT, just have it enabled already, but show the default rule
in the list! This makes it very obvious as to exactly what will get NATTed and
> what won't.
Interesting idea. I'm used to things the way they are, but I see merit
in both approaches.
> DHCP Server
> Should be able to support multiple address ranges. Some people (including me) use cisco routers on
the LAN side to proxy DHCP requests so only one server is required instead of
> one on each subnet.
I would suggest that anyone with a network of that complexity is able to
run a dhcp server on something other than their firewall. I would love
to see more access to the underlying DHCP features, but I plan to do that
in a different machine than my firewall when I need those features.
One thing smoothwall let me do that I do miss in m0n0wall is having
multiple MAC addresses for one IP. This let me keep the same IP on my
laptop as I switched between wireless and wired access, without any
disruption of current TCP connections.
> Password Reset
> On the GUI this should need you to first enter your old password. The htaccess method has no
sessions and potentially a user stumbling accross it on someone elses machine could
> reset the password without having to first log in with the old one.
This seems quite reasonable.
> Should have an option to email the logs after a certain size is reached. Also potentially an
option to automatically send logs to dshield.org
That's an interesting idea. I know my father would love such a feature.
Personally, I'm sending my logs to another machine that can summarize
them and email me the reports.
> Multiple destination subnets, and of course multiple local subnets!
If I understand this correctly, a single tunnel handling multiple network
on either end. I don't see why this isn't possible with correct routing
rules in the current software, although I haven't tried it so I might be
> I hate to say it... but PHP in itself shouts insecurity. Every white/gray hat
> i've spoken to has said they would not use m0n0wall because it has PHP on it.
I think I said enough on this one. *grin*