Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Sep 2001 01:03:49 -0700 (PDT)
From:      Bill Daniel <vlaad@baldfewls.net>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   misc/30571: Error handling by natd causes all communications to cease when ambiguous statement exists in natd.conf making remote administration to fix impossible.
Message-ID:  <200109140803.f8E83nn14612@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>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:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 14 01:10:00 PDT 2001
>Closed-Date:
>Last-Modified:
>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:
>Unformatted:

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?200109140803.f8E83nn14612>