Re: Subject: Re: SSL and Firewall Fun

    Steve,

        Boy this is a whole a different issue than I saw on yesterdays post.
If I am now reading this correctly there is a setup routine that is
executing in the CA install early enough in the process that it is not SSL
aware.  From your experience it is running once and only once, per system ?

        So my first question, would be are you comfortable enough with the
Daemon handling this initialization request that you would allow it to
except connections if the port is secure or even unsecure ?  What's in the
conversation anyway ?  The users actual password, or a dummy user that is
only usable for CA installation, with very limited access, or is it in the
form of a system management MIB just exchanging only some connectivity data
??

        My second question, are you sure this link is not used to allow you
distribute updates, and ptf's to the individual system ?  Or are you
disabling this feature so it does not matter ?

        My third question, is this connection only to the Managing system,
or once to each "host" system (IP Address) you connect with ?

        Based on the answers, which I readily admit I do not have.  You
might look at configuring a secondary  IP for the system that will only
accept  connections on port 8476.  Either through IP Filter rules and/or
Firewall NAT mapping to a private IP.   Then if the daemon is trusted and
the password if used is only valid for this process you should tight ?

        On the other hand, I like using GHOST to build a system that has
already been setup, or adding the registry fix as both seem cleaner, except
that you may have more help desks calls when the connections failure ??

Jeffrey M. Silberberg
Independent Consultant
CompuDesigns, Inc.

AS SOON AS I KNOW THE ANSWERS
THEY CHANGE THE QUESTIONS


----- Original Message -----
From: Steve Glanstein <mic@aloha.com>
To: mr <midrange-l@midrange.com>
Cc: "Simon Coulter" <shc@flybynight.com.au>
Sent: Sunday, August 12, 2001 9:28 AM
Subject: Subject: Re: SSL and Firewall Fun


> Hello Simon et al:
>
> Thanks for the response...let me recap problem and the two solutions that
I
> found...
>
> Here's the problem...
>
> First, assume a good SSL setup and latest service pack...which I have.
>
> The first connection for any new environment goes to port 8476 to obtain
> information about the "host" AS/400.
>
> After it goes there once, it never needs to repeat the process.
>
> Thus, when we tested PC1 PRIOR to enabling any host filter rules, client
> express worked. We connected to ports 9470+ and everything looked good.
>
> After the filter rules were enabled, PC1 still continued to work.
>
> We installed Client Express with SSL on PC2. It was unable to connect
using
> SSL. The host (in our case, the AS/400) has a journal called QIPFILTER
which
> we used to log rejected TCP/IP requests. This journal showed port 8476 as
a
> "DENY."
>
> Spoke to some IBMers yesterday...turns out one other person in the country
> had this problem and their solution was to enable to non-SSL port...which
is
> unacceptable!
>
> It turns out that you can defeat this problem two ways: One way is to make
a
> registry update to provide the version and release number to the
> environment.
>
> A simple Batch file that does the following will "fool" the computer...
>
> REGEDIT4
>
> [HKEY_CURRENT_USER\Software\IBM\Client Access
> Express\CurrentVersion\Environments\My AS/400
> Connections\NISSAN-HI.COM\Communication]
> "Version Release Level"=dword:00040400
>
> --------------------------------
>
> The second way ... which appears even better is to use CWBBACK which backs
> up the configuration to a couple of disk files. Then we use CWBREST to
> restore the configuration to the newer computer. This appears to work.
>
> --------------------------------
>
> Thanks,
>
> Steve Glanstein
> mic@aloha.com
>
> _______________________________________________
> MIDRANGE-L mailing list
> MIDRANGE-L@midrange.com
> http://lists.midrange.com/cgi-bin/listinfo/midrange-l