From root@z.infxa.com  Fri Dec 27 14:53:25 2002
Return-Path: <root@z.infxa.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 7F04337B401
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 27 Dec 2002 14:53:25 -0800 (PST)
Received: from z.infxa.com (z.infxa.com [80.238.135.123])
	by mx1.FreeBSD.org (Postfix) with SMTP id 3E5CD43EC2
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 27 Dec 2002 14:53:24 -0800 (PST)
	(envelope-from root@z.infxa.com)
Received: (qmail 894 invoked by uid 0); 27 Dec 2002 22:53:18 -0000
Message-Id: <20021227225318.893.qmail@z.infxa.com>
Date: 27 Dec 2002 22:53:18 -0000
From: Manuel Kasper <mk@neon1.net>
Reply-To: Manuel Kasper <mk@neon1.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc: mk@neon1.net
Subject: IPFilter and IPFW processing order is not sensible>
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         46564
>Category:       kern
>Synopsis:       IPFilter and IPFW processing order is not sensible>
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    andre
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Dec 27 15:00:19 PST 2002
>Closed-Date:    Tue Aug 24 18:04:18 GMT 2004
>Last-Modified:  Tue Aug 24 18:04:18 GMT 2004
>Originator:     Manuel Kasper <mk@neon1.net>
>Release:        FreeBSD 4.x
>Organization:
>Environment:
Any reasonably recent release of FreeBSD with both ipfilter and ipfw
compiled into the kernel (or loaded as modules at the same time).
>Description:
When both ipfilter and ipfw are loaded, incoming/outgoing packets are
checked in the following order:

incoming:
-> ipfw -> ipnat -> ipfilter ->

outgoing:
-> ipfw -> ipfilter -> ipnat ->

This does not make sense - if ipfw is checked first for incoming packets,
then it should be checked last for outgoing packets, or vice versa. This
applies especially when using ipnat:
incoming packets will be seen in ipfw with an un-NAT-ed public destination
IP address, while outgoing packets will have an internal IP address as their
source. Together with ipnat, this also breaks ipfw's keep-state feature, as
it won't see the same source/destination tuplet for incoming and outgoing
packets belonging to the same connection.

>How-To-Repeat:
Use both ipfilter and ipfw at the same time and observe the order in which
they get checked for incoming and outgoing packets (try using ipnat, too).
>Fix:
My suggestion is to reverse the processing order in sys/netinet/ip_output.c
so ipfw gets checked before ipfilter. That would at least provide consistent
behaviour.
An even better solution would be to make the processing order configurable,
preferably with a sysctl.
>Release-Note:
>Audit-Trail:

From: Manuel Kasper <mk@neon1.net>
To: <freebsd-gnats-submit@FreeBSD.org>, <mk@neon1.net>
Cc:  
Subject: Re: kern/46564: IPFilter and IPFW processing order is not sensible
Date: Sat, 28 Dec 2002 00:13:03 +0100

 SORRY, I confused the ordering - the description is wrong! Actually, at the
 moment, ipfilter is always checked BEFORE ipfw for both incoming and
 outgoing packets, so the order really is:
 
 incoming:
 -> ipnat -> ipfilter -> ipfw
 
 outgoing:
 -> ipfilter -> ipnat -> ipfw
 
 The problem is still the same (outgoing packets are seen with a public
 source IP address, incoming packets will have a private/internal destination
 address when used with ipnat), and the fix is correct.
 
Responsible-Changed-From-To: freebsd-bugs->ipfw 
Responsible-Changed-By: johan 
Responsible-Changed-When: Tue May 6 13:02:05 PDT 2003 
Responsible-Changed-Why:  
Over to ipfw maintainers who will hopefully know 
if this is the correct solution. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=46564 

From: Johan Karlsson <johan@freebsd.org>
To: Bug followup <bug-followup@freebsd.org>
Cc:  
Subject: Fwd: Re: kern/46564: IPFilter and IPFW processing order is not sensible>
Date: Tue, 6 May 2003 23:09:41 +0200

 Adding to the audit-trail.
 
 ----- Forwarded message from Pawel Malachowski <pawmal@unia.3lo.lublin.pl> -----
 
 From: "Pawel Malachowski" <pawmal@unia.3lo.lublin.pl>
 To: johan@FreeBSD.org, freebsd-bugs@FreeBSD.org, ipfw@FreeBSD.org
 Subject: Re: kern/46564: IPFilter and IPFW processing order is not sensible>
 Date: 	Tue, 06 May 2003 22:47:21 +0200
 
 Hello,
 
 	Here is some example:
 
 (private IPs)LAN---(fxp1)BOX(fxp0)---Internet
 
 There are:
 . dummynet running on fxp0
 . ipnat running on fxp0
 
 Right now outgoing packets on fxp0 go through ipnat and then through
 dummynet. It is not possible to shape this traffic on per-user
 basis (for example with src-ip mask) cause after ipnatting all packets
 have the same source IP. Possible sollutions are:
 . use dummynet on fxp0
 	This is not so good idea if I have a huge number of
 	local NICs and subnets cause I have to make exceptions
 	(ipfw skip) for local traffic.
 	It is very easy and natural to use dummynet on fxp0
 	interface for bandwith limitaion of `Internet' traffic.
 . use natd instead of ipnat
 	Sucessfully tested, but I simply prefer ipnat. :)
 
 So, probably packets flow should be:
 	incoming: IPFilter -> IPFW
 	outgoing: IPFW -> IPFilter
 
 This code is `for private use' and is quite bad but does that (4.8):
 http://unia.3lo.lublin.pl/~pawmal/freebsd/ip_output-ipfw-ipf.diff
 
 I know submitter tried something similar on his own, too.
 
 However, allowing user to decide about order (using sysctls?) would
 be the best solution.
 
 
 regards,
 -- 
 Pawel Malachowski
 
 ----- End forwarded message -----
 
 -- 
 Johan Karlsson		mailto:johan@FreeBSD.org
Responsible-Changed-From-To: ipfw->andre 
Responsible-Changed-By: andre 
Responsible-Changed-When: Tue Aug 24 18:01:21 GMT 2004 
Responsible-Changed-Why:  
Take over. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=46564 
State-Changed-From-To: open->closed 
State-Changed-By: andre 
State-Changed-When: Tue Aug 24 18:01:47 GMT 2004 
State-Changed-Why:  
The behaviour will not be changed for FreeBSD 4.x because the change is too 
intrusive.  Running ipfilter and ipfw is officially not supported.  In 5.3 
ipfw has been converted to use the PFIL_HOOKS as well and here the order 
will be observed.  The first loaded packet filter will get the packet first 
on input and last on output. 

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