Tor bootstrapping takes a very long time - 90 minutes / 1 h 30 min

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.

Thank you in advance!

Do you live in a censored area?

Have you got Tor Browser Bundle to work anywhere outside of Whonix yet?

Did you change any Whonix settings inside Whonix? Such as related to
networking or did you change the clock?

Check your Tor logs. See if there are any clock related or other
interesting messages.

Tor - Whonix

Thank you for the fast reply Patrick.

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.

Here is the full log anyway: http://pastebin.com/YWcZQ5zP

Then it’s really strange that neither Whonix KVM nor Qubes-Whonix works
for you.

Can you please check the clock inside sys-whonix? Set to UTC is
expected. Check using

date

Then look on the web for the time in UTC. See if that matches. (plus or
minus 5 minutes would not matter)

Since KVM is involved, /cc’ed @HulaHoop.

See if any systemd units failed.

sudo systemctl list-units --failed

More ideas…

Login as user clearnet.

sudo su clearnet

Try to ping some IP. (no hostnames, because Whonix-Gateway by default
has on purpose no system DNS resolver)

If you don’t mind to ping google.

ping 8.8.8.8

See if that works.

And see if both network interfaces are there.

sudo ifconfig

Does whonixcheck run on the gateway output anything we don’t know yet?

whonixcheck

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.

Stream Isolation

The following would be a better test command.

curl.anondist-orig --silent --tlsv1 --proto =https -H 'Host: check.torproject.org' -k https://38.229.72.22 | grep IP

It’s a rare issue. I remember a report where a user stated that its router was the cause of connection issues because it filtered ports.

https://groups.google.com/d/msg/qubes-users/plcsL6bS1U0/QKxWppOlDAAJ

(I just now requested further information on that.)

Could that be the cause in your case also?

Something that you could also try if it is appliable for you is the FascistFirewall setting which is now documented here:
Configure (Private) (Obfuscated) Tor Bridges

(I’ll try to use this thread also to help other users with similar connection issues.)

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.