[ previous ] [ next ] [ threads ]
 
 From:  "Krist van Besien" <krist dot vanbesien at gmail dot com>
 To:  "m0n0wall list" <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Firewall hangs.
 Date:  Thu, 19 Oct 2006 22:08:32 +0200
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.









-- 
krist dot vanbesien at gmail dot com
Bremgarten b. Bern, Switzerland