FTP fail accross ASA-5550 - Parent flow is closed message

Unanswered Question
Jul 30th, 2008
User Badges:

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
dentt Wed, 07/30/2008 - 12:18
User Badges:

Do you have FTP inspection turned on?

dentt Thu, 07/31/2008 - 13:57
User Badges:

I would also issue a "clear asp drop" command in Priv-exec mode. Then start an FTP session and wait for the failure. Issue the "show asp drop" command and paste the output.


When the parent flow of a subordinating flow is closed, the subordinating flow is also closed. For example, an FTP data flow (subordinating flow) will be closed with this specific reason when its control flow (parent flow) is terminated. This reason is also given when a secondary flow (pin-hole) is closed by its controlling application. For example, when the BYE messaged is received, the SIP inspection engine (controlling application) will close the corresponding SIP RTP flows (secondary flow).

fjmendonca Tue, 08/05/2008 - 10:20
User Badges:

We are using Passive FTP.

The transmission starts and after 4400 bytes ends with the "Parent flow is closed" message.

robertson.michael Tue, 08/05/2008 - 12:01
User Badges:
  • Silver, 250 points or more

Hi,


Try configuring a syslog server at level 6 to find out why the parent flow is being torn down. The message you want to watch out for is 302014. This message will give a specific reason for why the control channel is being torn down (i.e. resets, timeout, inspection, etc.) This will help identify the root cause of the issue.


-Mike

fjmendonca Thu, 08/07/2008 - 18:24
User Badges:

Hi,


I do a "clear asp drop" command and start an FTP session and wait for the failure then I do "show asp drop" command.

The result is in the attached file.



I'm curious about the outcome of this thread. I'm experiencing a very similar issue wherein uploads to an Internet FTP server fail from a LAN client. What I find from the logs is that the FTP server, from the Outside interface, is denied FTP commands back to the LAN client; even though FTP Inspect is enabled. Can someone continue the explanation, and diagnostic process, for the show asp drop command?


Thanks

suschoud Wed, 09/10/2008 - 08:00
User Badges:
  • Gold, 750 points or more

ALL YOU EVER WANTED TO KNOW ABOUT FTP AND ASA HANDLING FTP :



Various FTP forms:

1) Normal FTP

2) SFTP - SSH File Transfer Protocol

3) FTPS - FTP over SSL

i> Implicit FTPS

ii> Explicit FTPS


//// It has been assumed that FTP inspection is disabled on ASA in

scenarios below. ////


===========

Normal FTP:

===========


File Transfer Protocol (FTP) is a network protocol used to transfer data

from one computer to another through a network, such as the Internet.


-> Inbound FTP Scenarios:


Server----I(ASA)O----client


