XLATE on PIX seems to be messed up

Discussion in 'Cisco' started by Matt, May 10, 2004.

  1. Matt

    Matt Guest

    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?
     
    Matt, May 10, 2004
    #1
    1. Advertisements

  2. :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?
     
    Walter Roberson, May 10, 2004
    #2
    1. Advertisements

  3. Matt

    Matt Guest

    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.
     
    Matt, May 10, 2004
    #3
  4. :> 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.
     
    Walter Roberson, May 10, 2004
    #4
  5. Matt

    S. Gione Guest

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


     
    S. Gione, May 11, 2004
    #5
  6. :
    :> 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'.
     
    Walter Roberson, May 11, 2004
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.