kern/129103: [ipfw] IPFW check state does not work =(

[Ian Smith]

On Sun, 23 Nov 2008, linimon at 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?