[ previous ] [ next ] [ threads ]
 
 From:  "James W. McKeand" <james at mckeand dot biz>
 To:  "'Dub Dublin'" <dub at infowave dot com>, <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] Bug Report: Inbound NAT automatic rule creation
 Date:  Tue, 16 Nov 2004 11:30:17 -0500
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


-----Original Message-----
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
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




---------------------------------------------------------------------
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