[ previous ] [ next ] [ threads ]
 
 From:  Dub Dublin <dub at infowave dot com>
 To:  "James W. McKeand" <james at mckeand dot biz>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Bug Report: Inbound NAT automatic rule creation
 Date:  Tue, 16 Nov 2004 10:46:07 -0600
James W. McKeand wrote:

>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:  Thanks for the confirm.

This is definitely not an ISP problem -  the result is the same 
regardless of whether the packets come all the way through the ISP, or 
from another outside address right next door:
1) I have several static IPs from my ISP - I've set my laptop to one of 
them and can use that to test from the "outside" of the m0n0 box (the 
DSL router thoughtfully includes a hub) without ever even touching the 
ISP's network itself.
2) The server that I'm now attempting to move "inside" is relatively 
toughened itself, and has been providing web and mail services on this 
link for about 2 years.  Yep, it still works today...

See the config.xml I posted under the original topic to see if you can 
figure out what's wrong with my config,  In fact, I'd love to see yours, 
since it seems to be working.  I wonder if this could be something 
specific to the Soekris net4801 hardware/drivers, since it seems to be 
working for some people...

Dub

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