Qubes-Whonix ™ Tor Connectivity and sdwdate Troubleshooting

From Whonix



Occasionally, mostly since the release of Qubes R4.1, Qubes-Whonix ™ user are reporting connectivity issues as well as sdwdate issues. However, a lot issues Qubes-Whonix ™ connectivity issues are unspecific to Whonix ™. These issues are often misattributed to Whonix ™.

Even though the issue is happening inside Whonix ™, the cause is most often unrelated to Whonix ™ source code. Qubes is developed by Qubes OS Project, which is an independent entity. The is the norm in Linux distributions. To learn more about such relationships see link=https://www.kicksecure.com/wiki/Linux User Experience versus Commercial Operating Systems Linux User Experience versus Commercial Operating Systems . A different issue could be a Network Obstacle.

Whonix ™ does integration work Whonix ™ integrated into the Qubes platform. To use a simple analogy, Whonix ™ stays "on the outside". Very few modifications are made to Qubes through Qubes dom0 package qubes-core-admin-addon-whonix as described for developers in the Qubes-Whonix ™ qvm-tags chapter.

Qubes R4.1 was released with some "strange" connectivity bugs such as this.

A Qubes user might think the user has updated Qubes which should include bug fixes but actually the update might not have happened due to Qubes Updater issues. Quote:

The situation is however complicated due to Qubes Updater Issues, most notably such as:

To remedy this kind of issue, there are a few approaches.

Qubes sdwdate specific[edit]

It is often suspected that sdwdate might be the cause.

This is unlikely. No issues are reported for Whonix ™ on other platforms such as Whonix ™ for VirtualBox which has a magnitude of more users but no (or very rare) similar connectivity bug reports.

sdwdate-gui makes Tor issues in Qubes-Whonix ™ more visible due to its graphical indication and easily accessible logs.

However, at time of writing sdwdate-gui is mostly a unsuitable connectivity troubleshooting tool.

To exclude the possibly that sdwdate is the cause, the user could attempt to disable the autostart of sdwdate.

Connectivity Troubleshooting Approaches[edit]


1. The user is encouraged to learn about general (unspecific to Whonix ™) Qubes Updater issues and make sure updates are really installed. See also Qubes/Update.

2. Connectivity Troubleshooting

3. Tor Connectivity Troubleshooting

Qubes sys-net workaround[edit]

Complete the following steps:

  1. Shut down sys-whonix.
  2. Change the sys-whonix NetVM setting from sys-firewall to sys-net.
  3. Restart sys-whonix.

This procedure might help, but should not be considered a final solution. [1]

Please report if this workaround helped.



suspend resume related[edit]

Potential fix:

Properly suspend all VMs, not only those with PCI devices #473

clocksource tsc vs xen[edit]


The community is encouraged not to wait for Whonix ™ to fix these connectivity issues since this unfortunately is unlikely to happen. This is because Whonix ™ developers are not affected by these connectivity issues, these are non-reproducible issues and sometimes these are caused by already fixed Qubes bugs which are not yet fixed on Qubes due to Qubes Updater issues.

Related Qubes Bugs[edit]

Unexpected autostart of sys-whonix[edit]

If using multiple Qubes-Whonix ™ VMs, the user should make sure to have followed the relevant documentation.

3 components are related here.

On the Multiple Qubes-Whonix Templates wiki page take special note of the warning box in the UpdatesProxy chapter.

sdwdate-gui qrexec settings[edit]

sdwdate-gui qrexec settings fix[edit]

This wiki chapter is valid as of July 2022. It might be expired by August 2022.

A fully updated Qubes should not require any of the following steps.

1. 80-whonix.policy on github (raw) should look same as /etc/qubes/policy.d/80-whonix.policy in dom0.

2. The following files are legacy and could optionally be safely removed if step 1 was confirmed.

sudo rm /etc/qubes-rpc/policy/whonix.GatewayCommand

sudo rm /etc/qubes-rpc/policy/whonix.NewStatus

sudo rm /etc/qubes-rpc/policy/whonix.SdwdateStatus

sdwdate-gui qrexec debugging[edit]

Debugging Qubes qrexec is largely unspecific to Qubes-Whonix ™. Qubes qrexec debugging instructions from other resources such as perhaps the Qubes website should equally apply.

Note: Any commands that follow must be run inside Qube dom0.

1. Background information on qvm-tags.

See if you can make head or tail of qvm-tags developer notes. If not, skip this step.

2. Check qvm-tags of Whonix-Gateway ™ net qube.

qvm-tags sys-whonix

Expected printout should include:


3. Check qvm-tags of Whonix-Workstation ™ App Qube.

qvm-tags anon-whonix

Expected printout should include:


4. Check qvm-tags of Whonix-Gateway ™ Template.

qvm-tags whonix-gw-16-16

Expected printout should include:


5. Check qvm-tags of Whonix-Workstation ™ Template.

qvm-tags whonix-ws-16-16

Expected printout should include:


6. In dom0, check, follow journallog while reproducing sdwdate-gui qrexec messages.

Look for DENIED messages.

sudo journalctl -f

See Also[edit]


  1. This procedure was useful for Qubes-Whonix ™ R3.2 users, although the Qubes bug report is now resolved: https://github.com/QubesOS/qubes-issues/issues/2141