Bug 30571

Summary:	Error handling by natd causes all communications to cease when ambiguous statement exists in natd.conf making remote administration to fix impossible.
Product:	Base System	Reporter:	Bill Daniel <vlaad>
Component:	misc	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description Bill Daniel 2001-09-14 09:10:00 UTC

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.

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-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

Comment 1 Peter Pentchev 2001-09-14 09:42:28 UTC

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.

Comment 2 billf 2001-09-14 11:32:56 UTC

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.

Comment 3 ru freebsd_committer

2001-09-25 15:12:52 UTC

State Changed
From-To: open->closed

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.