Tor being blocked by mayor ISP in Mexico?
I've been running an exit relay for about 2 years. Since new year's day, I noticed that my relay went down and was no longer listed in Globe or Atlas. Just like Fabian Bustillos Vega reported here: https://lists.torproject.org/pipermail/tor-relays/2016-January/008491.html a few days ago.
Software version at the time: (was running without problems for almost five months) Tor: 2.6.10 openSSL: 1.0.1i libevent: 2.0.21 running on Linux
At first, I thought it was a configuration error, so I double checked the TORRC file manually and with software (Vidalia and ARM). Everything was OK.
I check the log file and found something very unusual, when trying to connect to the Tor network, there were several openSSL connection errors. Eventually after a while and several attempts, Tor connection was successful. Here's the error: *[warn]* 8 connections died in state connect()ing with SSL state (No SSL object) *[warn]* 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN *[warn]* Problem bootstrapping. Stuck at 50%: Loading relay descriptors. (Connection timed out; TIMEOUT; count 11; recommendation warn; host 7BE683E65D48141321C5ED92F075C55364AC7123 at 193.23.244.244:443) This happened for other host as well. Link to complete log http://pastebin.com/vUXkfXNf. *See note at bottom.
I thought maybe some Tor's Directories went down or my router was dropping packets for some reason. Several hours later I restarted my router and tried to connect again. I got the same error.
I went to the tor project website and read the release notes, I found that new versions were using a new *elliptic-curve* Diffie-Hellman function, so I decided to update Tor to version 2.7.6. The error appeared once again.
I tried with The Tor Browser and again, it took a while to establish a connection. I had to abort and reconnect several times in order to establish a successful connection. With these results I tried some other software; *TAILS* (Linux distro), *Fire.Onion* (Android browser). Both got stuck as well while bootstrapping. TAILS with no intervention is able to connect after a long long while, just like my Relay. Fire.Onion just like the Tor Browser are unable to connect unless I abort and reconnect several times.
Back to my Relay... When it finally connects: *[notice]* Bootstrapped 90%: Establishing a Tor circuit *[notice]* Tor has successfully opened a circuit. Looks like client functionality is working. *[notice]* Bootstrapped 100%: Done *[notice]* Now checking whether ORPort XXX.XXX.XXX.XXX:9001 and DirPort XXX.XXX.XXX.XXX:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) *[notice]* Self-testing indicates your DirPort is reachable from the outside. Excellent. *[notice]* Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. *[notice]* Performing bandwidth self-test...done.
So I Waited a couple of hours and check in Atlas and Globe again. No luck. In the log I also get: *[notice]* Heartbeat: It seems like we are not in the cached consensus.
The DIR and ONION ports are open as showed by the log, I also manually checked them using port scanners. I used other people's networks, the Tor Browser and TAILS to connect to my XXX.XXX.XXX.XXX:9030 port. In every case I got the DirPortFrontPage (html) served by Tor. As indicated by the log I have client connectivity and the Relay seems to be in order but in reality the Relay is dead.
It is also worth mentioning that after a successful connection the openSSL errors no longer appear in the Relay's log. Maybe Tor is skipping those (previously faulty) servers. I can only guess. A similar thing happen with the Tor Browser, if I open it frequently, it connects fast (after a successful connection), but if is not used in days, when I launch it, it gets stuck while bootstrapping. Since TAILS is a “live” distro I can't reproduce this behavior.
My Relay, the Tor Browser and Fire.Onion have a higher possibility to get stuck while bootstrapping at 0, 5, 20%. Once passed the 50~60% it get faster. My assumption is that my ISP is blocking or at least randomly dropping packets to and from well known Tor Authorities (IP blocking). I don't suspect DPI, as client functionality is working. Using bridges was not necessary when trying client functionality. I was able to connect (abort and retry). As reported by Fabian Bustillos as well.
Other Observations: Tor Project https://www.torproject.org/ website, TAILS https://tails.boum.org/ website and other Tor related pages are visible without tor. Once connected the Tor Browser is able to fetch updates. Instead of ports 9001 and 9030 I also tried 443 (OR) and 80 (DIR). *For the log, I deleted the Data directory in order to reproduce all the errors, this includes; keys, logs and cached* files.