- tor-relays - lists.torproject.org

Bridge not used
by Arnim Wiezer 10 May '22

10 May '22

Hi Tor-Operators, I have installed a bridge according to the official how-to. The config is as follows: Log notice file /var/log/tor/notices.log DataDirectory /var/lib/tor Address bridge.xxx.de BridgeRelay 1 ORPort 1044 ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:9043 ExtORPort auto ContactInfo arnimw(a)mailbox.org Nickname lunabridge PublishServerDescriptor 1 BridgeDistribution any Under https://metrics.torproject.org/rs.html#details/4DD98FB1959065309FD4A183530B… I see basically no usage, the logs are fine - as far as I can tell. Any help appreciated! Best, Arnim

3 4

Tor 0.4.7.7 Segmentation fault on Ubuntu 22.04 caused by "rseq"
by Xiaoqi Chen (Danny) 07 May '22

07 May '22

Dear relay operators, I recently upgraded one of my relays to Ubuntu 22.04 and now tor keeps crashing. I debugged a little bit and saw the following error in the log. It appears that it's due to seccomp not allowing "rseq" syscall, and possibly related to the latest version of Glibc. I temporarily mitigated the issue by turning off sandbox mode (remove "Sandbox 1" in torrc). Does anyone know how to properly resolve the crashing issue? Cheers, Danny Chen -- $ sudo tor -f /etc/tor/torrc May 07 02:10:46.831 [notice] Tor 0.4.7.7 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 and Glibc 2.35 as libc. ...... May 07 02:10:46.833 [notice] Opening Directory listener on 0.0.0.0:8080 May 07 02:10:46.833 [notice] Opened Directory listener connection (ready) on 0.0.0.0:8080 Fatal glibc error: rseq registration failed ============================================================ T=Fatal glibc error: rseq registration failed 1651889448 Tor 0.4.7.7 died: Caught signal 11 Fatal glibc error: rseq registration failed Fatal glibc error: rseq registration failed tor(+0xee525)[0x55c6431d6525] /lib/x86_64-linux-gnu/libc.so.6(abort+0x178)[0x7fe6da9ee898] /lib/x86_64-linux-gnu/libc.so.6(abort+0x178)[0x7fe6da9ee898] /lib/x86_64-linux-gnu/libc.so.6(+0x8945c)[0x7fe6daa4f45c] /lib/x86_64-linux-gnu/libc.so.6(+0x89770)[0x7fe6daa4f770] /lib/x86_64-linux-gnu/libc.so.6(+0x94b31)[0x7fe6daa5ab31] /lib/x86_64-linux-gnu/libc.so.6(+0x126a00)[0x7fe6daaeca00] Fatal glibc error: rseq registration failed

4 3

Relay Throttling
by sysmanager7 06 May '22

06 May '22

Hi Is there a tutorial on how to limit a relay's throughput?? There has to be! I did a search and came up empty. I'm trying to avoid shutting down my relay's due to financial burden Any help would be appreciated. Thank you! Sent with [ProtonMail](https://protonmail.com/) secure email.

5 4

Re: [tor-relays] Relay Throttling
by me＠mirandaniel.com 06 May '22

06 May '22

Hey, check your torrc, there is a RelayBandwidthRate setting (to limit speed) and also an AccountingMax setting to limit max traffic per month. -- MiranDaniel "---------- Původní zpráva ---------- Od: sysmanager7 via tor-relays <tor-relays(a)lists.torproject.org> Datum: 06.05.2022 14:16:35 Předmět: [tor-relays] Relay Throttling Hi Is there a tutorial on how to limit a relay's throughput?? There has to be! I did a search and came up empty. I'm trying to avoid shutting down my relay's due to financial burden Any help would be appreciated. Thank you! Sent with ProtonMail(https://protonmail.com/) secure email. "

1 0

Tor Exit: Complaints of IP being used for "spam" despite exit policy
by Neel Chauhan 05 May '22

05 May '22

Hi, A day or two ago, my Tor exit host, Psychz Networks, has sent me complaints about my IPs being used to send "spam" despite me having blocked Port 25 (and 465/587) in the exit policy. Psychz threatened to block Port 25 even when my exit policy explicitly blocks 25/465/587. The URLs I got were from Cisco Talos: * https://talosintelligence.com/reputation_center/lookup?search=104.149.136.2… * https://talosintelligence.com/reputation_center/lookup?search=104.149.133.5… Sometimes I think "is my FreeBSD exploited and being used to send spam", but then I also see Linux relays on other ISPs also on the blocklists. Yes, I am aware Tor exit relays will land on blacklists. But getting complaints from spam is new, especially when my relays are blocking SMTP. I am worried I would have to find a new host if they continue complaining. Darn, Psychz has been one of the more reliable exit hosts (on-and-off) for many years, although they are more vigilant on abuse than say BuyVM. BuyVM is similarly priced (although my Psychz is an special offer) and solid but has too many exits. OVH and TerraHost only allow exits on much more expensive dedicated servers. Prgmr and HostMaze allow exits but has so-so peering. I just hope Psychz doesn't continue to complain. -Neel

5 7

comments, hints and tipps for an ansible role to deploy Tor bridges
by Toralf Förster 04 May '22

04 May '22

I do appreciate those for my attempt here: https://github.com/toralf/tor-relays TIA -- Toralf

2 1

BSD tor ports/packages and impending 0.4.7.7 release
by George 03 May '22

03 May '22

BSD relay operators, like everyone else, should be aware that upgrading tor to 0.4.7.7 is critical for exit relays. The source is available now at: https://dist.torproject.org/tor-0.4.7.7.tar.gz Specifically for the BSD ports, here is the current status and workings. Any corrections appreciated. * DragonflyBSD https://github.com/DragonFlyBSD/DPorts/tree/master/security/tor Downstreams from FreeBSD quarterly updates, so may not have a 0.4.7.7 package or port for security/tor until July. * FreeBSD https://www.freshports.org/security/tor https://cgit.freebsd.org/ports/tree/security/tor https://svnweb.freebsd.org/ports/head/security/tor/ Updated to 0.4.7.7 already, and can be installed from security/tor now. Working fine at this point. For pkg(8) users, ensure that /etc/pkg/FreeBSD.conf line 11 is set to "latest", as opposed to "quarterly", which should be the case regardless of this security/tor release: url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest", * NetBSD https://pkgsrc.se/net/tor pkgsrc's current port of net/tor was updated to 0.4.7.7. The stable port is still on 0.4.6.10 at https://cdn.netbsd.org/pub/pkgsrc/stable/pkgsrc/net/tor/Makefile * OpenBSD https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/tor/ The -current net/tor has been updated to 0.4.7.7 and the package is available. For users running 7.1-stable, net/tor 0.4.7.7 will hopefully be officially backported. Users can also update net/tor from ports on -stable themselves easily enough. If you're not on 7.1-stable, consider upgrading immediately. Thanks. g

1 0

Possible Connection Storm
by Eddie 26 Apr '22

26 Apr '22

