07-30-2008 11:18 AM - edited 03-11-2019 06:23 AM
I have a conection with a costumer to FTP data to a server, but the transfer fail after the "Parent flow is closed" message.
Anyone got any ideas?
09-10-2008 10:52 AM
Ohhh.. :(
tcp fins would mean that both client and server negotiated to close the tcp connection.
It's a normal tcp close down sequence.So,I cannot really say whether it's the client or the server where the problem lies.
Are there any dropped packets ( crc,overruns,underruns,collisions etc. ) on ASA interfaces.
Also,can you capture the relevant packets:
Issue with communication between a client on inside interface and a server on outside interface.
Replace IP addresses appropriately-
access-list cpo permit ip host
access-list cpo permit ip host
capture capo access-list cpo buffer 2000000 packet-length 1518 interface outside
access-list cpi permit ip host
access-list cpi permit ip host
capture capi access-list cpi buffer 2000000 packet-length 1518 interface inside
SRC_IP : This is the original IP address of client from where request is being
generated
XSRC_IP : This is the translated IP address of the inside client. IP address to
which inside client is translated when going outbound.
DST_IP : This is the Destination IP address.
Alternatively, captures on both interfaces can be taken in a single capture file.
access-list cap permit ip host
access-list cap permit ip host
access-list cap permit ip host
access-list cap permit ip host
capture capio access-list cap buffer 2000000 packet-length 1518 interface outside interface inside
To download the captures:
using a maching with ASDM access-
https://interface_IP/capture/capo/pcap
--> save file as outside.cap
(Captures on outside interface)
https://interface_IP/capture/capi/pcap
--> save file as inside.cap
(Captures on inside interface)
https://interface_IP/capture/capio/pcap
--> save file as inout.cap
(Captures on inside and outside interface)
If ASDM is not available, captures can be sent to a TFTP server using following commands-
copy capture:capo tftp://x.x.x.x/outside.cap pcap
(Captures on outside interface of PIX, capture file will be saved as "outside.cap")
copy capture:capi tftp://x.x.x.x/inside.cap pcap
(Captures on outside interface of PIX, capture file will be saved as "inside.cap")
copy capture:capio tftp://x.x.x.x/inout.cap pcap
(Captures on inside and outside interface of PIX, capture file will be saved as "inout.cap")
x.x.x.x : IP address of TFTP server.
Regards,
Sushil
09-10-2008 11:57 AM
Thank you for the reply. It seems I've got some work to do. :)
Thanks again for your assistance with this.
09-10-2008 08:01 AM
====================
SFTP - FTP over SSH:
====================
SFTP (SSH File Transfer Protocol), sometimes called Secure File Transfer
Protocol is a network protocol that provides file transfer and
manipulation functionality over any reliable data stream. It is
typically used with version two of the SSH protocol (TCP port 22) to
provide secure file transfer.
SFTP is **not** FTP run over SSH, but rather a new protocol designed
from the ground up by the IETF SECSH working group. The protocol is not
yet an Internet standard.
Port used: 22(TCP)
Firewall Perspective of SFTP-
-----------------------------
Now, this is a firewall friendly stuff, reason being, all communication
is happening over port 22 (TCP). Hence, depending on setup, don't need
to configure much on firewall-
Server----I(ASA)O----client
Server inside, client outside, normally, need to have static mapping for
the server and open port 22 to the server's mapped IP for traffic to
flow through.
client----I(ASA)O----Server
Client inside, server outside, just need to open outbound access and
client should be able to access SFTP server.
FTP Inspection required: NO (Not a FTP protocol).
....contd. in the next post....
09-10-2008 08:01 AM
====================
FTPS - FTP over SSL:
====================
FTPS (S after FTP) is a super-set of the same FTP protocol, as it allows
for encryption of the connection over an SSL/TLS encrypted socket. There
are two modes this can be achieved-
i> Implicit FTPS
ii> Explicit FTPS
FTPS as a whole is not firewall friendly, refer to following scenarios
to understand why.
------------------
(I) Implicit FTPS-
------------------
In Implicit FTPS, basically it is a SSL encrypting socket wrapped around
the entire communication from the point of connection initiation. To
separate this from normal FTP, IFTPS was assigned a standard port
990(TCP), compared to normal FTP which uses 21(TCP). Note that this mode
is far less common than the explicit mode.
-> Inbound IFTPS Scenarios:
Server----I(ASA)O----client
a) Inbound Implicit FTPS, Passive Client [####FAILS####]
Client connects to server's public IP on port 990, authenticates over
TLS (AUTH command). After authentication for data protection, client
uses command PROT. After this client enters passive mode using PASV
command. When server receives PASV command, it generates a message in
which client is informed about the port it needs to connect to for data
transfer. However, server uses its own private IP address in the
communication and because this goes over encrypted session, firewall
cannot modify/translate the payload to the public IP of server. Hence,
client receives private IP address of the server and is unable to
connect for data connection.
Inspection Required: No, will not help anyways.
Can we make this work through ASA: No (Opening all the ports to the
server will not make this work).
Workaround: Use Active client, see below.
b) Inbound Implicit FTPS, Active Client [####WORKS####]
Client connects to server public IP on port 990, authenticates over TLS
(AUTH). After authentication for data protection uses command PROT, then
client sends a PORT command over the encrypted session. Server
calculates the port to which it needs to connect to the client and
initiates the connection to the port from source-port TCP/989
(ftps-data), in normal FTP port TCP/20 (ftp-data). Outbound connection
works fine because, by default outbound traffic is permitted on ASA.
Inspection Required: No.
contd..........
09-10-2008 08:03 AM
-> Outbound IFTPS Scenarios:
client----I(ASA)O----Server
a) Outbound Implicit FTPS, Active Client [####FAILS####]
Client connects to server public IP on port 990, authenticates over
TLS(AUTH). After authentication for data protection uses command PROT,
then client sends a PORT command over the encrypted session. However,
because this PORT command is being sent over encrypted session, server
receives a Private IP address of the Client. Due to this, server is
unable to initiate data connection to the Client and FTP fails.
Inspection Required: No, will not help anyways.
Can we make this work through ASA: No (Opening all the ports to the
server will not make this work).
Workaround: Use Active client, see below.
b) Outbound Implicit FTPS, Passive Client [####WORKS####]
Client connects to server public IP on port 990, authenticates over
TLS(AUTH). After authentication for data protection uses command PROT.
After this client enters passive mode using PASV command. When server
receives PASV command, it generates a message in which client is
informed about the port it needs to connect to for data transfer. Client
calculates this port and initiates a outbound connection on this new
port and establishes SSL connection for data transfer. As this is an
outbound connection, everything works fine.
Inspection Required: No.
-------------------
(II) Explicit FTPS-
-------------------
Soon after FTPS was in use some smart people decided it would be best if
we could have an FTP server that could support unencrypted as well as
encrypted connections, and do it all over the same port. To accommodate
this the "explicit" FTPS protocol connection begins as a normal
unencrypted FTP session over FTP's standard port 21. The client then
explicitly informs the server that it wants to encrypt the connection by
sending an "AUTH TLS" command to the server. At that point the
FTPS-enabled server and the client begin the SSL or TLS handshake and
further communications happen encrypted. Note that most (if not all)
explicit FTPS servers can be optionally configured to require
encryption, so it will deny clients that attempt to transfer data
unencrypted. Often this can be configured on a user by user basis.
09-10-2008 08:03 AM
-> Inbound EFTPS Scenarios:
Server----I(ASA)O----client
a) Inbound Explicit FTPS, Passive Client [####FAILS####]
Client connects to server public IP on port 21, authenticates over
TLS(AUTH). After authentication for data protection uses command PROT.
After this client enters passive mode using PASV command. When server
receives PASV command, it generates a message in which client is
informed about the port it needs to connect to for data transfer.
However, server uses its own private IP address in the communication and
because this goes over encrypted session, firewall cannot
modify/translate the payload to the public IP of server. Hence, client
receives private IP address of the sever and is unable to connect for
data connection.
Can we make this work through ASA: Yes. See details below-
If client in this scenario are capable of using CCC (Clear channel
command), the FTP client connects to the server, negotiates a secure
connection, authenticates (sends user and password) and reverts back to
plaintext(control-channel). Next, enable FTP inspection. Now, when
server responds with the port client needs to connect to, firewall would
be able to intercept it and translate IP address in payload and also
open the connection accordingly.
Note: Not all FTP clients/servers might support CCC command.
Inspection Required: Yes, along with CCC command from client.
Workaround: See above.
b) Inbound Explicit FTPS, Active Client [####WORKS####]
Client connects to server public IP on port 21, authenticates over
TLS(AUTH). After authentication for protection uses command PROT, then
client sends a PORT command over the encrypted session. Server
calculates the port to which it needs to connect to the client and
initiates the connection to the port from source-port 20 (ftp-data).
Outbound connection works fine because, by default outbound traffic is
permitted on ASA.
Inspection Required: No.
09-10-2008 08:03 AM
-> Outbound EFTPS Scenarios:
client----I(ASA)O----Server
a) Outbound Explicit FTPS, Active Client [####FAILS####]
Client connects to server public IP on port 21, authenticates over TLS.
After authentication for protection uses command PROT P, then client
sends a PORT command over the encrypted session. However, because this
PORT command is being sent over encrypted session, server receives a
Private IP address of the Client. Due to this, server is unable to
initiate data connection to the Client and FTP fails.
Can we make this work through ASA: Yes, see explanation of workaround
for "Inbound Explicit FTPS, Passive Client"
Inspection Required: See "Inbound Explicit FTPS, Passive Client"
Workaround: See "Inbound Explicit FTPS, Passive Client"
b) Outbound Explicit FTPS, Passive Client [####WORKS####]
Client connects to server public IP on port 21, authenticates over TLS.
After authentication for protection uses command PROT P. After this
client enters passive mode using PASV command. When server receives PASV
command, it generates a message in which client is informed about the
port it needs to connect to for data transfer. Client calculates this
port and initiates a outbound connection on this new port and
establishes SSL connection for data transfer. As this is an outbound
connection, everything works fine.
Inspection Required: No.
For more details about FTP AUTH, PROT, PBSZ, and CCC commands, refer to
following link:
http://tools.ietf.org/html/rfc2228
##############
#############
If the above does not resolve issue,check client and server...issue is there.........>>>
Regards,
Sushil
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide