explicit ssl connections to the ftps control port on the IBM i , either 990 or other port.

With the IBM i port-mapped NAT rules to hide port 21 behind 1021, ftp works in active mode when the hidden interface is accessible by the FTP client. FTP passive mode won't work because FTP data connection can not establish. To accept the data connection, FTP server listens on the hidden interface where the control connection is established but the FTP client attempts to establish data connection to the public interface. IBM i can not do interface map/behind combining with the port-mapped NAT rules.

A feasible solution is to use firewall NAT rules to hide 21 behind 1021.

A workaround to bypass the failure of compiling the port-mapped NAT rule is to add blank character around ':' in the statement . Now, the rule can be compiled and activated on my local system.
I am still evaluating the possible scenario to use the IBM i port-mapped NAT rule in FTP to achieve customer's goal.

I talked with IP policy owner. The NAT rule compiler has some problems for port-mapped NAT rules.
He suggested to use firewall NAT rule to do the map. If customer insists to use IBM i port-mapped NAT rules, please ask customer to open a PMR to address the port-mapped NAT rule problem.

Hello.
Customer try to define Masquerade (port-mapped) NAT rule on IBM I. Unfortunately there are no examples for this type of rule, only for Masrquerade (hide) NAT and even that doesn't work. For instance the following rule as verification error:

Message Id: TCP5A10
ERROR: An unexpected rules compiler error has occurred.Cause . . . . . : An unexpected error was encountered during the processing of rules. Processing could not continue. Recovery . . . : The following information can assist in determining the cause of the problem - Reason code: 253, Source file: CPIP/PACKETRULES/SARDINHA3.I3P, Source file line number: 6. The above information should be forwarded to service.

# Statements to hide 10.103.15.115 behind 10.103.15.113
# -----------------------------------------------------
ADDRESS HIDE1 IP = 10.103.15.115
ADDRESS BEHIND1 IP = 10.103.15.113
# -----------------------------------------------------
HIDE HIDE1:1021 BEHIND BEHIND1:21 TIMEOUT = 16 MAXCON = 256 JRN = OFF

This actually is not a ftp RFE. I think customer can get help via PMR or service team to figure out how to configure NAT rules to achieve his goal if the customer want to define the port-mapped NAT rules on IBM i. If customer tried to define the NAT rules on firewall, he should refer to firewall supporter.

So, where did the customer define the port-mapped NAT rule? On IBM i system or a firewall ?

When defining the port-mapped NAT on IBM i, he can refer to Knowledge center articles https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzajb/rzajbpdf.pdf?view=kc. In this pdf, there is an example "Scenario: Combining NAT and IP filtering ". In the configuration section, it mentions how to configure the port-mapped NAT rule.
One more thing I got from IP policy developer, the IBM i NAT rules don't allow the same IP address for hide and behind.

Hello.
After a while...the customer return with another request for using both 21 and 1021.
We're trying to implement Masquerade (port-mapped) NAT to FTP server listens on 1021 and a port-mapped NAT can be defined to translate 21 to 1021, however no success till now. Are there any documentation with examples? We tried this manual "Networking IP filtering and network address translation" but no examples.
Thanks

Yes this issue is closed.
Thanks

Does customer satisfy with the solution posted in Dec, 2018?

Ok, we're going to test and try.
Thanks

This is still possible, if combining with the Masquerade (port-mapped) NAT and IP filter.
Assume the ftp server listens on 1021. A port-mapped NAT can be defined to translate 21 to 1021. So, ftp client can connect to 21 and 1021 to access the ftp server. Meanwhile, define an IP filter to deny connection from outer network address for port 21.
Be very careful when defining these rules. A bad rule might cause the system can not be accessed from outside. Suggest to try on development machines first before applying to product system.

Very interesting solution, however ...the problem is the port number: we have to use different ports for external (1021 with SSL) and internal (21 insecure) users..
Thanks.

This is doable with a little complex program if the two types of ftp client users can be differentiated by ftp client IP.

