TLDR: After 5 hours of troubleshooting FTP over OpenVPN, the solution was enabling compression—the exact opposite of what everyone recommended.
Let’s talk about FTP file transfers, shall we? Picture this: A typical day, armed with FileZilla (for adhoc testing) and a Ruby script employing Net::FTP gem, tasked with the simple job of uploading files to a remote ProFTPD server. Sounds like a snooze-fest, right? Oh, how wrong you’d be!
In the office, everything was smooth sailing. File uploads were as effortless as breathing. But from home, connected through OpenVPN, I was greeted with an error so cryptic it might as well have been written in hieroglyphics:
Net::FTPTempError: 450 Transfer aborted. Link to file server lost.
And so began my descent into the swirling vortex of troubleshooting. pfSense firewall settings, NAT configurations, FTP server settings—everything was under scrutiny.
5 Hours In…
I tried every trick in the book:
- Switching between active and passive FTP
- Peering into the soul of the OpenVPN configuration
- Allowing ALL traffic between LAN & OpenVPN (a big no-no)
- Trying every possible permission configuration
- ProFTPd config changes
- Even blaming poor FileZilla for a hot second
But alas! I was no closer to a solution.
Yes. This too was not out of the question.
The Ghost Files
Oh, and let’s not forget the ghost files! Every failed attempt at uploading a file would result in the creation of a zero-sized file on the server. It was like the server was pointing and laughing at me, creating an empty shell of a file, a cruel reminder of my predicament.
The Plot Twist
Just when I was about to call it a day and accept defeat, I stumbled upon a tidbit of advice:
“Some VPN configurations may have compression enabled, which can cause issues with certain types of traffic. You can try disabling compression on your OpenVPN configuration to see if it resolves the issue.”
I thought to myself, “Could it be that simple?”
But wait! Plot twist! My OpenVPN configuration already had compression disabled.
So, in an act of sheer desperation, I decided to go against the grain. I enabled compression, held my breath, and…
Eureka! It worked. I kid you not. It worked faster too!
The Lesson
So there you have it, folks. The thrilling saga of FTP troubleshooting, where the hero turns out to be the unsuspecting compression feature, the very thing that was supposedly the villain of the piece. Just goes to show, when it comes to networking, expect the unexpected.
If there’s a moral to this story, it’s this: The answer might not always be where you expect it to be. And sometimes, you just gotta switch things on instead of off.
So, here’s to more head-scratching adventures in the world of IT. Because let’s face it, we wouldn’t have it any other way!
Happy troubleshooting!
Originally published: dev.to/konung/when-ftp-stands-for-frustrating-transfer-problem-1699
Last updated: June 19, 2023