Well, your point is made und understood, but active mode is the one using PORT; passive mode uses PASV. They both have their FW/load balancer issues.
We tend to use a variety of "fixes" for the various issues, given our convoluted (typical?) environment. EPSV can help. Some clients have the option to ignore PASV IP returned. Our load balancers host our server certs in some cases so they can decrypt and modify the IP. Our MFT proxy cluster has multiple nodes of FTP server adapter pairs, and each can be defined to return the same IP in the PASV response (they are session-break proxies, so they don't use the MFT servers' certs for encryption; they use their own); this IP would be the exposed forwarding VIP on the internet. There are other things, I'm sure I'm forgetting. Switch to SFTP, and life gets much easier--most of the time. First Horizon Bank Mainframe Technical Support -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Charles Mills Sent: Friday, June 12, 2020 2:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How is Passive FTP with TLS and NAT supposed to work? [External Email. Exercise caution when clicking links or opening attachments.] X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both urgent for us and perhaps a little obscure. With Passive FTP, the server uses a PORT command to say to the client "open the data connection on this IP address." Unfortunately with NAT that is an internal address that is meaningless at the client. Many firewalls or routers that support NAT are apparently smart enough to translate that PORT command from an internal to an external address, and everything works wonderfully. The wrinkle comes with TLS: the control connection is encrypted and inaccessible to the firewall or router. Enter CCC: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha lz001/ftpcastlsrfclevel.htm https://tools.ietf.org/html/rfc4217#page-19 CCC says "stop encrypting the control connection (so the router or firewall can see and translate it). Apparently -- and this is where my knowledge gets fuzzy -- the RFC now requires that the partners close the control connection at that point, but z/OS FTP perhaps does not support that (?). CCC has security red flags all over it, which is understandable, and it looks like we may be encountering a firewall or router that does not support it, or perhaps does not support the non-RFC version of it. I am asking here "what is the 'right' answer?" How is passive FTP supposed to work over a TLS session with NAT in effect? Charles ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN