Bug 22859 - rc.network should start ipf/ipnat AFTER ppp (like ipfw/natd)
Summary: rc.network should start ipf/ipnat AFTER ppp (like ipfw/natd)
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Darern Reed
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-11-15 05:40 UTC by eliyanah
Modified: 2002-03-26 10:07 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description eliyanah 2000-11-15 05:40:01 UTC
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.

Fix: 

Change rc.network so ipf/ipnat are started after ppp.
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"
Comment 1 Gerhard Sittig 2001-01-20 21:29:38 UTC
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.
Comment 2 Darern Reed freebsd_committer freebsd_triage 2001-02-21 21:32:27 UTC
Responsible Changed
From-To: freebsd-bugs->darrenr

darrenr is responsible for ipf/ipnat
Comment 3 sgeipel 2001-07-16 14:20:43 UTC
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>
Comment 4 Darern Reed freebsd_committer freebsd_triage 2001-10-20 05:46:57 UTC
State Changed
From-To: open->feedback

change implemented in -current
Comment 5 Guido van Rooij 2001-11-14 13:33:30 UTC
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/
Comment 6 Gerhard Sittig 2002-01-03 21:08:18 UTC
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.
Comment 7 Darern Reed freebsd_committer freebsd_triage 2002-03-26 10:05:36 UTC
State Changed
From-To: feedback->closed

this work has been integrated into -current