When disabling the Security Policy Control the issue persists.
USG logs don't show any activity when trying to connect to the FTP server. I'm not 100% sure that I'm looking in the right spot here. I'm checking Monitor - Log - View Log
Monitor - Log - View Log
Ok, Security Policy is also not the problem.
Mmmh, your adjustments are looking good. We have no other things in place for our port forwardings/NATs.
Did you check that no other existing NAT rules are in conflict with this new one?
Are you accessing from the internet by using a browser or FTP client like Clonezilla?
Thank you for the follow up!
I'm accessing from the internet using various FTP Clients (Filezilla,Transmit, Cyberduck and FTPClient (on iPhone))
I just have a few other NAT rules in place:
And that's it...
Check the SynologyNAS. They have their own OS running and if I remember correctly, with an own firewall or something security things like that. Maybe it accept queries from the own subnet only?
The Synology could be the culprit, I know. I'll double check all settings there. It works from the same LAN on port 22, it shows the right certificate... All problems started when shutting down the plain FTP services on the Synology and having only SFTP and FTPS activated.
SFTP is the same as SSH. Maybe you have to deactivate SSH that SFTP could be used for file transfer purposes? I will ask my colleague. He is adjusting our Synologies here which are in place for daily server backups. But he will be back in the office tomorrow.
Just talked to my colleague. The Synology has no separate firewall. But the SSH service of the Synology has some extended settings where you could choose different security level for the encrypted SSH / SFTP connection. And in case the SFTP client is not able to handle the highest security level of the Synology, you have to mitigate the settings. Don't know whether you are using different SFTP clients when connecting from WAN side (Internet) and from LAN side. In such case you could try it. If you are using the same client, you could forget this opportunity.
I'm using the same client from LAN & WAN.
This morning the daily USG reports came in and there I saw in one of the lines:
35 2020-03-24 15:10:34 192.168.0.120 nn.nn.nnn.nn
alert user Account: existingaccountname
Failed login attempt to Device from ssh (incorrect password or inexistent username) [count=4]
It appears that by using port 22 the redirection does not work as the USG "sees" it as the port to access its own ssh.
Each attempt I did was logged in the mailed Log. Apparently I'm looking on the wrong page when checking the logs on the USG by browsing the interface.
I'll try to rearrange the port forwarding for SFTP by using another port number and keep this thread updated.
BTW - SSH is not running on the Synology.
Yes, of course. How stupid are we! 😀
USG is using port 22 for own SSH access.
Now you could change the port for USG SSH access, or the port in Synology to another port umber. In USG it is at CONFIGURATION / SYSTEM / SSH / SERVER PORT.
I've changed the SSH port on the USG.
Reversed all settings to the previous settings as in my first post.
Trying to login from WAN by using port 22 but no luck: Error: Connection refused
Error: Connection refused