a) Passive Client [####FAILS####]


Client connects to server's public IP on port 21, authenticates. 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 firewall is

not doing FTP inspection, it will not 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.


Solution: Enable FTP inspection.


b) Active Client [####WORKS####]


Client connects to server public IP on port 21, authenticates. Then

client sends a PORT command. Server calculates the port to which it

needs to connect to the client and initiates the connection to the port

from source-port TCP/20 (ftp-data). Outbound connection works fine

because, by default outbound traffic is permitted on ASA.


FTP Inspection required: NO.


-> Outbound FTP Scenarios:


client----I(ASA)O----Server


a) Active Client [####FAILS####]


Client connects to server public IP on port 21, authenticates. Then

client sends a PORT command. However, PORT command is being sent using

clients private IP address and because firewall is not doing FTP

inspection, it will not modify/translate the payload to the public IP of

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


Solution: Enable FTP inspection.


b) Passive Client [####WORKS####]


Client connects to server public IP on port 21, authenticates. 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.


FTP Inspection required: NO.


Refer to following link for detailed explanation of Active/Passive FTP:


http://slacksite.com/other/ftp.html





check the next post..........

Thanks! I've read through each post and find that in the option b) Passive Client [####WORKS####] FTP Inspection Required: NO scenario this applies to my configuration. Since we have FTP Inspect enabled to allow Internet customers access to FTP servers inbound (NAT to servers on the Inside Interface), then our Pasv clients on the LAN should be able to access Internet based FTP servers and perform Uploads and downloads Ad Nauseum. However, since the Uploads and Downloads fail (for LAN based clients on the Inside Interface to Internet based FTP servers on the Outside interface) and logging shows “Parent flow is closed”, or “Deny TCP no connection” from the FTP server with “FIN ACK on the Outside interface”, or “Deny TCP no connection” to the FTP server with “ACK on the Inside Interface”. I have to believe that further diagnostics need to be performed.


Your last line in the last post states, “If the above does not resolve issue,check client and server...issue is there.........>>>” would further indicate a need to “discover” what is happening. Which is why I was curious how to use the clear asp drop to continue trouble shooting this issue to point me to either server or client for additional discovery.


Looking forward to your response.


Thanks



suschoud Wed, 09/10/2008 - 09:16
User Badges:
  • Gold, 750 points or more

could you post :


sh run policy-map

sh run class-map

sh run service-policy



command outputs.

Also,let me know what version you are running on asa ( will check for bugs accordingly. )


you won't find anything is asp drops as " f/w " did not drop these packets on it's own.



The server closed the conneciton.The child connections which remained were deleted as parent connection was closed.For outbound connecitons,it's the outside server which closes the conneciton.If this server is accessible from a location which is not behind ASA,we need to check ASA.Let me check the basics first,if needed,we'll delve into captures......



Regards,

Sushil

My pleasure and Thank you!


*** show run policy-map ***


policy-map type inspect dns preset_dns_map

parameters

message-length maximum 512

policy-map global_policy

class inspection_default

inspect esmtp

inspect pptp

inspect http

inspect dns

inspect icmp

inspect icmp error

inspect ftp

*** show run class-map ***


class-map inspection_default

match default-inspection-traffic


*** show run service-policy ***


service-policy global_policy global


*** ASA Version ***


ASA - 8.0(4)

ASDM - 6.1(3)


Thanks

suschoud Wed, 09/10/2008 - 09:42
User Badges:
  • Gold, 750 points or more

Hi,


The config. is perfect.

The s/w code u r running does not have any known issues.


##


You mentioned you saw " parent flow is closed " message in the syslogs.


Before this log appears,there would be a teardown connection message...something like :



Teardown TCP connection 278 for

WAN:x.x.x.x/1868 to STORE-SERVER:y.y.y.y/21 duration 0:02:04

bytes 345 TCP Reset-O



This message will essentially tell us why the the connection was closed...." parent flow " message is just a follow up message which tells that the major connection ( control conn. ) is closed and data channel is now closed too.



Please look for this teardown and let me know what you see at the end.In the example above, RESET-O , is at the end of message which essentially mean that device on outside (server) sent a reset-bit set packet.In your case,it could be anything....let's find that out and you would know who the culprit is.



On a side note,make sure that there are no dropped packets on asa interfaces involved in communication.Sometime,few lost packets in ftp exchanges can result in teared connections.




Regards,

Sushil


Thank you for your assistance!


*** These show up before the "parent flow closed" message but no Reset-(X) ***

Teardown TCP connection 20440132 for Outside2_Current:External FTP Server/21 to Inside:Client Machine/1958 duration 0:02:39 bytes 488 TCP FINs

Teardown TCP connection 20436932 for Outside2_Current:External FTP Server/21 to Inside:Client Machine/1935 duration 0:00:24 bytes 478 TCP FINs

Teardown TCP connection 20434600 for Outside2_Current:External FTP Server/21 to Inside:Client Machine/1923 duration 0:00:22 bytes 469 TCP FINs

Teardown TCP connection 20432302 for Outside2_Current:External FTP Server/21 to Inside:Client Machine/1911 duration 0:00:23 bytes 472 TCP FINs

Teardown TCP connection 20431530 for Outside2_Current:External FTP Server/21 to Inside:Client Machine/1907 duration 0:00:25 bytes 470 TCP FINs



*** Then I occasionally see this: ***


Deny TCP (no connection) from Client Machine/1909 to External FTP Server/15423 flags ACK on interface Inside


*** and this: ***


Deny TCP (no connection) from Client Machine/1897 to External FTP Server/21 flags FIN ACK on interface Inside



I hope this helps! :)


Thanks for your help!


*** As a side note, not to stir things up, FTP to this server worked with the previous firewall in place, W _ _ _ _ G _ _ _ _. FTP has failed to this server since the ASA has been in place. ***

suschoud Wed, 09/10/2008 - 10:52
User Badges:
  • Gold, 750 points or more

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 host

access-list cpo permit ip host host


capture capo access-list cpo buffer 2000000 packet-length 1518 interface outside

access-list cpi permit ip host host

access-list cpi permit ip host 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 host

access-list cap permit ip host host

access-list cap permit ip host host

access-list cap permit ip host 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

suschoud Wed, 09/10/2008 - 08:01
User Badges:
  • Gold, 750 points or more

====================

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

suschoud Wed, 09/10/2008 - 08:01
User Badges:
  • Gold, 750 points or more

====================

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

suschoud Wed, 09/10/2008 - 08:03
User Badges:
  • Gold, 750 points or more

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

suschoud Wed, 09/10/2008 - 08:03
User Badges:
  • Gold, 750 points or more

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


suschoud Wed, 09/10/2008 - 08:03
User Badges:
  • Gold, 750 points or more

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

Actions

This Discussion