From wawa@wawa.yandex.ru  Mon Oct 25 16:30:23 2004
Return-Path: <wawa@wawa.yandex.ru>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id CA1EB16A4CF
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 25 Oct 2004 16:30:23 +0000 (GMT)
Received: from wawa.yandex.ru (wawa.yandex.ru [213.180.193.150])
	by mx1.FreeBSD.org (Postfix) with ESMTP id D008243D2F
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 25 Oct 2004 16:30:22 +0000 (GMT)
	(envelope-from wawa@wawa.yandex.ru)
Received: from wawa.yandex.ru (localhost [127.0.0.1])
	by wawa.yandex.ru (8.13.1/8.13.1) with ESMTP id i9PGULwj001249
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 25 Oct 2004 20:30:21 +0400 (MSD)
	(envelope-from wawa@wawa.yandex.ru)
Received: (from root@localhost)
	by wawa.yandex.ru (8.13.1/8.13.1/Submit) id i9PGULrU001248;
	Mon, 25 Oct 2004 20:30:21 +0400 (MSD)
	(envelope-from wawa)
Message-Id: <200410251630.i9PGULrU001248@wawa.yandex.ru>
Date: Mon, 25 Oct 2004 20:30:21 +0400 (MSD)
From: Vladimir Ivanov <wawa@yandex-team.ru>
Reply-To: Vladimir Ivanov <wawa@yandex-team.ru>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: IPFW misbehaviour in RELENG_5
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         73129
>Category:       kern
>Synopsis:       [patch] IPFW misbehaviour in RELENG_5
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    andre
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Oct 25 16:30:31 GMT 2004
>Closed-Date:    Sat Sep 10 07:50:17 GMT 2005
>Last-Modified:  Sat Sep 10 07:50:17 GMT 2005
>Originator:     Vladimir Ivanov
>Release:        FreeBSD 5.3-STABLE i386
>Organization:
Yandex LLC
>Environment:
System: FreeBSD wawa.yandex.ru 5.3-STABLE FreeBSD 5.3-STABLE #0: Mon Oct 25 19:21:30 MSD 2004 wawa@wawa.yandex.ru:/usr/src/sys/i386/compile/WAWA i386


	
>Description:
	IPFW does not forward packets which has dst-addr from directly connected network.
	
>How-To-Repeat:
	there are three interfaces on router:

vlan3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 213.180.192.168 netmask 0xfffffff0 broadcast 213.180.192.175
        ether 00:30:48:29:e9:62
        media: Ethernet 1000baseTX (1000baseTX <full-duplex>)
        status: active
        vlan: 3 parent interface: em0
vlan159: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 213.180.200.254 netmask 0xffffff00 broadcast 213.180.200.255
        ether 00:30:48:29:e9:62
        media: Ethernet 1000baseTX (1000baseTX <full-duplex>)
        status: active
        vlan: 159 parent interface: em0
vlan169: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 213.180.218.254 netmask 0xffffff00 broadcast 213.180.218.255
        ether 00:30:48:29:e9:62
        media: Ethernet 1000baseTX (1000baseTX <full-duplex>)
        status: active
        vlan: 169 parent interface: em0

Firewall:
	fwd 213.180.192.162 tcp from 213.180.200.32/28 to 213.180.218.0/24 in via vlan159
	allow ip from any to any

The very first firewall command does not forward packets et all. Though it increments counters
I've found a strange piece of code in the module ip_route.c. The problem may be fixed by removing a couple of lines.
I'm not sure whether it is a valid solution cause code is pretty complicated. Author's comments are desirable :-)
	
>Fix:


--- ip_output.c.orig    Sun Oct  3 21:04:40 2004
+++ ip_output.c Mon Oct 25 20:01:59 2004
@@ -706,16 +706,11 @@
        /* Or forward to some other address? */
        fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL);
        if (fwd_tag) {
-               if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) {
-                       dst = (struct sockaddr_in *)&ro->ro_dst;
-                       bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in));
-                       m->m_flags |= M_SKIP_FIREWALL;
-                       m_tag_delete(m, fwd_tag);
-                       goto again;
-               } else {
-                       m_tag_delete(m, fwd_tag);
-                       /* Continue. */
-               }
+               dst = (struct sockaddr_in *)&ro->ro_dst;
+               bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in));
+               m->m_flags |= M_SKIP_FIREWALL;
+               m_tag_delete(m, fwd_tag);
+               goto again;
        }
 #endif



>Release-Note:
>Audit-Trail:

From: Maxim Konovalov <maxim@macomnet.ru>
To: Vladimir Ivanov <wawa@yandex-team.ru>
Cc: bug-followup@freebsd.org
Subject: Re: kern/73129: IPFW misbehaviour in RELENG_5
Date: Mon, 25 Oct 2004 20:57:34 +0400 (MSD)

 Haven't checked the code yet but this PR sounds similar to kern/71910.
 Could you please check the patch in kern/71910 solves your problem?
 TIA.
 
 -- 
 Maxim Konovalov

From: Vladimir Ivanov <wawa@yandex-team.ru>
To: Maxim Konovalov <maxim@macomnet.ru>
Cc: bug-followup@freebsd.org
Subject: Re: kern/73129: IPFW misbehaviour in RELENG_5
Date: Mon, 25 Oct 2004 21:41:23 +0400

 Maxim Konovalov wrote:
 
 >Haven't checked the code yet but this PR sounds similar to kern/71910.
 >Could you please check the patch in kern/71910 solves your problem?
 >TIA.
 >
 >  
 >
 They've got trouble with locally originated traffic that's why they've 
 removed in_localip(srcip) check.
 I've got problem with intercepting traffic which flows to directly 
 connected subnet (ip_localaddr(dstip) check).
 
 The idea of this strange "if" operator is absolutly unclear for me. The 
 only meaning which I can see: "disable forwarding traffic which are 
 either locally originated or originally has  been directed to connected 
 subnets". I can't understand why.
 That's why I've removed both checks.
 
 But I still suppose there were some reason to write this code.
Responsible-Changed-From-To: freebsd-bugs->andre 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Thu Dec 2 13:21:14 GMT 2004 
Responsible-Changed-Why:  
These checks (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) were 
introduced with PFIL_HOOKS conversion by Andre. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=73129 
State-Changed-From-To: open->closed 
State-Changed-By: andre 
State-Changed-When: Sat Sep 10 07:49:44 GMT 2005 
State-Changed-Why:  
See kern/71910 for solution. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=73129 
>Unformatted:
