kern/150798: ipfw2 fwd rule matches packets but does not do the job in fact.

Andrey Voitenkov av at holymail.biz
Tue Sep 21 21:40:02 UTC 2010


>Number:         150798
>Category:       kern
>Synopsis:       ipfw2 fwd rule matches packets but does not do the job in fact.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Sep 21 21:40:02 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     Andrey Voitenkov
>Release:        tag=RELENG_8_1 date=2010.08.08.00.00.00
>Organization:
>Environment:
FreeBSD thin.XXX.ua 8.1-RELEASE FreeBSD 8.1-RELEASE #1: Tue Aug 24 18:08:01 EEST 2010     root at thin.XXX.ua:/usr/obj/usr/src/sys/THIN  amd64
>Description:
Faced a strange issue - fwd rule matches packets but does not do the job in fact.

The test host has 2 active interfaces: fxp0 with 10.0.1.115/24 and em0 with 10.0.0.66/24.
Default route is set to 10.0.1.1. There is also router 10.0.0.1 available via em0.

The ruleset:
# ipfw -d show
00050         0            0 allow ip from any to any via lo0
00055         0            0 allow ip6 from any to any via lo0
00200         4          220 skipto 700 log logamount 100 tag 1 ip from any to any dst-ip 10.0.0.66 in
00210         8          440 skipto 700 log logamount 100 tag 1 ip from any to any src-ip 10.0.0.66 out
00300         0            0 allow icmp from any to any
00600        19         1540 allow tcp from any to me dst-port 22 in
00610        17         1932 allow tcp from me 22 to any out
00700         0            0 check-state
00710         5          240 deny log logamount 100 tcp from any to any established
00720         2          120 skipto 2000 log logamount 100 ip from any to any tagged 1
00800         0            0 allow tcp from me to any out setup keep-state
00810         0            0 allow udp from me to any out keep-state
00820         0            0 allow tcp from any to 10.0.1.115 dst-port 80 in setup keep-state
00830         0            0 allow tcp from any to 10.0.1.115 dst-port 21 in setup keep-state
01000        11          528 skipto 65000 log logamount 100 ip from any to any
02000         0            0 skipto 60000 log logamount 100 tcp from me to any out setup keep-state
02010         0            0 skipto 60000 log logamount 100 udp from me to any out keep-state
02020         0            0 skipto 60000 log logamount 100 icmp from any to any keep-state
02030         4          240 skipto 60000 log logamount 100 tcp from any to me dst-port 25,465,587 in setup keep-state
02040         3          180 skipto 60000 log logamount 100 tcp from any to me dst-port 143,993 in setup keep-state
03000         0            0 skipto 65000 log logamount 100 ip from any to any
60000         7          420 count ip from any to any
60010         3          180 allow log logamount 100 ip from any to any in tagged 1
60020         4          240 fwd 10.0.0.1 log logamount 100 ip from 10.0.0.66 to any out
65000        11          528 deny log logamount 100 ip from any to any
65001         0            0 deny ip6 from any to any
65535 348792682 269452781083 allow ip from any to any
## Dynamic rules (2):
02030         3          180 (298s) STATE tcp 192.168.0.86 39598 <-> 10.0.0.66 465
02040         2          120 (300s) STATE tcp 91.215.8.2 55670 <-> 10.0.0.66 143

-----------------------------------------------------------------

Trying to connect to 10.0.0.66 port 465 (exim is up and running) from host 192.168.0.86,
ipfw.log looks exactly as I expected:

Sep 21 23:46:31 thin kernel: ipfw: 200 SkipTo 700 TCP 192.168.0.86:39598 10.0.0.66:465 in via em0
Sep 21 23:46:31 thin kernel: ipfw: 720 SkipTo 2000 TCP 192.168.0.86:39598 10.0.0.66:465 in via em0
Sep 21 23:46:31 thin kernel: ipfw: 2030 SkipTo 60000 TCP 192.168.0.86:39598 10.0.0.66:465 in via em0
Sep 21 23:46:31 thin kernel: ipfw: 60010 Accept TCP 192.168.0.86:39598 10.0.0.66:465 in via em0
Sep 21 23:46:31 thin kernel: ipfw: 210 SkipTo 700 TCP 10.0.0.66:465 192.168.0.86:39598 out via fxp0
Sep 21 23:46:31 thin kernel: ipfw: 2030 SkipTo 60000 TCP 10.0.0.66:465 192.168.0.86:39598 out via fxp0
Sep 21 23:46:31 thin kernel: ipfw: 60020 Forward to 10.0.0.1 TCP 10.0.0.66:465 192.168.0.86:39598 out via fxp0

