Donald, Is your z/OS system the client or the server? There's a few approaches to take...
1.) In the "SYSFTPD" configuration, ensure that a line specifies: "TLSRFCLEVEL CCCNONOTIFY" http://www-01.ibm.com/support/docview.wss?uid=isg1PK67193 2.) You may also try enabling EPSV4 in the "SYSFTPD" configuration: "EPSV4 true" 3.) If neither of the above work, ask the network administrators to open up ports 1024 and above or, if they complain about it, a range of ports. In the configuration for the ftpd server on whichever end, enter that port range so the server will always allow those to pass through. Did they change the networking hardware? Or did they just make some arbitrary decision that they were going to "harden" things up? Scott On Mon, Jan 4, 2010 at 4:12 PM, Donald Russell <russell....@gmail.com>wrote: > The troubleshooting *I've* done is quite minimal. I'm not an MVS sys > prog. I developed a TSO clist (REXX) that runs as a batch process > (PGM=IKJEFT1A) to send files to a zLinux system. It was all working > fine, I saw the messages about "successful negotiation", and the > transfer continued successfully. > > A few weeks ago, that changed... now I get "negotiation failed", and > the "required" authentication causes FTP to exit. > (At first I thought my cert had expired... I went through all that...) > > In reporting this to our MVS people, they did a trace and determined > the cause to be a firewall issue. They say the cert is being > mangled... you say it's due to not being able to monitor the control > channel. > > FTP fails with "TLS negotion Failed". > > Now that the holidays are past, I hope to get to the correct people to > find out when things changed. As I mentioned, this was working fine at > one point. > > I'm told the firewall has to be specifically configured for FTP/SSL... > and those requests were never done... (So, why did it ever work? hmmm) > > > > > > On Mon, Jan 4, 2010 at 15:29, Scott <sc...@aitrus.org> wrote: > > Donald, what troubleshooting have you done? I'm happy to help you work > > through the issues, as there's a few solutions/workarounds for you to > try. > > > > I've worked through our own firewall issue and even some instances where > two > > firewalls were at play. It's not mangling the Digital Certificate. > Rather, > > it cannot monitor the control channel and the client/server connection > drops > > after negotiation. > > > > Scott > > > > On Mon, Jan 4, 2010 at 2:54 PM, Donald Russell <russell....@gmail.com > >wrote: > > > >> Until recently, I was using FTPS to send data from MVS to zLinux.... > >> then it broke. > >> Apparently somebody (re)configured a firewall so it now stops the AUTH > >> TLS portion of the negotiation or something.... the symptom is the > >> authentication negotiation fails... I'm told it's because the firewall > >> mangles the digital certificate. > >> > >> SFTP works fine using USS... but I don't have USS on all the MVS > >> systems I need to send data from... > >> > >> Is there a way to run SFTP (FTP/SSH) from MVS without USS? > >> > >> (If I can do that, I can avoid tracking down the firewall people to > >> get the FTP/TLS thing working.... I PREFER to use SFTP, but FTPS is > >> acceptable... and I want the process to be the same on all the MVS > >> systems, not sftp here, ftps there...) > >> > >> Cheers > >> > >> > >> On Mon, Jan 4, 2010 at 13:50, Scott <sc...@aitrus.org> wrote: > >> > Packet inspection? Weird. > >> > > >> > You can, with FTPS, open up the control channel so the Firewall can > >> monitor > >> > the control connection (port 21), which lets it dynamically assign > ports > >> > that the server/client negotiate for the data connection (aka port > 20). > >> > SFTP (SSH) is entirely encrypted and cannot have its activity > monitored. > >> > > >> > Scott > >> > > >> > On Mon, Jan 4, 2010 at 1:01 PM, Hal Merritt <hmerr...@jackhenry.com> > >> wrote: > >> > > >> >> Trying to do some due diligence in planning some data transfers and > >> getting > >> >> really confused. > >> >> > >> >> Many seem to be saying that all FTP traffic has to be encrypted to > meet > >> PCI > >> >> standards. And yet I cannot find any such statement in the PCI > >> standards. > >> >> But I did find a requirement for firewall packet inspection which, I > am > >> >> told, is impossible if the traffic is encrypted. Did I read that > right? > >> >> > >> >> > >> >> NOTICE: This electronic mail message and any files transmitted with > it > >> are > >> >> intended > >> >> exclusively for the individual or entity to which it is addressed. > The > >> >> message, > >> >> together with any attachment, may contain confidential and/or > privileged > >> >> information. > >> >> Any unauthorized review, use, printing, saving, copying, disclosure > or > >> >> distribution > >> >> is strictly prohibited. If you have received this message in error, > >> please > >> >> immediately advise the sender by reply email and delete all copies. > >> >> > >> >> > ---------------------------------------------------------------------- > >> >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN > INFO > >> >> Search the archives at http://bama.ua.edu/archives/ibm-main.html > >> >> > >> > > >> > ---------------------------------------------------------------------- > >> > For IBM-MAIN subscribe / signoff / archive access instructions, > >> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN > INFO > >> > Search the archives at http://bama.ua.edu/archives/ibm-main.html > >> > > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > >> Search the archives at http://bama.ua.edu/archives/ibm-main.html > >> > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
