Well there you go: the hangup in the "Licensing and Activation" page confirms the root cause. As for the 404, that's an ok thing. It wants a specific call, but at least that confirms cf could reach it.
The call to that specific ip may be the real hangup for you. As you may know, it's a special address used for local routing. You can find more on it at this article.
And perhaps someone else here may offer a ready solution for what's needed next for you. Until then, I have more diagnostics ton consider.
First, what happens if you ping or curl that ip on the server's command line? Does that hang up?
And note the article I shared concludes with mention of how one might want to limit calls to it via iptables. That raises the interesting question of whether perhaps it is for some reason blocked. Can you check for any iptables logging, or just check your iptables rules for any related to that ip address or pattern?
Indeed, that article indicates how they'd recommend blocking calls to that ip for processes running as other than root. That raises an interesting thought: when you installed cf, you probably told it to run as other than root. You could try changing it to run as other than root. Does that then change this hangup?
Finally, if somehow the above prove fruitless or challenging, we can consider more diagnostics from a cf perspective. Can can you look at cf's http.log to see if it's tracking anything related to this activation hangup? Note that it tracks the start and end of requests. I'm not saying all calls out of cf get logged there (some, like these, may be too low-level), but it's worth a shot.
Otherwise both the cf pmt (new since cf2018, and optionally installed) and fusionreactor (commercial, with free trial) can also track calls out of cf, which might also help here.
These are among the things I alluded to at the end of my first reply. I realize it may be a bit much for some to stomach, if they just want the problem solved (without having to figure out such things). To that, I'll note in conclusion that I can help directly, remotely via screenshare. More on that (rates, approach, satisfaction guarantee, online calendar, and more) at carehart.org/consulting.
But I do hope you may resolve this with what I or others may share, or you may find on your own. Please do let us know how it goes. It seems an important challenge that others might experience.
The ping to 169.254.169.254 made the router at our provider to answer with "network not reachable".
The curl to 169.254.169.254 created exactly the same hang-up-behaviour.
Rejecting this IP-address at the local firewall did the trick 🙂
iptables -A OUTPUT --destination 169.254.169.254 --jump REJECT
Thanks alot for your time and support! Have a great day!