Hello. I have been reading about this OS for a while now, and I wanted to try it myself, but I’m unable to make it work, neither in Qubes nor KVM (Arch Linux) :’(
Whonix-gateway’s Tor daemon always gets stuck at “Bootstraping 45% done, asking for relay descriptors” for hours. I have tried reinstalling in both systems, but still the same. Restarting or reloading tor.service and re-running whonixcheck or Tor-setup neither seem to work. Tor Browser runs without problems in both hosts, so it isn’t (at least exclusively) a network connection issue.
I will be pleased to provide the needed logs, perform any tests or whatever is neccesary to solve this issue, as I really want to start using Whonix.
I don’t live in a censored area, TBB works fine outside of Whonix. I did not change any settings at first, then I tried setting up bridges but it didn’t resolve the isue. Now I have a fresh install and default settings. The clock is set fine as UTC by default.
The Tor log doesn’t show anything inusual aside of this:
Jan 19 22:41:04.000 [notice] No circuits are opened. Relaxed timeout for circuit 6 (a General-purpose client 1-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway. 0 guards are live.
The clock is correctly set, just a few seconds ahead the real UTC time.
There’s one systemd unit that fails in sys-whonix(KVM): mnt-shared-kvm.service. In sys-whonix(Qubes) only service that fails is AppArmor.service (I will check this one later).
I can succesfully ping any server as user clearnet, but I can’t wget (for example “wget http://94.23.250.81” returns “Connecting to 94.23.250.81:80…” without succeeding or failing, and it’s the same with HTTPS requests or any other websites. I don’t know if this is expected or relevant to the issue.
Both interfaces are up and running.
whonixcheck’s output is this, each two seconds:
[INFO] [whonixcheck] Tor Bootstrap Result: Bootstrapping for X seconds. 45 % done. Tor Circuit: not established. Tor reports: NOTICE BOOTSTRAP PROGRESS=45 TAG=requesting_descriptors SUMMARY=“Asking for relay descriptors”
And when it fails:
[ERROR] [whonixcheck] Tor Bootstrap Result:
Whonixcheck gave up waiting after 120 seconds.
Tor Circuit: not established
Bootstrapping 45 % done. Tor reports: NOTICE BOOTSTRAP PROGRESS=45 TAG=requesting_descriptors SUMMARY=“Asking for relay descriptors”
Plus a list of possible issues and reccomendations.
Running whonixcheck with “–debug --verbose” options gives no additional errors.
UPDATE: I guess I should have been more patient. After 1h35min, Whonix finally got connected to Tor. http://pastebin.com/3dzRZPQ3
Now Whonix has downloaded the upgrades at a normal speed, so the only problem is it takes a while for Tor to get bootstrapped. I will update this post if this upgrades fix the issue.
Thanks for your report! This is a rare issue. I wonder where it is
coming from.
Possibilities:
You happened to choose a slow Tor entry guard. Unlikely. As per Tor
default, in order for Tor relays to become entry guards, they need to
fulfill certain criteria. And since this happened to you two times
independently, even more unlikely.
Your ISP is somehow recognizing the connections as Tor connections and
throttling those. Even when you are using bridges. Unlikely. Since it
didn’t happen with TBB. And since you said you’re not living in a
censored area. However, there are censorship methods that exactly work
like this - throttling Tor so much that users hopefully give up on it.
But would be very sophisticated here: somehow detect the connection
being a Whonix Tor connection as opposed to a TBB Tor connection - and
then discriminate Whonix so the user uses TBB instead.
A bug in Tor. (In the version that comes from deb.torproject.org for
Debian jessie.)
A Whonix issue.
What could that be? Especially since it makes Tor slow rather than not connecting. (A firewall issue would much more likely Tor connections totally fail instead of super slow.)
Tor does not need a lot. No DNS or whatsoever. A working TCP internet connection. User clearnet works. [Okay, somewhat.] whonix-gw-firewall iptables rules give user debian-tor full network access.
Using
The clock is correctly set, just a few seconds ahead the real UTC time.
Okay.
There’s one systemd unit that fails in sys-whonix(KVM): mnt-shared-kvm.service. In sys-whonix(Qubes) only service that fails is AppArmor.service (I will check this one later).
All unrelated. [former is a unimportant cosmetic issue which will be
fixed in Whonix 13; the latter see our AppArmor instructions in the wiki)
I can succesfully ping any server as user clearnet, but I can’t wget (for example “wget http://94.23.250.81” returns “Connecting to 94.23.250.81:80…” without succeeding or failing, and it’s the same with HTTPS requests or any other websites. I don’t know if this is expected or relevant to the issue.
Because wget is configured to use Tor by uwt. You need to disable/circumvent that uwt wrapper first.
After updating Whonix KVM VM’s it’s definitely working without problems. I’m not sure whether this is because of the updates or because it already connected once and therefore it has “learned” how to connect.
Same goes with Qubes: it connected after “only” 45 minutes, and after updating and rebooting, everything is working as expected and Tor bootstraps almost instantly.
EDIT: it was not because of the updates, but because of the local data (/var/lib/tor/). As time went by Tor progressively became slower and a few hours ago it didn’t work at all.
I will mess with my router’s configuration and see if anything solves the problem.