Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is: no domain. Just an FTP server (Windows 11 Pro IIS) with a DDNS address kept current by noip.com via URL tikilane.ddns.net
I ran this command: Set FTP server to "Require SSL Connections", Created and selected a Self Signed Certificate using IIS. Connected to FTP site from remote computer using Filezilla Client.
It produced this output:
Status: Resolving address of tikilane.ddns.net
Status: Connecting to 108.174.191.139:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Status: Server sent passive reply with unroutable address. Using server address instead.
Command: LIST
Response: 150 Opening BINARY mode data connection.
Error: Connection timed out after 20 seconds of inactivity
Error: Failed to retrieve directory listing
My web server is (include version): IIS FTP
The operating system my web server runs on is (include version): Windows 11 Pro, verions 24H2
My hosting provider, if applicable, is: N/A
I can login to a root shell on my machine (yes or no, or I don't know): I'm sure I can, but don't know how
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Don't think I've gotten this far.
That's going to be highly subjective and depend on both the users and the use case. As long as FTPS is properly configured, there is nothing inherently wrong with it.
Might be subjective indeed, but it's an ancient protocol with inherent difficulties with the whole active vs. passive and all the related required portmaps and/or firewall settings. I'd argue SFTP is better in any way
An important factor is that this FTP server will be used to receive video files from surveillance cameras, which for some of them, means that it will actually be receiving files from a Lorex 6100 series NVR (a 6108, to be exact). I don't think it supports SFTP. Maybe not even FTPS. Security isn't an issue as all of these surveillance files are footage of wildlife, particularly some screech owls that are nesting in a roost I made on the front porch of our house.
If it worked, here is the entireity of the FTP configuration page on the Lorex NVR. Can you tell from the options it lets you configure if SFTP or FTPS are supported?
The server it's currently pointing to (192.168.42.215) is on the same LAN as the NVR. What I want is to have it send it's files to a server not in the LAN, specifically, a server behind a router addressed as tikilane.ddns.net (the router is properly configured to send FTP traffic to a particular computer within the remote LAN). The DDNS part works. I do get sporadic successes. i.e., I configure the FTP settings on another camera at the same location, but of a different kind that has a "TEST" button on its FTP configuration page. I do the TEST, it works (popup says "Success" and a .txt file appears on the remote FTP server). But then, almost immediately, it doesn't. Sometimes I'll get like 1 video file, as well, and then it goes back to not working and further "TEST"s fail.
If it has a SFTP option, it's probably somewhere else, as it's an entirely different protocol than FTP. From the screen you've shown there are no specific SSL/TLS options, but that might not mean it wouldn't try.
It's probably a good idea to ask this question on a Lorex support channel before trying to continue.
The Lorex N861 series apparently does support FTPS and that configuration screen shows a choice between FTP and FTPS:
In my experience - when stuff like that happens, it is often because the online support was generated after a firmware upgrade.
Often times there are open source firmwares that can be used as well.
I wasn't able to find any of that, but I did find this link on Reddit that sent me down a quick rabbithole of random links
1- Lorex was a subsidary of Dahua
2- In 2019 there was a classaction lawsuit over their firmware bricking units
3- In 2019 it was discovered their chips had a backdoor; the were banned from all US Government Facilities
4- In 2022 the FCC banned Dahua in the US consumer market due to the backdoor
5- Immediately after being banned in the USA, Dahua sold Lorex to a Taiwanese company
There may be new firmware from the new Taiwan owners; I definitely wouldn't install any firmware prior to 2018 as it could brick the unit; and I'd try to upgrade to something past 2022 if possible.
In any event, I'd be very wary of this item as-is, I'd consider it fundamentally insecure, and I don't think an SSL cert will fix it.
