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"
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 darrenr is responsible for ipf/ipnat
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 change implemented in -current
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/
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 this work has been integrated into -current