Subject: Re: IPF 4.1.22
To: None <tech-net@netbsd.org>
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
List: tech-net
Date: 05/17/2007 19:44:41
[Thread re-directed to tech-net list. Please post any replies there.]

At 13:14 Uhr +0000 17.5.2007, Darren Reed wrote:
>On Tue, May 15, 2007 at 04:05:34PM +0200, Hauke Fath wrote:
>>
>> 4.1.20 is fscked, it goes to 'block all' mode in about a day here.
>> Not useable.
>
>More information please.
>
>What made it seem like "block all" mode?

From some point of time (reached within a few hours on a working day) all
incoming packets were blocked. In the end, the router itself was flooding
the local DNS servers with requests while at the same time blocking some of
the outgoing packets:

05:59:59.971309 wm0 @131:2 b 130.83.xx.yy,58501 ->
ns1.hrz.tu-darmstadt.de[130.83.22.63],domain PR udp len 20 72 OUT

where group 131 has

# ipfstat -on | grep 131
@2 block out log quick on wm0 all head 131
@1 pass out quick proto tcp from 130.83.xx.yy/32 to any flags S/FSRPAU keep
state keep frags group 131
@2 pass out quick proto udp from 130.83. xx.yy/32 to any keep state keep
frags group 131
@3 pass out quick proto icmp from 130.83. xx.yy/32 to any keep state keep
frags group 131
#

-- note that 131:2 is actually a _pass out_ rule.

>Did it stop creating state or what..?

An ipfstat of 4.1.20 (netbsd-4 of May 10th) that I found in the conserver
logfile (uptime 2.5 d):

<snip>
# ipfstat
bad packets:            in 0    out 0
 IPv6 packets:          in 0 out 0
 input packets:         blocked 567981 passed 97536223 nomatch 0 counted
70502091 short
output packets:         blocked 483869756 passed 97529765 nomatch 0 counted
0 short 0
 input packets logged:  blocked 558599 passed 5547
output packets logged:  blocked 483869747 passed 6783
 packets logged:        input 0 output 0
 log failures:          input 226145 output 434428672
fragment state(in):     kept 1031757    lost 7250059    not fragmented 28334143
fragment state(out):    kept 1030550    lost 7256536    not fragmented 28334143
packet state(in):       kept 417373     lost 292339
packet state(out):      kept 534714     lost 483853624
ICMP replies:   6998    TCP RSTs sent:  53956
Invalid source(in):     0
Result cache hits(in):  29371089        (out):  29016112
IN Pullups succeeded:   56847   failed: 0
OUT Pullups succeeded:  70438   failed: 0
Fastroute successes:    72771   failures:       0
TCP cksum fails(in):    0       (out):  0
IPF Ticks:      423313
Packet log flags set: (0)
        none
#
</snip>

An ipfstat of the downgraded system (netbsd-4 of April 20th, uptime 2 d):

<snip>
# ipfstat
bad packets:            in 0    out 0
 IPv6 packets:          in 3115 out 3423
 input packets:         blocked 117276 passed 159652988 nomatch 3115
counted 67336617 short 0
output packets:         blocked 1066 passed 159686377 nomatch 3422 counted
0 short 0
 input packets logged:  blocked 104999 passed 3902
output packets logged:  blocked 839 passed 4460
 packets logged:        input 0 output 0
 log failures:          input 7991 output 2509
fragment state(in):     kept 725418     lost 4224213    not fragmented 24393974
fragment state(out):    kept 723262     lost 4236167    not fragmented 24393974
packet state(in):       kept 1222636    lost 19
packet state(out):      kept 12535      lost 1032
ICMP replies:   4428    TCP RSTs sent:  40584
Invalid source(in):     0
Result cache hits(in):  21440267        (out):  21417706
IN Pullups succeeded:   4991    failed: 0
OUT Pullups succeeded:  8462    failed: 0
Fastroute successes:    40751   failures:       0
TCP cksum fails(in):    0       (out):  0
IPF Ticks:      339141
Packet log flags set: (0)
        none
#
</snip>

The previous version is doing fine, apart from the general problems that
ipfilter versions on the netbsd-4 branch seem to have with stateful NFS
connections, both from Linux 2.6 and NetBSD machines.

The state problem seems to be traffic-related, though. Ipfilter 4.1.20
created no problems so far on my home NAT router, an SS10.

	hauke


--
"It's never straight up and down"     (DEVO)