Date: Sat, 20 Jan 2001 19:20:02 -0800 (PST) From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-bugs@FreeBSD.org Subject: Re: conf/22859: rc.network should start ipf/ipnat AFTER ppp (like ipfw/natd) Message-ID: <200101210320.f0L3K2r74551@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR conf/22859; it has been noted by GNATS.
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.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101210320.f0L3K2r74551>