I am trying to access an external URL using public IP, which is successful. From that web page we have a link used to view files, when clicked it redirects to an FTP server and fails to open the file. When bypassing the ASA it works.
Access rules created seperately those IP's opening ftp-data, still no luck. When checked the log it says " user anonymous retrieved file /XML/Web...... "
Checked the service policy and cleared the ACL's didn't help. Anyother thing apart from this need to be checked ?
Log screenshot attached..
The logs are actually not showing the firewall dropping the traffic, it actually show how both endpoints are gracefully closing the tcp connection via FIN packets.
That being said is the server running on Passive/Active mode?
Do u have the FTP inspection on the policy-map?
Rate all of the helpful posts!!!
Follow me on http://laguiadelnetworking.com
Thanks for the response.
FTP inspection is already turned on.
FTP passive/active mode, It works when we connect via a 3G modem. So do we need to do any specific config in ASA for active/passive ?
What do your ACLs look like for the inside interface and the outside interface of your ASA?
Just for the sake of testing, try adding a permit IP any any to the outside interface and see if the connection completes. I am wondering if it might be that when you are redirected a new data flow is created which then is dropped by the ASA...though this is not shown in the log.
Another option would be to run a packet capture between the inside interface and the outside interface on the ASA to have a better idea of how the traffic is flowing.
Sorry for the delay in response, added ACL's to permit any any on both the interfaces still no luck. Will run a capture and let you know the result.
Things that we need to know:
- This is Active FTP
- The internal user 10.103.156.36 is mapped to 188.8.131.52 and is trying to connect over active FTP to 184.108.40.206
Please post show tech, show service-policy, show run all service and show run all sysopt
We need to confirm that there is no conflicting NAT configuration, check if there are hits on the inspect FTP confirm that the OS that you are running on the ASA is FTP bug free.
I would also like to know if you use any external IP address under the same range as the NAT on the ASA if you are able to get to this FTP server.
How large is the file that it needs to download, please setup a capture on the ASA between the host and remote end:
capture out interface outside match ip host 220.127.116.11 host 18.104.22.168
capture in interface inside match ip host 10.103.156.36 host 22.214.171.124
capture asp type drop-all buffer 150000
Download the captures over the browser:
name the file in.pcap
name the file out.pcap
name the file asp.pcap
This doesn't look like a problem in FTP inspection. The control and data FTP connections seem to be established, especially that the ASA logs " user anonymous retrieved file..." which wouldn't happen without a data-connection being opened.
However, it would be great if you can get inside and outside captures (in pcap format) so that we trace the two flows. Also try passive FTP as it is recommended when the client sets at the inside of the firewall and the server at the outside so that you make both FTP connections going from inside -> outside and hence avoid the need for return traffic pinholes (which is needed in active FTP with inside client to outside server scenario).
Hope this helps.
Just checked it. This is not an inpection problem.
The TCP window is getting full in the data channel. Having inside and outside captures at the same time can clarify the ASA's role better. Please try allowing the TCP window scaling option as it is being cleared by the ASA and the server is proposing the option:
Set connection advanced-options: allow-probes
Selective ACK cleared: 1668 Timestamp cleared : 11362
Window scale cleared : 227
Other options cleared: 50
Opt 20: 6 Opt 30: 44
Other options drops: 0
The TCP windows are negotiated automatically between the TCP connection endpoints, what we are trying here is to make sure that the ASA is not intercepting/normalizing the TCP parameters. However i am not 100% sure of the situation because we don't have the INSIDE captures that correspond to the outside capture you provided so that we compare them.
For now, please configure the existing tcp-map to allow Window scaling:
tcp-options window-scale allow
If the issue persists, please provide the inside captures.