[c-nsp] FWSM v2.3.3 NAT issue

[Brett Looney]

Christian,

At 19:34 28/12/2005, you wrote:
> >       global (INSIDE) 1 1.2.3.4
> >       nat (OUTSIDE) 0 access-list NONAT-OUTSIDE outside
> >       nat (OUTSIDE) 1 access-list NAT-OUTSIDE outside
> >
> >Connections from the outside interface used to appear to come from
> >1.2.3.4 for hosts on the inside. Now they don't - they appear to come
> >from the originator's real IP address.
>
>I never used outside dynamic NAT, so my suggestions are more generic.
>
>Does a 'show xlate' marks the connections in question as 'Outside'?

Yup.

>Are there any static statements 'nat x access-list' would collide with
>(static (outside,inside)) or static statements for your inside hosts
>(static (inside,outside)) configured? The last one would be necessary,
>for outside NAT IIRC, even if it is only static identity NAT translating
>inside hosts to the same addresses.

No, the config looks fine - and it was working previously, it's only 
broken on this version of software.

>If you can afford loosing all established connections, try a 'clear
>xlate'. Then try to initiate communication from an outside hosts and
>look at the xlate table. This eliminates the influence of existing
>xlate entries from connections initiated at the inside.

Well, we had to get to an outage window to do the "clear xlate" but 
it made no difference. Logs have been sent to the TAC.

As a side note, one of the most annoying things about the PIX/FWSM is 
that cisco *recommends* that you do a "clear xlate" after changing 
any NAT rules or anything associated with them. That's just crazy - 
it drops all of the user sessions running through the box - and in 
this case the customer is a 24x7x365 operation - getting a window to 
do a "clear xlate" is next to impossible. Surely the software can be 
smart enough to figure out what to clear without dropping all the 
sessions. Bah! ;-)

B.