Almost there - but...
After 16 days of uptime (a new record) monowall went down. The device was
rebooted but went down again a couple of hours later.
It seems that denying ICMP data does prolong the uptime of monowall, but
apparently it's not enough.
My next steps are:
1) Deny fragmented packages in general
2) Move management to HTTPS
3) Install an I-BOOT device (http://www.dataprobe.com/power/iboot.html)
4) Find out if anyone returned from vacation and if so - find out which
hardware rejoined the setup.
I have a couple of questions for the list:
1) Is there *ANY* way that mini_httpd can crash the entire box?
2) If you have a device that locks up: Are you allowing management from WAN
3) If you have a device that locks up: Are you allowing any type of
4) Anyone getting closer to a solution?
>From: Lee Sharp <leesharp at hal dash pc dot org>
>To: "Soren Vanggaard Jensen" <svanggaard at hotmail dot com>,akemp at iquest dot net,
>m0n0wall at lists dot m0n0 dot ch
>Subject: Re: [m0n0wall] Version 1.22 freeze
>Date: Thu, 06 Jul 2006 15:48:14 -0500
>On Thu, 06 Jul 2006 12:59:41 +0000
> "Soren Vanggaard Jensen" <svanggaard at hotmail dot com> wrote:
>>It seems my case is getting stronger. Your posts and my uptime (now 6
>>days, 6 hours - usually less than 2 days) since blocking all ICMP traffic.
>>Now, why is it that some (most) monowall installations dos not freeze even
>>though outbound ICMP is allowed by default rules? I think there could be 2
>>1) The problem only occurs under heavy load conditions
>>2) The problem occurs only when a junk router, Accesspoint or PC (internet
>>or LAN) does not handle fragmentation correctly.
>Or junk PC. I have seen PCs with dieing nics send some bad stuff and knock
>down an entire network.