From nobody@FreeBSD.org  Fri Sep 14 01:03:53 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 3C43A37B407
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 14 Sep 2001 01:03:49 -0700 (PDT)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.4/8.11.4) id f8E83nn14612;
	Fri, 14 Sep 2001 01:03:49 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200109140803.f8E83nn14612@freefall.freebsd.org>
Date: Fri, 14 Sep 2001 01:03:49 -0700 (PDT)
From: Bill Daniel <vlaad@baldfewls.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Error handling by natd causes all communications to cease when ambiguous statement exists in natd.conf making remote administration to fix impossible.
X-Send-Pr-Version: www-1.0

>Number:         30571
>Category:       misc
>Synopsis:       Error handling by natd causes all communications to cease when ambiguous statement exists in natd.conf making remote administration to fix impossible.
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 14 01:10:00 PDT 2001
>Closed-Date:    Tue Sep 25 07:12:52 PDT 2001
>Last-Modified:  Tue Sep 25 07:19:59 PDT 2001
>Originator:     Bill Daniel
>Release:        4.4-RC
>Organization:
Texas Metropolitan Services
>Environment:
FreeBSD firewall.cargoven.com 4.4-RC FreeBSD 4.4-RC #0: Fri Sep 14 01:02:23 CDT
2001     root@firewall.cargoven.com:/usr/src/sys/compile/cargoven  i386
>Description:
I made a typo in the natd.conf... the obvious solution is to not make typos in natd.conf... however..
The error caused all communications to the unit to cease.. i couldn't get to it internally (via a local user) or externally... 
The only reason this is a major problem is that remote administration of the box becomes impossible at this point... so there's no way to fix it without user intervention..  considering this box was across town at 2am my time.... (ugh)

I had just installed a new kernel is why the reboot was necessary..
not to mention the fact that killing the natd remotely (even on the external ip) causes my connection to lock and the box to stop responding.. entering into a no-communication state once again..


Luckily i had an engineer onsite to walk through a boot into the .GENERIC so that I could get in to see what I did wrong... that is, of course, a rareity to not only myself (I support over 50 boxes remotely all running fbsd - some in other cities that would be impossible for me to go to) but I suspect for many other people.


>How-To-Repeat:
do something like this in /etc/natd.conf:
redirec_port tcp 192.168.2.200:80 80

------------------------------------------------
reboot
------------------------------------------------
attempt any communication to the box that isn't console

>Fix:
My suggestion would be to either abort loading natd on ambiguous statements in the .conf file or to simply ignore the ambiguous statement.

My preference, being security minded, would be to simply abort loading the natd at all when an ambiguous statement is found. and hopefully this would make a *lot* of "noise" via syslog :)


>Release-Note:
>Audit-Trail:

From: Peter Pentchev <roam@ringlet.net>
To: Bill Daniel <vlaad@baldfewls.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/30571: Error handling by natd causes all communications to cease when ambiguous statement exists in natd.conf making remote administration to fix impossible.
Date: Fri, 14 Sep 2001 11:42:28 +0300

 On Fri, Sep 14, 2001 at 01:03:49AM -0700, Bill Daniel wrote:
 > 
 > >Number:         30571
 > >Category:       misc
 > >Synopsis:       Error handling by natd causes all communications to cease when ambiguous statement exists in natd.conf making remote administration to fix impossible.
 > >Originator:     Bill Daniel
 > >Release:        4.4-RC
 > >Organization:
 > Texas Metropolitan Services
 > >Environment:
 > FreeBSD firewall.cargoven.com 4.4-RC FreeBSD 4.4-RC #0: Fri Sep 14 01:02:23 CDT
 > 2001     root@firewall.cargoven.com:/usr/src/sys/compile/cargoven  i386
 > >Description:
 > I made a typo in the natd.conf... the obvious solution is to not make typos in natd.conf... however..
 > The error caused all communications to the unit to cease.. i couldn't get to it internally (via a local user) or externally... 
 [snip]
 > >Fix:
 > My suggestion would be to either abort loading natd on ambiguous statements in the .conf file or to simply ignore the ambiguous statement.
 > 
 > My preference, being security minded, would be to simply abort loading the natd at all when an ambiguous statement is found. and hopefully this would make a *lot* of "noise" via syslog :)
 
 How about another solution - have natd(8) grow an Apache-like 'configtest'
 mode, so it only parses the config file without actually doing anything?
 
 G'luck,
 Peter
 
 -- 
 When you are not looking at it, this sentence is in Spanish.

From: Bill Fumerola <billf@mu.org>
To: Bill Daniel <vlaad@baldfewls.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/30571: Error handling by natd causes all communications to cease when ambiguous statement exists in natd.conf making remote administration to fix impossible.
Date: Fri, 14 Sep 2001 05:32:56 -0500

 On Fri, Sep 14, 2001 at 01:03:49AM -0700, Bill Daniel wrote:
 
 > My preference, being security minded, would be to simply abort loading the natd
 > at all when an ambiguous statement is found. and hopefully this would make a
 > *lot* of "noise" via syslog :)
 
 you're diverting all your traffic to a divert socket that isn't being
 serviced by any process. you're diverting it because the ipfw rule is
 still there. no process is servicing it because natd "simply abort[ed]
 loading".
 
 so I'm unclear where a problem is, other then in your ability to check
 config files twice before pushing the magic button to reboot.
 
 useful thing to do: in natd.c change the warnx() call in ParseOption()
 to a Warn() call, to make your requested noise. you won't see the noise
 because you have no connectivity....
 
 -- 
 - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org
 
 
 ps. why are you rebooting for natd changes anyways?
 pps. serial consoles / out of band are cheaper and quicker then remote hands.
State-Changed-From-To: open->closed 
State-Changed-By: ru 
State-Changed-When: Tue Sep 25 07:12:52 PDT 2001 
State-Changed-Why:  
As Bill pointed out, the problem is that there's no process 
listening on the divert port "natd".  There is nothing wrong 
with natd(8)'s error handling. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=30571 
>Unformatted:
