- an IIS 8.5 server which accepts FTP connections from whitelisted IP addresses
- a PHP web app (on a LEMP server) which creates XML files and uploads them to this IIS server over FTP.
Our web app was able to make the connection and upload its XML files. We could also connect via Filezilla.
Directory listing, file upload, folder creation functioned without issue for months.
Recently however, the ability to list or write to the folder stopped working when connecting from certain whitelisted IPs.
See this screenshot for an example.
- On the left is a command line FTP session I opened up while using my whitelisted residential IP. No issue getting a listing (directory is empty).
- The session on the right was opened after connecting to my OpenVPN server. Immediately disconnected after
A similar test (screenshot) with another whitelisted IP yielded the same result -
DIR fails in the first attempt (using a different VPN), but succeeds in the second attempt (using residential IP).
This behavior persists when using Filezilla.
Even worse, we're now getting this behavior in our web app's FTP sessions. Here's a screenshot of an FTP session I started from our LEMP server over SSH.
dir command, it just hangs indefinitely until I hit Ctrl+C. I noticed the
550 response code there.
550 comes up again when our web app attempts to
STOR a file:
Upload attempt by our web app
2019-01-14 17:43:18 [ip removed] DOMAIN\Username 192.168.1.2 21 TYPE A 200 0 0 53e4f879-8616-435f-bef2-4a84ae0d7989 - - 2019-01-14 17:43:18 [ip removed] DOMAIN\Username 192.168.1.2 21 PORT xxx,xxx,xxx,xxx,158,231 200 0 0 53e4f879-8616-435f-bef2-4a84ae0d7989 - - 2019-01-14 17:43:39 [ip removed] DOMAIN\Username 192.168.1.2 21 STOR r4intake-general-testlname-testfname-1547487798.xml 550 4294967295 0 53e4f879-8616-435f-bef2-4a84ae0d7989 /r4intake-general-testlname-testfname-1547487798.xml -
Here's a log of a file upload attempt using Filezilla (from my residential IP). The
2019-01-14 17:47:49 [ip removed] DOMAIN\Username 192.168.1.2 21 TYPE A 200 0 0 808bb5b7-4e6a-4950-a204-f59a87f3d7b9 - - 2019-01-14 17:47:49 [ip removed] DOMAIN\Username 192.168.1.2 21 PORT xxx,xxx,xxx,xxx,214,2 200 0 0 808bb5b7-4e6a-4950-a204-f59a87f3d7b9 - - 2019-01-14 17:47:49 [ip removed] DOMAIN\Username 192.168.1.2 21 STOR r4intake-general-testlname-testfname-1547487999-full.xml 226 0 0 808bb5b7-4e6a-4950-a204-f59a87f3d7b9 /r4intake-general-testlname-testfname-1547487999-full.xml -
Same FTP server, same credentials, same folder, same transfer mode - different response.
There are five whitelisted IPs we have tested with. Commands succeed with 2 and fail with 3 of these IPs.
Of the three that fail, two belong to Digital Ocean (our LEMP server and my OpenVPN server), and one belongs to a known commercial VPN service.
I typically work with the LEMP stack and know almost nothing about IIS, and have few ideas from this point as to what the cause could be.
Is it possible that IIS does not like certain IP ranges (datacenter, known VPNs, etc.), or that some type of security or group policy could be affecting the ability of certain IP ranges to read/write to the folder despite the fact that said IPs are whitelisted for FTP connection?