Port Forwarding for FTP with TLS/SSL

Hello,

I am trying to configure my Balance 380 (Firmware 5.4.9 build 2573) for a secure FTP server (FTP with TLS/SSL). I have an entry for my FTP server under Inbound Access–>Servers. Under Inbound Access–>Services I created rules for TCP port 21 and TCP ports 3000-3050 and associated them with my FTP server. When I connect using regular/insecure FTP, it works as expected. When I connect using secure FTP, the connection times out.

If I modify my rule under Inbound Access–>Services to allow TCP ports 1 through 3050 for my FTP server, then I can connect with secure FTP. The developer of my FTP server software thinks that the Peplink is not forwarding traffic to ports 3000-3050 with my original set of rules (see paragraph above). Is the developer correct? If so, how do I go about configuring my Balance 380 so that I can access my FTP server securely without opening all TCP ports from 1 through 3050?

Thanks for reading!

SFTP typically runs over TCP port 22 so I suspect the modification allowed port 22 to work. You can confirm which port number is used with an inbound firewall rule and event logging enabled to view the allowed inbound sessions to your server.

Here is what I captured with the inbound firewall rule and event logging enabled.

*[7637764.639983] Allowed CONN=WAN1 SRC=<remote_IP_address> DST=172.16.177.16 LEN=44 PROTO=TCP SPT=6000 DPT=22
*
What does *LEN=44 *mean? Does *SPT *mean Source Port? Does DPT mean Destination Port?

Hello,

Correct. SPT and DPT are Source and Destination Port. Per the log it does look like TCP port 22 is being used.

LEN=44 refers to the total length of the packet itself. This count, which is measured in bytes takes into account not only the TCP and IP header but also includes the data that was sent if any.

The source port (SPT) being 6000 is irrelevant in terms of the inbound firewall rule? All that matters for a firewall rule is the destination port (DPT) of 22?

This is correct as the source port may be a random port number.

Under non secure FTP (plain text), the NAT router normally sniffs the clients Active state port allocations, and the router quietly forwards the port on a one time basis.

When the session uses SFTP or FTPS (encrypted), then the router cannot sniff the conversation, and any client Active port allocations fail. Its possible in a few FTP clients, to set aside a small port range to be used. You can forward those, but its not a good way to do this. Every FTP client in your network would need a port range reserved, which could easily conflict elsewhere with normal surfing.

So with both NAT and the client using encryption on FTP, then the FTP client must use Passive state transfers. Under passive state transfers, the session succeeds without any router adjustments. Too easy.