Checking my relays after being away for a few days, noticed that one of them was showing as Overloaded, which I've never seen in over a year's running. Looking in the logs, it looks like there was a huge increase in connections, which has now settled down and I'm no longer showing as overloaded. Here's some relevant pieces: Apr 21 03:45:08.000 [notice] Heartbeat: Tor's uptime is 110 days 12:00 hours, wi th 6977 circuits open. I've sent 5236.04 GB and received 5121.19 GB. I've receiv ed 5232797 connections on IPv4 and 269395 on IPv6. I've made 2018765 connections with IPv4 and 580408 with IPv6. Apr 21 03:45:08.000 [notice] Circuit handshake stats since last time: 1901/1901 TAP, 244943/244943 NTor. Apr 21 07:04:49.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config opti on or choosing a more restricted exit policy. Apr 21 09:45:08.000 [notice] Heartbeat: Tor's uptime is 110 days 18:00 hours, wi th 47998 circuits open. I've sent 5263.73 GB and received 5148.85 GB. I've recei ved 5244063 connections on IPv4 and 270025 on IPv6. I've made 2021914 connection s with IPv4 and 581488 with IPv6. Apr 21 09:45:08.000 [notice] Circuit handshake stats since last time: 1609/1609 TAP, 6391488/6532508 NTor. Apr 21 15:45:08.000 [notice] Heartbeat: Tor's uptime is 111 days 0:00 hours, wit h 45439 circuits open. I've sent 5300.03 GB and received 5185.19 GB. I've receiv ed 5253283 connections on IPv4 and 270537 on IPv6. I've made 2024515 connections with IPv4 and 582464 with IPv6. Apr 21 15:45:08.000 [notice] Circuit handshake stats since last time: 467/467 TA P, 9937327/9984534 NTor. Is this anything I need to be concerned about, or is it just one of things that occasionally happens. Cheers.

2 1

Re: [tor-relays] Bridge Distribution Mechanism none
by Ross Camm 21 Apr '22

21 Apr '22

I have no error from Apparmor and I dont believe obfs4 proxy is the issue as I have obfs4 installed and confirmed running dpkg -l | grep obfs4 ii obfs4proxy 0.0.7-4 ps ax | grep obfs4 5501 ? Sl 0:01 /usr/bin/obfs4proxy netstat -nap | grep obfs4 tcp 0 0 X.X.X.X:12345 0.0.0.0:* LISTEN 5501/obfs4proxy Tor logs Apr 18 17:00:33 pi Tor[5497]: Registered server transport 'obfs4' at 'X.X.X.X:12345' torrc ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 X.X.X.X:12345 [ https://bridges.torproject.org/scan/ ]( https://bridges.torproject.org/scan/ ) also reports my ORPort is reachable via IPv4 and IPV6 Tor logs Apr 18 17:01:37 pi Tor[5497]: Self-testing indicates your ORPort [X:Y:Z::A]:993 is reachable from the outside. Excellent. Apr 18 17:01:37 pi Tor[5497]: Self-testing indicates your ORPort A.B.C.D:993 is reachable from the outside. Excellent. Publishing server descriptor. What am I missing ? Thanks again Ross > Probably because obfs4 is not installed or not running properly.> Check your logs for obfs4 errors, and for Apparmor error messages as well.> On Mon, Apr 18, 2022 at 09:07, Ross Camm <ross(a)whyza.net> wrote:> I have been up and running with my Tor Bridge for a number of months now, yet Tor Metrics reports that the Bridge Distribution Mechanism for my server is stuck on 'none'.>> Consequently I see no incoming connections to my Bridge.>> I have tried altering the following>> BridgeRelay 1>> PublishServerDescriptor bridge> BridgeDistribution moat>> with no success.>> The mechanism is always none....and I have left the changes for a week to see if Metrics updates to no avail.>> I have a static IPv4 address and functional IPv6 and have confirmed my ports are publicly accessible for both protocols>> Self-testing indicates your ORPort [XXXX:XXXX:XXXX::XXX]:993 is reachable from the outside. Excellent.> Self-testing indicates your ORPort XXX.XXX.XXX.XXX:993 is reachable from the outside. Excellent. Publishing server descriptor.>> I am running raspberry pi os buster which had an obsolete Tor version.>> I subsequently upgraded and stay up to date with the latest bullseye version via bullseye backports,>> Currently Tor 0.4.6.10-1~bpo10+1>> Any ideas of why my servers Bridge Distribution Mechanism is always reported and behaving as none ?>> Thanks in advance ;)>> Ross

2 1

Bridge Distribution Mechanism none
by Ross Camm 20 Apr '22

20 Apr '22

Thanks, that will no doubt be an issue Upgraded via debian backports dpkg -l | grep obfs4 ii obfs4proxy 0.0.13-1~bpo11+1 I will keep my eye on the bridge status page to see if the Bridge Mechanism changes as well as my incoming connections. Regards Ross Date: Tue, 19 Apr 2022 15:59:35 +0200 From: lists(a)for-privacy.net To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Bridge Distribution Mechanism none Message-ID: <2335525.61UdpqZOmS@w530> Content-Type: text/plain; charset="utf-8" On Tuesday, April 19, 2022 2:28:01 PM CEST 55578 via tor-relays wrote: > Probably because obfs4 is not installed or not running properly. Get the obfs4proxy package from backports. Outdated obfs bridges are rejected AFAIK. https://lists.torproject.org/pipermail/tor-relays/2022-March/020447.html -- ?_? Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

2 1

Bridges configuration
by onionize＠riseup.net 20 Apr '22

20 Apr '22

Hello, the Tor community. We already run relays and we have MyFamily configured. Now we want to start bridges. Should bridges have a separate family or we need to include them into relay family?

2 1

Another error
by onionize＠riseup.net 20 Apr '22

20 Apr '22

Hello, we tried a solution proposed by admin(a)for-privacy.net (deleting /var/lib/tor folder) but now we get another error: │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 204.13.164.118:80. Please correct. │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 154.35.175.225:80. Please correct. │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 199.58.81.140:80. Please correct. │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 86.59.21.38:80. Please correct. │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 171.25.193.9:443. Please correct. │ 19:41:54 [WARN] http status 400 ("Suspicious relay address range -- if you think this is a mistake please set a valid email address in ContactInfo and send an email to │ bad-relays(a)lists.torproject.org mentioning your address(es) and fingerprint(s)?") response from dirserver 131.188.40.189:80. Please correct. Please help us if you know why it happens

2 1

Tor 0.4.5.8 died: Caught signal 7
by Gary C. New 19 Apr '22

19 Apr '22

All: I'm having an issue with a Tor Node catching signal 7 and exiting in high-load situations. ============================================================ T= 1650367869 Tor 0.4.5.8 died: Caught signal 7 /opt/sbin/tor(+0x1af500)[0x2a1af500] /opt/sbin/tor(hs_intro_received_introduce1+0x0)[0x2a09e6b8] /opt/sbin/tor(hs_intro_received_introduce1+0x0)[0x2a09e6b8] Anyone experience similar issues? Respectfully, Gary

1 0

Bridge Distribution Mechanism none
by Ross Camm 19 Apr '22

19 Apr '22

I have been up and running with my Tor Bridge for a number of months now, yet Tor Metrics reports that the Bridge Distribution Mechanism for my server is stuck on 'none'. Consequently I see no incoming connections to my Bridge. I have tried altering the following BridgeRelay 1 PublishServerDescriptor bridge BridgeDistribution moat with no success. The mechanism is always none....and I have left the changes for a week to see if Metrics updates to no avail. I have a static IPv4 address and functional IPv6 and have confirmed my ports are publicly accessible for both protocols Self-testing indicates your ORPort [XXXX:XXXX:XXXX::XXX]:993 is reachable from the outside. Excellent. Self-testing indicates your ORPort XXX.XXX.XXX.XXX:993 is reachable from the outside. Excellent. Publishing server descriptor. I am running raspberry pi os buster which had an obsolete Tor version. I subsequently upgraded and stay up to date with the latest bullseye version via bullseye backports, Currently Tor 0.4.6.10-1~bpo10+1 Any ideas of why my servers Bridge Distribution Mechanism is always reported and behaving as none ? Thanks in advance ;) Ross

3 2

Instabilities in Hydra family expected
by abuse-node49＠posteo.de 19 Apr '22

19 Apr '22