The exit point QIBM_QTMF_SVR_LOGON has 2 input fields of format TCPL0300, one is "Client IP address", the other is defined in "Application-specific information", it is "Control connection security mechanism". An exit program can be built for this exit point QIBM_QTMF_SVR_LOGON which returns corresponding "Allow logon" based on the combination of "Control connection security mechanism" and "Client IP address".
The detailed steps are:
1. CHGFTPA ALWSSL(*YES)
2. build an exit program and register to QIBM_QTMF_SVR_LOGON.
a) When the ftp client IP belongs to internal network, return 1 (Continue the logon operation with the specified user identifier and authentication string.) for field "Allow logon" .
b) When the ftp client IP beongs to external network, and Control "connection security mechanism" is 0 (The control connection is not secured), return 0 (Reject the logon operation) for field "Allow logon" .

But, the port are same for external and internal users, for example, 1021 for both types of ftp users.

More details for format TCPL0300, please refer to https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzaiq/rzaiql0300.htm
And application-specific information can be found in page https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzaiq/rzaiqfaps.htm

Hope this helps.

We have a difficult customer who wants to keep ftp-control port 21 for internal legacy FTP applications and port 1021 ftp-control for FTP over TLS/SSL with FIREWALL communications.
Is that possible to accomplished?

Completely success with the tests, your recommendation works fine with ftp-control port 1021.
Thanks

For now we don't need anything more.
We're testing the configuration you proposed with a small change - ftp-control with port 1021:
1. delete the tcp and udp entries for ftps-control, if customer still wants to use *IMPLICIT FTP, add tcp and udp entries for ftps-control with other ports.
2. delete the tcp and udp entries for ftp-control and add tcp and udp entries for ftp-control with port 1021 or any specified ports.
3. run CL: CHGFTPA ALWSSL(*ONLY), the FTP command is only allowed after AUTH TLS is sent. This satisfies customer's security requirements.

-> ftp-control with port 990 doesn't work!

What's the customer's use case to ask to have the ftp client sends AUTH TLS in IMPLICIT FTPs?

Actually, I do not understand this is necessary. For IMPLICIT FTPs, when the ftp client connects to FTP server, ftp client would challenge immediately the FTP server with a TLS ClientHello message and the connection is secured by TLS to use. I do not see what the ftp subcommand "AUTH TLS" can help here.

I also checked with z/OS ftp developer. When the ftp server listens on 990 port, AUTH TLS and CCC ftp subcommand are not allowed.

Yes that's right we know port 21 could be used with IBM i ALLSSL(*ONLY), however Clients don't agree with that solution and other IBM platforms like z/OS works with Explicit FTP connections with secure ports....
So we would like you to reconsider your position about this and review your recommendation because there is no industry standard for not using EXPLICIT FTP with secure ports and it's more simple and compatible with Firewall Security patterns.
Thanks

IBM i FTP server already satisfies customer's security requirements: use Explicit FTP in passive mode with FTPS Control port 990 or others.

Below is the steps to do the configuration:
1. delete the tcp and udp entries for ftps-control, if customer still wants to use *IMPLICIT FTP, add tcp and udp entries for ftps-control with other ports.
2. delete the tcp and udp entries for ftp-control and add tcp and udp entries for ftp-control with port 990 or any specified ports.
3. run CL: CHGFTPA ALWSSL(*ONLY), the FTP command is only allowed after AUTH TLS is sent. This satisfies customer's security requirements.

But, 990 is not recommended to use as EXPLICIT FTPS. 990 is a default port for IMPLICIT FTPS in industry. Reconfiguration the port 990 to use as EXPLICIT FTPS would confuse the FTP users.

Does anyone know what is needed to have this improvement to IBM i FTP Server made?
Thanks in advance.

Yes that's right we know port 21 is not insecure with IBM i ALLSSL(*ONLY), however Clients don't agree with that solution and other IBM platforms like z/OS works with Explicit FTP connections with secure ports....
Thanks