Just for completeness, we understand now what happened: 1. Jun/2022 - the delivery servers IP addresses changed to the ones described in https://www.ibm.com/support/pages/ibm-software-electronic-delivery-servers-change 2. Nov/2023 - the 129.35.xxx.xxx IP addresses changed as described in https://www.ibm.com/support/pages/node/7030591
Therefore, the 129.35.xxx.xxx IP addresses are wrong in https://www.ibm.com/support/pages/ibm-software-electronic-delivery-servers-change (the document we originally followed) We will ask IBM to fix that. Thanks all, ------------------------------------------------------------------------------------------------------------------------------- *Lucas Rosolen* [email protected] / linkedin.com/in/lrosolen/ <https://www.linkedin.com/in/lrosolen> Em ter., 8 de abr. de 2025 às 11:41, Lucas Rosalen <[email protected]> escreveu: > Thanks Alex. > > The only problem is that we do not select the servers where we download > maintenance from. > We select an IBM server to place the order (either eccgw01.boulder.ibm.com > or eccgw02.rochester.ibm.com), then you order is automatically placed in > one of the download servers (the ones in IBM Software Electronic Delivery > Servers Change > <https://www.ibm.com/support/pages/ibm-software-electronic-delivery-servers-change>), > and the download happens automatically. > > Anyway, thanks again for your inputs, they helped a lot! > > > ------------------------------------------------------------------------------------------------------------------------------- > *Lucas Rosolen* > [email protected] > linkedin.com/in/lrosolen/ <https://www.linkedin.com/in/lrosolen> > > > > Em ter., 8 de abr. de 2025 às 10:18, Alexander Huemer < > [email protected]> escreveu: > >> On Tue, Apr 08, 2025 at 09:33:47AM +0200, Lucas Rosalen wrote: >> > We have a strange behavior when attempting to download maintenance use >> SMPE >> > Receive Order. >> > >> > As indicated here ( >> > >> https://www.ibm.com/support/pages/ibm-software-electronic-delivery-servers-change >> ), >> > our firewall has been opened for: >> > deliverycb-mul.dhe.ibm.com - 129.35.224.118 >> > deliverycb-mul.dhe.ibm.com - 170.225.126.48 >> > >> > However the download fails. >> > >> > When we ping deliverycb-mul.dhe.ibm.com, it resolves to >> 170.225.119.154, >> > not to the IPs above. >> > We tried ping/nslookup deliverycb-mul.dhe.ibm.com from several clients, >> > from our own laptops in different networks, but they all resolve the >> same. >> >> In DNS on the public internet, deliverycb-mul.dhe.ibm.com is a CNAME to >> deliverycb-mul.dublindata.ibm.com., which in turn resolves to >> 170.225.119.154 currently. >> >> > We have a case opened with IBM, but they say don't support DNS >> resolution. >> >> Well, that is a contradiction in itself, for a number of reasons. >> * The website at [1] clearly states the FQDNs (they call them hostnames >> there). >> * Apparently the webserver that feels responsible for >> deliverycb-mul.dhe.ibm.com has a vhost set up for that FQDN only, not >> for the IP address. if you punch, let's say https://170.225.119.154/ >> into your browser, you are being served a certificate that is valid >> for the FQDN only, not for the IP address. Your browser is going to >> warn you about that condition, will allow you to continue though, as a >> match is not enforced. >> >> If they do not support DNS resolution, why are there DNS entries for the >> servers? Why are the web servers configured so that they only accept >> requests targeted at those FQDNs? >> Anyways... Provided DNS wouldn't be there at all and you still wanted to >> download from those servers. You could either instruct your download >> program to talk to that specific IP, e.g. >> >> $ curl --connect-to 170.225.119.154:443 >> https://deliverycb-mul.dhe.ibm.com >> >> Or you can associate the IP address with the FQDN in /etc/hosts or >> whatever the equivalent on Windows is. >> >> What really happened here is that they changed the IP adddresses of >> their servers for some unknown reason and neglected to drive appropriate >> customer communication and also neglected to update the documentation >> that you pointed to. >> >> Assuming that no funny business is happening here, you can just update >> your firewall rules to allow traffic to the 'new' IP address and be done >> with it. Modern firewalls can also whitelist DNS entries... >> >> The whole thing does not smell strange, the 'new' IP address is owned by >> IBM. I wouldn't worry too much about this. >> >> -Alex >> >> [1] >> https://www.ssllabs.com/ssltest/analyze.html?d=deliverycb-bld.dhe.ibm.com >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