Hello network! I would like to briefly inform that I have repeated problems with the hoster Yourserver.se, where I run some exit relays. Again a relay was deactivated with the message "Botnet". At that time I wrote a detailed explanation about the issue. I agreed to a temporary switch to a harmless relay, but as an exit operator I did not want to keep this state. So starting today the "Hydra family" will get some gaps which will take some time to replace. I know that there is an attempt to write a list of recommended providers somewhere. However, I have found that some of the information is not up to date. It is better to look into the Tor Metrics and find out the hoster for current exit relays that is mentioned there. Sometimes you are lucky. From my point of view, it should be possible to find out the age of exit relays from the Tor network database in relation to the hosters (ASxxxx) and thus find a ranking for reliability and suitability. Automatically, this would be a ranking for "privacy support". However, it would then be problematic that all newcomers would rely on these few hosters. Perhaps we will have to live with these problematic hosters and endure the dynamics. Here is a note about startup problems of the Tor service after a reboot: In my observation, this only happens with slow hardware and may also depend on the hypervisor. I use the same systems and configurations everywhere and see dead Tor services after startup only with the hoster Trabia.com and UDN (Ukrainian Data Network), with UDN working better now than a few years ago. It seems to be a timeout during start-up of the OS. With Debian "systemctl restart tor.service" solved the problem until the next reboot. With delayed start or a cron job this could be avoided, I assume. The fast hosters like * OVH.com, * Frantech.ca, * Flokinet.is, * Bahnhof.net * and Terrahost.com do not have the problem after reboot. First I will try to replace the failing VPS at Yourserver.se with reliable providers from my list, but I am checking other offers. I would also like to ask other participants in the network to name smaller, still unknown hosters. Kind regards Olaf

2 1

Tor Relay showing as down
by Alexandre Corradi Guerreiro 19 Apr '22

19 Apr '22

I have been running a ToR Relay for almost a year. https://metrics.torproject.org/rs.html#details/6C6C87A774A211F53DE5116A7A8A… and suddenly it stopped working. I don't see any errors on the logs but the relay is always showing in the relay search page as down. I even tried to upgrade the Tor client to a new version 0.4.6.10 to see if something changes, but no success. The process is running all the time, I see some circuit connections forming and after a while no more traffic going. Based on the syslog I see that everything looks fine, see next example. Apr 18 20:32:17 ubu01 Tor[1093]: Bootstrapped 10% (conn_done): Connected to a relay Apr 18 20:32:17 ubu01 Tor[1093]: Bootstrapped 14% (handshake): Handshaking with a relay Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 15% (handshake_done): Handshake with a relay done Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Apr 18 20:32:18 ubu01 Tor[1093]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit Apr 18 20:32:19 ubu01 Tor[1093]: Bootstrapped 100% (done): Done Apr 18 20:32:54 ubu01 Tor[1093]: New control connection opened. Apr 18 20:37:51 ubu01 Tor[1093]: External address seen and suggested by a directory authority: 187.74.71.95 Apr 18 20:38:17 ubu01 Tor[1093]: Now checking whether IPv4 ORPort 187.74.71.95:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) Apr 18 20:39:20 ubu01 Tor[1093]: Self-testing indicates your ORPort 187.74.71.95:9001 is reachable from the outside. Excellent. Publishing server descriptor. Apr 18 20:40:27 ubu01 Tor[1093]: New control connection opened. Apr 18 20:42:20 ubu01 Tor[1093]: Performing bandwidth self-test...done. I tried to test my income connection from another computer to validate that there was no block on the ISP side, I could connect successfully to port 9001 as indicated on the logs. How can I troubleshoot this problem? -- Alexandre C Guerreiro

1 0

How can I tell if standalone Snowflake is running?
by tor＠Bevitt.ws 18 Apr '22

18 Apr '22

I installed standalone Snowflake on Ubuntu per these instructions: https://community.torproject.org/relay/setup/snowflake/standalone/. Now how can I tell if it's running? Can I see the number of connections it's serviced? Will it continue after a reboot? Thanks, Chuck Bevitt Tor Project | Standalone Snowflake proxy<https://community.torproject.org/relay/setup/snowflake/standalone/> Our mission: To advance human rights and freedoms by creating and deploying free and open source anonymity and privacy technologies, supporting their unrestricted availability and use, and furthering their scientific and popular understanding. community.torproject.org

2 1

tor/munin/stem
by potlatch 15 Apr '22

15 Apr '22

Hello Tor braintrust, Is there some authoritative documentation for setting up VPS monitoring via stem and munin other than product websites? I hate to re-invent installations if I can gain knowledge elsewhere. I'm very slow working with python3. The TMS combo seems to work fine but the first error I found claims all of my relays and bridges have similar user count (as 1.67k US). They also don't self-upgrade when I modify the .conf files followed by restart. Thanks in advance for any user help, stay safe and sane, potlatch Sent with [ProtonMail](https://protonmail.com/) secure email.

2 1

Relay question
by onionize＠riseup.net 13 Apr '22

13 Apr '22

Hello, I have a question for other operators of the Tor. I started the nodes recently. On yui.cat status is displayed as offline (https://yui.cat/family/F81C34435CA08B81105B3C77CF29EE7824652BFB/, https://metrics.torproject.org/rs.html#search/family:8CD3507662A9946899CFE3… I did everything according to the instructions, the server work, the Tor process is running. Yesterday everything was displayed normally on yui.cat. I'm new relay operator, I do not know why it happens. Is this normal? Has anyone had the same situation?

3 6

Re: [tor-relays] Does Tor work with Intel QAT acceleration
by Andreas Bollhalder 12 Apr '22

12 Apr '22

Hello Alex Thank you for your nice hint ot QAT_Engine. Yes, in theory it really seems to be possible. Looking at the Github repo of the QAT_Engine, it looks like there are still some issues with OpenSSL 3.0: Support for QAT HW ECX, QAT SW ECX, QAT HW PRF and QAT HW HKDF is disabled when built against OpenSSL 3.0 due to known issues instead it uses non-accelerated implementation from OpenSSL.I'm on Ubuntu 20.04, so I should be still using OpenSSL 1.x. There are plans for switching to OpenSSL 3.0 in Ubuntu 22.04. We'll see... So, one really has to test and I need to think about it. Wouldn't be a cheep test, but if this platform can give me a medium power system (~50W) and great speed, then it's definitively what I'm looking for. Otherwise I would prefer a Ryzen like the 5750GE. Andreas On Tuesday, April 12, 2022 03:42 CEST, Alex Xu <alex(a)alxu.ca> wrote: Excerpts from Andreas Bollhalder's message of April 10, 2022 3:32 pm: > > Hi all > > I have my first Tor relay up und running. It's currently installed on a little desktop computer with an Intel i5 9500T CPU. My Internet connection is 10Gb/s symetric. From this bandwidth, I would be able to spend a good part for supporting the Tor network. > > With that little machine, it seems that it would max out at somewhere at ~30 MBytes/s. For my definitive Tor relay hardware, I'm currently researching some options, which would be capable of handling Tor traffic at the rate of 200 to 300MBytes. Even it would be used nowadays, but who knows whats coming in the future and I hope this relay would last 5 years ore so. > > It looks to me, that with a normal CPU, it's impossible to reach my goal. But then I encountered, that Intel has the Quick Assist Technoloy (QAT) integrated in some of their products (ie. Atom C3xx8). This QAT can be used with OpenSSL as a hardware accelerator for encryption. There also exist dedicated PCIe cards with QAT (ie. Netgate CPIC-8955). > > Searching the Internet, I couldn't find any information if QAT would be helpful with Tor. But Tor uses the OpenSSL library and this can use the QAT acceleration. Is there anyone who has tried this und can share his expirience? > > Thanks in advance > Andreas > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > In theory, you should be able to enable QAT with "HardwareAccel 1" on OpenSSL 1.x after installing https://github.com/intel/QAT_Engine. I'm not sure about the process for OpenSSL 3.0; I believe it involves editing OPENSSLDIR/openssl.cnf.

2 2

DNS server
by onionize＠riseup.net 10 Apr '22

10 Apr '22

I was setting up exit nodes and I had a question. Why is it recommended to use DNS caching software Unbound? What benefits does it provide compared to using hoster's DNS resolver?

3 4

Next Tor Relay Operator Meetup - April 2 @ 1900 UTC
by gus 08 Apr '22

08 Apr '22

Hello relay operators and Tor friends, The next Tor Relay Operator meetup will happen this Saturday, April 2 @ 1900 UTC / 1500 EDT / 2100 CET. Where: BigBlueButton - https://tor.meet.coop/gus-og0-x74-dzn No need for a registration or anything else, just use the room-link above. The agenda is available here: https://pad.riseup.net/p/tor-relay-meetup-april-2022-keep Everyone is free to bring up additional questions or topics at the meeting itself. Please share with your friends, social media and other mailing lists! cheers, Gus -- The Tor Project Community Team Lead

4 4

Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)
by gus 02 Apr '22

02 Apr '22

Hello everyone, This Saturday, March 5th @ 2000 UTC, we have a Tor Relay Operator Meetup! We'll share some updates about Tor Network Health, Tor Bridges and the ongoing situation in Russia/Ukraine (Snowflake surge, bridges blocked, BBC and DW onionsites). Everyone is free to bring up additional questions or topics at the meeting itself. Date & Time: March 5, 2022 - 2000 UTC Where: BigBlueButton room - https://tor.meet.coop/gus-og0-x74-dzn No need for a registration or anything else, just use the room-link above. Please share with your friends, social media and other mailing lists! cheers, Gus -- The Tor Project Community Team Lead

9 12

Exit Node Questions
by tdukes＠palmettoshopper.com 02 Apr '22

02 Apr '22

Just a couple questions regarding exit node setup: 1) what exactly do I add to my in-addr.arpa zone file? 2) how do I implement a 'reduced exit policy'? Is that something that needs to be added to the torrc file? Thanks

