XLATE on PIX seems to be messed up

Hi,
I have a PIX with the following config:

63.174.x.x OUTSIDE
172.16.1.x INSIDE
10.200.1.x DMZ

My DNS servers are on the DMZ.. and also have an outside address static
mapped.

I have an alias command taking the OUTSIDE address and mapping it to
it's address on the DMZ (for inside)...

My problem is it seems like the xlate table is getting messed up..
because I'll set people up with:

172.16.1.6 (ip address)
172.16.1.1 (gateway)
10.200.1.2 (dns1)
10.200.1.25 (dns2)

It will work fine for a while.. and then die... they can ping and go by
IP but they can't do DNS resolution.
If I change their DNS to the 63.174.x.x DNS server address (same
machine) it will start working again... for a while.. and then die.. but
if you switch back to the 10.200.1.x address it works fine.
It also seems to start working again if I do a clear xlate.
Any idea on this?

 

:My DNS servers are on the DMZ.. and also have an outside address static
:mapped.

:My problem is it seems like the xlate table is getting messed up..

:It will work fine for a while.. and then die... they can ping and go by
:IP but they can't do DNS resolution.

How are you doing the address translation between your inside interface
and your DMZ?

My first guess would be that you have used a nat (inside) / global (dmz)
pair, but in the global statement, you specified the actual IP address
of the dmz interface instead of using the keyword 'interface'.


Which PIX version are you using? 6.3(1) perchance?

 

static (dmz,inside) 10.200.1.0 10.200.1.0 netmask 255.255.255.0 0 0
static (inside,dmz) 172.16.1.0 172.16.1.0 netmask 255.255.255.0 0 0

I have the following nat and global statements:
global (outside) 1 63.174.244.xx netmask 255.255.255.0 [address masked
here]
global (dmz) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
nat (dmz) 1 0.0.0.0 0.0.0.0 0 0

Cisco PIX Firewall Version 6.2(2)
Cisco PIX Device Manager Version 2.1(1)

Finally I have aliases:
alias (inside) 63.174.244.x 10.200.1.2 255.255.255.255 [again address
masked here in newsgroups]

It will work for a while, then die.. clear xlate or use the other IP
(10.200 or 63.174.. swap back and forth) and it's all good.

 

:> How are you doing the address translation between your inside interface
:> and your DMZ?

:static (dmz,inside) 10.200.1.0 10.200.1.0 netmask 255.255.255.0 0 0

Packets going from a lower security interface to a higher security
interface do not normally have their source IP translated, so that line
is not necessary. It may be interfering, as it is instructing the PIX
to do unusual "reverse nat".


:Cisco PIX Firewall Version 6.2(2)

There are known security problems with that version; upgrading to 6.2(3)
or later is recommended.

 

I think your static statements are a little "off".

If your inside network is 172.16.1.0 and the dmz is 10.200.1.0, I think the
static statement(s) need to show the relationship(s)

e.g. static (inside,dmz) 10.200.1.0, 172.16.1.0 ....

 

:
:> static (dmz,inside) 10.200.1.0 10.200.1.0 netmask 255.255.255.0 0 0
:> static (inside,dmz) 172.16.1.0 172.16.1.0 netmask 255.255.255.0 0 0

:I think your static statements are a little "off".

:If your inside network is 172.16.1.0 and the dmz is 10.200.1.0, I think the
:static statement(s) need to show the relationship(s)

:e.g. static (inside,dmz) 10.200.1.0, 172.16.1.0 ....

Not if you don't -want- address translation to take place.

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/s.htm#wp1026694

and see the section on 'Identity NAT'.