Allright, I've found it by myself: it is DNS resolution that behaves differently inside the "cloud" datacenters, at least it is true for the EMEA2 (Amsterdam).
I've changed the automatically assigned internal DNS servers to the Google's DNS (126.96.36.199, 188.8.131.52) in the network interface parameters, and all the public Oracle servers started accepting SSO authentication. Problem solved!
Kind of unrelated info: the speed of download from edelivery to the compute instances is unbelievable, I was able to see up to 50 MB/sec download rate
One word of caution though: complegely removing the default oracle's dns will break some cloud tools, I recommend to keep the Oracle's dns as a secondary to fall back into when the Google's dns doesn't resolve internal URIs.
Thank you for the answer, been looking for a fix to this issue and had looked at the servers DNS name but not the actual DNS server.
You are welcome, Brian.
I've just tried to do the same modification in our new paid cloud subscription and it didn't work this time! Exactly the same that worked for trial - doesn't work in the new compute zone.
I've no idea why, this is really frustrating. Tried it both Linux and windows instances.
Now that we are paid customer, I'll try to open an SR for this subject with the support.
something must have changed since you last did it as it never worked for me, wasn't sure if i was doing it wrong so being testing a few changes.
Interested what they come back with.
Will surely come back here with our findings.
I'll file this as a bug: there is no reason whatsoever why oracle's own support sites should not be available from inside the cloud.
Here is Oracle supports workaround for the issue.
Please resolve public IP for logic.oracle.com and add that to the /etc/hosts. Basically anything on *.oracle.com has to be explicitly added to the /etc/hosts if required. Lastly ensure whatever you add is in fact publicly resolvable from internet.
Entries in host file should look like below.
That's a nasty hack, I hope they will come up with something better somewhere in the future.
Will note this workaround for the next time we need it!
any news from the SR?
We are having the same issue and none of the previous is fixing it (DNS change, /etc/hosts manual entries...)
No, they just responded with literally the same text Brian Dwyer quoted.
I did try to play with hosts file, with no avail. As of now we have to access the sites and download files elsewhere and upload them through the sftp to the cloud instances.
I requested to file my SR as a bug, and it is still in the "Oracle Working" state, for more than a month.
i've one idea for the workaround I'll be testing shortly (going through external proxy hosted outside of oracle cloud), I'll post my update here if it is successful.
The issue is not only at DNS level
if you ping login.oracle.com it is resolved to:
Pinging login.hsd.oraclecorp.com [10.230.86.136]
oraclecorp.com is Oracle's intranet only reachable using Oracle's VPN (and only storing @oracle.com users)
If you set the entry in etc/hosts to:
does not work since that IP is not reachable from that compute zone...
odd they are unable to fix this
These are exactly my observations too.
My wild guess this was done to make some internal Oracle cloud tooling work seamlessly with internal SSO, but nobody was thinking about the impact it could have to outside customers.
I've tried to connect the web browser on the cloud instance through a SOCKS5 proxy and it worked (it was Firefox on Ubuntu 16.4 in this case, but it should work on OL or Windows images too).
So I have a proxy outside of the Oracle cloud and I've set up the Firefox to use it for http(s) and dns forwarding, you can find it under the Advanced / Network / connection menu in the FF.
One caveat though: the http traffic will be all going through the proxy in this case. This means among other things, that you may have to pay for the traffic, depending on the conditions attached to your proxy's hosting, or be limited in bandwidth.