2 1

Help needed to get obfs4proxy 0.0.13-1 into Ubuntu focal-backports
by wurstsemmel 01 Apr '22

01 Apr '22

Dear Community, Dear Bridge Operators, an updated obfs4proxy package was pushed to Debian bullseye-backports about 2 weeks ago and solves a security issue and a partial incompatibility between Tor browser and bridges [1, 2, 3]. See also the E-Mail from meskio [4]. The new version, 0.0.13-1, will be available in Ubunutu jammy, planned to be released in April as 22.04 LTS. I would like to get this version into focal-backports, as focal (20.04 LTS) is a popular system. For this reason, I filed a bug with Ubuntu. https://bugs.launchpad.net/ubuntu/+source/obfs4proxy/+bug/1967003 Anyone who has experience with Ubuntu packages and backports is very welcome to help. Thank you and kind regards, wurstsemmel [1] https://lists.torproject.org/pipermail/anti-censorship-team/2022-January/00… [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804 [3] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs… [4] https://lists.torproject.org/pipermail/tor-relays/2022-March/020447.html

1 0

Appears things are working again.
by tdukes＠palmettoshopper.com 31 Mar '22

31 Mar '22

Had been using a docker container with not much luck so I switched to using the tor files for centos 8. Working so far. I'm now in the relay search. Not sure or why its saying I'd be better suited for an exit. Fingers crossed!

1 0

Bridge lifecycle expectations
by Just a Pleb 30 Mar '22

30 Mar '22

Hi All, I have three lifecycle questions: 1) How long is typical (or what factors are involved ) before the bridge address is given out to users. 2) How do I know when the bridge is burned (identified and blocked) 3) When it is burned and I build a new one on an other address should I copy the key with the config to maintain "trust" continuity or is that neutral or bad for bridges? As a little context I've run relays before and just started up an obfs4proxy Bridge (well 10days ago). https://bridges.torproject.org/status?id=<MY_BRIDGE_ID> says it's good, logs look good but I've yet to see any real traffic, just the same 8 German node that I presume are Tor infrastructure checking status. $ cat bridge-stats bridge-stats-end 2022-03-22 18:44:43 (86400 s) bridge-ips de=8 bridge-ip-versions v4=8,v6=0 bridge-ip-transports <OR>=8,obfs4=8 every day is the same (other than bridge-stats-end) Thanks, A. Pleb

3 3

BadMiddle Nodes Loadbalancing Re: How to reduce tor CPU load on a single bridge?
by Jonas Friedli 26 Mar '22

26 Mar '22

Hi Gary, wait, your Relays are BadMiddle Nodes! It breaks at least all onion features. Thanks for trying to saturate the connection by balancing the single-core tor bottleneck. But think of any client try to establish RendezvousPoints or IntroductionPoints or fetch HsDir with one of your tor instances that all have same descriptor and look same to outside. It will result into fail the connection! 1. a_tor_client => HAProxy server tornode41 192.168.0.41:9001 => RendezvousCookie 46B9FA5B onionservice => HAProxy server tornode51 192.168.0.41:9001 => RendezvousCookie 46B9FA5B 2. tornode51 does not know cookies of tornode41 will: [WARN] Rejecting RENDEZVOUS1 cell with unrecognized rendezvous cookie 46B9FA5B. Didn't recognize cell, but circ stops here circuit_receive_relay_cell (forward) failed This Loadbalancing setup is only valid and usefull for Bridges or ExitNode relay roles. Not for any that have MiddlePropability consensusweigths. just FYI > David, Roger, et al., > > I just got back from holidays and really enjoyed this thread! > > I run my Loadbalanced Tor Relay as a Guard/Middle Relay, very similar to David's topology diagram, without the Snoflake-Server proxy. I'm using Nginx (which forks a child process per core) instead of HAProxy. My Backend Tor Relay Nodes are running on several, different Physical Servers; thus, I'm using Private Address Space instead of Loopback Address Space. > > In this configuration, I discovered that I had to configure Nginix/HAProxy to use Transparent Streaming Mode, use Source IP Address Sticky Sessions (Pinning), configure the Loadbalancer to send the Backend Tor Relay Nodes' traffic back to Nginx/HAProxy (Kernel & IPTables), configure all Backend Tor Relay Nodes to use a copy of the same .tordb (I wasn't able to get the Backend Tor Relay Nodes working with the same .tordb (over NFS) without the DirectoryAuthorities complaining), and configure the Backend Tor Relay Nodes to use the same DirectoryAuthority (to ensure each Backend Tor Relay Node sends Meta-Data to the same DirectoryAuthority). Moreover, I've enabled logging to a central Syslog Server for each Backend Tor Relay Node and created a number of Shell Scripts to help remotely manage each Backend Tor Relay Node. > > Here are some sample configurations for reference. > > Nginx Config: > > upstream orport_tornodes { > #least_conn; > hash $remote_addr consistent; > #server 192.168.0.1:9001 weight=1 max_fails=1 fail_timeout=10s; > #server 192.168.0.1:9001 down; > server 192.168.0.11:9001 weight=4 max_fails=0 fail_timeout=0s; > server 192.168.0.21:9001 weight=4 max_fails=0 fail_timeout=0s; > #server 192.168.0.31:9001 weight=4 max_fails=3 fail_timeout=300s; > server 192.168.0.41:9001 weight=4 max_fails=0 fail_timeout=0s; > server 192.168.0.51:9001 weight=4 max_fails=0 fail_timeout=0s; > #zone orport_torfarm 64k; > > > HAProxy Config (Alternate): > > frontend tornodes > # Log to global config > log global > > # Bind to port 443 on a specified interface > bind 0.0.0.0:9001 transparent > > # We're proxying TCP here... > mode tcp > > default_backend orport_tornodes > > # Simple TCP source consistent over several servers using the specified > # source 0.0.0.0 usesrc clientip > backend orport_tornodes > > balance source > hash-type consistent > #server tornode1 192.168.0.1:9001 check disabled > #server tornode11 192.168.0.11:9001 source 192.168.0.1 > server tornode11 192.168.0.11:9001 source 0.0.0.0 usesrc clientip check disabled > server tornode21 192.168.0.21:9001 source 0.0.0.0 usesrc clientip check disabled > #server tornode31 192.168.0.31:9001 source 0.0.0.0 usesrc clientip check disabled > server tornode41 192.168.0.41:9001 source 0.0.0.0 usesrc clientip check disabled > server tornode51 192.168.0.51:9001 source 0.0.0.0 usesrc clientip check disabled > > > Linux Kernel & IPTables Config: > > modprobe xt_socket > modprobe xt_TPROXY > > echo 1 > /proc/sys/net/ipv4/ip_forward; cat /proc/sys/net/ipv4/ip_forward > echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind; cat /proc/sys/net/ipv4/ip_nonlocal_bind > echo 15000 64000 > /proc/sys/net/ipv4/ip_local_port_range; cat /proc/sys/net/ipv4/ip_local_port_range > > ip rule del fwmark 1 lookup 100 2>/dev/null # Ensure Duplicate Rule is not Created > ip rule add fwmark 1 lookup 100 # ip rule show > ip route add local 0.0.0.0/0 dev lo table 100 # ip route show table wan0; ip route show table 100 > > iptables -I INPUT -p tcp --dport 9001 -j ACCEPT > iptables -t mangle -N TOR > iptables -t mangle -A PREROUTING -p tcp -m socket -j TOR > iptables -t mangle -A TOR -j MARK --set-mark 1 > iptables -t mangle -A TOR -j ACCEPT > #iptables -t mangle -A PREROUTING -p tcp -s 192.168.0.0/24 --sport 9001 -j MARK --set-xmark 0x1/0xffffffff > #iptables -t mangle -A PREROUTING -p tcp --dport 9001 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 9001 --on-ip 127.0.0.1 > > > Backend Tor Relay Node Configs: > > # cat /tmp/torrc > Nickname xxxxxxxxxxxxxxxxxx > ORPort xxx.xxx.xxx.xxx:9001 NoListen > ORPort 192.168.0.11:9001 NoAdvertise > SocksPort 9050 > SocksPort 192.168.0.11:9050 > ControlPort 9051 > DirAuthority longclaw orport=443 no-v2 v3ident=23D15D965BC35114467363C165C4F724B64B4F66 199.58.81.140:80 74A910646BCEEFBCD2E874FC1DC997430F968145 > FallbackDir 193.23.244.244:80 orport=443 id=7BE683E65D48141321C5ED92F075C55364AC7123 > DirCache 0 > ExitRelay 0 > MaxMemInQueues 192 MB > GeoIPFile /opt/share/tor/geoip > Log notice file /tmp/torlog > Log notice syslog > VirtualAddrNetwork 10.192.0.0/10 > AutomapHostsOnResolve 1 > TransPort 192.168.0.11:9040 > DNSPort 192.168.0.11:9053 > RunAsDaemon 1 > DataDirectory /tmp/tor/torrc.d/.tordb > AvoidDiskWrites 1 > User tor > ContactInfo tor-operator at your-emailaddress-domain > > # cat /tmp/torrc > Nickname xxxxxxxxxxxxxxxxxx > ORPort xxx.xxx.xxx.xxx:9001 NoListen > ORPort 192.168.0.41:9001 NoAdvertise > SocksPort 9050 > SocksPort 192.168.0.41:9050 > ControlPort 9051 > DirAuthority longclaw orport=443 no-v2 v3ident=23D15D965BC35114467363C165C4F724B64B4F66 199.58.81.140:80 74A910646BCEEFBCD2E874FC1DC997430F968145 > FallbackDir 193.23.244.244:80 orport=443 id=7BE683E65D48141321C5ED92F075C55364AC7123 > DirCache 0 > ExitRelay 0 > MaxMemInQueues 192 MB > GeoIPFile /opt/share/tor/geoip > Log notice file /tmp/torlog > Log notice syslog > VirtualAddrNetwork 10.192.0.0/10 > AutomapHostsOnResolve 1 > TransPort 192.168.0.41:9040 > DNSPort 192.168.0.41:9053 > RunAsDaemon 1 > DataDirectory /tmp/tor/torrc.d/.tordb > AvoidDiskWrites 1 > User tor > ContactInfo tor-operator at your-emailaddress-domain > > > Shell Scripts to Remotely Manage Tor Relay Nodes: > > # cat /usr/sbin/stat-tor-nodes > #!/bin/sh > uptime-all-nodes; memfree-all-nodes; netstat-tor-nodes > > # cat /usr/sbin/uptime-all-nodes > #!/bin/sh > /usr/bin/ssh -t admin at 192.168.0.11 'hostname; uptime' > /usr/bin/ssh -t admin at 192.168.0.21 'hostname; uptime' > /usr/bin/ssh -t admin at 192.168.0.31 'hostname; uptime' > /usr/bin/ssh -t admin at 192.168.0.41 'hostname; uptime' > /usr/bin/ssh -t admin at 192.168.0.51 'hostname; uptime' > > # cat /usr/sbin/memfree-all-nodes > #!/bin/sh > /usr/bin/ssh -t admin at 192.168.0.11 'hostname; grep MemFree /proc/meminfo' > /usr/bin/ssh -t admin at 192.168.0.21 'hostname; grep MemFree /proc/meminfo' > /usr/bin/ssh -t admin at 192.168.0.31 'hostname; grep MemFree /proc/meminfo' > /usr/bin/ssh -t admin at 192.168.0.41 'hostname; grep MemFree /proc/meminfo' > /usr/bin/ssh -t admin at 192.168.0.51 'hostname; grep MemFree /proc/meminfo' > > # cat /usr/sbin/netstat-tor-nodes > #!/bin/sh > /usr/bin/ssh -t admin at 192.168.0.11 'hostname; netstat -anp | grep -i tor | grep -v 192.168.0.1: | wc -l' > /usr/bin/ssh -t admin at 192.168.0.21 'hostname; netstat -anp | grep -i tor | grep -v 192.168.0.1: | wc -l' > /usr/bin/ssh -t admin at 192.168.0.31 'hostname; netstat -anp | grep -i tor | grep -v 192.168.0.1: | wc -l' > /usr/bin/ssh -t admin at 192.168.0.41 'hostname; netstat -anp | grep -i tor | grep -v 192.168.0.1: | wc -l' > /usr/bin/ssh -t admin at 192.168.0.51 'hostname; netstat -anp | grep -i tor | grep -v 192.168.0.1: | wc -l' > > # cat /jffs/sbin/ps-tor-nodes > #!/bin/sh > /usr/bin/ssh -t admin at 192.168.0.11 'hostname; ps w | grep -i tor' > /usr/bin/ssh -t admin at 192.168.0.21 'hostname; ps w | grep -i tor' > /usr/bin/ssh -t admin at 192.168.0.31 'hostname; ps w | grep -i tor' > /usr/bin/ssh -t admin at 192.168.0.41 'hostname; ps w | grep -i tor' > /usr/bin/ssh -t admin at 192.168.0.51 'hostname; ps w | grep -i tor' > > # cat /usr/sbin/killall-tor-nodes > #!/bin/sh > read -r -p "Are you sure? [y/N] " input > case "$input" in > [yY]) > /usr/bin/ssh -t admin at 192.168.0.11 'killall tor' > /usr/bin/ssh -t admin at 192.168.0.21 'killall tor' > #/usr/bin/ssh -t admin at 192.168.0.31 'killall tor' > /usr/bin/ssh -t admin at 192.168.0.41 'killall tor' > /usr/bin/ssh -t admin at 192.168.0.51 'killall tor' > return 0 > ;; > *) > return 1 > ;; > esac > > # cat /usr/sbin/restart-tor-nodes > #!/bin/sh > read -r -p "Are you sure? [y/N] " input > case "$input" in > [yY]) > /usr/bin/ssh -t admin at 192.168.0.11 '/usr/sbin/tor -f /tmp/torrc --quiet' > /usr/bin/ssh -t admin at 192.168.0.21 '/usr/sbin/tor -f /tmp/torrc --quiet' > #/usr/bin/ssh -t admin at 192.168.0.31 '/usr/sbin/tor -f /tmp/torrc --quiet' > /usr/bin/ssh -t admin at 192.168.0.41 '/usr/sbin/tor -f /tmp/torrc --quiet' > /usr/bin/ssh -t admin at 192.168.0.51 '/usr/sbin/tor -f /tmp/torrc --quiet' > return 0 > ;; > *) > return 1 > ;; > esac > > I've been meaning to put together a tutorial on Loadbalancing Tor Relays, but haven't found the time as of yet. Perhaps, this will help, until I am able to find the time. > > I appreciate your knowledge sharing and for furthering the topic of Loadbalancing Tor Relays; especially, with regard to Bridging and Exit Relays. > > Keep up the Great Work! > > Respectfully, > > > Gary > On Tuesday, January 4, 2022, 09:57:52 PM MST, Roger Dingledine <arma at torproject.org> wrote: > > [I'm about to go off-line for some days, so I am sending my current > suboptimally-organized reply, which I hope is better than waiting another > week to respond :)] > > On Thu, Dec 30, 2021 at 10:42:51PM -0700, David Fifield wrote: > > Let's make a distinction between the "frontend" snowflake-server > > pluggable transport process, and the "backend" tor process. These don't > > necessarily have to be 1:1; either one could be run in multiple > > instances. Currently, the "backend" tor is the limiting factor, because > > it uses only 1 CPU core. The "frontend" snowflake-server can scale to > > multiple cores in a single process and is comparatively unrestrained. > > Excellent point, and yes this simplifies. Great. > > > I believe that the "pinning" of a client session to particular tor > > instance will work automatically by the fact that snowflake-server keeps > > an outgoing connection alive (i.e., through the load balancer) as long > > as a KCP session exists. > >[...] > > But before starting the second instance the first time, copy keys from > > the first instance: > > Hm. It looks promising! But we might still have a Tor-side problem > remaining. I think it boils down to how long the KCP sessions last. > > The details on how exactly these bridge instances will diverge over time: > > The keys directory will start out the same, but after four weeks > (DEFAULT_ONION_KEY_LIFETIME_DAYS, used to be one week but in Tor > 0.3.1.1-alpha, proposal 274, we bumped it up to four weeks) each > bridge will rotate its onion key (the one clients use for circuit-level > crypto). That is, each instance will generate its own fresh onion key. > > The two bridge instances actually haven't diverged completely at that > point, since Tor remembers the previous onion key (i.e. the onion key > from the previous period) and is willing to receive create cells that > use it for one further week (DEFAULT_ONION_KEY_GRACE_PERIOD_DAYS). So it > is after 5 weeks that the original (shared) onion key will no longer work. > > Where this matters is (after this 5 weeks have passed) if the client > connects to the bridge, fetches and caches the bridge descriptor of > instance A, and then later it connects to the bridge again and gets > passed to instance B. In this case, the create cell that the client > generates will use the onion key for instance A, and instance B won't > know how to decrypt it so it will send a destroy cell back. > > If this is an issue, we can definitely work around it, by e.g. disabling > the onion key rotation on the bridges, or setting up a periodic rsync+hup > between the bridges, or teaching clients to use createfast cells in this > situation (this type of circuit crypto doesn't use the onion key at all, > and just relies on TLS for security -- which can only be done for the > first hop of the circuit but that's the one we're talking about here). > > But before we think about workarounds, maybe we don't need one: how long > does "the KCP session" last? > > Tor clients try to fetch a fresh bridge descriptor every three-ish > hours, and once they fetch a bridge descriptor from their "current" > bridge instance, they should know the onion key that it wants to use. So > it is that up-to-three-hour window where I think things could go wrong. > And that timeframe sounds promising. > > (I also want to double-check that clients don't try to use the onion > key from the current cached descriptor while fetching the updated > descriptor. That could become an ugly bug in the wrong circumstances, > and would be something we want to fix if it's happening.) > > Here's how you can simulate a pair of bridge instances that have diverged > after five weeks, so you can test how things would work with them: > > Copy the keys directory as before, but "rm secret_onion_key*" in the > keys directory on n-1 of the instances, before starting them.) > > Thanks! > --Roger >

