[ previous ] [ next ] [ threads ]
 From:  Ivan Sie <i dot sie at masc dot nl>
 To:  Manuel Kasper <mk at neon1 dot net>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Default rules on non-WAN-side too permissive?
 Date:  Thu, 25 Nov 2004 12:02:41 +0100
Thanks for your answer.
Sorry that I didn't answer earlier. I needed time to test some things.
For your information: I use version 1.11.

Manuel Kasper wrote:
> There's an implicit default rule that allows connections from LAN to
> m0n0wall itself regardless of the filter rule set.
Is there any way to see ALL rules, including the implicit default rules?

> I can't see why you should need to do that - if you've got the bad
> guys on the LAN side, you have bigger things to worry about.

Maybe true, but even if I had bigger things to worry about, this should not be 
neglected. A lot of intrusions come with a little help from the inside...
I think it makes perfect sense to disable m0n0wall configuration for your LAN 
workstations and to enable m0n0wall for just a couple of workstations on your LAN.
Imagine that an intruder somehow managed to break into a workstation from a 
sloppy colleague and install a keylogger...
Even though the sloppy colleague may be a bigger thing to worry about, it would 
still be very handy to be able to shut his computer out from the firewall 

> The
> anti-lockout rule doesn't apply to optional interfaces, so as long as
> you don't have any rules on OPT1 that allow them, all connections
> from OPT1 to m0n0wall itself will be blocked.

This seemed to be true, until I defined a static route via OPT2:

OPT2 ip:
static route: via on OPT2.

Portscanning and pinging from revealed that no connections were 
blocked (only rejected) and that it is possible to ping
Even when explicitly denying traffic.
What's even worse:
I can configure m0n0wall from
I have not tested this for OPT2 having an ip-adress within a private subnet 
(,,, but it seems that when one 
configures a static route via an optional interface, m0n0wall opens its gates 
for the destination of that route...
Maybe this is a bug?

> That won't work. m0n0wall does stateful packet filtering, which means
> that once a packet has been allowed by a filter rule, all packets in
> the other direction that correspond to the same connection are
> allowed, no matter what the ruleset says.

I understand the concept of stateful packet filtering, and the default should, 
of course, be that corresponding packets are allowed.
Still, I would like to be able to define explicit rules that ALWAYS deny certain 
traffic, even though they belong to an otherwise allowed connection.
You may wonder why one would want this, but I think that explicitly defined 
rules should come before implicit rules.
Will that be possible in the future?

I would like to emphasize that I really like m0n0wall. The wishlist is very 
promising (I would really love to see the possibility of secondary networks on 
the WAN-interface) and it is very user friendly. I think it would be an even 
better product, especially for advanced users, when all explicitly defined rules 
would come before implicit rules.