At 05:58 PM 12.13.2003 +0100, Daan Vreeken [PA4DAN] wrote:
>On Saturday 13 December 2003 17:25, Jack L. Stone wrote:
>> Dear list:
>> I manage a remote gateway/nat/router/fw server where it is not convenient
>> for anyone to go downtown to the colo and do reboots.
>> I've managed to do everything here remotely from my own console, including
>> reboots when updating the OS requires it -- that is except when
>> reconfiguring the natd.conf file to add another forwarding service. I can
>> reboot and it comes up okay, but rather would avoid a reboot. BUT, if I try
>> to kill/restart the natd daemon remotely, it kills my SSH session -- no
>> restart of NATD -- cannot log back in and that means a 30-min trip for
>> someone to the colo. That gets old and rather just reboot which is a lot
>> less inconvenient.
>> Obviously, when I do the kill of natd, it disconnects my SSH session and I
>> can't restart the daemon so it can reread the natd.conf file for my
>> changes.
>> I've tried a background script, but that hasn't worked either. Perhaps a
>> second session would stay alive.... either SSH or even a telnet session
>> just for the duration for this event??? Or a better background script...??
>The simple answer is : "a better background script" :)
>I manage a bunch of remote machines and sometimes have to fool around with 
>NATD remotely. When I do this, I make a cron entry that starts 
>/root/ipfw-rescue .
>In there there's something like :
>/sbin/natd -f flush
>/sbin/natd 10000 divert natd all from any to any via xl0
>/sbin/natd 50000 pass all from any to any
>killall -KILL natd
>/sbin/natd -n xl0
>This way the machine will always recover from ipfw or natd tests within 10 
>When loading firewall rules remotely, I direct the output of ipfw to
>to be sure ipfw loads the entire rule set.
>If for example you have a rc.firewall file like this :
>${fwcmd} -f flush
>${fwcmd} add blah blah
>${fwcmd} add blah blah2
>${fwcmd} add 5000 pass all from any to any
>And you start it over SSH with :
>sh /etc/rc.firewall
>You will get locked out because ipfw prints every rule it adds. So after
>-f flush" it will print "ruleset flushed", but packets aren't allowed to 
>travel outside over the SSH connection (since the ruleset is empty) so 
>execution of rc.firewall stops there... :(
>Loading the ruleset like this does work :
>sh /etc/rc.firewall >/dev/null 2>/dev/null
>(Direct both stdout and stderr to /dev/null)
>Alternatively you could direct the output to a log-file so you can verify if 
>anything went wrong. (And don't forget to remove the cron-entry when you're 
>Hope this helps,

Daan & Michael:
Here's a simple script that I cooked up from the tips that works great:

# killnatd

ipfw -ade l | mail -s "Flush Sage-One Firewall" sageame
/bin/sh /etc/rc.sagefw &
killall -KILL natd
/sbin/natd -f /etc/natd.conf -n rl0

Plus, the cron job, just in case, as insurance is an excellent idea for
managing daemons for remotes like this.

Mnay thanks again!

Best regards,
Jack L. Stone,

Sage American
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to