I can confirm that you're correct that the auto-created rule does not
have the <type> setting. My config.xml did not have them either, but
it did work.
Is it possible that your ISP is filtering your connection (not
allowing SMTP or HTTP)? Can you try a sacrificial lamb (a pc with web
and/or SMTP services) outside of your m0n0wall to see if the ISP is
blocking traffic to ports 25 and 80?
James W. McKeand
From: Dub Dublin [mailto:dub at infowave dot com]
Sent: Tuesday, November 16, 2004 11:10 AM
To: m0n0wall at lists dot m0n0 dot ch
Subject: [m0n0wall] Bug Report: Inbound NAT automatic rule creation
(Not sure about correct bug reporting procedure for m0n0 - do I have
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:
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:
<descr>NAT SMTP WAN-x.y.z.1:25</descr>
Comparing to another rule shows the problem:
<type>pass</type> **NOTE THIS LINE IS MISSING IN ABOVE
<descr>Default LAN -> any</descr>
I'm pretty sure that type (action, really) should be explicitly
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
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
or other mysterious rules before Inbound NAT will work. If that's
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...
To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch