> > 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
> and LAN?
I have thought about this point... and there is no simple answer. The
only way to do this really is to take the cards in order, first
alphabetically and then numerically and set the first to LAN and second
to LAN or vice versa. If people know what cards they have they should
know where to plug the cable in... and anyways, the card assignments can
always be changed. By getting them assigned in the first place just
gives a realistic chance of "plug and play" if you catch my drift.
> > 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.
A bypass option is entirely reasonable and i thought would be assumed,
sorry i didn't mention that :/ You may not be a fan of wizards, but
home users generally are! As, believe it or not, are some corporate
network admins... that are used to windows. A confirmation page at the
end with a checklist of things they may still need to do may be a good
idea. But with no wizard at all surely they may not even get as far as
the wizard could take them!?
> > 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.
Fair point, and this is why i specified it as an auto-apply OPTION...
i.e. not forced.
> > Tools
> > -----
> > 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.
status.php is nice, but its not linked anywhere on the GUI. exec.php...
again, not linked, and not everyone knows UNIX commands ;) nslookup does
not neccessarily mean the nslookup tool, but an nslookup function.
> > Failover
> > --------
> > 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).
m0n0wall is aimed at SOHO currently... but it has so much potential and
is almost ready to rival commercial appliances. The fact that its
engineered for embedded PCs really is a major factor here, it could
become very successful in the corporate market if stuck in a 1U box.
> > 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 SonicWall box!
> 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.
Not snort, thats not the job of a firewall. These are basic attacks, not
complex ones, and not a large amount of them.
> > Static Routes
> > [cut]
> > 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
Easily fixed, may even get around to it over the weekend.
> > NAT
> > ---
> > 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.
This is true... maybe make the name a little more obvious and also have
autoadditions if one doesn't exist in the list?
> > 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.
Granted networks like this are large and complex, however i have seen
them in smaller environments such as schools where m0n0wall is aimed.
And if it gets in to corporate markets it wouldn't be a bad thing to
have for the effort required!
> > 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.
> > Logs
> > ----
> > 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.
Not everyone has other machines, hence email is a nice way to get the
logs off for reporting. Another idea (lightbulb!) is maybe to have an
option to download logs from a page?
> > VPN
> > ---
> > 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
> missing something.
Not with IPSec, its rather more complicated!
> > PHP
> > ---
> > 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*
Yeah, there are arguments both ways, and to be honest i never expected
it to change. Enough said on both sides i think.
Dan Goscomb <dang at cashcade dot co dot uk>