(Not sure about correct bug reporting procedure for m0n0 - do I have to 
join and send this to the dev list, or is this OK?)

Well, I've found a definite bug in m0n0wall itself, but working around 
the bug still doesn't allow m0n0wall to answer ports (80 and 25, in my 
case) on the WAN interface as it should.  Anyway, here's the bug:  When 
the Firewall rules are automatically created by checking the "create 
rules" box in the Inbound NAT setup, the config file for those entries 
is created malformed, like this:

        <rule>
            <interface>wan</interface>
            <protocol>tcp</protocol>
            <source>
                <any/>
            </source>
            <destination>
                <address>192.168.57.1</address>
                <port>25</port>
            </destination>
            <descr>NAT SMTP WAN-x.y.z.1:25</descr>
        </rule>

Comparing to another rule shows the problem:

        <rule>
            <type>pass</type>  **NOTE THIS LINE IS MISSING IN ABOVE ENTRY**
            <descr>Default LAN -&gt; any</descr>
            <interface>lan</interface>
            <source>
                <network>lan</network>
            </source>
            <destination>
                <any/>
            </destination>
        </rule>

I'm pretty sure that type (action, really) should be explicitly declared 
in a firewall device. :-)  Oddly, when you view these automatically 
created firewall rules in the web UI, it shows the action for these 
rules as "pass", even though that information is clearly NOT in the 
config.xml file.  This scares me, since it tends to indicate there's at 
least some part of the code (hopefully only in the UI) that regards 
"pass" as the default action for a rule when none is specified. 

Simply saving each rule does add the <type> line to each (verified by 
diffing config.xml before and after saving one of the rules), but the 
firewall will still not answer for the Inbound NAT services on the WAN 
port, even after this is fixed.

So I'm still stuck - perhaps it will turn out I do really need proxy ARP 
or other mysterious rules before Inbound NAT will work.  If that's true, 
then at the very least it would be a good idea to update the 
documentation.  I'm surprised such a simple setup is so difficult...

Dub