03-04-2011 10:33 AM - edited 03-11-2019 01:00 PM
Hi !
We have 2 ASA 5580 with a cluster active/standby configuration
We have updated to version 8.4.(1) since version 8.3(1) but since then it is impossible to establish the FTP connection in passive mode with NAT.
Before this update, all was OK.
Here our configuration :
class-map global-class
match default-inspection-traffic
!
!
policy-map global-policy
class global-class
inspect dns
inspect http
inspect icmp
inspect icmp error
inspect sunrpc
inspect tftp
inspect pptp
inspect rtsp
inspect ftp
!
service-policy global-policy global
Do you know if it's a bug or you can fixed this problem ?
Thank you very much for your help.
Regards,
06-21-2011 07:00 AM
yes, the issue was not corrected by the software upgrade.
The ticket open on this is 618020667.
06-21-2011 07:49 AM
We also seem to be running into this problem with a 5585x 8.4.1 with IPS. One server works and the other does not. The non-working servers is NATed to an internal number, the working server is not.
06-21-2011 09:11 AM
Dprod,
Please verify if you are not hitting the following defect CSCto09465. Ryan, I checked on the case and the captures were taken only on port 21. I have asked this question before, what is it that does not work? What happens when you try to pull a file?
Mike
06-21-2011 09:26 AM
Hi, we are running into CSCto09465 also, my understanding is that CSCto09465 applies to active ftp. We also seem to have issues with passive ftp.
06-21-2011 09:54 AM
Hi,
Ok, can you take captures and paste them here as pcap format? I want you to take the captures with IP instead of just the control channel of FTP.
******* Capture configuration ******
{Enable GUI interface:}
http 0 0 inside
http server enable
{For outside interface:}
access-list capture1 permit ip host
access-list capture1 permit ip host
{For inside interface:}
access-list capture2 permit ip host
access-list capture2 permit ip host
capture tcpin access-list capture1 interface outside
capture tcpout access-list capture2 interface inside
****** To download the files then *****
Open the browser
https://
https://
Note:
Username: blank = no name
Password: {enable password}
********* To delete them *********
clear access-list capture1
clear access-list capture2
no capture tcpin
no capture tcpout
********** End *********
Let me know.
Mike
06-21-2011 10:17 AM
I do not believe that this ASA5510 is being hit by this bug CSCto09465.
The RN clearly says ASA5510s are NOT affected.
Conditions:
To hit this bug, the following conditions must be met:
1) The ASA must be running version 8.4(1) or greater
2) The ASA must have multiple CPUs. ASA 5580 and 5585 platforms are affected by this problem. The ASA 5505, 5510, 5520, 5540 and 5550 platforms are NOT affected by this problem
3) The FTP connection must be subjected to port address translation (PAT) on the ASA. Connections subjected to static NAT, or connections that do not hit any NAT rule on the ASA will not encounter this problem.
Control channel stalls meaning data channel cannot be open. In this case data starts to flow as the text based captures show but, seem to break later. We need to see the entire capture until the very end and may be a few seconds later after the break so, we what might be going on.
-KS
06-21-2011 10:20 AM
No, I dont believe that it is the same bug either.
06-21-2011 10:57 AM
Yeah, but dprod was running with an ASA 5585 and the customer on the main threat has an ASA 5580. There is no ASA 5510 mentioned.
Anyways, we asked for the capture, and we still have none, so it is going to be very difficult to troubleshoot with no Info.
Mike.
06-21-2011 11:01 AM
06-21-2011 11:27 AM
Unfortunately no, but you can create a temporary username and password for the session then delete it.
Mike
06-21-2011 11:30 AM
Dprod,
In your particular case, you will need to take a capture on the server, as I am able to see the list command passing thru the device, but as for the retransmissions, it seems like the LIST command is not getting to the server, would you be able to take a capture there?
Mike
06-21-2011 11:35 AM
FYI, when I try this internally (directly to the internal IP address of the server) rather than going through the firewall there is no problem.
06-21-2011 11:40 AM
Nice to hear that, however, I need to make sure that the server is able to see a packet coming from 67.52.213.103 with the list command on it. As per the firewall, the packet is passing thru.
Mike
06-21-2011 11:05 AM
I am agreeing with you. I dont think that this is the same bug that was affecting dprod.
I can get a packet capture a little latter on. I have some already running from the ASA, and spanned ports before and after the ASA.
06-21-2011 11:30 AM
Thats, fine, I will wait for the captures.
Mike
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