1 0

Bridges not being distributed
by Spydar007 25 Mar '22

25 Mar '22

Hello, I notice (almost) all bridges are showing their distributor mechanism as None on Tor Metrics.[1] There are also hardly any in the latest pool assignments file from CollecTor.[2] Curious as to why? Is this a change that needs fixing on a bridge operators end, or simply BridgeDB not reporting properly? [1] https://metrics.torproject.org/rs.html#search/type:bridge%20 [2] https://metrics.torproject.org/collector/recent/bridge-pool-assignments/

3 2

update obfs4proxy if you run a bridge
by meskio 23 Mar '22

23 Mar '22

Hello, TL;RD: if you are a bridge operator please update obfs4proxy to a version>=0.0.12. There is a new version of obfs4proxy (>=0.0.12) which fixes a security issue[0]. Tor Browser has already updated to the new version, which reduces a bit the security problem, but introduces a partial incompatibility between versions[1]. Because of that updating to the latest version greatly will help bridge users. If you use debian you can find the latest version bullseye-backports[2]. If you use docker there is a new version of the official docker image that you can upgrade to[3]. Thank you for running bridges, let me know if you need any help upgrading it. [0] https://lists.torproject.org/pipermail/anti-censorship-team/2022-January/00… [1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804 [2] https://packages.debian.org/stable-backports/obfs4proxy [3] https://hub.docker.com/layers/thetorproject/obfs4-bridge/0.11/images/sha256… -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

4 3

Re: [tor-relays] Bridge lifecycle expectations
by Just a Pleb 23 Mar '22

23 Mar '22

Hi meskio, Thanks for the detailed response. My bridge has been assigned to telegram so that explains why it's not active yet. Watching per country stats makes sense for determining where the bridge has been blocked. Also good to know the bridge state should be fully disposed when recycling rather than preserved for reputational purposes. Follow up question on running bridges and relays. If the consensus is I should pick Relays xor Bridges to run I will but I'm not fully convinced that's the right trade off for capacity -vs- security given "good actors" wouldn't attack the traffic and bad actors wouldn't obey the injunction the only extra security impact I see is limiting damage from "good actor who get compromised" which is *some* obviously... Thanks

1 0

Ports blocked
by tdukes＠palmettoshopper.com 23 Mar '22

23 Mar '22

Looks like my ISP has shut me down. The ports I were using are now blocked. I checked them with an online port checker. I tried.

1 0

Snowflake vs bridge on home connection on a Raspberry Pi 4
by Cristian Consonni 22 Mar '22

22 Mar '22

Hi all, I have a fiber connection at home and I would like to run a bridge or standalone Snowflake proxy on a dedicated Raspberry Pi 4. I have been reading some threads [1][2] from this list about the topic, but it is not completely clear to me what would be the best choice. The requirements [3] for running a bridge are 24/7 connectivity and the ability to expose TCP ports; however, I have read that it is also preferred that you have a static IP to run a bridge (in the page about the recent campaign about bridges, having a static IP was listed as a requirement [4]). In principle my home connection has a dynamic IP, but I have been logging my IP address for the last few days and it seems quite stable (it has not changed for the last 4 days). What's the best choice? Can I run both? Best, Cristian [1]: https://lists.torproject.org/pipermail/tor-relays/2022-February/020298.html [2]: https://lists.torproject.org/pipermail/tor-relays/2022-February/020355.html [3]: https://community.torproject.org/relay/setup/bridge/ [4]: https://blog.torproject.org/run-a-bridge-campaign/

