Re: SNDPTFORD resolving to strange, unknown local IPs

On 31-Jul-2015 09:00 -0600, Steinmetz, Paul wrote:

I've been using the
TRCINT Trace type . . . . . . . . . . .> *SCKSSL
to monitor my SSL changes.

I found something unusual.
In the TRCINT, whenever I do a SNDPTFORD, the local IP is populated
with a strange, unknown local IPs,
198.74.64.168, 198.74.64.38, 198.74.64.52
Shouldn't it be one of two IPs that I have assigned to this LPAR.
Can anyone explain this?

SSLDAT SSLTIM SSLVER CIPHER LPORT LIP RPORT RIP
07/30/15 08:51:35.328116 TLSV1.0 TLS_RSA_WITH_3DES_EDE_CBC_SHA 11036 198.74.64.168 443 207.25.252.200
07/30/15 09:09:44.467380 TLSV1.0 TLS_RSA_WITH_3DES_EDE_CBC_SHA 34898 198.74.64.38 443 207.25.252.200
07/30/15 10:24:43.341012 TLSV1.0 TLS_RSA_WITH_3DES_EDE_CBC_SHA 64434 198.74.64.52 443 207.25.252.200

The Send PTF Order (SNDPTFORD) uses communications according to parameter specifications on that command and the Electronic Customer Support (ECS) setup established under\for the Electronic Service Agent (ESA) [with the Universal Connection Wizard or IIRC with the Create Service Configuration (CRTSRVCFG) and\or the Change Services Attribute (CHGSRVA) CL command(s)]. The specific request described, had apparently setup and then initiated a Virtual Private Network (VPN) to make the connection; i.e. of the ESA connection method choices, an Internet virtual private network (VPN) was likely the effect, for which the local IP addresses are active to establish the connection for whatever was the type of communication.

p.s. I recall reading [¿perhaps in the MTU for v7r2?] that Dialup modem connections were removed from ESA and that actual PTF orders over VPN were no longer going to be supported at IBM i 7.2 [which likely is the release being used?].