Sep 21 23:46:34 thin kernel: ipfw: 200 SkipTo 700 TCP 192.168.0.86:39598 10.0.0.66:465 in via em0
Sep 21 23:46:34 thin kernel: ipfw: 2030 SkipTo 60000 TCP 192.168.0.86:39598 10.0.0.66:465 in via em0
Sep 21 23:46:34 thin kernel: ipfw: 60010 Accept TCP 192.168.0.86:39598 10.0.0.66:465 in via em0
Sep 21 23:46:34 thin kernel: ipfw: 210 SkipTo 700 TCP 10.0.0.66:465 192.168.0.86:39598 out via fxp0
Sep 21 23:46:34 thin kernel: ipfw: 2030 SkipTo 60000 TCP 10.0.0.66:465 192.168.0.86:39598 out via fxp0
Sep 21 23:46:34 thin kernel: ipfw: 60020 Forward to 10.0.0.1 TCP 10.0.0.66:465 192.168.0.86:39598 out via fxp0

Sep 21 23:46:37 thin kernel: ipfw: 200 SkipTo 700 TCP 192.168.0.86:39598 10.0.0.66:465 in via em0
Sep 21 23:46:37 thin kernel: ipfw: 2030 SkipTo 60000 TCP 192.168.0.86:39598 10.0.0.66:465 in via em0
Sep 21 23:46:37 thin kernel: ipfw: 60010 Accept TCP 192.168.0.86:39598 10.0.0.66:465 in via em0
Sep 21 23:46:37 thin kernel: ipfw: 210 SkipTo 700 TCP 10.0.0.66:465 192.168.0.86:39598 out via fxp0
Sep 21 23:46:37 thin kernel: ipfw: 2030 SkipTo 60000 TCP 10.0.0.66:465 192.168.0.86:39598 out via fxp0
Sep 21 23:46:37 thin kernel: ipfw: 60020 Forward to 10.0.0.1 TCP 10.0.0.66:465 192.168.0.86:39598 out via fxp0
-----------------------------------------------------------------

But client does not get response from the test host.
In spite of the fact the the rule 60020 matches the ack's, I still see them on fxp0 going out to the default gw:

# tcpdump -n -i em0 src 192.168.0.86 or dst 192.168.0.86
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
23:46:31.188517 IP 192.168.0.86.39598 > 10.0.0.66.465: Flags [S], seq 579129109, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 2443437844 ecr 0], length 0
23:46:34.188457 IP 192.168.0.86.39598 > 10.0.0.66.465: Flags [S], seq 579129109, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 2443440844 ecr 0], length 0
23:46:37.388808 IP 192.168.0.86.39598 > 10.0.0.66.465: Flags [S], seq 579129109, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 2443444044 ecr 0], length 0

# tcpdump -n -i fxp0 src 192.168.0.86 or dst 192.168.0.86
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
23:46:31.188609 IP 10.0.0.66.465 > 192.168.0.86.39598: Flags [S.], seq 1231665894, ack 579129110, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 3020614121 ecr 2443437844], length 0
23:46:34.188526 IP 10.0.0.66.465 > 192.168.0.86.39598: Flags [S.], seq 1231665894, ack 579129110, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 3020614121 ecr 2443440844], length 0
23:46:37.188384 IP 10.0.0.66.465 > 192.168.0.86.39598: Flags [S.], seq 1231665894, ack 579129110, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 3020614121 ecr 2443440844], length 0
-----------------------------------------------------------------

Tried a couple of variations of rule 60020:
fwd 10.0.0.1 log logamount 100 src-ip 10.0.0.66 out
fwd 10.0.0.1 log logamount 100 tagged 1 out
result is exactly the same.

At the same time this 60020 rule works fine for outgoing connections from the test host:
% telnet -s 10.0.0.66 192.168.0.86 25
Trying 192.168.0.86...
Connected to 192.168.0.86.
Escape character is '^]'.
^C

Outgoing packets are matched and forwarded as expected.
-----------------------------------------------------------------


fwd works ok with a very simple ruleset in the same test case:

00050       490       363540 allow ip from any to any via lo0
00055         0            0 allow ip6 from any to any via lo0
00100       596       240883 fwd 10.0.0.1 ip from 10.0.0.66 to any out xmit fxp0
65535 348794572 269453265568 allow ip from any to any

>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list