Speaking of PIX Translation Problems... [7:72573]

2003-07-18 Thread John Neiberger
I thought I'd share an embarrassing moment from yesterday in hopes that
others will learn from my mistake.

I have a router on the outside of a firewall that needed to be upgraded
after the advisory yesterday. In order to reach the TFTP server I needed to
add a static translation in the PIX. No problem. I should also mention that
this server is one of our internal DNS servers.  

The file transfer doesn't take long at all and I remove the conduit and
static translation from the PIX as soon as I'm done. As far as I'm concerned
this is the end of it. I was wrong.

We later start receiving reports that certain web pages have become
inaccessible, while others are still responding. My first thought is that
I've hosed something with the IOS upgrade, but after checking things out I
was satisfied that everything there was working properly. So, I check the
firewall logs which leads me to check the xlate table. Lo and behold, the
static translation that I'd previously added--and removed--is still there!  
[I hear knowing laughter already.]  It's in the table but somehow traffic is
being hosed. Our DNS server is sending queries to our external server and
replies are coming back, but something is wrong and communications continue
to fail. I clear the xlate table and all is immediately fixed. This caused a
fair amount of irritation with me but my boss was even more irritated.

I presumed this was a 'feature' or a bug because it was my _assumption_ that
the removal of the static translation from the config would also clear it
from the xlate table. Wrong! I looked up the command on CCO and there is
this little tidbit:

"Usage Guidelines 

The clear xlate command clears the contents of the translation slots.
("xlate" means translation slot.) The show xlate command displays the
contents of only the translation slots. 

Translation slots can persist after key changes have been made. Always use
the clear xlate command after adding, changing, or removing the aaa-server,
access-list, alias, conduit, global, nat, route, or static commands in your
configuration."

So, there are two morals to this story. First, don't get into the habit of
making assumptions about commands that you think you're familiar with,
because there may be unforeseen consequences. Second, don't get into the
habit of making changes to critical production equipment even when you think
those changes are insignificant.

Of course, I'll continue to make what I think are insignificant changes but
I'm going to be a lot more careful in the future. 

Let that be a lesson to you,
John




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=72573&t=72573
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]


Re: Speaking of PIX Translation Problems... [7:72573]

2003-07-18 Thread Robert Edmonds
John,
That's not so bad.  I have been aware of that fact for quite some time, but
still continue to forget to issue a clear xlate about half the time.  So
which is worse, ignorance or stupidity?

Robert

""John Neiberger""  wrote in message
news:[EMAIL PROTECTED]
> I thought I'd share an embarrassing moment from yesterday in hopes that
> others will learn from my mistake.
>
> I have a router on the outside of a firewall that needed to be upgraded
> after the advisory yesterday. In order to reach the TFTP server I needed
to
> add a static translation in the PIX. No problem. I should also mention
that
> this server is one of our internal DNS servers.
>
> The file transfer doesn't take long at all and I remove the conduit and
> static translation from the PIX as soon as I'm done. As far as I'm
concerned
> this is the end of it. I was wrong.
>
> We later start receiving reports that certain web pages have become
> inaccessible, while others are still responding. My first thought is that
> I've hosed something with the IOS upgrade, but after checking things out I
> was satisfied that everything there was working properly. So, I check the
> firewall logs which leads me to check the xlate table. Lo and behold, the
> static translation that I'd previously added--and removed--is still there!
> [I hear knowing laughter already.]  It's in the table but somehow traffic
is
> being hosed. Our DNS server is sending queries to our external server and
> replies are coming back, but something is wrong and communications
continue
> to fail. I clear the xlate table and all is immediately fixed. This caused
a
> fair amount of irritation with me but my boss was even more irritated.
>
> I presumed this was a 'feature' or a bug because it was my _assumption_
that
> the removal of the static translation from the config would also clear it
> from the xlate table. Wrong! I looked up the command on CCO and there is
> this little tidbit:
>
> "Usage Guidelines
>
> The clear xlate command clears the contents of the translation slots.
> ("xlate" means translation slot.) The show xlate command displays the
> contents of only the translation slots.
>
> Translation slots can persist after key changes have been made. Always use
> the clear xlate command after adding, changing, or removing the
aaa-server,
> access-list, alias, conduit, global, nat, route, or static commands in
your
> configuration."
>
> So, there are two morals to this story. First, don't get into the habit of
> making assumptions about commands that you think you're familiar with,
> because there may be unforeseen consequences. Second, don't get into the
> habit of making changes to critical production equipment even when you
think
> those changes are insignificant.
>
> Of course, I'll continue to make what I think are insignificant changes
but
> I'm going to be a lot more careful in the future.
>
> Let that be a lesson to you,
> John




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=72579&t=72573
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]