From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 24 13:21:26 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BD701065670 for ; Mon, 24 Nov 2008 13:21:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id AF74A8FC1E for ; Mon, 24 Nov 2008 13:21:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mAOCs65U036898; Mon, 24 Nov 2008 23:54:07 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 24 Nov 2008 23:54:05 +1100 (EST) From: Ian Smith To: Eugen Konkov In-Reply-To: <200811232342.mANNgOnr069400@freefall.freebsd.org> Message-ID: <20081124203046.I43853@sola.nimnet.asn.au> References: <200811232342.mANNgOnr069400@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org Subject: Re: kern/129103: [ipfw] IPFW check state does not work =( X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2008 13:21:26 -0000 On Sun, 23 Nov 2008, linimon@freebsd.org wrote: > Old Synopsis: IPFW check state does not work =( > New Synopsis: [ipfw] IPFW check state does not work =( > > Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw > Responsible-Changed-By: linimon > Responsible-Changed-When: Sun Nov 23 23:42:11 UTC 2008 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=129103 Eugen, I'll have a go; worst that can happen is I get it all wrong :) Last things first: a check-state rule NEVER counts any packets; the packet/byte counts are attributed to the triggering keep-state rule, which I think explains the counts you show. The prob 0.5 split makes it a bit harder to see what's happening here, but I'll quote the relevant: > 00001 0 0 check-state As expected. It would be helpful to put another like rule 2 *before* this check-state, showing the total number of icmp packets via ng0, or perhaps even two, one for 'in recv ngo' and one for 'out xmit ng0'. > 00002 6 360 count log icmp from any to any via ng0 This only counts icmp that has not yet been attributed to one of the check-state rules below, ie original, trigger packets for a flow; the response packets in a flow are counted by the keep-state rule (and are shown below in your expired dynamic rule counts) > 00003 5 300 prob 0.500000 skipto 6 log icmp from any to any via ng0 So 5 packets did the skipto 6. Unclear how many failed the prob test, but perhaps 5 or 6 fell through; we don't have the total count .. > 00004 8 480 skipto 5 log icmp from any to any via ng0 keep-state .. however, this 8 count includes some responses to the already established state - that you apparently expected to see in the check-state count. > 00005 3 180 skipto 10 log icmp from any to any via ng0 I'm not sure why this shows only 3 packets though, perhaps because some of the keep-state response packets by now are going out via ng1? > 00006 3 180 skipto 7 log icmp from any to any via ng0 keep-state > 00007 3 180 count log icmp from any to any via ng0 > 00010 6 360 count log icmp from any to any via ng0 That seems to tally, though dynamic rule 6 shows 2 (plus 1 trigger pkt?) > 00099 47 2924 nat 1 ip from any to any via ng0 [..] > ## Dynamic rules (2): > 00004 7 420 (0s) STATE icmp 192.168.9.4 0 <-> 213.180.204.8 0 > 00006 2 120 (0s) STATE icmp 213.180.204.8 0 <-> 91.124.239.145 0 This seems to indicate a total of 9 packets passed due to kept state, so perhaps there were 11 icmp packets in total, 6 out and 5 responses (^C)? > Why 5 packets for rule 3 and 8 packets for rule 4? I'm not sure, but there may be another issue here. I'll tail-quote the first of your security logs below, which seem, on a quick check, to add up to the packet counts for each rule, however it's worth noting the packets logged as being via ng1 (presumably your inside, NAT interface?) Use of 'via' can be a bit misleading. On inbound packets (ie from ip_input) only the receive interface can be tested before routing has occurred, so 'via ng0' shows just those packets. However on outbound packets, 'via iface' applies to packets either received on *or* being transmitted on that interface, which I think is what's happening with those that are logged showing ng1 .. remembering these are shown before NAT translation. Happy to accept any correction on any of this .. Regarding the other (kern/129093: [ipfw] ipfw nat must not drop packets) I can't say anything about what I haven't used, but what's your value of net.inet.ip.fw.one_pass ? cheers, Ian ===== quote from PR, not indented: cat security Nov 23 23:18:39 home kernel: ipfw: 2 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:39 home kernel: ipfw: 4 SkipTo 5 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:39 home kernel: ipfw: 5 SkipTo 10 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:39 home kernel: ipfw: 10 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:39 home kernel: ipfw: 2 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:39 home kernel: ipfw: 3 SkipTo 6 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:39 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:39 home kernel: ipfw: 7 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:39 home kernel: ipfw: 10 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:39 home kernel: ipfw: 4 SkipTo 5 ICMP:0.0 213.180.204.8 192.168.9.4 out via ng1 Nov 23 23:18:40 home kernel: ipfw: 4 SkipTo 5 ICMP:8.0 192.168.9.4 213.180.204.8 in via ng1 Nov 23 23:18:40 home kernel: ipfw: 2 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:40 home kernel: ipfw: 3 SkipTo 6 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:40 home kernel: ipfw: 4 SkipTo 5 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:40 home kernel: ipfw: 5 SkipTo 10 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:40 home kernel: ipfw: 10 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:40 home kernel: ipfw: 2 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:40 home kernel: ipfw: 3 SkipTo 6 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:40 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:40 home kernel: ipfw: 7 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:40 home kernel: ipfw: 10 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:40 home kernel: ipfw: 4 SkipTo 5 ICMP:0.0 213.180.204.8 192.168.9.4 out via ng1 Nov 23 23:18:41 home kernel: ipfw: 4 SkipTo 5 ICMP:8.0 192.168.9.4 213.180.204.8 in via ng1 Nov 23 23:18:41 home kernel: ipfw: 2 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:41 home kernel: ipfw: 3 SkipTo 6 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:41 home kernel: ipfw: 4 SkipTo 5 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:41 home kernel: ipfw: 5 SkipTo 10 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:41 home kernel: ipfw: 10 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:42 home kernel: ipfw: 2 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:42 home kernel: ipfw: 3 SkipTo 6 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:42 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:42 home kernel: ipfw: 7 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:42 home kernel: ipfw: 10 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:42 home kernel: ipfw: 4 SkipTo 5 ICMP:0.0 213.180.204.8 192.168.9.4 out via ng1 Why in log do I see trafic for ng1 interface while rule 1 does not invoked?