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)?