Hi,
My previous setup had a working whonix 16 configuration, but with whonix 17 I am having issues. The main issue is that sys-whonix cannot establish a tor circuit.
I have read the qubes-whonix manual and troubleshooting guide, including the complete reinstallation of the templates, and the salt step. The gateway is still not working as expected.
But if I install tor client and browser on a separate appVm, it can establish the circuit.
Is there any known issue/workaround here?
Thanks
Before anything else, if you right-click the padlock in the top-right region of the panel, then hover over sys-whonix, then click on “Tor control panel” in the menu that appears… you get a window with 3 tabs, last of which is “Logs”.
Probably the reason for not establishing a Tor circuit is somewhere there.
Do you have Qubes OS 4.1 or Qubes OS 4.2?
If Qubes OS 4.2 then did you do a fresh install or an in-place upgrade from Qubes OS 4.1?
If it’s a fresh install of Qubes OS 4.2 then do you use the Whonix templates installed during Qubes OS 4.2 installation or did you restore them from backup?
I am using Qubes 4.2. But in the past I had restored whonix 16 backups from r4.1 to Qubes 4.2, during the times when whonix 17 was not available yet. But I have read through the glitch that occurred in the past and I believe cleaned it up. And during the reinstallation, cleaned up everything documented.
I have installed fresh templates from the template manager and run salt.
There might be something with anondate and time sync in general.
Also the sys-whonix domU guest had 1 minute time offset when compared to dom0 and other vms, whose time are correct. But even after fixing that manually on sys-whonix, after rebooting sys-whonix, the difference persisted.
In sys-whonix after manually fixing the time difference and subsequently restarting the networking service, the sys-whonix journal reports this
1 ____ ### START: ### /usr/sbin/anondate-set
2 ____ INFO: Status file '/run/sdwdate/tor_certificate_lifetime_set' does not yet exist.
3 ____ INFO: Running anondate-get...
4 ______ ### START: ### /usr/sbin/anondate-get
5 ______ WARNING: Tor bootstrap not done.
6 ______ INFO: Attempting to determine Tor consensus time middle range...
7 ______ WARNING: Could not determine Tor consensus time middle range.
8 ______ INFO: Attempting to determine Tor certificate lifetime...
9 ______ INFO: Tor certificate lifetime valid, ok.
10 ______ INFO: Could not determine a time later than minimum time from either Tor consensus time or Tor certificate lifetime, ok.
11 ______ INFO: Showing minimum time instead as result...
12 ______ INFO: minimum time: '2023-06-12 00:00:00'
13 ______ ### END: ### Exiting with exit_code '0' indicating 'Showed Tor consensus time middle range or minimum time.'.
14 ____ INFO: anondate-get returned Tor consensus middle range time or minimum time.
15 ____ INFO: The 'anondate-get' time_result is earlier than the current system time, ok. Not setting clock backwards.
16 ____ ### END: ### Exiting with exit_code '3' indicating 'Setting time using anondate either not possible or not required.'.
I have no idea if this is expected or not. It is interesting that the sys-whonix had almost 1 minute time offset, perhaps deliberately randomizing it.
Random time shift is an intended feature, not a bug.
Check the tor log, maybe there will be some info why it fails to connect.
I don’t see any errors or similar info in the tor logs. Just a bunch of listening sockets.
On the other hand,
In which qube?
sys-whonix
What’s the output of these commands in sys-whonix?
ip a
ip r
ip addr output:
1. lo: ...
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ...
inet 10.137.0.12/32 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether ...
inet 10.137.0.12/32 brd 10.255.255.255 scope global eth1
valid_lft forever preferred_lft forever
ip route returns empty
Set sys-whonix net qube to none, run this command in sys-whonix terminal:
sudo journalctl -f -n0
Set sys-whonix net qube to sys-firewall.
Check the log to see the errors related to the network.
I think there is something:
Sep 25 11:20:36 host systemd[1]: Starting qubes-network-uplink@eth0.service - Qubes network uplink (eth0) setup...
Sep 25 11:20:36 host setup-ip[7563]: Error: ipv6: IPv6 is disabled on this device.
Sep 25 11:20:36 host systemd[1]: qubes-network-uplink@eth0.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Sep 25 11:20:36 host systemd[1]: qubes-network-uplink@eth0.service: Failed with result 'exit-code'.
Sep 25 11:20:36 host systemd[1]: Failed to start qubes-network-uplink@eth0.service - Qubes network uplink (eth0) setup.
Sep 25 11:20:36 host (udev-worker)[7537]: eth0: Process '/usr/bin/systemctl restart --job-mode=replace qubes-network-uplink@eth0.service' failed with exit code 1.
Did you enable ipv6 feature for sys-net/sys-firewall/sys-whonix?
sys-net: ipv6 flag set to 0
sys-firewall and sys-whonix: ipv6 flag not set
Run this command in sys-whonix:
sudo sed -i '2i set -x' /usr/lib/qubes/setup-ip
Then run this command:
sudo journalctl -f -n0
And this command in another terminal:
sudo systemctl restart qubes-network-uplink@eth0.service
And post the journalctl command output.
(I was going to post the journal lines, but sys-whonix journal data gets reset after reboot)
Apparently, ipv6 in sys-net and sys-firewall was enabled.
After explicitly disabling ipv6,
qvm-features sys-firewall ipv6 '' and also for the sys-net,
the eth0 interface in sys-whonix is up.
systemcheck also reports OK.
I think whonix-qubes documentation might consider add this as a troubleshooting step.
It’s better to suggest it here so Whonix devs will see it:
http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/c/qubes-whonix/12