From nobody@FreeBSD.ORG  Tue Nov 14 21:38:12 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id B04F737B479; Tue, 14 Nov 2000 21:38:12 -0800 (PST)
Message-Id: <20001115053812.B04F737B479@hub.freebsd.org>
Date: Tue, 14 Nov 2000 21:38:12 -0800 (PST)
From: eliyanah@techie.com
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: rc.network should start ipf/ipnat AFTER ppp (like ipfw/natd)
X-Send-Pr-Version: www-1.0

>Number:         22859
>Category:       conf
>Synopsis:       rc.network should start ipf/ipnat AFTER ppp (like ipfw/natd)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    darrenr
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Nov 14 21:40:01 PST 2000
>Closed-Date:    Tue Mar 26 02:07:38 PST 2002
>Last-Modified:  Tue Mar 26 02:07:38 PST 2002
>Originator:     Janet Sullivan
>Release:        4.2-BETA
>Organization:
>Environment:
FreeBSD nene.shekhina.com 4.2-BETA FreeBSD 4.2-BETA #0: Tue Nov 14 18:28:29 MST 2000     root@nene.shekhina.com:/usr/obj/usr/src/sys/NENE  i386  
>Description:
If ipfilter, ipnat, and ppp are enabled in rc.conf, rc.network will 
start ipfilter and ipnat BEFORE user ppp, which does not work if you 
are using ipf/ipnat with tun0.  rc.network correctly starts ipfw/natd
AFTER ppp, and even states "Start user ppp if required.  This must
happen before natd."  What is true for ipfw/natd is also true for 
ipf/ipnat - User ppp needs to be started BEFORE ipf/ipnat for proper 
operation.
>How-To-Repeat:
Add the following lines to rc.conf, and ipf/ipnat are started before ppp.  
This is a problem if your ipf/ipnat rules use tun0 - it won't work.  User
ppp must be started first.

ipfilter_enable="YES"
ipfilter_flags=""
ipnat_enable="YES"
ppp_enable="YES"
ppp_nat="NO"
>Fix:
Change rc.network so ipf/ipnat are started after ppp.

>Release-Note:
>Audit-Trail:

