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

In article <bf1641fb.0411160707.6a2179a7@posting.google.com>,
Bruce <mygroupmail@gmail.com> 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. 

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

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