2 1

Newbie needs help
by tdukes＠palmettoshopper.com 22 Mar '22

22 Mar '22

Hi, Thanks for adding me to the list. I setup a Tor Relay in Docker using this image: https://hub.docker.com/r/doudou34/tor-server Its running, so how can I test it? When I try to access it using port 9001, I'm unable to connect. I have opened the port on my firewall to the public. Haven't done it on my router yet but I have Portainer running in Docker and have no problem accessing it. Not a lot of instructions that I can find. I can post the torrc file but it's the same as the one on the docker page. ### /etc/torrc ### # see /etc/torrc/torrc.default and https://www.torproject.org/docs/tor-manual.html.en # Server's public IP Address (usually automatic) #Address 10.10.10.10 # Port to advertise for incoming Tor connections. # common ports are 9001, 443 ORPort 9001 # Mirror directory information for others (optional) # common ports are 9030, 80 #DirPort 9030 # Run as a relay only (not as an exit node) ExitPolicy reject *:* # no exits allowed # Set limits #RelayBandwidthRate 1024 KB # Throttle traffic to #RelayBandwidthBurst 2048 KB # But allow bursts up to #MaxMemInQueues 512 MB # Limit Memory usage to # Run Tor as obfuscated bridge #ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed #ServerTransportListenAddr obfs3 0.0.0.0:54444 #BridgeRelay 1 # Run Tor only as a server (no local applications) SocksPort 0 # Run Tor as a regular user (do not change this) User debian-tor DataDirectory /var/lib/tor # If no Nickname or ContactInfo is set, docker-entrypoint will use # the environment variables to add Nickname/ContactInfo here #Nickname Tor4 # only use letters and numbers #ContactInfo email(a)example.org I've only been using docker for a few days, so maybe its an issue there. TIA

4 4

Bridge on two port
by binarynoise 21 Mar '22

21 Mar '22

Hello everyone, I currently run a bridge on port 8080. As I don't have a webserver running, I thought I'd also publish that bridge on port 443. For relays there is that "ORPort 443 NoListen"-Option. What is the equivalent for ServerTransportListenAddr? Is ServerTransportListenAddr obfs4 0.0.0.0:443 NoListen the right way? Is this possible at all? Does make running a bridge on two ports make sense at all? Greetings binarynoise

1 0

Tor 0.3.5.x is unsupported, please upgrade
by Georg Koppen 21 Mar '22

21 Mar '22

Hello! It's time again to get relays upgraded running an EOL Tor series (0.3.5.x). We'll start reaching out to operators with valid contact information this week and plan to start reject relays which are still on 0.3.5.x about 4 weeks from now on at the begin of March. You can follow along that process in our bug tracker[1] if you want. For the general processes around dealing with EOL relays in the Tor network see my mail from last October[2]. Feedback and improvements are welcome, as always. Georg [1] https://gitlab.torproject.org/tpo/network-health/team/-/issues/171 [2] https://lists.torproject.org/pipermail/tor-relays/2021-October/019862.html

1 1

Connection burst
by Felix 21 Mar '22

21 Mar '22

Hi everybody Just to let you know. Yesterday between 21:26 and 21:31 utc the relay 03C3069E814E296EB18776EB61B1ECB754ED89FE (Tor 0.4.7.4-alpha, LibreSSL 3.4.2) received a connection burst of 2k+ source addresses out of 174 /8 ip4 nets (1-223/8). They were kicked off by the packetfilter because the max conn per ip rate was above my applied max threshold. The notice level DoS mitigation entry remained untouched while sitting behind the pf. Beautiful! -- Cheers Felix

2 1

Which is the most useful: relay or bridge
by Thoughts 19 Mar '22

19 Mar '22

Currently running both a guard relay and a bridge, one each on two different systems, but both behind the same firewall and static IP. Curious if this is a good idea, or if one or the other is of much greater value. Seeing about 2200 inbound, 2800 outbound connections on my relay per nyx, with an observed speed of 5 MB/s (only a few days into the guard ramp-up phase) Seeing about 20 connected clients on the bridge, which is advertising 2.2 MiB/s per the metrics page. R/W rates around around 150k per that same page, about 1/4th of the average on the guard relay. Thoughts?

4 4

What is the current method of submitting Tor-friendly ISPs for consideration?
by Isaac Grover, Aileron I.T. 18 Mar '22

18 Mar '22

Good afternoon from Wisconsin, Following up on a previous post to this list, I started contacting AS administrators in bulk and currently have five ISPs in unique ASs who state they can accommodate Tor exit nodes. The GoodBadISPs page on TP.o doesn't have a submission form or contact email address where I can submit the relevant info. Should I post them here or is there a better/preferred method? Thank you in advance, Isaac Grover

2 1

Possible compression bomb
by Tschador 18 Mar '22

18 Mar '22

Hi, today I found this message in my Tor relay log: Mar 17 14:26:17.000 [warn] Possible compression bomb; abandoning stream. Mar 17 14:26:17.000 [warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 86.59.21.38:80). What does it mean? Regards

1 0

Re: [tor-relays] Auto-discovered IPv6 address [...] has not been found reachable.
by Onion Operator 14 Mar '22

14 Mar '22

> Fran wrote: > Hej, Hello, > > TLS handshake succeeds for me from my laptop: > > $ curl --insecure https://[2a02:a446:5ef1:1:d072:53ff:fef4:ea59] -v > * Trying 2a02:a446:5ef1:1:d072:53ff:fef4:ea59:443... > * Connected to 2a02:a446:5ef1:1:d072:53ff:fef4:ea59 > (2a02:a446:5ef1:1:d072:53ff:fef4:ea59) port 443 (#0) > * ALPN, offering h2 > * ALPN, offering http/1.1 > * TLSv1.3 (OUT), TLS handshake, Client hello (1): > * TLSv1.3 (IN), TLS handshake, Server hello (2): > * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.3 (OUT), TLS handshake, Client hello (1): > * TLSv1.3 (IN), TLS handshake, Server hello (2): > * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): > * TLSv1.3 (IN), TLS handshake, Certificate (11): > * TLSv1.3 (IN), TLS handshake, CERT verify (15): > * TLSv1.3 (IN), TLS handshake, Finished (20): > * TLSv1.3 (OUT), TLS handshake, Finished (20): > * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 > * ALPN, server did not agree to a protocol > * Server certificate: > * subject: CN=www.s5uu2cs3ui4yok4.net > * start date: Nov 2 00:00:00 2021 GMT > * expire date: Apr 16 00:00:00 2022 GMT > * issuer: CN=www.yi5r3anmk2gd3fbqrw4.com > * SSL certificate verify result: unable to get local issuer certificate (20), > continuing anyway. >> GET / HTTP/1.1 >> Host: [2a02:a446:5ef1:1:d072:53ff:fef4:ea59] >> User-Agent: curl/7.82.0 >> Accept: */* >> > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): > * old SSL session ID is stale, removing > ^C > > What if you configure the IPv6 address by hand in torrc? for months my torrc had ORPort 443 IPv4Only ORPort [2a02:a446:5ef1:1:d072:53ff:fef4:ea59]:443 IPv6Only Address XXX and read in the logs: Unable to find IPv6 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. (XXX had only the A record) > > Can you please send your torrc and the output of --- cut here --- ContactInfo flev @ kpnmail . nl Nickname RealityLeighWinner ExitPolicy reject *:* ExitPolicy reject6 *:* AvoidDiskWrites 1 DirPort 80 ORPort 443 Address XXX --- cut here --- where XXX is a DNS entry with both A and AAAA records. > > ip route show table all default via 192.168.2.254 dev eth0 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.102 broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 broadcast 192.168.2.0 dev eth0 table local proto kernel scope link src 192.168.2.102 local 192.168.2.102 dev eth0 table local proto kernel scope host src 192.168.2.102 broadcast 192.168.2.255 dev eth0 table local proto kernel scope link src 192.168.2.102 ::1 dev lo proto kernel metric 256 pref medium 2a02:a446:5ef1:1::/64 dev eth0 proto kernel metric 256 expires 257593sec pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium default via fe80::7e39:53ff:fef6:d2cc dev eth0 proto ra metric 1024 expires 1464sec hoplimit 64 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local 2a02:a446:5ef1:1:d072:53ff:fef4:ea59 dev eth0 table local proto kernel metric 0 pref medium local fe80::d072:53ff:fef4:ea59 dev eth0 table local proto kernel metric 0 pref medium multicast ff00::/8 dev eth0 table local proto kernel metric 256 pref medium > ip address show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether d2:72:53:f4:ea:59 brd ff:ff:ff:ff:ff:ff permaddr 00:1e:06:42:f9:14 inet 192.168.2.102/24 brd 192.168.2.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a02:a446:5ef1:1:d072:53ff:fef4:ea59/64 scope global dynamic mngtmpaddr valid_lft 257524sec preferred_lft 171124sec inet6 fe80::d072:53ff:fef4:ea59/64 scope link valid_lft forever preferred_lft forever BTW, it's also silly that the DirPort seems not effective. I can reach it from outside but don't get it in the descriptor. This the output of ss -plt: LISTEN 0 4096 0.0.0.0:80 0.0.0.0:* users:(("tor",pid=992,fd=9)) LISTEN 0 4096 127.0.0.1:9050 0.0.0.0:* users:(("tor",pid=992,fd=6)) LISTEN 0 4096 0.0.0.0:443 0.0.0.0:* users:(("tor",pid=992,fd=7)) LISTEN 0 4096 [::]:443 [::]:* users:(("tor",pid=992,fd=8)) > > tnx & ciao, > fran thanks Oo.

