On Mon, 17 Jul 2006 10:52:29 -0600, Aaron Cherman wrote
> After 16 days of uptime (a new record) monowall went down. The device was
> rebooted but went down again a couple of hours later.
The m0n0wall installation over here is currently on 19 days
It seems that blocking all traffic with the exclusion of http, https, ssh and very
few others, really helped. There was a lot of P2P traffic here, which in turn
attracts lot of hosts (malconfigured ones also) which could have sent the "sudden
death" packets (if any, I still need to be convinced ;-))
> 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.
Option 1 might really screw up your windows environment, if you use windows that
is and if several windows machines are spreaded across different subnets that are
routed via m0n0wall. I had problems, others had none.
I only allow management on https over here and 4 might be a really interesting
course of action indeed.
> 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
As for the anwser on 2, I do not allow management via wan. But it did crash.
> I do not allow management from the WAN - but I do from all other interfaces.
> 3) If you have a device that locks up: Are you allowing any type of
> fragmented data?
Same here. No fragmented packets allowed on wan. Everywhere else, they are allowed.
> In the Advanced tab I do have "Allow fragmentedt IPsec packets" checked.
I'll report back in a few days and immediately if the box crashes again.