tor-relays

tor-relays@lists.torproject.org

42 participants
4821 discussions

Heartbeat: It seems like we are not in the cached consensus.
by Fran 27 Sep '20

27 Sep '20

Hello, I'm taking care of a server of a friend who's on holiday. The server is up and running but not part of the consensus. As beeing instructed I updated to the lastest OpenBSD snapshot when I saw that a new tor release is available (Tor 0.4.3.5 on OpenBSD). Excerpts from the log: Jul 13 20:04:02.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Jul 13 20:05:02.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jul 13 20:05:35.000 [notice] Performing bandwidth self-test...done. Jul 14 02:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 02:04:01.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 2.04 MB and received 6.25 MB. Jul 14 02:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 33% Jul 14 02:04:01.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 5/5 NTor. Jul 14 02:04:01.000 [notice] Since startup we initiated 0 and received 157 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 5 v4 connections; initiated 48 and received 124 v5 connections. Jul 14 02:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Jul 14 06:04:02.000 [notice] Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 9 connections to 6 relays. Found 4 current canonical connections, in 0 of which we were a non-canonical peer. 3 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections. Jul 14 08:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 08:04:01.000 [notice] Heartbeat: Tor's uptime is 12:00 hours, with 1 circuits open. I've sent 3.46 MB and received 11.22 MB. Jul 14 08:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 47% Jul 14 08:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 1/1 NTor. Jul 14 08:04:01.000 [notice] Since startup we initiated 0 and received 340 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 10 v4 connections; initiated 57 and received 246 v5 connections. Jul 14 08:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Jul 14 14:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus. Jul 14 14:04:01.000 [notice] Heartbeat: Tor's uptime is 18:00 hours, with 1 circuits open. I've sent 4.89 MB and received 15.33 MB. Jul 14 14:04:01.000 [notice] Average packaged cell fullness: 26.760%. TLS write overhead: 51% Jul 14 14:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 6/6 NTor. Jul 14 14:04:01.000 [notice] Since startup we initiated 0 and received 493 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 18 v4 connections; initiated 64 and received 370 v5 connections. Jul 14 14:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0 INTRODUCE2 rejected. Atlas show the server as down: https://metrics.torproject.org/rs.html#details/AC601DBDB7FBD53454045EDC08DA… Accessing the status page on port 80 works. No FW on the machine. Any ideas? Thanks and regards Fran

4 7

Exit not utilizing full bandwidth
by 4punk7＠mailbox.org 26 Sep '20

26 Sep '20

Hi, i am running a tor exit node for over 2 years now and it's just using around 1.7 MiB/s of a 100 MBit/s connection. My other relays (not exits) from the same hoster (same bandwidth) are using around 10 MiB/s (which is the rate I expect). I have tried to limit the bandwithrate, set no limits, adding IPv6 and also excluding relays from overseas (i'm located in Germany). Nothing happened. CPU is around 10%... Any idea how to speed up the exit ? Thanks, apunkt Tor Version is 0.4.2.7, here is my current torrc: /var/log/tor/notices.log RunAsDaemon 1 DataDirectory /var/lib/tor ControlPort 9051 ORPort 1234 ORPort [2a0a:51c0::103]:9001 Nickname 4punk7e1 RelayBandwidthRate 100 MBytes # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 100 MBytes # But allow bursts up to 200KB (1600Kb) MyFamily $CEFBCB5FCE5FB37784AD489BCDEC46F1D59C06CB,$ABA31795BAD2AB8097F3AD0FE1A9 20E518D3D3F3 ExitRelay 1 IPv6Exit 1 ExitPolicy reject6 *:22 ExitPolicy reject6 *:587 #ExitPolicy reject6 *:* ExitPolicy accept *:20-21 # FTP #ExitPolicy accept *:22 # SSH ExitPolicy accept *:23 # Telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79 # finger ExitPolicy accept *:80-81 # HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:465 # URD for SSM (more often: an alternative SUBMISSION port, see 587) ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL #ExitPolicy accept *:587 # SUBMISSION (authenticated clients [MUA's like Thunderbird] send mail over STARTTLS SMTP here) ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # kerberos ExitPolicy accept *:853 # DNS over TLS ExitPolicy accept *:873 # rsync ExitPolicy accept *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-990 # FTP over SSL ExitPolicy accept *:991 # Netnews Administration System ExitPolicy accept *:992 # TELNETS ExitPolicy accept *:993 # IMAP over SSL ExitPolicy accept *:994 # IRCS ExitPolicy accept *:995 # POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8082 # HTTPS Electrum Bitcoin port ExitPolicy accept *:8087-8088 # Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept *:8232-8233 # Zcash ExitPolicy accept *:8332-8333 # Bitcoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:9999 # distinct ExitPolicy accept *:10000 # Network Data Management Protocol ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:19294 # Google Voice TCP ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept *:50002 # Electrum Bitcoin SSL ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* ExcludeNodes {US},{CA}

1 0

"Your server (xxxx:443) has not managed to confirm that its ORPort is reachable."
by Pham Minh Duc 23 Sep '20

23 Sep '20

I see this in syslog: Your server (xxxx:443) 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. torrc: Nickname Contake ORPort 443 ExitRelay 0 SocksPort 0 ControlSocket 0 ContactInfo contakechuyennghicmt(a)gmail.com What happened and how to fix this?

3 7

Who am I?
by Kencf0618＠riseup.net 22 Sep '20

22 Sep '20

Whatever the torrc, with "Tor" I get Sep 18 08:02:12.538 [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. Sep 18 08:02:12.538 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Sep 18 08:02:12.538 [notice] Read configuration file "/etc/tor/torrc". Sep 18 08:02:12.542 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand. Sep 18 08:02:12.542 [notice] Scheduler type KIST has been enabled. Sep 18 08:02:12.542 [notice] Opening OR listener on 0.0.0.0:443 Sep 18 08:02:12.542 [warn] Could not bind to 0.0.0.0:443: Permission denied Sep 18 08:02:12.542 [warn] Failed to parse/validate config: Failed to bind one of the listener ports. Sep 18 08:02:12.542 [err] Reading config failed--see warnings above. whereas with "sudo Tor" (yeah, yeah, I know, I know -"bad form") I get ep 18 08:04:12.236 [notice] Tor 0.3.2.10 (git-0edaa32732ec8930) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. Sep 18 08:04:12.236 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Sep 18 08:04:12.237 [notice] Read configuration file "/etc/tor/torrc". Sep 18 08:04:12.240 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand. Sep 18 08:04:12.240 [notice] Scheduler type KIST has been enabled. Sep 18 08:04:12.240 [notice] Opening OR listener on 0.0.0.0:443 Sep 18 08:04:12.241 [warn] /home/kenneth/.tor is not owned by this user (root, 0) but by kenneth (1000). Perhaps you are running Tor as the wrong user? Sep 18 08:04:12.241 [warn] Failed to parse/validate config: Couldn't access/create private data directory "/home/kenneth/.tor" Sep 18 08:04:12.241 [err] Reading config failed--see warnings above. What is happening?

4 6

Expiration time from torbulkexitlist
by Julien Moutinho 22 Sep '20

22 Sep '20

Hello Tor fans, New to Tor here, nonetheless this month I've tried to work on some type-checking and hardening of Tor in NixOS (see https://github.com/NixOS/nixpkgs/pull/97740 in case this interests you), hence I've tested Tor as an Exit node a few hours behind 80.67.180.251, as visible in: https://collector.torproject.org/recent/exit-lists/2020-09-22-01-02-00 > ExitNode 483F3347218DA225540D67AC3B9D48235A23DB89 > Published 2020-09-07 19:22:15 > LastStatus 2020-09-08 01:00:00 > ExitAddress 80.67.180.251 2020-09-08 01:59:25 And, if I'm not mistaken, only used it as a non Exit node since then (mostly to test a new NixOS abstraction around onion services). It's now 14 days past my Exit node test, yet that IPv4 is still listed in: https://check.torproject.org/torbulkexitlist despite https://lists.torproject.org/pipermail/tor-project/2020-March/002759.html announcing that: > This list is updated at most once every 40 minutes depending on the > number of exit relays in the network at the time, fetching it every hour > would be reasonable. A quick grep in https://collector.torproject.org/archive/exit-lists/exit-list-2020-07.tar.xz shows that in the past at least some exit nodes have been removed after one month: > $ grep LastStatus exit-list-2020-07/13/2020-07-13-18-02-00 | sort -r | tail -1 > LastStatus 2020-06-15 03:00:00 > $ grep LastStatus exit-list-2020-07/13/2020-07-13-19-02-00 | sort -r | tail -1 > LastStatus 2020-07-11 20:00:00 Am I right to assume that one month is the expiration time from torbulkexitlist? And can I do anything to trigger the removal before that delay? Thanks in advance for your answers, Julien

1 0

Fwd: Re: "Your server (xxxx:443) has not managed to confirm that its ORPort is reachable."
by lists＠for-privacy.net 17 Sep '20

17 Sep '20

Please always reply to the list so that everyone can help you. -------- Original Message -------- Subject: Re: [tor-relays] "Your server (xxxx:443) has not managed to confirm that its ORPort is reachable." Date: 17.09.2020 13:42 From: Pham Minh Duc <phamducvn.0308(a)gmail.com> To: lists(a)for-privacy.net > Help, I've followed steps on your Github but I still see this error. My > IP address is dynamic. It may affects? How to fix this? dynamic IP = you have your relay running at home? Then things are quite different. I guess: You have a router that connects you to the Internet and your computer running Tor gets the IP/IPv6 via DHCP? Then you have to set up port forward (ORPort, DirPort) on the router and don't need iptables on the computer in the LAN. Which OS do you have exactly. Your syslog can be every GNU/Linux, *BSD or another UNIX. Be sure you have absolutely no exit traffic, add to your torrc: ExitPolicy reject *:* and advertise the directory service on some port: DirPort 80 -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

1 0

Become a Fallback Directory Mirror (deadline: July 23)
by gus 17 Sep '20

17 Sep '20

Dear Relay Operators, Do you want your relay to be a Tor fallback directory mirror? Will it have the same address and port for the next 2 years? Just reply to this email with your relay's fingerprint. Important: you have until July 23 2020 to reply to this message to get in the fallback directory mirror list. If your relay is on the current fallback list, you don't need to do anything. If you're asking: Q: What's a fallback directory mirror? Fallback directory mirrors help Tor clients connect to the network. For more details, see [1]. Q: Is my relay on the current list? Search [2] and [3] for your relay fingerprint or IP address and port. [2] is the current list of fallbacks in Tor. [3] is used to create the next list of fallbacks. Q: What do I need to do if my relay is on the list? Keep the same IP address, keys, and ports. Email tor-relays if the relay's details change. Q: Can my relay be on the list next time? We need fast relays that will be on the same IP address and port for 2 years. Reply to this email to get on the list, or to update the details of your relay. Once or twice a year, we run a script to choose about 150-200 relays from the potential list [3] for the list in Tor [2]. Q: Why didn't my relay get on the list last time? We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might be down when we check. That's ok, we will check it again next time. It's good to have some new relays on the list every release. That helps tor clients, because blocking a changing list is harder. cheers, Gus [1] https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDire… [2] https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc [3] https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list [4] https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_… -- The Tor Project Community Team Lead http://expyuzz4wqqyqhjn.onion/

26 30

OVH Warnings
by Dr Gerard Bulger 15 Sep '20

15 Sep '20

OVH seemed to have upped their game with more information than just throwing all traffic into "mitigation" which can result in bad exit status, with no information as to what their systems are detecting as a threat of denial of service attack. For the first time I got an email.no mitigation. Dear Customer, Abnormal activity has been detected on your VPS Attack detail : 4Kpps/2Mbps dateTime srcIp:srcPort dstIp:dstPort protocol flags bytes reason 2020.09.15 19:02:21 CEST <http://51.38.64.136:42845/> my ip:42845 <http://212.22.93.124:25565/> 212.22.93.124:25565 TCP SYN 60 ATTACK:TCP_SYN 2020.09.15 19:02:21 CEST <http://51.38.64.136:39673/> my ip:39673 <http://212.22.93.124:25565/> 212.22.93.124:25565 TCP SYN 60 ATTACK:TCP_SYN Etc Gerry

1 0

Odd error with tor 4.3 log file
by Keifer Bly 14 Sep '20

14 Sep '20

1 0

non-encrypted connections from Tor exit relays
by kirgali＠riseup.net 10 Sep '20

10 Sep '20

hi, generalized question about Tor exit relays and exit relay operators. do some exit relay operators have a policy to prevent connections leaving their exit node via non-encrypted ports (e.g. port 25)? this could be a philosophical position - not even wanting to be in a position to observe users' data passing through the exit node in clear text. or a pragmatic position - hoping that encrypted connections provide some level (even very weak) of plausible deniability in the event that a connection attracts the attention of law enforcement. this is just my thoughts.

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays