Translation Creation Failed

Discussion in 'Cisco' started by Bruce, Nov 16, 2004.

  1. Bruce

    Bruce Guest

    I am having a problem with a secure FTP server. I have a secure FTP
    server (SFTP) in my DMZ on a PIX 515E. I am able to connect to it
    from the Internet successfully using passive mode without any problem.
    However, I cannot connect to it from my internal network.

    The SFTP server is a WS-FTP server and has the firewall options set to
    send back to a passive client the Internet IP address and a range of
    ports (5100-5300) for connection. Having opened ports 5100-5300
    through the firewall to the SFTP server, connection from the Internet
    works fine. However, when using a passive client from the internal
    network I cannot connect. I cannot use active because I use ingress
    filtering from the DMZ into my internal network. And I did open the
    same ports from my internal into the DMZ.

    What I found in the syslog when trying to connect from the internal
    network to the SFTP in the DMZ is the following translation error:

    %PIX-3-305006: regular translation creation failed for tcp src
    inside:192.168.113.104/2685 dst dmz:66.193.18.58/21

    I don't understand how to fix this. Yes, I've read the Cisco
    documentation on this error message, but it hasn't provided me with
    the insight I need to understand the underlying problem. The host
    address is not a network or broadcast address, and the NAT / Static
    does not overlap anything as far as I can see.

    Below are what I believe to be the pertinent lines from my config -
    any help or pointers would be greatly appreciated:


    PIX Version 6.3(3)
    .....
    nameif ethernet0 outside security0
    nameif ethernet1 inside security100
    nameif ethernet2 dmz security10
    .....
    fixup protocol ftp 21
    .....
    access-list inlist permit tcp any host 1.2.3.58 eq ftp
    access-list inlist permit tcp any host 1.2.3.58 range 5100 5300
    .....
    access-list outlist permit tcp any host 1.2.3.58 eq ftp
    access-list outlist permit tcp any host 1.2.3.58 range 5100 5300
    .....
    access-list nonat permit ip 192.168.0.0 255.255.0.0 10.10.10.96
    255.255.255.224
    .....
    ip address dmz 10.10.10.97 255.255.255.224
    .....
    global (outside) 1 interface
    nat (inside) 0 access-list nonat
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    nat (dmz) 0 access-list nonat
    nat (dmz) 1 0.0.0.0 0.0.0.0 0 0
    .....
    static (dmz,outside) 1.2.3.58 10.10.10.125 netmask 255.255.255.255 0 0
    static (dmz,inside) 1.2.3.58 10.10.10.125 netmask 255.255.255.255 0 0
    .....
    access-group inlist in interface outside
    access-group outlist in interface inside
    .....


    A few notes:
    - I am using the external address to access the DMZ SFTP server even
    from the inside, because in passive mode the server sends back the
    external IP address to the client as the IP to connect to. That's how
    passive mode works, and the server does not have a way to
    differentiate between clients (i.e. send one IP for external clients,
    another IP for internal clients).
    - I will not use active mode for my internal clients because I will
    not open up ~65000 ports from the DMZ into my internal network.
    - I do not want to NAT connections from my internal network into the
    DMZ for logging reasons on my DMZ servers.
    - Internal network = 192.168.0.0/16
    - DMZ network = 10.10.10.96/27
    - Outside SFTP address = 1.2.3.58
     
    Bruce, Nov 16, 2004
    #1
    1. Advertisements

  2. :I am having a problem with a secure FTP server. I have a secure FTP
    :server (SFTP) in my DMZ on a PIX 515E. I am able to connect to it
    :from the Internet successfully using passive mode without any problem.
    : However, I cannot connect to it from my internal network.

    :%PIX-3-305006: regular translation creation failed for tcp src
    :inside:192.168.113.104/2685 dst dmz:66.193.18.58/21

    :pIX Version 6.3(3)

    :access-list nonat permit ip 192.168.0.0 255.255.0.0 10.10.10.96 255.255.255.224

    :ip address dmz 10.10.10.97 255.255.255.224

    :global (outside) 1 interface
    :nat (inside) 0 access-list nonat

    Okay, so data sourced from 192.168.0.0 goes to 10.10.10.96-127 without
    address changes.

    :nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    :nat (dmz) 0 access-list nonat

    Small problem there. Never re-use an access-list that is used for
    access control, as the PIX might be manipulating it internally
    to provide Adaptive Security.

    :nat (dmz) 1 0.0.0.0 0.0.0.0 0 0


    :- I am using the external address to access the DMZ SFTP server even
    :from the inside, because in passive mode the server sends back the
    :external IP address to the client as the IP to connect to.

    But when you do that, use the external address, you aren't using
    a destination address that is covered by your 'nonat' access list.
    Therefore the nat 0 access-list does not apply and you fall back
    to the nat (inside) 1 statement. You then fail to have a corresponding
    global (dmz) 1 statement, so the PIX doesn't know how to translate
    IPs as they go from the higher security level 'inside' to the lower
    security level 'dmz', and that's why you get the translation creation
    failed.

    :- I will not use active mode for my internal clients because I will
    :not open up ~65000 ports from the DMZ into my internal network.

    ??? You don't need to. 'fixup ftp 21' handles that all transparently.
     
    Walter Roberson, Nov 16, 2004
    #2
    1. Advertisements

  3. Bruce

    Bruce Guest

    Robert,

    Thanks for the assistance, but I wasn't able to make this work. When
    I add the line:

    access-list nonat permit ip 192.168.0.0 255.255.0.0 host 1.2.3.58

    ....the translation error does in fact go away, but now I get a routing
    error on the firewall:

    %PIX-6-110001: No route to 192.168.113.104 from 1.2.3.58

    Interesting since the firewall has the routes to both of these
    networks.

    Any more thoughts?

    As a sidenote, the 'fixup ftp 21' command does not work in this
    scenario - since this is a secure FTP server, the PIX cannot
    dynamically open the ports since the packets are encrypted.

    Also, I don't understand your statement about not re-using an
    access-list that is used for access control when referring to my
    'nonat' access-list. As I understand it, the 'nat 0' is only used for
    NAT exemptions - therefore I'm not using it for access control. Or
    are you saying that I should have different NAT exemption lists (nat
    0) for different interfaces rather then combining the lists?

    Thanks again!
     
    Bruce, Nov 17, 2004
    #3
  4. Bruce

    PES Guest

    I think the above nonat should actually be
    access-list nonat permit 192.168.0.0 255.255.0.0 1.2.3.58
    255.255.255.255 "or similar"

    Just for clarity, the above two lines should not affect the
    configureation. Also, since the nonat is only to exclude nat, I don't
    think it is processed or modified by the asa. However, I doubt that the
    same nonat statement should be on two interfaces.
    I think the above line should be removed and replaced with

    static (dmz,inside) 1.2.3.58 1.2.3.58 netmask 255.255.255.255
    You also may need to create the following

    access-list dmzlist permit tcp host 1.2.3.58 eq ftp any
    access-list dmzlist permit tcp host 1.2.3.58 range 5100 5300 <ipaddr>

    access-group dmzlist in interface dmz

    The above may not be not be exactly correct. However, if the ftp server
    starts a connection back inbound, you will have to permit it unless the
    ftp fixup is intelligent enough to understand without. Since it is
    secure ftp I doubt it is. Since it is passive, it may not be required.
    I am a bit unfamiliar with sftp I would recommend looking at it with
    ethereal.
     
    PES, Nov 18, 2004
    #4
  5. Bruce

    PES Guest

    I am incorrect on this. I think you are correct here.
     
    PES, Nov 18, 2004
    #5
  6. Bruce

    Bruce Guest

    access-list nonat permit ip 192.168.0.0 255.255.0.0 10.10.10.96
    Paul, thanks so much! That was the trick - I simply needed to add a
    NAT exclusion into my access-list for my inside network to reach the
    external IP of the secure FTP server (I still needed the other line to
    reach my DMZ addresses without NAT for logging purposes - so I simply
    added the "nonat" line you proposed).

    Here's a funny thing though that I didn't put in my original post. I
    put this scenario through my test environment first, and it worked
    perfectly fine without the NAT exclusion. I've gone back and verifed
    that everything is set the same, and it is. There's only one
    difference I can see - my test PIX has version 6.3.4, while my
    production PIX has version 6.3.3. Dunno if there's some variation in
    how the versions handle this or what. I'll explore the versioning
    difference sometime in the future, but for now, your help has allowed
    me to get this into production.

    Thanks again!
    - Bruce
     
    Bruce, Nov 18, 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.