May 2018 - tor-relays - lists.torproject.org

Verizon AS701 blocking Tor consensus server tor26 (86.59.21.38)
by Neel Chauhan 24 May '18

24 May '18

Hi tor-relays mailing list, I have noticed that the Tor consensus server tor26 (https://metrics.torproject.org/rs.html#details/847B1F850344D7876491A54892F9…) is blocked on Verizon's UUNET (AS701) backbone, and therefore, Verizon's retail services like FiOS and Wireless. I can confirm this on FiOS, but I don't use Verizon Wireless (my smartphone uses Sprint) so I can't test it there. A traceroute to tor26's IP address 86.59.21.38 from a Brooklyn apartment shows this is filtered on Verizon's backbone: neel@xb2:~ % traceroute 86.59.21.38 traceroute to 86.59.21.38 (86.59.21.38), 64 hops max, 40 byte packets 1 unknown (192.168.1.1) 1.128 ms 0.780 ms 0.613 ms 2 lo0-100.NYCMNY-VFTTP-401.verizon-gni.net (173.68.77.1) 1.001 ms 3.632 ms 0.900 ms 3 B3401.NYCMNY-LCR-22.verizon-gni.net (100.41.137.96) 2.291 ms B3401.NYCMNY-LCR-21.verizon-gni.net (100.41.137.94) 3.172 ms 4.046 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * ^C neel@xb2:~ % In a normal traceroute, you will see ALTER.NET at hop 5. Also, the subnet 86.59.21.0/24 is not filtered on UUNET. A traceroute to 86.59.21.1 works: neel@xb2:~ % traceroute 86.59.21.1 traceroute to 86.59.21.1 (86.59.21.1), 64 hops max, 40 byte packets 1 unknown (192.168.1.1) 0.863 ms 0.757 ms 0.579 ms 2 lo0-100.NYCMNY-VFTTP-401.verizon-gni.net (173.68.77.1) 1.010 ms 1.545 ms 1.034 ms 3 B3401.NYCMNY-LCR-22.verizon-gni.net (100.41.137.96) 3.616 ms B3401.NYCMNY-LCR-21.verizon-gni.net (100.41.137.94) 5.696 ms 10.062 ms 4 * * * 5 0.et-5-1-5.BR3.NYC4.ALTER.NET (140.222.2.127) 3.492 ms 3.506 ms 2.996 ms 6 204.255.168.118 (204.255.168.118) 8.462 ms 7.479 ms 7.252 ms 7 144.232.4.84 (144.232.4.84) 5.041 ms 4.688 ms sl-crs3-lon-0-6-3-0.sprintlink.net (144.232.9.165) 71.865 ms 8 sl-crs2-lon-0-0-3-0.sprintlink.net (213.206.128.181) 72.214 ms 73.579 ms 72.339 ms 9 213.206.129.142 (213.206.129.142) 81.390 ms sl-crs4-ams-0-7-0-3.sprintlink.net (213.206.129.139) 85.854 ms 93.238 ms 10 217.149.47.46 (217.149.47.46) 79.004 ms 85.669 ms 79.392 ms 11 ams5-core-1.bundle-ether1.tele2.net (130.244.82.54) 86.507 ms 78.374 ms 77.740 ms 12 ams-core-2.bundle-ether9.tele2.net (130.244.82.57) 79.642 ms 77.926 ms 81.515 ms 13 wen3-core-2.bundle-ether15.tele2.net (130.244.71.47) 105.400 ms 105.089 ms 109.751 ms 14 tele2at-bundle2-vie3.net.uta.at (212.152.189.65) 122.716 ms 110.820 ms 114.354 ms 15 86.59.21.1 (86.59.21.1) 106.389 ms * 105.379 ms neel@xb2:~ % I got in contact with Peter Palfrader and he says he couldn't help, and also with Verizon FiOS support and they said the filtering 'isn't on Verizon's network' (read: isn't on Verizon's internal FiOS network but still on Verizon's AS701 which I have to go to to get anywhere on the Internet here). I know that this IP could have been blackholed, and you may think that if Verizon is blocking it, then isn't Level 3 or Cogent? Well, Cogent doesn't block tor26: traceroute to 86.59.21.38 (86.59.21.38), 30 hops max, 60 byte packets 1 gi0-1-1-19.5.agr21.jfk02.atlas.cogentco.com (66.28.3.113) 0.727 ms 0.727 ms 2 be2605.ccr41.jfk02.atlas.cogentco.com (154.54.1.153) 2.177 ms be2606.ccr42.jfk02.atlas.cogentco.com (154.54.2.29) 0.734 ms 3 be2490.ccr42.lon13.atlas.cogentco.com (154.54.42.86) 68.557 ms be2317.ccr41.lon13.atlas.cogentco.com (154.54.30.186) 70.829 ms 4 be12488.ccr42.ams03.atlas.cogentco.com (130.117.51.42) 74.570 ms be12194.ccr41.ams03.atlas.cogentco.com (154.54.56.94) 76.767 ms 5 be2434.agr21.ams03.atlas.cogentco.com (130.117.2.241) 74.515 ms 74.612 ms 6 149.6.129.250 (149.6.129.250) 80.758 ms 74.625 ms 7 ams5-core-1.bundle-ether1.tele2.net (130.244.82.54) 75.421 ms 75.425 ms 8 ams-core-2.bundle-ether9.tele2.net (130.244.82.57) 74.516 ms 74.558 ms 9 wen3-core-2.bundle-ether15.tele2.net (130.244.71.47) 97.605 ms 95.470 ms 10 tele2at-bundle2-vie3.net.uta.at (212.152.189.65) 100.314 ms 97.947 ms 11 86.59.118.145 (86.59.118.145) 96.918 ms 98.620 ms 12 tor.noreply.org (86.59.21.38) 97.853 ms 98.110 ms (Source: http://www.cogentco.com/en/network/looking-glass) It could be possible that other Tier 1 networks formerly blocked tor26, and also unblocked, but Verizon was sloppy not to do so. It's also possible that Verizon could be doing it because the FCC repealed Net Neturality, and wants to discourage use of Tor to mine FiOS/VZW customers' browsing habits. But despite a NN repeal I can still access Tor on FiOS, and also run a relay (I do both) because other consensus relays are still unblocked. But if Verizon didn't unblock tor26, could it actually mean that Verizon wants to discourage Tor (and VPN/proxy) use to try to mine information of their customers (and sell ads/information) and direct users to VZ-owned AOL and Yahoo? Well, I hope they were just sloppy and don't mean to wage war on Tor. While I'm not saying you should avoid using anything Verizon at all costs (I certainly wouldn't want to go to the local cable company), I just want to point out a blocked consensus server. Thank You, Neel Chauhan === https://www.neelc.org/

8 13

Unable to confirm my ORPort is reachable
by Yash Kumar 24 May '18

24 May '18

Hi all, I have set up a tor relay on my Ubuntu machine by following the instructions given in the link <https://trac.torproject.org/projects/tor/wiki/TorRelayGuide>. To confirm whether the setup was done properly, I checked the status using the command: $ sudo service tor status and was getting status as "Active". Further, I looked into the log file /var/log/tor/notices.log using the command: $ tail -f /var/log/tor/notices.log and following was the output: May 24 18:24:54.000 [notice] Starting with guard context "default" May 24 18:24:54.000 [notice] Bootstrapped 80%: Connecting to the Tor network May 24 18:24:54.000 [notice] Signaled readiness to systemd May 24 18:24:55.000 [notice] Guessed our IP address as x.x.x.x (source: 204.13.164.118). May 24 18:24:55.000 [notice] Bootstrapped 85%: Finishing handshake with first hop May 24 18:24:56.000 [notice] Bootstrapped 90%: Establishing a Tor circuit May 24 18:24:59.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. May 24 18:24:59.000 [notice] Bootstrapped 100%: Done May 24 18:24:59.000 [notice] Now checking whether ORPort x.x.x.x:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) May 24 18:44:55.000 [warn] Your server (x.x.x.x:9001) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Can anyone please help me with this issue? I am not able to figure out the reason behind this error message "Your server (x.x.x.x:9001) has not managed to confirm that its ORPort is reachable". Please also let me know if you feel there is any issue with the tor configuration. Thank you, Yash Kumar

4 3

Re: [tor-relays] tor-relays Digest, Vol 88, Issue 41
by Yash Kumar 24 May '18

24 May '18

Hi Jonathan, Thank you for offering your support. Yes, you are absolutely right.The exact problem which I was facing was that, I wasn't able to find the "Self-testing" line in /var/log/syslog file. I followed the instructions as told by you and I'm mentioning their results as well below. 1. I executed the command: $ sudo systemctl status tor I got the following output: [image: tor status.jpg] 2. I checked whether there was an issue related to permissions for the command: $ cat /var/log/syslog I figured out that there wasn't any error running that command (although I'm not attaching the output of that command). I am still not getting that "Self-testing" line in /var/log/syslog, which is the problem I'm facing specifically. It would be of great help if you can think of any other possible issue because of which I am facing this problem. Thanks, Yash Kumar On Wed, 23 May 2018 at 17:30, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: tor enters uninterruptible sleep forever when using > transparent proxy (Zack Weinberg) > 2. Setting up tor relay (Yash Kumar) > 3. Re: Setting up tor relay (Jonathan Marquardt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 May 2018 20:25:33 -0400 > From: Zack Weinberg <zackw(a)cmu.edu> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] tor enters uninterruptible sleep forever > when using transparent proxy > Message-ID: > <CAKCAbMgwDwAsKLf3egHAprr=Up==jmpoEd= > a_Y1iP11WXJRPVg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Tue, May 22, 2018 at 8:11 PM, Nicolás Dato <nicolas.dato(a)gmail.com> > wrote: > >> tor enters uninterruptible sleep forever when using transparent proxy > > > > For future references, the issue was the kernel version 4.4.118, > > upgraded and the problem was gone. > > A bit of Unix sysadmin lore that isn't as widely advertised as it once > was (because, thankfully, it comes up far less often than it used to): > there are only three reasons why a process would remain in an > uninterruptible sleep for more than a few milliseconds: an abnormally > slow storage peripheral (e.g. a tape drive being rewound, or a hard > drive that's about to fail), a network file server that isn't > responding to messages, or a kernel bug. > > zw > > > ------------------------------ > > Message: 2 > Date: Wed, 23 May 2018 10:48:10 +0530 > From: Yash Kumar <yashkr.99(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Setting up tor relay > Message-ID: > <CAGagdeCFKM=pw5+E5+YFn5Y9Fj3yOvq5N5R0= > C7N2kvBKLDWCQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear all, > I want to setup my machine as a tor relay. I am using Ubuntu 16.04 LTS on > a Intel i5 processor with 4 GB of memory. > I followed the instructions given on this link > <https://trac.torproject.org/projects/tor/wiki/TorRelayGuide>, but was > getting some issue. In one of the later steps, it says "Verify that your > relay works". This is done by checking my logfile(syslog) contains the > following text: > > "Self-testing indicates your ORPort is reachable from the outside. > Excellent. Publishing server descriptor." > > I checked the syslog by the command: > > $ cat /var/log/syslog > > > To bring it to your knowledge, I have followed all the previous steps > mentioned on that link > <https://trac.torproject.org/projects/tor/wiki/TorRelayGuide>, and was > successfully able to execute all the commands. I would request you to > please help me out in setting up my machine as a relay to make tor network > faster and more usable. > > Thank you, > Yash Kumar >

1 0

Re: [tor-relays] can dirport be disabled on fallback directory?
by teor 23 May '18

23 May '18

Hi, I didn't get your original email, it appears my spam filter is eating all your emails. (And a few other emails.) At 12:25 5/18/2018 -0400, starlight.2017q4 at binnacle.cx wrote: >Lately seeing escalating abuse traffic on the relay dirport, now up to 20k rotating source IP addresses per week. > >The simple solution is to disable dirport, but the relay is a fallback directory and I don't want to make a change that will negatively affect the relay's ability to function as such. Would >disabling dirport be a problem? All supported Tor clients use the ORPort. They won't notice if you remove the DirPort. >also: > >can a non-advertised dirport be left configured for local-system use while the public advertised dirport is disabled? This config doesn't work, and that's a bug: https://trac.torproject.org/projects/tor/ticket/26136 >does a command utility or method exist for querying dirport documents via tunnelled-dir-server? including miscellanous documents such as > >/tor/status-vote/current/consensus.z … Stem master supports ORPort endpoints in stem.descriptor.remote.Query requests: https://stem.torproject.org/change_log.html There might not be convenience functions for some of the document types you listed, so you'll need to pass their paths in the resource argument. You might also want to avoid compression locally by dropping the ".z". There don't seem to be any examples of ORPort endpoints in the Stem repository. I think Dave plans to add some more documentation as part of Tor Summer of Privacy. T

2 2

Setting up tor relay
by Yash Kumar 23 May '18

23 May '18

Dear all, I want to setup my machine as a tor relay. I am using Ubuntu 16.04 LTS on a Intel i5 processor with 4 GB of memory. I followed the instructions given on this link <https://trac.torproject.org/projects/tor/wiki/TorRelayGuide>, but was getting some issue. In one of the later steps, it says "Verify that your relay works". This is done by checking my logfile(syslog) contains the following text: "Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor." I checked the syslog by the command: $ cat /var/log/syslog To bring it to your knowledge, I have followed all the previous steps mentioned on that link <https://trac.torproject.org/projects/tor/wiki/TorRelayGuide>, and was successfully able to execute all the commands. I would request you to please help me out in setting up my machine as a relay to make tor network faster and more usable. Thank you, Yash Kumar

2 1

tor enters uninterruptible sleep forever when using transparent proxy
by Nicolás Dato 23 May '18

23 May '18

Hello there, First thanks for reading! I've been running a tor relay for almost two weeks from my home. Yesterday,* I did some upgrades to my Slackware 14.2 including glibc and kernel*. I run tor there and it worked fine. After upgrading Slackware I had to reboot and run windows for the night. Windows messes with the machine time. Today, *I rebooted and run Slackware and (as usual after running windows) *the clock was -3 hours apart. I do run NTP but looks like it doesn't make the adjustment if the difference is way too big. I adjusted the time and run the NTP service again. *Tor daemon launches at startup* so it was running when my clock was -3 hours from present time. I use irssi (IRC client) connecting to the tor transparent proxy using iptables. As usual, I runned irssi and tried to connect to a server but the connection hangs forever and tor hangs forever too, hanging the relay too. I tried a different server but hangs too. *Before trying to connect with irssi, this works:* The tor relay works fine and accepts connections and delivers traffic. I can run nyx and it connects fine and shows me the stats. I can connect to the socks proxy and it works and doesn't hangs tor daemon. After trying to connect with irsse, *all of that stop working.* I didn't changed any tor configuration neither the iptables configuration I did build the tor packages (recompiling it) and installed it, but didn't work I removed some files and folders from /var/log/tor, only removed the ones modified yesterday and today, but it didn't work neither. tor is reported by ps to be on uninterruptible sleep 1347 ? Dl 0:06 11 0 491216 87432 2.2 /usr/bin/tor and there is no way to kill it other than rebooting, neither kill -9 as root works after all the reboots, after removing some /var/lib/tor files, and having the machine clock on time, tor still hangs when using the transparent proxy this are the last lines from the debug log: https://paste.debian.net/plain/1025878 (that's from the time I tried to connect to freenode and it hanged, no more logs after that) this is my iptables: http://paste.debian.net/plainh/c949bc2a (irssi runs as ircuser) this is my torrc: http://paste.debian.net/plain/1025881 (I didn't copy some lines) Thanks again for reading.

2 3

VPNGate Project Exit Node Volunteers / I2P
by grarpamp 22 May '18

22 May '18

http://www.vpngate.net/ For those relay operators who may have extra non tor listed IP addresses and want to help a related projects / userbase. https://geti2p.net/ I2P also has an exit proxy function. " VPNGate: Free Access to World Knowledge Beyond Government's Firewall. VPN Gate Academic Experiment Project is an online service as an academic research at Graduate School of University of Tsukuba, Japan. The purpose of this research is to expand the knowledge of "Global Distributed Public VPN Relay Servers" . You can take these advantages by using VPN Gate: You can get through the government's firewall to browse restricted web sites (e.g. YouTube). You can disguise your IP address to hide your identity while surfing the Internet. You can protect yourself by utilizing its strong encryption while using public Wi-Fi. Unlike traditional VPN services, VPN Gate can get through most firewalls. VPN Gate is free of charge. Not a single registration is required " " I2P I2P is an anonymous overlay network - a network within a network. It is intended to protect communication from dragnet surveillance and monitoring by third parties such as ISPs. "

3 5

Running a bridge remotely
by Keifer Bly 22 May '18

22 May '18

Hello, I have been running my home computer as a public tor relay for some time now with no issues, and unfortunately do not have a data center or anywhere else to run my relay from. I have noticed that there are far fewer bridges (about 2,000) then there are relays (about 7,000). As I have been running my home computer as a relay since last year, my ip address has already been in the tor network for a while, and thus will already be known as a relay to begin with. Is there a free way that I could remotely run an obfuscated bridge as well? I would need a way to do this remotely as I said my only available network ip has been on the public tor network for a considerable while.

3 2

DirPort DOS activity against Fallback Directories
by starlight.2017q4＠binnacle.cx 21 May '18

21 May '18

Recently I noticed excessive DirPort requests to my relay, where DirPort bandwidth reached 15% of ORPort bandwidth. Normal DirPort load is around 2%. https://lists.torproject.org/pipermail/tor-relays/2018-May/015253.html Just looked over a sample of FallBackDir relays in Relay Search and it appears this excess-load abuse is directed at them in particular. Some fall-back directories show more than a month of excess request traffic, presumably on the DirPort. Logs here indicate six weeks of abuse escalating in increments. Possibly this foreshadows a major increase in an effort to impair FallBackDir relay functionality. Either an iptables connection-rate limit or disabling DirPort resolves the problem.

3 3

Nyx and Arm
by gerard＠bulger.co.uk 21 May '18

21 May '18

Arm says I have 3506 outbound 354 exit Nyx has long blue list but states 50 outbound. No mention of exits. What am I doing wrong with Nyx? Gerry

2 2