On 25.11.2004 12:02 +0100, Ivan Sie wrote:
> Is there any way to see ALL rules, including the implicit default
> 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...
As I said, you can do that with the new option in 1.2b1 (but see
> This seemed to be true, until I defined a static route via OPT2:
> OPT2 ip: 126.96.36.199/28
> static route: 188.8.131.52/24 via 184.108.40.206 on OPT2.
> Portscanning and pinging from 220.127.116.11 revealed that no
> connections were blocked (only rejected) and that it is possible to
> ping 18.104.22.168.
> Even when explicitly denying traffic.
> What's even worse:
> I can configure m0n0wall from 22.214.171.124
That's because since 1.1b16, m0n0wall passes traffic between
statically routed subnets on an interface and the m0n0wall subnet on
the same interface unconditionally (but statelessly) to handle more
complicated routing topologies properly.
The unfortunate side effect of this is that it also passes traffic to
m0n0wall itself, which is indeed a bug and will have to be resolved
with skip rules. This will happen in the next beta version. I don't
see this as a serious security problem though.
> 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
That probably won't work as long as the packet filter is based on
ipfilter 3.4, which doesn't even consult the rule set if there's
already a matching entry in the state table. We could switch to pf
sometime in the future (not sure right now if that would solve the
problem though), but that doesn't only bring advantages (as described
in a separate thread).
> 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.
Well, that's not so easy to change now. In the beginning, m0n0wall
didn't even support block rules (as it's usually a bad idea to use
them, except when you have to for more complex matching), so there
was no reason to put user-defined rules first.
Anyway, thanks for reporting this issue!