ntpd -g does not sync the clock

Normally after allowing NTP through any firewall, the first few packets are processed (increasing reach), a system peer is selected, and the initial step fixes the time. This system has reachable peers but rejected them all, which is odd.

After reviewing readvar output, rootdelay=0.000 doesn't make sense. Remote over the internet, cannot be zero. Possibly why you got a flash word of distance threshold exceeded.

A theory from IRC is that NTP packets are being mangled by some middlebox. Which if true would be bad as it apparently broke NTP. ntpd applies dscp to its packets but ntpdate does not. Try dscp 0 in ntp.conf Ask around if differentiated services aware boxes are in the path. Take a packet capture (tcpdump) of NTP packets and look at it in Wireshark. See if it can dissect both any DSCP fields, wrapping NTP packets with NTP timestamps.

Also study ntpd in an entirely different network to contrast what it looks like when working. ntpd can run on anything, so maybe a VM on your workstation.

My original answer with a critique of the config follows.

Your reach recorded there is only 1. Wait 3 minutes after starting ntpd. Takes some time to get the first couple packets returned.

Regarding your configuration:

server time.google.com minpoll 3 maxpoll 4

Consider adding iburst to your server and pool lines. Initial burst at startup of several packets with a short delay.

I am not convinced configuring minpool and maxpool is a good idea, neither is Red Hat. Too frequent for a sustained period and public NTP services may block you. ntpd is already good at dynamically selecting the pool interval.

Need more NTP servers, ideally 4 for detecting falsetickers with n+1 redundancy. Google public NTP has 4 frontends, which you can use with either the pool directive or multiple server lines. Feel free to add other NTP services as a second opinion, like 2.pool.ntp.org. (However you will have a messy leap second smear if your NTP servers don't agree on that.)

No, public NTP services do not require NTP authentication. Authentication is not your problem, allowing large steps and tweaking the poll rate is.

My suggested change for the server line is more like this:

pool time.google.com iburst

As to how you're starting ntpd:

ntpd -g -n -4 -c /etc/ntp.conf &

-g option is necessary to fix such a large offset of many hours, keep it. Allows infinite step once at start. Normally, large offset causes ntpd to panic. Use -g in any script that starts ntpd, so time will be fixed at boot.

I don't see the purpose of no fork plus shell backgrounding. For starting in the background, I use the system's service manager or init script. For example, a ntpd.service unit for Linux with systemd.

Delete -4. Google is IPv6 capable.

If you wish to set the time once and exit, the -q option is useful. For interactive use when troubleshooting, normal operation is leaving ntpd running. Do not use ntpdate, which is obsolete.

ntpd -g -q