2 2

Moving Bridges
by Eddie 12 Mar '22

12 Mar '22

One of my bridges has just taken on a slew of new connections. Over the last few days it's gone from an average of around 15 users to over 300 (according to tor metrics. The logs show over 1,000 unique clients for the same period). Unfortunately with the VPS provider I'm using, this isn't sustainable as I'll probably blow my bandwidth allowance in a matter of days and the excess charges are crazy. So I'm looking to move both my bridges to a new VPS, which unfortunately is probably going to p!ss off the 300 plus folks who have just found my bridge only for it to promptly disappear, as I'm certain that there's no way to "move" them to the new location and have a couple of questions. I'm guessing that the only advantage in copying over the keys directory is that the historical statistics will remain. Is there any reason to copy over the pt_state directory, to retain the same bridgeline information. Cheers.

4 5

Flooding of unbound via resolve attempts
by Georg Koppen 11 Mar '22

11 Mar '22

Hello! As you might know we are doing regular (at the moment weekly) scans of exit nodes to find and help with misconfigurations or errors that have potentially serious effects for Tor network usability and performance. The results we got so far after over a year of scanning are roughly single digit numbers of exit relays per week having mostly DNS configuration issues (unbound crashed etc.) However, this week we suddenly found almost 80 exit relays with malfunctioning DNS resolution[1] which was surprising. Additionally, after some of the servers got fixed the issue returned. DrWhax (thanks!) pointed us to a possible explanation twittered by the unredacted folks: https://twitter.com/unredacted_org/status/1501458345219215363 It seems that someone (intentionally or not) is overwhelming unbound leading to DNS resolution issues for those exit operators that do run this local resolver, which we currently recommend. We've opened a ticket[2] for further investigation, but I hope this email raises some awareness so that exit operators can keep and eye on the situation. Feel free to add insights you have to the ticket. Additionally, I bet if someone would share how they do monitoring for such a problem on their exits then a lot of exit operators would be happily picking up that setup and the Tor network would win. :) Thanks, Georg [1] https://gitlab.torproject.org/tpo/network-health/team/-/issues/197 [2] https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/30

3 2

Auto-discovered IPv6 address [...] has not been found reachable.
by Onion Operator 11 Mar '22

11 Mar '22

Hi Need another couple of eye balls on my relay, RealityLeighWinner. I keep reading "Auto-discovered IPv6 address [2a02:a446:5ef1:1:d072:53ff:fef4:ea59]:443 has not been found reachable..." in the logs but I actually can reach it with openssl s_client from another ipv6 box not in the same network. Could please anybody double check and maybe explain this behavior? Thanks. Oo.

2 1

Ansible role to deploy Bridges
by Erasme - Relay Operator 09 Mar '22

09 Mar '22

Hi all, In the effort of deploying obfs4 bridges for the community we are sharing our Ansible role that allowed us to deploy multiple nodes: https://github.com/NewNewYorkBridges/ansible-tor-bridge For now it is only available on Debian but we will make it available for other distributions. We hope this role is helpful for the community. Feel free to send us your feedback! Kind regards, Erasme

3 2

Relay Finger Print Mismatch Error
by Peligro 08 Mar '22

08 Mar '22

Hello Everyone, I started running a relay, recently and it got up for 3 days became middle node and suddenly stopped. I am not sure what was happened, In logs i found that finger print mismatch error. so i tried to find is there any related post or blog but i couldn't found any, please help me on this to get back relay community. Very Happy using tor, want contribute to community Thanks Peligro

3 2

Good hosting providers for an exit node
by Charles Bevitt 07 Mar '22

07 Mar '22

I run a middle relay at home but now I’m planning to also lease a VPS to run an exit node. I’d appreciate any suggestions for a good hosting provider. My first choice would have been BUYVM, but it seems they’re always out of stock. This will be my first time working with a VPS and Linux, so wish me luck! Chuck Bevitt Sent from my iPad

3 2

FreeBSD DNS/tor version question
by George 07 Mar '22

07 Mar '22

At Saturday's relay ops events, someone had issues with a FreeBSD relay. I believe the issues were related to DNS and the tor version. Please feel free to raise those questions here, or on IRC at #tor-relays. g

1 0

New bridge IN Russia?
by a tor op 06 Mar '22

06 Mar '22

Hi, I am thinking of starting another bridge. In regards to the current situation, is there a real benefit in deploying one within Russia or does that really not matter? A tor op

2 1

rdsys was ignoring BridgeDistribution
by meskio 05 Mar '22

05 Mar '22

As mentioned before[0] BridgeDB now uses rdsys as backend. I just found out that there was a bug in rdsys and the BridgeDistribution configuration was ignored. Private bridges configured with 'BridgeDistribution none' might have being distributed by bridgedb if they were not configured with 'PublishServerDescriptor 0'. Disabling PublishServerDescriptor stops the bridge from sending it's descriptor to the bridge authority, so rdsys doesn't know it exists. Other bridges configured to be used by an specific distributor might have being distributed by a different one. This has being happening from February 28th ~12:00UTC until today March 4 ~12:00UTC. You can search for your hashed fingerprint in the pool assignments during this period if you want to know to what distributor was your bridge assigned to: https://metrics.torproject.org/collector/recent/bridge-pool-assignments/ Only bridges assigned to moat, email or https might have being distributed, as telegram, settings and reserved bridges are not distributed at the moment. The metrics relay search[1] will take some time to display the new assignments. I'm sorry for the situation. [0] https://lists.torproject.org/pipermail/tor-relays/2022-February/020365.html [1] https://metrics.torproject.org/rs.html -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

2 2