From owner-freebsd-stable  Mon Nov  6  8:16:49 2000
Delivered-To: freebsd-stable@freebsd.org
Received: from itsdsv1.enc.edu (unknown [63.85.52.127])
	by hub.freebsd.org (Postfix) with ESMTP id CD4BF37B663
	for <freebsd-stable@FreeBSD.ORG>; Mon,  6 Nov 2000 08:16:43 -0800 (PST)
Received: from enc.edu (r2s1.r.its.enc.edu [10.100.0.21]) by itsdsv1.enc.edu (8.7.5/8.7.3) with ESMTP id LAA10055; Mon, 6 Nov 2000 11:18:57 -0500 (EST)
Message-ID: <3A06DD19.7F055C8B@enc.edu>
Date: Mon, 06 Nov 2000 11:32:25 -0500
From: "Charles N. Owens" <owensc@enc.edu>
Organization: Eastern Nazarene College
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Marko Cuk <cuk@cuk.nu>
Cc: freebsd-stable@FreeBSD.ORG
Subject: Re: rc.firewall script & natd on 4.1.1
References: <3A05D143.8DF86396@cuk.nu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sun, Nov 05, 2000 at 10:29:39PM +0100, Marko Cuk wrote:

> Do you guys know, that in rc.firewall script in 4.1.1 was a mistake and
> natd won't start automatically from rc.conf ?
>
> I put script from 4.1 and now it works ok.
>
> Please, fix it prior 4.2 .

I've seen this same problem with a system I recently upgraded from 3.5 to
4.1 (cvsup's a day or three prior to 4.1.1 being released).

Whatever the cause (I haven't had time to dig) I've boiled this down to the
bizarre observation that natd refuses to start until the PPP connection has
been established.

I thought for a while that it had something to do with the fact that in 4.x
the tun device is a virtual thing... tun0 doesn't exist until it is used.
A posting on this list from a few months ago mentioned this and suggested
that a simple "echo </dev/tun0" will coax it into existence.  Along these
lines I've tried adding this to rc.conf

     # create tun0 device
     if ! ifconfig -l | grep -q tun0 ; then
             echo < /dev/tun0
     fi

Going further, I've also put in an explicit ifconfig_tun0 line, thinking
that this also may make natd happier. ...but still it refuses to start
until _after_ the ppp link is up.  Sigh... it all worked fine and dandy
before the upgrade.

This system is on another continent, so troubleshooting is difficult, to
say the least.  For now I've gotten around the problem by disabling natd in
rc.conf and adding the hack listed below to rc.local to explicitly start
natd after the ppp link is up.  It works nicely, but I'd certainly prefer
the clean solution drive just by the standard natd_enable directive in
rc.conf.

The hack:

     # Start hack as background process
     (
             # where 10.x.x.x is the remote end of the PPP link
             while ! ping -c 1 -t 8 -q 10.x.x.x > /dev/null ; do
             done
             # I've tweaked my rules in rc.firewall to make sure that rule 1900
             # is empty _and_ is the appropriate spot where the divert rule should go
             /sbin/ipfw add 1900 divert natd all from any to any via tun0
             /sbin/natd -n tun0 -f /etc/natd.cf
             echo INTERNET CONNECTION IS NOW ACTIVE | wall
     )&

cno

--
-------------------------------------------------------------------------
  Charles N. Owens                               Email: owensc@enc.edu
                                            http://www.enc.edu/~owensc
  Network & Systems Administrator
  Information Technology Services  "Outside of a dog, a book is a man's
  Eastern Nazarene College         best friend.  Inside of a dog it's
                                   too dark to read." - Groucho Marx
-------------------------------------------------------------------------




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message