From: Gerhard Sittig <Gerhard.Sittig@gmx.net>
To: eliyanah@techie.com
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: conf/22859: rc.network should start ipf/ipnat AFTER ppp (like ipfw/natd)
Date: Sat, 20 Jan 2001 22:29:38 +0100

 On Tue, Nov 14, 2000 at 21:38 -0800, eliyanah@techie.com wrote:
 > 
 > >Description:
 > If ipfilter, ipnat, and ppp are enabled in rc.conf, rc.network
 > will start ipfilter and ipnat BEFORE user ppp, which does not
 > work if you are using ipf/ipnat with tun0.  rc.network
 > correctly starts ipfw/natd AFTER ppp, and even states "Start
 > user ppp if required.  This must happen before natd."  What is
 > true for ipfw/natd is also true for ipf/ipnat - User ppp needs
 > to be started BEFORE ipf/ipnat for proper operation.
 
 I dare to disagree. :)  AFAIK the only prerequisite may be that
 the *interface* has to be available when the filter / natd starts
 up.  I'm not positive about the details, but since I did the
 rc.network stuff for hooking ipf in I'm absolutely sure that it
 works for me on several machines. :>
 
 > >Fix:
 > Change rc.network so ipf/ipnat are started after ppp.
 
 Starting ipf this early was done on purpose.  That's why there is
 so big a comment in rc.network.  I've been through this in Linux
 land:  ipfwadm (the filter when kernel 2.0 was active) couldn't
 work on interfaces that haven't been *up* yet.  This changed with
 ipchains (fitting kernel 2.2) which can load the filter and
 afterwards config and up the interface.  I like this better since
 *every* action with this interface is done at a time when there's
 an established ruleset.  I tried to discuss this in some
 freebsd-* list (don't know which one it was) and to get myself
 clear if there's a similar issue with FreeBSD and ipfw / ipf.
 The result is that I started ipf as soon as I could (read: before
 any outside communication can occur).  And I never had any
 problem with it.  Nor did others that I could hear of.
 
 I can see two (or three, depends on your configuration) solutions
 which keep the early ipf startup and possibly solve your problem:
 - compile the tun interfaces into your kernel instead of using
   modules (it's what I have and I never experienced that NAT
   wouldn't work -- but it could be due to the next item, too)
 - _sync_ your ipf/ipnat setup after ppp is up (it's what I do in
   ppp.link{up,down} since I get IPs assigned dynamically), see
   "man 8 ipf" and the -y option
 - make sure your interfaces are there when they're needed, which
   could be achieved with some lines just before calling ipf:
       for IF in ${ipfilter_interfaces}; do
         < /dev/$IF
         # or: dd if=/dev/$IF of=/dev/null count=0
       done
 
 I feel when moving the invocation of ipf/ipnat behind ppp is the
 solution for you, you only see the effect of ppp working with
 tun0 -- tun interfaces magically jump into existence when they
 are opened.  So the third item of the above would be a solution
 for you.  And when it works with other NIFs besides tunN, it
 could be extended for any case where NIC drivers are loaded as
 modules.
 
 Although the second item would be the simplest:  Insert some
   case ${ipfilter_enable} in
   [Yy][Ee][Ss]) /sbin/ipf -y;;
   esac
 before or after the ipfw code in rc.network.  But to repeat it:
 I never had to do this, something in your setup must be different
 and you don't describe it.  Do you use modules?
 
 
 virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
 Gerhard Sittig   true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
 -- 
      If you don't understand or are scared by any of the above
              ask your parents or an adult to help you.
 
Responsible-Changed-From-To: freebsd-bugs->darrenr 
Responsible-Changed-By: darrenr 
Responsible-Changed-When: Wed Feb 21 13:32:27 PST 2001 
Responsible-Changed-Why:  
darrenr is responsible for ipf/ipnat 

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

From: Sven Geipel <sgeipel@bfh.fh-hof.de>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: conf/22859: rc.network should start ipf/ipnat AFTER ppp (like 
 ipfw/natd)
Date: Mon, 16 Jul 2001 15:20:43 +0200

 I was bitten by this, too.  Since ppp creates tun devices on
 demand it might establish a situation which ipf is not familiar
 with (yet):  new devices after loading and parsing the rules.
 But I recognize and appreciate the reasons for starting ipf this
 early (see the rc.network comment and the one year old discussion
 on -security for details where nobody brought up this reasoning
 for starting late(r), the thread is referenced in PR conf/20202,
 started with Message-ID <20000626220852.M9883@speedy.gsinet> and
 is archived at
 
 http://www.freebsd.org/cgi/getmsg.cgi?fetch=59495+0+/usr/local/www/db/text/2000/freebsd-security/20000702.freebsd-security
 ).
 
 The easiest solution while still keeping all the benefits
 (starting the filter as early as possible and yet cope with
 dynamically inserted and reconfigured devices) is to issue an
 "ipf -y" command at the time where ipfw is (to be) brought up,
 too.  ipf is easily sync'ed with changed interface lists and
 parameters. :)
 
 Please apply these changes (patch below) to the source repo!
 
 
 BTW:  The issue doesn't come up when all the interfaces are
 linked into the kernel and thus needn't be created by ppp.  So
 monolithic kernels are another "solution".  That's the reason why
 not every ipf and ppp user faces this problem.
 
 
 # This is a shell archive.  Save it in a file, remove anything before
 # this line, and then unpack it by entering "sh file".  Note, it may
 # create directories; files and directories will be owned by you and
 # have default permissions.
 #
 # This archive contains:
 #
 #	ipf-y.diff
 #
 echo x - ipf-y.diff
 sed 's/^X//' >ipf-y.diff << 'END-of-ipf-y.diff'
 X--- rc.network	2001/07/16 11:40:15	1.1
 X+++ rc.network	2001/07/16 11:41:46
 X@@ -225,6 +225,16 @@
 X 		;;
 X 	esac
 X 
 X+
 X+	# Re-Sync ipfilter
 X+	#
 X+	case ${ipfilter_enable} in
 X+	[Yy][Ee][Ss])
 X+		/sbin/ipf -y
 X+		;;
 X+	esac
 X+
 X+
 X 	# Initialize IP filtering using ipfw
 X 	#
 X 	if /sbin/ipfw -q flush > /dev/null 2>&1; then
 END-of-ipf-y.diff
 exit
 
 
 -- 
 Sven Geipel <sgeipel@yahoo.com>
State-Changed-From-To: open->feedback 
State-Changed-By: darrenr 
State-Changed-When: Fri Oct 19 21:46:57 PDT 2001 
State-Changed-Why:  
change implemented in -current 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=22859 

From: Guido van Rooij <guido@mouse.gvr.org>
To: freebsd-gnats-submit@FreeBSD.org, eliyanah@techie.com
Cc:  
Subject: Re: conf/22859: rc.network should start ipf/ipnat AFTER ppp (8like ipfw/natd)
Date: Wed, 14 Nov 2001 14:33:30 +0100

 Arjan de Vet and Doug Barton have made patches to the FreeBSD rc system
 that should solve all of the known problems with IPFilter.
 Current and stable patches are available at the URL underneath.
 Please be so kind to:
 1) Test the patches if they do work for you
 2) mail your feedback to Arjan de Vet (devet@devet.org)
 3) If al is worked out and Arjan has the patches committed, please
 update the PR.
 
 Url:
 http://home.iae.nl/users/devet/freebsd/
 

From: Gerhard Sittig <Gerhard.Sittig@gmx.net>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: conf/22859: rc.network should start ipf/ipnat AFTER ppp (like ipfw/natd)
Date: Thu, 3 Jan 2002 22:08:18 +0100

 On Sat, Jan 20, 2001 at 22:29 +0100, Gerhard Sittig wrote:
 > 
 > [ ... sync by means of "ipf -y" after setting up tun(4)s ... ]
 
 I understand that this is what rev 1.109 of src/etc/rc.network
 from 2001-10-20 and the style cleanup which followed in rev 1.113
 from 2001-11-24 make sure.
 
 So the PR can be closed.
 
 
 virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
 Gerhard Sittig   true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
 -- 
      If you don't understand or are scared by any of the above
              ask your parents or an adult to help you.
State-Changed-From-To: feedback->closed 
State-Changed-By: darrenr 
State-Changed-When: Tue Mar 26 02:05:36 PST 2002 
State-Changed-Why:  
this work has been integrated into -current 

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