[ previous ] [ next ] [ threads ]
 
 From:  Chris Hoy Poy <chrishp at dugeo dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Firewall hangs.
 Date:  Fri, 20 Oct 2006 09:22:24 +0800
The dropped packets are those where the connection has been torn down already 
by one end, and these are just either left over packets/repeats/garbage. This 
is in the FAQ, and I think a variation on this question gets asked every 
week - usually more often. 

everything else looks normal. I recommend running memcheck86 or something to 
check the memory on the machine. Theres a liveCD version of that running 
around, I think a lot of linux distro's package it as well. To me this looks 
like hardware - but then, I run monowall on very old hardware.. so when this 
starts happening after its been stable a while, I figure out the box is worth 
about $AU20 and I typically ditch the whole lot before I spend entire 
weekends trying to fix it.. ;) 

cheers;


-- 
Chris Hoy Poy
System Administrator
DownUnder GeoSolutions
http://www.dugeo.com

On Friday 20 October 2006 04:08, Krist van Besien wrote:
> Hello all,
>
> Yesterday evening my m0n0wal hung. This morning it hung again.
>
> This is baffling me. It has been working flawlessly for months, and
> only the last weeks the firewall has decided to hang on me at regular
> intervals.
>
> Bit rot? I wouldn't know. It runs from a read only file system after all.
>
> So I investigated a bit further, and found a few odd things that I
> can't really explain.
>
> - Looking in the ipmon logs (which get logged on my syslog server) I
> see lines like this:
>
> Oct 19 21:58:35 192.168.1.1 ipmon[82]: 21:58:35.180467 ng0 @0:19 b
> 189.160.44.200,2163 -> 192.168.1.99,19100 PR tcp len 20 40 -AR IN
>
> This tells me (if I'm not mistaken) that rule nr. 19 caused it to drop
> packets from some host to my internal host at 192.168.1.99, port
> 19100.
>
> This is odd, because I have a rule that explicitly allows this
> connection. I NAT port 19100 to my internal server for the use of my
> Bittorrent client. Wny then do such connections get blocked quite
> often, but not always (as bittorrent works fine)
>
> - lookin at what rules I have with ipfstat -in I get the following:
>
> $ ipfstat -in
> @1 pass in quick on lo0 from any to any
> @2 block in log quick from any to any with short
> @3 block in log quick from any to any with ipopt
> @4 pass in quick on sis2 proto udp from any port = 68 to
> 255.255.255.255/32 port = 67
> @5 pass in quick on sis2 proto udp from any port = 68 to
> 192.168.1.1/32 port = 67
> @6 pass in quick on sis1 proto udp from any port = 68 to
> 255.255.255.255/32 port = 67
> @7 pass in quick on sis1 proto udp from any port = 68 to
> 192.168.2.1/32 port = 67
> @8 block in log quick on ng0 from 192.168.1.0/24 to any
> @9 block in log quick on ng0 from 192.168.2.0/24 to any
> @10 block in log quick on ng0 proto udp from any port = 67 to
> 192.168.1.0/24 port = 68
> @11 pass in quick on ng0 proto udp from any port = 67 to any port = 68
> @12 block in log quick on sis2 from !192.168.1.0/24 to any
> @13 block in log quick on sis1 from !192.168.2.0/24 to any
> @14 block in log quick on ng0 from 10.0.0.0/8 to any
> @15 block in log quick on ng0 from 127.0.0.0/8 to any
> @16 block in log quick on ng0 from 172.16.0.0/12 to any
> @17 block in log quick on ng0 from 192.168.0.0/16 to any
> @18 skip 1 in proto tcp from any to any flags S/FSRA
> @19 block in log quick proto tcp from any to any
> @20 block in log quick on sis2 from any to any head 100
> @1 pass in quick from 192.168.1.0/24 to 192.168.1.1/32 keep state group 100
> @2 pass in quick from 192.168.1.0/24 to any keep state group 100
> @21 block in log quick on ng0 from any to any head 200
> @1 pass in quick proto tcp from any to 192.168.1.91/32 port = 22 keep
> state group 200
> @2 pass in quick proto tcp/udp from any to 192.168.1.99/32 port 19099
>
> >< 19102 keep state group 200
>
> @3 pass in quick proto tcp from any to 83.78.55.5/32 port = 443 keep
> state group 200
> @4 pass in quick proto tcp from 138.188.101.25/32 to 192.168.1.99/32
> port = 6883 keep state group 200
> @5 pass in quick proto tcp from any to 192.168.1.91/32 port = 80 keep
> state group 200
> @6 pass in quick proto tcp from any to 192.168.1.91/32 port 19109 ><
> 19120 keep state group 200
> @7 pass in quick proto tcp from any to 192.168.1.91/32 port = 25 keep
> state group 200
> @8 pass in quick proto tcp from any to 192.168.1.91/32 port = 993 keep
> state group 200
> @22 block in log quick on sis1 from any to any head 300
> @1 pass in quick from any to any keep state group 300
> @23 block in log quick from any to any
>
>
> This I don't completely understand. Why are there two rules numberd
> @1. @2 etc...
> Why is there a rule aparently blocking eveything higher up than the
> rule allowing connections. And why does my bittorrent client work
> anyway?
>
> Waht I also did was have a look at the state table using ipfstat -t
>
> Looking at this I get an extremely long table that doesn't seem to end
> (the page never stops loading).
>
> So I have a few questions.
>
> - Are my firewall rules screwed up.
> - Is my firewall unstable because some state table keeps filling up?
>
>
> Thanks in advance for any answers.