Date: Sat, 13 Dec 2003 17:58:43 +0100 From: "Daan Vreeken [PA4DAN]" <Danovitsch@Vitsch.net> To: "Jack L. Stone" <jacks@sage-american.com> Cc: FreeBSD-questions@FreeBSD.org Subject: Re: NATD config remote management Message-ID: <200312131758.43647.Danovitsch@Vitsch.net> In-Reply-To: <3.0.5.32.20031213105415.014c2010@10.0.0.15> References: <3.0.5.32.20031213105415.014c2010@10.0.0.15>
next in thread | previous in thread | raw e-mail | index | archive | help
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 convenie=
nt
> for anyone to go downtown to the colo and do reboots.
>
> I've managed to do everything here remotely from my own console, includ=
ing
> reboots when updating the OS requires it -- that is except when
> reconfiguring the natd.conf file to add another forwarding service. I c=
an
> 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 lo=
t
> less inconvenient.
>
> Obviously, when I do the kill of natd, it disconnects my SSH session an=
d 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..=
=2E??
The simple answer is : "a better background script" :)
I manage a bunch of remote machines and sometimes have to fool around wit=
h=20
NATD remotely. When I do this, I make a cron entry that starts=20
/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 1=
0=20
minutes.
When loading firewall rules remotely, I direct the output of ipfw to /dev=
/null=20
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=20
-f flush" it will print "ruleset flushed", but packets aren't allowed to=20
travel outside over the SSH connection (since the ruleset is empty) so=20
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=20
anything went wrong. (And don't forget to remove the cron-entry when you'=
re=20
done)
Hope this helps,
Daan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200312131758.43647.Danovitsch>