Below are a few suggestions, mainly related to the webGUI. None of
these are of great importance, but I feel that they would all make
working with m0n0wall easier in one way or another.
I don't presume that all these suggestions should necessarily be
implemented straight away or even at all. This is mainly to test the
waters and see how all of you feel about these ideas, I guess it will
then be up to Manuel and other m0n0wall-developer gurus to decide
which of these, if any, should be considered for implementation.
(WARNING: Looong read ahead, make yourself comfortable!)
= = =
Since m0n0wall is now able to check for new versions on the firmware
page, I must assume it wouldn't be too much of a problem making it
possible to have it download the image directly from the website as well.
I imagine that in case a new version is available, a button would be
shown (next to the notice about the new firmware for instance), which
when clicked would initiate a transfer of the image from the website
directly to m0n0wall, instead of going through the extra steps of
first saving the image locally, then uploading it to m0n0wall.
In case there is any concern about increased load on the m0n0.ch
server because of this feature, I see no problem with imposing a steep
bandwidth limit for these m0n0wall-initiated downloads, since there
need not be any user intervention after the download has been started,
as m0n0wall could simply perform the upgrade and then reboot
automatically upon completion of the download.
Also, I think it would be prudent to include an option to disable the
automatic version check, as some (more paranoid individuals) might not
like the fact that m0n0wall contacts a server on the internet on its
own. When disabled, a button for doing a manual version check could be
shown on the firmware page.
A "Disable" checkbox, like the one in the firewall rules, would make
it much easier to test and manage the shaper rules.
Showing the "names" (unparsed comment field) of queues and pipes
instead of their numbers, in the rule list as well as the queue list,
would make it much easier to read these lists. In case no comment has
been entered, the usual "Pipe #" could be shown instead.
I recently noticed that the "DHCP leases" list allow sorting according
to the various columns. A similar sorting feature for the various
other lists in the GUI (such as firewall rules, shaper rules, aliases,
DNS overrides etc.) would be very nice (and, IMHO, much more useful in
these places than the DHCP list).
= = =
The following suggestions aren't strictly mine, but rather inspired by
suggestions I've seen on the list. I've included them here mainly to
add my vote to them, but also since my idea of how some of them could
or should be implemented might differ from the original idea:
To facilitate easy management and testing, it would be nice to have a
way to quickly enable and disable rules without having to edit each
I imagine a checkbox could be shown beside each rule in the list,
allowing you to quickly change the "state" of any number of rules and
then applying the changes.
The same would go for the shaper rules, should the suggestion about a
"disable" checkbox for the shaper rules be implemented.
To avoid misunderstandings (not the least by new users), consider
showing the "implicit" rule(s) in the firewall rule list (perhaps
grayed out to diferentiate between these and the actual rules).
Also, it might be helpful if one could somehow enable a kind of
"advanced view" in the rule list, making m0n0wall show the actual
("low level") rules generated for each rule in the list (these should
be grouped together with the "GUI rule" to which they belong so one
knows where they come from).
I realise that this information can be found in status.php, but some
of us aren't very good at interpreting this output, and also the main
idea behind the above is to allow you to quickly make sure that a
given rule in the GUI actually produces the expected set of actual
First of all, I would like to reiterate a suggestion I made myself
some time ago: There are a number of places where IP addresses or
subnets can be entered, but where aliases aren't allowed (more or less
everywhere outside the "Firewall" section).
It would be very nice to be able to use aliases in ALL places where an
IP or subnet can be entered. The goal being that the ONLY place where
actual IPs and subnets have to be used is the "Aliases" page.
This way, providing that aliases are used in all places, one could
rest assured that regardless of what IP or subnet need to be changed,
it would need to be done in one place only, and there would be no
chance of forgetting to change it in some obscure place or other, with
all the horrible scenarios such an oversight might otherwise lead to.
In places where aliases CAN be used (in- or excluding the above), it
would be nice for these to occur in a dropdown for quick selection as
well as preventing the possibility of typos (and/or forgetfulness!) It
should of course still be possible to enter these manually.
= = =
Finally I have one other suggestion, which is perhaps a bit off topic,
since it isn't related to the webGUI (not strictly anyway):
Some of you may remember my suggestion for some way of interfacing
with m0n0wall without going through the GUI. This would be to allow
people (such as I) to produce various binary "clients" capable of
interacting with m0n0wall (such as for monitoring or time-based rule
I fully understand why this was considered somewhat out of the scope
of m0n0wall. However, I would like to suggest a less complicated
alternative, which would both make the above "clients" possible (to
some extent at least) AND provide an easy way for m0n0wall
administrators to automate and/or script various tasks:
By means of a PHP page, a little like the exec.php, it could be made
possible to affect certain changes and actions in m0n0wall, normally
done through the webGUI, by way of some parameters given directly in
the URL for the PHP page.
This would only be for such things as enabling and disabling rules,
changing the IP of an alias, enabling and disabling various features
(traffic shaper, DHCP and such) and other things that one might want
to either automate, be able to do quickly, or have done by a client
It would make this post much longer than it alread is, if I were to
try to explain this idea thoroughly, so I'll jsut provide a few
examples, and let you fill in the blanks:
A user wanting to be able to quickly open and close access to the WAN,
could do so by first making a topmost rule on the WAN interface that
will block all traffic. Then two "internet shortcuts" (or similar)
could be made with URLs along the following lines:
http://user:pwd at m0n0 dot mydom/do.php?action=toggle_rule&id=1&state=enabled
http://user:pwd at m0n0 dot mydom/do.php?action=toggle_rule&id=1&state=disabled
A user wanting to implement time-based rule changes, could do so by
having a cron job (or similar) execute a number of URLs similar to the
ones above at various times.
A (perhaps somewhat ambitious) user, wanting to make a small tray util
showing the current load on the various interfaces, could do so by
sending an URL along these lines to m0n0wall:
http://user:pwd at m0n0 dot mydom/do.php?action=get_stats&type=interface&id=wan
Which would then cause m0n0wall to return a small XML document
containing some relevant interface statistics that the program could
parse and display in a nice graph or whatever.
I hope you get the general idea by now. The syntax and specific
commands and their arguments are of course just something I've grabbed
out of the air. The idea is to mainly provide functionality already
present in m0n0wall, thus keeping it relativly simple to produce the
PHP script that parses the URL and then call the apropriate function(s).
This alone would provide a very powerful alternative (read: script
friendly) interface for m0n0wall. Add to this the ability to return
XML formatted responses (such as the interface stats in the last
example), and very complex interactions will be possible between
m0n0wall and anything from a simple shell script to a large database
application. In fact, anything capable of making a http request by
some means, would be able to interact with m0n0wall in this way,
either making changes to its configuration or polling for various
While I guess there are a number of other ways to achieve this
functionality (such as SNMP or a SSH based CLI), there are a number of
advantages when doing it this way:
- Security isn't an issue, as this is inherent in the http/https
protocols and is already in place for the webGUI.
- There is virtually no additional overhead nor any need for any
- Most of the code is probably already present for the webGUI. Only
the "do.php" (or whatever it should be called) script to be
implemented, and this should mainly be a matter of some code parsing
the URL and then calling various existing PHP scripts.
- It is in line with the design philosophy of m0n0wall, namely that
PHP should be used for everything.
- It should be very easy to maintain. Typically no special care would
need to be taken, at least until it is decided that some new GUI
feature should be accessible in this manner as well. Even then it is a
simple matter of adding a few lines to do.php, making it recognise the
new command(s) and calling the corrosponding function(s) which have
already been implemented for the GUI.
= = =
Well, that's it folks! (For now at least.)
Let's hear what you think?
P.S. Sorry for wasting so much of your time. I'm afraid I have a
problem with expressing myself in short sentences ;)