asd23 Absent Member.
Absent Member.
1707 views

Firewall question

We have a cisco asa here and we are having issues ftp'ing from one site.

We can download from other sites without issue, just not one. When we
try from this one, the file downloads until the last few bytes, then
the ftp session times out and the file is 'corrupt'. Doesn't matter
how big or small the file is.

If we download via ftp from this site on a connection not behind our
asa, things download fine.

Any suggestions on what to check?

--
Stevo
Labels (1)
0 Likes
6 Replies
Knowledge Partner
Knowledge Partner

Re: Firewall question

FTP is a pain because of different modes of transfer, specifically BINARY
vs. ASCII. Always use BINARY, always.

Other than that, I'd try with clients/servers that are both at that other
site to rule in/out firewalls. If the firewall is causing problems, stop
the firewall from doing that (ask Cisco?) but if the problem happens
regardless of the firewall, and if the client is the same in both cases,
try checking the server side.

Also, file size may matter. Near any interesting size boundaries, like 2
GiB, 4 GiB, etc.? LAN trace may be interesting to see if the server is
sending an "I'm done" prematurely.


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
asd23 Absent Member.
Absent Member.

Re: Firewall question

ab sounds like they 'said':

> FTP is a pain because of different modes of transfer, specifically
> BINARY vs. ASCII. Always use BINARY, always.
>
> Other than that, I'd try with clients/servers that are both at that
> other site to rule in/out firewalls. If the firewall is causing
> problems, stop the firewall from doing that (ask Cisco?) but if the
> problem happens regardless of the firewall, and if the client is the
> same in both cases, try checking the server side.
>
> Also, file size may matter. Near any interesting size boundaries,
> like 2 GiB, 4 GiB, etc.? LAN trace may be interesting to see if the
> server is sending an "I'm done" prematurely.


So my response to ab's comment is...

Only happens from this one site, and doesn't matter the file size.

--
Stevo
0 Likes
ScorpionSting Absent Member.
Absent Member.

Re: Firewall question

ACTIVE versus PASSIVE?

FTP versus FTPS versus SFTP?

I've often found the former causes problems depending on each network's config....

Also, if it's this one site....it could be their issue, not yours...

Visit my Website for links to Cool Solution articles.
0 Likes
asd23 Absent Member.
Absent Member.

Re: Firewall question

ScorpionSting sounds like they 'said':

>
> ACTIVE versus PASSIVE?
>
> FTP versus FTPS versus SFTP?
>
> I've often found the former causes problems depending on each
> network's config....
>
> Also, if it's this one site....it could be their issue, not yours...


So my response to ScorpionSting's comment is...

I'm completely stumped on it. I can ftp from anywhere else, and from
another web connection (not behind our firewall) I can ftp from their
site.

Tried passive, active, sftp, ftp, none of them make a difference.

--
Stevo
0 Likes
Knowledge Partner
Knowledge Partner

Re: Firewall question

On 11/21/2016 03:44 PM, Stevo wrote:
> Tried passive, active, sftp, ftp, none of them make a difference.


sftp isn't even handled by the same client OR server; sftp is typically
handled by sshd, so if that's the case then I'd probably really check a
LAN trace to see why two completely separate protocols, that work in
completely different ways, would die similarly.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
dpartrid Absent Member.
Absent Member.

Re: Firewall question

A colleague of mine ran into a similar symptom recently. (And if you ended up opening a SR with SUSE, it may have well been your case.) But anyway, in the case I heard about, at the end of a FTP file transfer, the last few bytes would be absent and so the file was essentially corrupt.

In that case, he discovered that some packet fragmentation and reassembly was not occurring correctly. That, in combination with the very primitive way the FTP signals that the file is done, caused the file to be considered "ended" prematurely.

FTP signals end-of-file by putting a FIN in the packet. (Remember that FTP transfers files on a separate connection from the main FTP control connection, so a FIN on the data connection doesn't end the whole session.) But what if your final packet of file data was in a packet of size 3000 that came from a OS or network that could handle that size, but then went through a router (or NIC doing segmentation offloading) than had to break it into 2 packets of 1500? That entity doing the fragmentation would create 2 packets and would have to be make sure to put the FIN *only* in the second of those packets.

In my colleague's case, the device doing the fragmentation made the mistake of putting the FIN in the first fragment. By doing so, it caused the receiving side to believe that end-of-file was reached, and anything contained in the second fragment would be lost.

You can catch this kind of thing by looking at a packet trace from the perspective of the receiving side of the file transfer. Examine the last few packets, their sequence numbers, and which one contains the FIN. If the FIN comes before the final data (by packet sequence number, not necessary by arrival time) then my above description fits. If this is indeed happening, the hard part may be tracking down what device is building the bad fragment (i.e. putting the FIN in a fragment other than the last one.) Sometimes a machine using segmentation offloading is responsible (where the NIC is in charge of segmentation instead of the OS). On linux, segmentation offloading is one of many offloadings that can be controlled with ethtool -K.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.