FTP != port 21 not working

Currently reading
FTP != port 21 not working

DS1819+ DS1817+
Operating system
  1. macOS
  2. Windows
Mobile operating system
  1. iOS

DSM 6.2.4-25556 Update 5

I changed FTP port 21 to 30021.
CP > File Services > FTP > Port number setting of FTP : 30021
Port forwarding on router is correctly setup (30021/tcp->30021/tcp)

This works except when I use a FQDN to access the NAS from inside (!) the LAN.
There is a reason why I have to use the FQDN addressing i.s.o. local LAN IP of the NAS.
However I don't see a reason why this should not work.
(it works for other services as well)

This works properly:
LAN FTP client : LAN IP port 30021/tcp -> NAS listen 30021/tcp
WAN FTP client : FQDN port 30021/tcp -> NAS listen 30021/tcp
This doesn't work:
LAN FTP client : FQDN port 30021/tcp -> NAS listen 30021/tcp

If I change the router port forwarding into a port redirection 30021/tcp->21/tcp, all works as expected:
LAN FTP client : LAN IP port 30021/tcp -> NAS listen 21/tcp
LAN FTP client : FQDN IP port 30021/tcp -> NAS listen 21/tcp

Why is the FTP connection not working in conjunction with port forwarding and FQDN inside the LAN?
That does seem strange. It may be a quirk of the router and how it's handling local loopback with the FTP data connection when on the LAN-side you don't use the standard TCP 21. FTP is a funny service and was always one to check when, back in the day, setting up firewalls.

Is there a reason to use FTP instead of a secure service? (File Transfer Protocol - Wikipedia) You can use SFTP and assign a different TCP port than is used for SSH, so a firewall can allow SFTP and deny SSH.
I suppose the next question is: do you really have to have the camera access the NAS from outside the LAN? This is back to the point that you're opening FTP access which isn't the most secure service.

That you give the examples of testing on LAN and Internet it would seem that you could wait to upload until the camera is back on the LAN.

It still seems to be most probably an issue with the router's local loopback.
Last edited:
It still seems to be most probably an issue with the router's local loopback.
Understood. But other services (http(s), ssh, ...) work while using FQDN inside the LAN in conjunction with port forwarding.
It's only the FTP which generates this behavior. Weird !!!
FTP isn't like HTTP, SSH, and other services. It was always handled as a special case service back when I worked on Check Point FW-1: it had to be explicitly added to rules as FTP connections. Take a look at the Wikipedia link.

It could be due to negotiating the data connection that this is failing. With FTP it's not usual that the TCP port 21 handles all traffic, there's a hand off to a temporary new port. If loopback isn't catching this then that could explain the problem (it may be only thinking FTP = TCP 21 and not inspecting non-21 traffic). Purely a guess in this case, but FTP isn't straight client - server on one port..

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

  • Solved
Specs are not updated, and reflect only the max capacity tested at time of product announcement. For all...
Yep, that won't change. But the front port isn't reserved for UBS Copy, it's more of an accessibility...
Welcome to the forum imho, I would use Hyper Hackup tool running as a single file rsync task. I have...
I can’t connect to an external exchange server for mail... I think I need an expert to set it up because...
Sooo... I hate to type this out given that you've all spent some time on this thread, but I figured I'd...

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!