Run clocksync in Firewall VM

In my network setup, I am using two separate network qubes for Ethernet (sys-net-lan with sys-firewall-trusted) an WiFi (sys-net-wifi with sys-firewall-untrusted) connection.
At work, our Intranet is Ethernet-based and this link does not allow any external connections. Therefore, I have configured my Qubes to use the Wifi net VM as clock-VM. “clocksync” service is enabled in this VM and in the global settings, it is configured as “ClockVM”.

However, there are certain scenarios in which I don’t have a WiFi connection. For example, at home I connect the laptop via Ethernet and route work traffic through a dedicated VPN VM. In this moment, sys-net-lan takes over the role of sys-net-wifi by providing untrusted Internet access (by connecting sys-firewall-untrusted to sys-net-wifi), and sys-vpn replaces sys-net-lan by providing a trusted network connection to everything work-related through sys-firewall-trusted.
In all cases, sys-firewall-untrusted has a direct Internet connection.

During longer periods without WiFi connection, the internal clock will diverge from the actual time. This is why it felt natural to move the clocksync service one step up the network chain and enable it in sys-firewall-untrusted. No matter the physical network connection, this VM should always be able to synchronise its clock via ntp.
When testing this setup (making sure that “clocksync” service is enabled in the firewall VM and that “ClockVM” is changed accordingly in the global settings) my colleagues and I have experienced that no reliable clock synchronisation is happening.

Is there any mechanism inside of Qubes that requires the clocksync to be running in an actual network VM?
Might this even be related to Properly suspend all VMs, not only those with PCI devices by marmarek · Pull Request #473 · QubesOS/qubes-core-admin · GitHub (which I found by chance when searching for this issue)?

sudo date -s “$(wget -qSO- --max-redirect=0 2>&1 | grep Date: | cut -d’ ’ -f5-8)Z”

If you are in a NATO country this should work in any Linux. i2p implemented network time based on this. Tor has a different system. Do not use in Whonix WS that uses time shift for security. Not related: Iondine (DNS over ipv4) it is also a security risk in Whonix. If you have a USB GPS your problems are over with the template found I2P for QubesOS updates - #11 by i2p (yes it is a pitch for you to join i2p)

While this is a nice thing to know (I personally wouldn’t use Google tough, but you should be able to change this for any reliable source that you want) I don’t see how this relates to my issue.

In theory, there already is a clocksync service that can be uses right away (based on the NTP protocol instead of (ab)using the much more bloated HTTP protocol). It just seems that this service doesn’t work as expected.