cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
634
Views
0
Helpful
5
Replies

ASA5520-Access to FTP site

bm_5789
Level 1
Level 1

I thought I would run this by the forum in case there is someone out there who experienced the same issue.  I have users behind an ASA5520 firewall running 8.x code who are unable to access a particular ftp site through a web browser or an ftp client such as FileZilla.  Keep in mind that other ftp sites are accessible.  I was notified of this as it worked in the morning of a particular day and then stopped working in the afternoon on the same day.  Accessing the site from our guest network(different firewall) is possible.  The SysAdmin insists it is a firewall issue.  I have run the packet tracer on the firewall and the traffic is allowed.  FTP inspection is configured.  I get the same results when I try to access with IE or Firefox.  Anyways, I thought I would post the questions to see if anyone has seen something like this before.  If anyone is interested, the site is ftp://authordev.healthstream.com.  TIA for any help or advice.

1 Accepted Solution

Accepted Solutions

Hi,

Seems to me that both of the captures show the same thing.

It shows first that the host forms the FTP Control connection (TCP/21) just fine and after that the server sends a TCP Reset for the connection immediately.

So TCP connections forms ok as we can see

  • Initial TCP SYN from the client
  • TCP SYN ACK from the Server
  • TCP ACK from the Client

But then we see TCP Reset ACK from server.

I would suggest looking at the capture with Wireshark if you can see anything there.

But at the moment it seems that the TCP connection between the Client and Server forms just fine but for some reason the actual FTP server resets the connection.

I would probably ask the remote site information on what they see on their end with regards to the FTP server since it sends the TCP Reset.

- Jouni

View solution in original post

5 Replies 5

Do you get any response from the ftp site in any way? Can you ping it, does it respond at all when you connect with filezilla?



Sent from Cisco Technical Support iPhone App

Please rate as helpful, if that would be the case. Thanx

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

You could always take a packet capture on the firewall and/or on the actual host to see where the communication stops.

You could for example configure the ASA to capture the traffic between the client and the server.

Example configuration could be

access-list FTP-CAP permit ip host host

access-list FTP-CAP permit ip host host

capture FTP-CAP type raw-data access-list FTP-CAP interface buffer 10000000

You could naturally also capture the traffic on the internal side of the firewall if you want to compare the 2 captures on both sides of the firewall

access-list FTP-CAP-INTERNAL permit ip host host

access-list FTP-CAP-INTERNAL permit ip host host

capture FTP-CAP-INTERNAL type raw-data access-list FTP-CAP-INTERNAL interface buffer 10000000

You can then use the following command to confirm if traffic is captured

show capture

You can use the following command to show the capture on the CLI

show capture FTP-CAP

show capture FTP-CAP-INTERNAL

I would suggest copying the actual captures to your computer with following commands and then viewing the contents with Wireshark

copy /pcap capture:FTP-CAP tftp://x.x.x.x/FTP-CAP.pcap

copy /pcap capture:FTP-CAP-INTERNAL tftp://x.x.x.x/FTP-CAP-INTERNAL.pcap

You can remove the captures from the ASA with

no capture FTP-CAP

no capture FTP-CAP-INTERNAL

The ACLs will have to be removed separately.

These captures should give you a picture what happens to the FTP connection.

- Jouni

Here is the text from the inside and outside captures.  Curious to know what you think about them.  TIA

INTERNAL Capture

My ASA5520/pri/act# show capture ftpcap_inside

4 packets captured

   1: 11:59:06.247866 xxx.xxx.xxx.xxx.53522 > 64.37.254.212.21: S 3563085223:3563085223(0) win 8192
   2: 11:59:06.263963 64.37.254.212.21 > xxx.xxx.xxx.xxx.53522: S 2469665219:2469665219(0) ack 3563085224 win 3600
   3: 11:59:06.264421 xxx.xxx.xxx.xxx.53522 > 64.37.254.212.21: . ack 2469665220 win 16500
   4: 11:59:06.281204 64.37.254.212.21 > xxx.xxx.xxx.xxx.53522: R 2469665220:2469665220(0) ack 3563085224 win 3600
4 packets shown

EXTERNAL Capture

My ASA5520/pri/act# show capture ftpcap

4 packets captured

   1: 11:52:01.331617 xxx.xxx.xxx.xxx.16946 > 64.37.254.212.21: S 3569461477:3569461477(0) win 8192
   2: 11:52:01.347668 64.37.254.212.21 > xxx.xxx.xxx.xxx.16946: S 2669600381:2669600381(0) ack 3569461478 win 3600
   3: 11:52:01.348202 xxx.xxx.xxx.xxx.16946 > 64.37.254.212.21: . ack 2669600382 win 16500
   4: 11:52:01.366817 64.37.254.212.21 > xxx.xxx.xxx.xxx.16946: R 2669600382:2669600382(0) ack 3569461478 win 3600
4 packets shown

Hi,

Seems to me that both of the captures show the same thing.

It shows first that the host forms the FTP Control connection (TCP/21) just fine and after that the server sends a TCP Reset for the connection immediately.

So TCP connections forms ok as we can see

  • Initial TCP SYN from the client
  • TCP SYN ACK from the Server
  • TCP ACK from the Client

But then we see TCP Reset ACK from server.

I would suggest looking at the capture with Wireshark if you can see anything there.

But at the moment it seems that the TCP connection between the Client and Server forms just fine but for some reason the actual FTP server resets the connection.

I would probably ask the remote site information on what they see on their end with regards to the FTP server since it sends the TCP Reset.

- Jouni

Excellent information.  I suspected it was the website.  Thanks for your assistance.

Review Cisco Networking products for a $25 gift card