NATD config remote management

[Daan Vreeken [PA4DAN]]

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

When loading firewall rules remotely, I direct the output of ipfw to /dev/null 
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 "ipfw 
-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 
done)

Hope this helps,
Daan