I have a vendor who's application uses ftp to communicate to/from a workstation on our network. The process is started on our workstation as a scheduled job. Looking at the log, a connection is being made (authenticated), but during the transfer of a test file, it's timing out. Naturally, they're saying that it's our problem (firewall). Correct me if I'm wrong, but isn't all traffic allowed out by default unless otherwise changed? Suggestions?
I have a feeling you are running into an issue where your PIX is running out of out-of-order packet buffers. To test if this is the issue, do a show asp drop. If the "TCP Out-of-0rder packet buffer full" lines is rapidly growing you have run out of out-of-order packet buffers (which is likely causing the problem). If you are running an ASA, you can resolve this issue, but not if you are using a PIX. Cisco has yet to decide when they will extend the fix to PIXs. Basically the "fix" just increases the number of buffers for out-of-order packets on ASAs. Let me know if you have an ASA and I will send you the commands to make the change.
You mentioned firewall but I am not sure which Cisco product or software level. My suggestions will be general.
Does your server initiate both the control and data connection? Does your firewall have ftp fixup or inspect enabled? Having ftp fixup or inspect enabled assists the firewall in knowing how to handle the ftp communication. FTP can start on port 21 and switch to port 20. Fixup/inspect understands and can handle this change automatically. Make sure their side also can handle any port changes.
If you are using PIX/ASA 6.2, 6.3 or 7.x code you can capture the data communication. http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_62/cmdref/c.htm#wp1053548. I would set your access-list to permit ip and a second access-list to permit ip . This will allow you to see the data packets arriving and leaving your firewall. Make sure you test both interfaces (inside and outside). If you see a data packet leave your firewall but their server not respond then: something blocked the traffic before it got to their server, their server didn?t handled the data/respond, or their server?s response was blocked before getting back to you.
You may also want to test your ftp communications manually. See if you can log in, see directory and file structure, get and put small files versus large files. Remembering that I am not sure how you are connected, the problem might be with MTU. A small file (text doc with a couple characters) might pass but the large batch file fails.
Lastly or really first, make you have your systems and theirs logging at the highest level (debug for Cisco).
Hope some of this helps. Make sure you understand all command suggestions before issuing any on a production environment.
Didn't realize I didn't offer any more info than I did....we're running a PIX 515E, with 6.3(5) as the software version. We do have ftp fixup enabled, but not familiar with the inspect. I will read through this again (and the accompanying link) and post back the results. I should note that this is taking place at a remote location and here at the host, I've been able to successfully ftp files. One of my first thoughts was that the issue was maybe a bandwidth problem...packets getting dropped...not sure.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...