Connection lost when downloading file from specific FTP (weird!)

Question

Hello, 
 I have a very, very weird problem: 
 When I download a large file from a specific FTP, my uplink is lost after some minutes. (when I download the same file from another FTP with the same speed, this problem doesn't occur! ???) When I get the error, UTM reports "State: Up" and "Uplink: Error". My modem (connected via Ethernet) shows a normal connection (all LEDs are lit normally). 
 When I then do nothing, the connection will come back after 5 to 20 minutes. 
 While I'm disconnected, I can see DHCPACKs in the system log, but not a single server from outside can be reached. 
 When I restart the firewall, the time for a comeback of the line seems to be the same. When I restart my modem, I have a connection after the modem's initialization. 
 This led me to the conclusion that the problem must lie beyond my firewall. 
 I then contacted my ISP and they observed my modem while I forced the disconnect with the download. 
 The interesting thing was: I phoned over IP. When I lost the connection, I could hear my ISP for a minute or so but he couldn't hear me. So packets seem to reach me, but no packet could be sent. And: While I was disconnected, my ISP could call the webinterface of my modem normally and could ping servers from there, while I was unable to ping any server from my UTM. 
 So now the conclusion seems to be, that the problem is on my UTM. What the heck is going on here? :-) I found this thread and I had hopes, but the ethtool call didn't help: https://community.sophos.com/products/unified-threat-management/f/hardware-installation-up2date-licensing/30148/9-312-intel-82572ei-e1000e-hardware-unit-hang 
 I cannot tell it exactly and it is maybe coincidence, but maybe the problems began when updating my UTM from 9.504-1 to 9.605-1. I have a single internet line with no load balancing. 
 Thanks in advance for any help. This problem is driving me mad.

Swift42 · Answer

OMG, I found the solution for problem #2: A bad cable between my switch and the UTM, simple as that. (very annoying: it wasn't a cheap cable) 
 Now eth0 isn't resetting anymore (new cable) and eth1 (WAN) has no longer these persistent disconnects (new modem, cable unchanged). 
 So I really had 2 different problems (I'm lucky!) and both are fixed now. 
 Thanks for your help.

Swift42 · Answer

In case someone has ever a similar problem, here is my update: 
 It wasn't the cable. It was just coincidence that it worked the first hour. The problems came back after then. 
 But I had a new theory: I used the same hardware (an atom D510) for my private firewall for years, because at home I don't need all UTM features and my bandwidth wasn't that big. 
 But over the years my private internet connection got faster and faster and the UTM got more and more features, but my hardware stayed the same. 
 While downloading a file in the past, I could see that the CPU of the firewall jumps to 23% - 25% and I thought: Ok, it can't be a CPU problem. 
 But I forgot one critical thing (and I can blame myself that I didn't think earlier of this): The CPU has 4 threads and most network related tasks can't be paralleled - they must run on one thread. And with 4 threads this means 25% cpu. Ugh. 
 So maybe sometimes the cpu can't handle the full load and the network buffer runs full. And maybe this resets the interface. 
 So I thought it would be a very good idea to update my hardware after all these years :-) 
 And yes, it was a good idea: after transfering the config of the UTM to the new machine, there are no more resets on the internal interface. 
 The new machine has also 4 threads, but is 15x faster. CPU is at 5% while downloading a large file. 
 If I extrapolate this to a thread on the old cpu, 5% x 15 would be 75% on the old thread, which was then capped at 25%. 
 So yes: The old CPU wasn't capable to handle the full load. 
 tl;dr: Always check if a thread of the CPU can handle the full network load. If a thread (not the CPU!) is constantly at 100%: Houston, we have a problem.