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

  2. In article <>,
    Bruce <> wrote:
    :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.
    --
    Those were borogoves and the momerathsoutgrabe completely mimsy.
    Walter Roberson, Nov 16, 2004
    #2
    1. Advertising

  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

    Bruce wrote:
    > 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


    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"


    > 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


    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.

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


    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

    > ....
    > access-group inlist in interface outside
    > access-group outlist in interface inside
    > ....


    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.

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



    --
    -------------------------
    Paul Stewart
    Lexnet Inc.
    Email address is in ROT13
    PES, Nov 18, 2004
    #4
  5. Bruce

    PES Guest

    PES wrote:
    > Bruce wrote:
    >
    >> 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

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

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

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


    I am incorrect on this. I think you are correct here.

    >
    >> ....
    >> access-group inlist in interface outside
    >> access-group outlist in interface inside
    >> ....

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

    >
    >
    >



    --
    -------------------------
    Paul Stewart
    Lexnet Inc.
    Email address is in ROT13
    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
    > >
    > >
    > > 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"


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

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    1,194
    Digital Photography Now
    Oct 4, 2005
  2. Replies:
    2
    Views:
    14,494
    milkboy33
    Apr 17, 2012
  3. Replies:
    16
    Views:
    19,300
    javijavi
    May 5, 2009
  4. M
    Replies:
    3
    Views:
    4,353
    Matthew Melbourne
    Mar 5, 2009
  5. Sam Wilson
    Replies:
    0
    Views:
    867
    Sam Wilson
    Oct 18, 2012
Loading...

Share This Page