bug in IPFW+NATD+keep-state (FreeBSD 8.2, GENERIC) ?

[62mkv]

Hello Freebsd-ipfw,

  A was already asking a question to this maillist couple of days
  ago. as long as nobody answered, I went on and discovered a very
  strange thing, which definitely is not normal.

  In short: I am using IPFW+NATD, essentally in the same way as is
  written in handbook (NAT+Stateful rules, example 1). Everything (I
  test for simplicity only on ICMP packets) works OK if I use stateless syntax.

  BUT only I add a "keep-state" option to a "skipto $nat" rule - NATD
  stops aliasing !!! It just pushes packets "as is" onto a global
  interface with unregistered source IP !!!

  It is so much unexpected and goes in contrary with Handbook, so that
  I decided to post it here.

  general setup: rl0 - external (WAN) interface, fxp0 - LAN
  (unregistered) interface. I want to make it possible for a single
  station from LAN (192.168.0.2) make pings and get replies of course,
  to global WAN addresses. for this I use IPFW and NATD.

  IPFW setup 0 (stateless):

  ipfw show:
00001 11  660 divert 1000 ip from any to any in via rl0
00002  0    0 check-state
00005  0    0 allow ip from any to me via fxp0
00006  0    0 allow ip from me to any via fxp0
00010  0    0 allow ip from any to any via lo0
00011 15  900 allow icmp from 192.168.0.2 to any in via fxp0
00012 15  900 skipto 20 icmp from 192.168.0.2 to any out via rl0
00013  0    0 allow ip from any to me via fxp0
00016 11  660 deny log logamount 5 icmp from any to any
00019 49 5670 deny ip from any to any
00020 15  900 divert 1000 ip from any to any via rl0
00040 11  660 allow ip from any to any
65535  0    0 deny ip from any to any

  natd.log (I had to type it in manually, because with ">" or "| tee"
  redirections I cannot get logs of natd (probably when I terminate
  him with Ctrl-C, it loses its buffered output) -is there a
  workaround for this ?) :

Out {default}[ICMP] [ICMP] 192.168.0.2 -> 81.201.246.17 8(0) aliased to
           [ICMP] 81.201.146.94 -> 81.201.246.17 8(0)
In  {default}[ICMP] [ICMP] 81.201.246.17 -> 81.201.246.94 0(0) aliased to 
           [ICMP] 81.201.246.17 -> 192.168.0.2 0(0)
...

natd is run as follows: natd -p -1000 -v -n rl0

tcpdump on rl0:
13:54:11.419747 IP 81.201.246.94 > 81.201.246.17: ICMP echo request, id 512, seq 46601, length 40
13:54:11.420345 IP 81.201.246.17 > 81.201.246.94: ICMP echo reply, id 512, seq 46601, length 40
13:54:16.919819 IP 81.201.246.94 > 81.201.246.17: ICMP echo request, id 512, seq 46857, length 40
13:54:16.920352 IP 81.201.246.17 > 81.201.246.94: ICMP echo reply, id 512, seq 46857, length 40

so, all works fine (except that "replies" are dropped by IPFW because as
such they're forbidden, and IPFW ruleset is yet stateless)

now IPFW setup 1 (=setup0 + only one keep-state to skipto rule #12):
ipfw -d show:
00001  1   60 divert 1000 ip from any to any in via rl0
00002  0    0 check-state
00005  0    0 allow ip from any to me via fxp0
00006  0    0 allow ip from me to any via fxp0
00010  0    0 allow ip from any to any via lo0
00011 15  900 allow icmp from 192.168.0.2 to any in via fxp0
00012 19 1140 skipto 20 icmp from 192.168.0.2 to any out via rl0 keep-state
00016  0    0 deny log logamount 5 icmp from any to any
00019 45 4845 deny ip from any to any
00020 17 1020 divert 1000 ip from any to any via rl0
00040 10  600 allow ip from any to any
65535  1   78 deny ip from any to any
## Dynamic rules (1):
00012  0    0 (1s) STATE icmp 192.168.0.2 0 <-> 81.201.246.17 0

natd.log:
Out {default}[ICMP] [ICMP] 192.168.0.2 -> 81.201.246.17 8(0) aliased to
           [ICMP] 192.168.0.2 -> 81.201.246.17 8(0)
Out {default}[ICMP] [ICMP] 192.168.0.2 -> 81.201.246.17 8(0) aliased to
           [ICMP] 192.168.0.2 -> 81.201.246.17 8(0)

tcpdump on rl0:
17:54:13.711016 IP 192.168.0.2 > 81.201.246.17: ICMP echo request, id 512, seq 50443, length 40
17:54:19.211081 IP 192.168.0.2 > 81.201.246.17: ICMP echo request, id 512, seq 50699, length 40
17:54:24.711198 IP 192.168.0.2 > 81.201.246.17: ICMP echo request, id 512, seq 50955, length 40


So, what would it all mean, and what am I doing wrong ?
--
Best wishes, 62mkv

mailto: 62mkv at mail.ru