[ previous ] [ next ] [ threads ]
 
 From:  Dub Dublin <dub at infowave dot com>
 To:  Manuel Kasper <mk at neon1 dot net>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Bug Report: Inbound NAT automatic rule creation
 Date:  Tue, 16 Nov 2004 14:46:29 -0600
Manuel Kasper wrote:

>On 16.11.2004 10:09 -0600, Dub Dublin wrote:
>
>  
>
>>Well, I've found a definite bug in m0n0wall itself, but working
>>    
>>
>
>No, you haven't (yet). ;)
>
>  
>
...and I was hoping for a prize...  ;-)

>>            <type>pass</type>  **NOTE THIS LINE IS MISSING IN ABOVE
>>ENTRY**
>>    
>>
>
>This is for historical reasons. Before pb19, you could only define
>pass rules, and any packet that didn't match a pass rule was blocked.
>This is still the recommended way of writing filter rulesets (not
>only with m0n0wall) - default-to-deny. Unfortunately, since the rule
>language isn't 100% flexible, deny/block rules sometimes have to be
>used to avoid having to create large numbers of similar pass rules.
>  
>
>For this reason, rules without a "type" are treated as pass rules,
>and I can't see a problem with it. Again, if at all possible, use
>pass rules only - any decent book on packet filtering will tell you
>this.
>
>  
>
That's OK, so long as it's understood that's how it works.  It wasn't 
quite clear, especially since pass was explicit on the others.  I won't 
worry about it now that I know.

>>but the firewall will still not answer for the Inbound NAT services
>>on the WAN port, even after this is fixed.
>>    
>>
>
>...which means your problem is somewhere else.
>  
>
Any pointers?  I posted my config.xml in another message in this thread. 

I've also noticed another odd behaviour:  After saving the firewall 
rules (so that they now have the explicit pass "type"), m0n0wall is 
doing something strange - even though I've only set ports 25 and 80 to 
be open for NAT, a port scan now reveals that port 21 (ftp control) is 
open, and sure enough, it is, although it appears there's no ftp daemon 
living there.  Is an offset error or something similar possible here?  
(Although I'd expect port 76 to be open then, and it's not.)  Puzzling...

>- Manuel
>
>  
>