- tor-relays - lists.torproject.org

Re: Interest in sharing a IPv4 /24 across a datacenter provider?
by Tor at 1AEO 25 Feb '25

25 Feb '25

Yes, that's a great suggestion! I've adjusted the subject line to match new topic. If anybody is interested in sharing, please reach out. I should have a few IPv4 /24 coming online over the next few weeks. On Monday, February 24th, 2025 at 4:26 AM, boldsuck via tor-relays <tor-relays(a)lists.torproject.org> wrote: > > > On Saturday, 22 February 2025 06:49 Tor at 1AEO via tor-relays wrote: > > > > > https://metrics.torproject.org/rs.html#search/185.220.101. > > > > We are 5 relay orgs sharing a /24. would be nice if you share the subnet > > > > with 1-2 other relay operators. > > > > Logistically, how do you or how would you recommend to share a /24 across > > > > more than 1 organization? Lots of ideas / questions ... > > > > Are they required to be in the same data center and/or same rack and/or > > > > nearby data centers with a dedicated/private connection? Different servers > > > > next to each other? > > > Whether the servers need to be in one rack or data center depends on the > provider’s backbone. There are providers who have several locations/data > centers internally networked. But the most practical and safest way is to > share a e.g. 1/4 rack: > https://www.myloc.de/en/colocation/rack/quarter-rack.html > > > Router locally doing BGP for something like a /26 to specific servers or > > statically mapping /26 to specific server ports? > > > > Doesn't seem possible via BGP to share a /24 across internet connections due > > to the limit on needing to be a /24 for default-free zone... > > > That was the reason for my statement. You can't BGP advertise smaler than /24 > And hardly anyone can afford a 10G, 40G or 100G connection or several petabytes > of traffic per month. > > We have divided a /24 into /27 which are routed. One AS and each /27 is > individually RIPE ASSIGNED PA > > > On Wednesday, July 10th, 2024 at 6:27 AM, lists(a)for-privacy.net <lists@for- > > privacy.net> wrote: > > > > On Mittwoch, 10. Juli 2024 00:32:04 CEST Osservatorio Nessuno via > > > tor-relays> > > > wrote: > > > > > > > we are planning to get some hardware to run a physical Tor exit node, > > > > starting with a 1Gbps dedicated, unmetered uplink (10Gbps downlink). We > > > > will also route a /24 on it, so we will have large availability of > > > > addresses to run multiple instances. We have been running a few exit > > > > nodes so far, but never on our own hardware. > > > > > > Your bottleneck is the 1G uplink. > > > For comparison, I have 2x Xeon E5-2680v2 10C/20T and 256Gb RAM > > > 2x 10G nic (LACP bond) and I can not achieve 10G throughput with it. > > > As a rule of thumb, I would always count one instance per thread or core. > > > I have 40T and 40 tor exit instances. > > > > > > F3Netze has specified the hardware in Contact info: > > > https://metrics.torproject.org/rs.html#search/185.220.100. > > > > > > > Which is the bandwith limit per core/Tore instance? Or what can we > > > > expect to be the bottleneck? > > > > > > That depends on the CPU clock speed. Fast Ryzen or Epyc's can do 50-70 > > > MiB/s per core/instance. > > > > > > > Due to some other requirements we need for some experiments (SFP ports, > > > > coreboot support, etc) we can mainly choose between these 2 CPUs: > > > > Intel i5-1235U > > > > Intel i7-1255U > > > > > > > > The cost between the two models is significant enough in our case to > > > > pick the i7 only if it's really useful. > > > > > > > > In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is > > > > it?). > > > > > > > > Should this allow us to saturate the uplink? > > > > > > Guards need more resources than exits since the introduction of > > > congestion- > > > control and because of DDoS I would use 64GB RAM for a guard. > > > With your IP space and 1G uplink, I would take the i5 with 32Gb, save the > > > money and maybe add a second server later. Or if you build the hardware > > > yourself, look for a used Epyc or Ryzen server. 16 or 32 core with high > > > base clock. Used server hardware from the data center is like new. > > > > > > > To summarize, with this bandwith, this hardware and a /24 how many Tor > > > > exit nodes should be ideal to run considering that each of them could > > > > have their own address? > > > > > > https://metrics.torproject.org/rs.html#search/185.220.101. > > > We are 5 relay orgs sharing a /24. Currently 5x 2x10G(or 25G) > > > With now 8 relays per IP, over 2000 instances can run in a /24 subnet. It > > > would be nice if you share the subnet with 1-2 other relay operators. > > > > > > -- > > > ╰_╯ Ciao Marco! > > > > > > Debian GNU/Linux > > > > > > It's free software and it gives you > > > freedom!_______________________________________________ tor-relays > > > mailing list > > > tor-relays(a)lists.torproject.org> > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > -- > ╰_╯ Ciao Marco! > > Debian GNU/Linux > > It's free software and it gives you freedom!_______________________________________________ > tor-relays mailing list -- tor-relays(a)lists.torproject.org > To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org

1 0

Issues with Ubuntu packages on deb.torproject.org and its Onion Service
by Alexander Hansen Færøy 25 Feb '25

25 Feb '25

Hey folks, We are aware of two issues related to deb.torproject.org that we are working on fixing: The first issue is the Ubuntu packages are missing when using apt. Tor has, for a while, had flaky CI across our entire infrastructure due to Docker upstream adding rate-limiting for their images, and our different teams have been working on moving to our own Docker images with our own container registry. Things went a bit too fast here, but we expect to have x86-64 and aarch64 packages for the Ubuntu releases out again very soon. This should NOT negatively impact your current installs of Tor, but apt will be unhappy when you do an `apt update` until this is resolved (expected eta: 1 day). This issue is being tracked in [0]. In addition to the situation with the Ubuntu packages, we are also aware of an issue with the Onion Service provided for deb.torproject.org being unreachable/unstable[1]. Sorry for the inconvenience here. I'll update the list when we think it's fixed. Cheers, Alex [0]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/42052 [1]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/42054 -- Alexander Hansen Færøy

1 0

Re: Hardware sizing for physical exit node
by Tor at 1AEO 24 Feb '25

24 Feb '25

>> https://metrics.torproject.org/rs.html#search/185.220.101. >> We are 5 relay orgs sharing a /24. would be nice if you share the subnet with 1-2 other relay operators. Logistically, how do you or how would you recommend to share a /24 across more than 1 organization? Lots of ideas / questions ... Are they required to be in the same data center and/or same rack and/or nearby data centers with a dedicated/private connection? Different servers next to each other? Router locally doing BGP for something like a /26 to specific servers or statically mapping /26 to specific server ports? Doesn't seem possible via BGP to share a /24 across internet connections due to the limit on needing to be a /24 for default-free zone... Sent with Proton Mail secure email. On Wednesday, July 10th, 2024 at 6:27 AM, lists(a)for-privacy.net <lists(a)for-privacy.net> wrote: > On Mittwoch, 10. Juli 2024 00:32:04 CEST Osservatorio Nessuno via tor-relays > wrote: > > > we are planning to get some hardware to run a physical Tor exit node, > > starting with a 1Gbps dedicated, unmetered uplink (10Gbps downlink). We > > will also route a /24 on it, so we will have large availability of > > addresses to run multiple instances. We have been running a few exit > > nodes so far, but never on our own hardware. > > > Your bottleneck is the 1G uplink. > For comparison, I have 2x Xeon E5-2680v2 10C/20T and 256Gb RAM > 2x 10G nic (LACP bond) and I can not achieve 10G throughput with it. > As a rule of thumb, I would always count one instance per thread or core. > I have 40T and 40 tor exit instances. > > F3Netze has specified the hardware in Contact info: > https://metrics.torproject.org/rs.html#search/185.220.100. > > > Which is the bandwith limit per core/Tore instance? Or what can we > > expect to be the bottleneck? > > > That depends on the CPU clock speed. Fast Ryzen or Epyc's can do 50-70 MiB/s > per core/instance. > > > Due to some other requirements we need for some experiments (SFP ports, > > coreboot support, etc) we can mainly choose between these 2 CPUs: > > Intel i5-1235U > > Intel i7-1255U > > > > The cost between the two models is significant enough in our case to > > pick the i7 only if it's really useful. > > > > In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is > > it?). > > > > Should this allow us to saturate the uplink? > > > Guards need more resources than exits since the introduction of congestion- > control and because of DDoS I would use 64GB RAM for a guard. > With your IP space and 1G uplink, I would take the i5 with 32Gb, save the > money and maybe add a second server later. Or if you build the hardware > yourself, look for a used Epyc or Ryzen server. 16 or 32 core with high base > clock. Used server hardware from the data center is like new. > > > To summarize, with this bandwith, this hardware and a /24 how many Tor > > exit nodes should be ideal to run considering that each of them could > > have their own address? > > > https://metrics.torproject.org/rs.html#search/185.220.101. > We are 5 relay orgs sharing a /24. Currently 5x 2x10G(or 25G) > With now 8 relays per IP, over 2000 instances can run in a /24 subnet. It > would be nice if you share the subnet with 1-2 other relay operators. > > -- > ╰_╯ Ciao Marco! > > Debian GNU/Linux > > It's free software and it gives you freedom!_______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: Guidance on optimal Tor relay server configurations
by Tor at 1AEO 21 Feb '25

21 Feb '25

Also interested in this thread and efforts. Plan to do your suggestion on 80 core and 128 core Tor server node tests. Will work on posting back here too. BGP plan to keep separate on router to avoid using Tor server resources. Does DNS have similar resource concerns as BGP tables? If so, what's best way to handle DNS outside of Tor server resources? On router too? Can you say more on why you say this, "You can't fully utilize a /24 with 6x 64 core servers on a 100G Router."? On Tuesday, February 18th, 2025 at 8:43 AM, boldsuck via tor-relays <tor-relays(a)lists.torproject.org> wrote: > On Tuesday, 18 February 2025 17:00 usetor.wtf via tor-relays wrote: > > > Another question - what's the most optimal count of Tor relays per IP when > > using an IPv4 /24, i.e. roughly 256 IPs? Looking for thoughts / guidance as > > this can quickly be a costly endeavor with slow turn around times on > > securing data center capacity. > > > The number of IPs is unimportant. > CPU cores count and network bandwidth, fast cores, the fastest and best > cooling! The higher the CPU clock speed, the more MiB/s traffic per tor > instance. > Slam 60 tor instances onto a 64-core CPU (or 120 instances on 128 core) with > 2x10 or 2x25G card and let it run for a few weeks. Then you will see if you > can create some more instances. > You also have to do DNS. PowerDNS + dnsdist is your friend with 2x10G or more. > Where do you do BGP on the server or router? Full table BGP need recources > too. You can't fully utilize a /24 with 6x 64 core servers on a 100G Router. > > > Current hypothesis is around 2 Tor Instances per 256 IPs for 512 relays at 5 > > MiB/s each needing 21 Gbps port speed. See details below. > > > > Option 1: Is it 8 Tor instances per IP, the current maximum? 2048 total Tor > > instances across 256 IPs in /24? 1/4 of the current ~8000 running relays > > (~8200 relays bandwidth measured today)? Seems too many. Example: At 256 > > IPs, 8 Tor instances per IP, average speed of 10 MiB/s per Tor relay, need > > roughly 172 Gbps, which is much less common, especially among volunteer Tor > > relays. > > > > Option 2: Is it 1 Tor instance per IP, the minimum amount per IP? When Tor > > is blocked, it's done by IP, so have 8 per IP is less efficient when 256 > > are available to spread out the relays and minimize blockage, unless the > > full /24 gets blocked? Example: At 256 IPs, 1 Tor instances per IP, average > > speed of 10 MiB/s per Tor relay, need roughly 21 Gbps, which seems much > > more reasonable using 2 x 10 Gbps links on one node with ~256 cores or > > split across 2 nodes of each having 10 Gbps and 128 cores. > > > If you use a /24 for Tor exit traffic, it is completely blacklisted anyway. Stop > doing the math ;-) > > > Option 3: Seems like the ideal would be however many can be utilized per > > available bandwidth? > > > > Here's a rough sizing table (attached and inline) of Port Speed in Gbps > > needed depending on # of available IPs, # of Tor instances per IPv4 and > > Speed per Tor (MiB/s). Legend: <= 10 Gbps is green, <= 20 Gbps is yellow, > > and > 20 Gbps is red. > > > > During the Fall of 2021, I saw ~15 MiB/s per Tor Instance and now I see > > around ~5 MiB/s per Tor Instance (no changes on my servers other than OS > > and Tor updates). > > > > Current conclusion: I'm looking at the 256, 2, 512, 5, 2560, 21 row as where > > I'll likely start. 512 is a lot of Tor instances... [image.png] > > > > ~8200 relays bandwidth measured today: > > https://consensus-health.torproject.org/graphs.html > > > > Sent with Proton Mail secure email. > > > > On Monday, February 3rd, 2025 at 8:00 AM, usetor.wtf > > usetor.wtf(a)protonmail.com wrote: > > > > Hi All, > > > > > > Looking for guidance around running high performance Tor relays on Ubuntu. > > > > > > Few questions: > > > 1) If a full IPv4 /24 Class C was available to host Tor relays, what are > > > some optimal ways to allocate bandwidth, CPU cores and RAM to maximize > > > utilization of the IPv4 /24 for Tor? > > > > > > 2) If a full 10 Gbps connection was available for Tor relays, how many CPU > > > cores, RAM and IPv4 addresses would be required to saturate the 10 Gbps > > > connection? > > > > > > 3) Same for a 20 Gbps connection, how many CPU cores, RAM and IPv4 > > > addresses are required to saturate? > > > > > > Thanks! > > > > > > Sent with Proton Mail secure email. > > > > -- > ╰_╯ Ciao Marco! > > Debian GNU/Linux > > It's free software and it gives you freedom!_______________________________________________ > tor-relays mailing list -- tor-relays(a)lists.torproject.org> To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org

2 1

Re: Adding falgs to new relays
by Marco Moock 13 Feb '25

13 Feb '25

Am Wed, 12 Feb 2025 04:46:14 +0000 schrieb ZK <zk(a)onionmail.org>: > > >Please give the Nickname for the affected relay. > > family:265E819C80A418EF3690F778B17AF4ED507AC3B1 Check your IPv6 exit policy. It rejects all. Test outgoing connections from the machine. Is there a firewall running? Check the logs for outgoing rejected packets. BadExit indicates that outgoing connections are not possible.

2 2

Re: (No Subject)
by Marco Moock 11 Feb '25

11 Feb '25

Am Mon, 10 Feb 2025 21:03:46 +0000 schrieb Azraxiel <azraxiel(a)proton.me>: > I openened Port 9001 on my router 192.168.178.1 and forwarded it to > my OpenSense 192.168.178.2 In OpenSense(10.0.0.1 Own IP) i created > the following NAT rule and same Firewall rule for the WAN Interface > TCP *AnySource *AnyPort Destination:WAN address Port:9001 IP:10.0.0.1 > Port9001 The External IP is 109.199.164.117 Double NAT is always a bad idea. Why are you doing it in general? Please also provide the IPv6 address, so we can test it too. This is the outcome of my traceroute. m@zbook:~$ sudo traceroute 109.199.164.117 -T -p 9001 traceroute to 109.199.164.117 (109.199.164.117), 30 hops max, 60 byte packets 1 10.254.254.1 (10.254.254.1) 1.787 ms 2.142 ms 2.135 ms 2 172.18.0.1 (172.18.0.1) 5.794 ms 6.896 ms 7.238 ms 3 adslgwffm.tal.de (82.139.222.46) 12.980 ms 13.633 ms * 4 xe-101-0-3-90.fix5-r1.de.syseleven.net (37.49.155.221) 13.947 ms * * 5 po1-1000.r4-fra1-de.as5405.net (45.153.82.4) 14.233 ms * * 6 * * * 7 r3-fra1-de.as5405.net (94.103.180.6) 10.937 ms * * 8 ffm-b5-link.ip.twelve99.net (62.115.148.98) 11.824 ms * * 9 ffm-bb1-link.ip.twelve99.net (62.115.114.88) 11.429 ms * * 10 mcn-b5-link.ip.twelve99.net (62.115.126.111) 18.171 ms * * 11 infrafibre-ic-373861.ip.twelve99-cust.net (213.248.97.162) 21.586 ms * * 12 * * * 13 109.199.164.117 (109.199.164.117) 25.685 ms * * 14 * * * 15 * * * It indicates that the traffic is being dropped. Change you settings to give proper ICMP error messages to make diagnosing more easy.

1 0

(No Subject)
by Azraxiel 10 Feb '25

10 Feb '25

Hello, does anybody use the Opensense Plugin for Tor? I followed every step in the Documention for setting up a Relay but it doesn't work and the opnsense community can't help either. Best regards Azra Sent from Proton Mail Android

2 1

Mass-email sent to relay operators
by Zachary 10 Feb '25

10 Feb '25

Hello my fellow relay operators, I just received an email that was sent to many relay operators' contact emails. The content is as follows: // Start message Hello to all the relays operators. My name is Zakwan Kalb. I'm investigating a possible ongoing end-to-end confirmation attack run by the Torproject. Please reply to me if you have encountered one of the following and provide as much information as possible: 1. Your relay has been removed by the Torproject. (You've seen something like that in your log files: "http status 400 ("Fingerprint and/or ed25519 identity is marked rejected ...") 2. The Torproject added flags it's not supposed to add to your relays (BadExit, MiddleOnly) 3. You have been asked by the Torproject to install unknown software, spy on users or do something else that's suspicious 4. You know something about the ongoing attack I have some evidence of the attack: the Torproject doesn't allow people to run relays by removing them from the network or making them unusable as Guard or Exit for no known reason for years. A random person cannot run a Guard or Exit relay. Thus the Tor network is entirely run by the people chosen by the Torproject by unknown criteria. More evidence and details are needed. I think we need to discuss this issue with each other, contact the media and freedom of speech organizations and let people know what's happening. // End message Looking through his mailing list history it looks like he was asking about this same thing back in 2021. Just wanted to give everyone a heads up. It doesn't seem like there's any malicious intent, maybe a bit of schizophrenia perhaps, but I've reached back out simply asking if he has any proof of anything actually going on just to appease my own curiosity. I have no further comment about this. Zachary

3 2

Adding falgs to new relays
by ZK 10 Feb '25

10 Feb '25

I'm asking the Torpoject to publicly answer the question: why do you add BadExit and MiddleOnly flags to new relays? Please don't lie as you did before and list the criteria here

3 2

Web Tunnel Bridges
by gerard＠bulger.co.uk 29 Jan '25

29 Jan '25

Web tunnel bridges Port 443, https I set up three of these. One in UK, one in Australia and one in USA. Only the USA service is attracting traffic. This might be normal. The others are very quiet. Then I look at it on Tor Relay metric it reports Running <https://metrics.torproject.org/rs.html#search/flag:running> V2Dir <https://metrics.torproject.org/rs.html#search/flag:v2dir> Valid <https://metrics.torproject.org/rs.html#search/flag:valid> Additional Flags none First Seen 2025-01-26 14:22:20 Last Restarted 2025-01-28 20:49:38 Platform Tor 0.4.8.13 on Linux Transport protocols Transport protocols supported by this bridge. webtunnel Bridge distribution mechanism Settings <https://bridges.torproject.org/info#settings> The difference between the quiet ones and the active USA server is Bridge Distribution Mechanism it says "settings" rather than HPPTS for my USA one Does this change automatically or do I need to change something? Gerry

1 0

Re: Having trouble with setting up a relay in a censored country.
by George Hartley 22 Jan '25

22 Jan '25

Hi, sorry for the late reply, I was busy working. The only thing that stands out to me immediately is that you configured two separate ControlPort authentication methods: > HashedControlPassword XX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > CookieAuthentication 1 You might want to comment out the first line. Otherwise, everything else looks correct. P.S: Since you do not run a bridge, there is no need to un-comment the obfs4 related settings: > ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy > ServerTransportListenAddr obfs4 0.0.0.0:9002 This will do nothing, unless you actually configure the relay to be a bridge. Try to comment both HashedControlPassword and the obfs4 settings, and restart the relay. nyx should now work - additionally, you might want to check the log using journalctl -u tor. There should be a line stating that your ORPort is reachable from the outside, and that your server descriptor has been published. If that is not the case, then I would conclude that your host / ISP is up to some "funny" business, and you might not be able to run a normal relay. Since I can't find any relay with your specified nickname, I assume that it is still not working. However, you could still run an obfs4 bridge, which should work fine in Russia - if you can do this, please do.. any relay or bridge not run by intelligence agencies or government helps! Regards, -GH On Wednesday, January 15th, 2025 at 3:23 PM, nyyymi <nyyymi(a)protonmail.com> wrote: > Hi, here is my torrc file. Enabling cookieauth didn't change anything >

1 0

All of my nodes have been banned
by petition_tricky750＠simplelogin.com 20 Jan '25

20 Jan '25

Hello, What are some of the most common reasons for relays and exits to be banned from Tor? Had it happen to all of my 5 nodes and I'm currently awaiting response from bad-relays list. They all present this in logs Jan 18 20:41:40 example.com Tor[2439671]: http status 400 ("Fingerprint and/or ed25519 identity is marked rejected -- 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 fingerprint(s)?") response from dirserver 204.13.164.118:80. Please correct. All of them have been running just fine before 4E1E745FF661657E3D3CE10DF1A1AEEF1D3F7996 2D9D4F0D298C68044F2476DFCB191CEBCE7AC860 078B7B30953A6DA8BB73612035BB876EA90847E3 DE3550EBB205660730900C05B6330B663CEED25434A09907FB89BE444A0A456C12A1A9C54CCF1A8A I'm genuinely curious if others also had it happen to them, and the reason behind it. Thank you.

2 2

Possible attack on servers via Tor Guard relays?
by x9p 19 Jan '25

19 Jan '25

Hi, I am running a relay and other servers. Sometimes doing SSHD over Tor via a hidden service in a VPS in openbsd.amsterdam. In all my other setups, in other providers, I do not see this problem happening. Upon connecting for the first time, I do get a "banner line contains invalid characters" error, and the connection is terminated. (MSG1) Upon connecting for the second time, everything goes smooth. (MSG2) Problem is happening on my 2 servers in openbsd.amsterdam. Any directions into debugging this problem? Both via Tor or via SSHD? Is it possible a bad guard is logging the IPs first connecting, then dropping the connection, and then allowing the connection to succeed later? Any directions would be appreciated to solve the problem. System: uname -a OpenBSD xxxx.yyyy.com 7.6 GENERIC#501 amd64 Tor version: Tor version 0.4.8.13. MSG1 (BAD): localhost:~# torify ssh -v ams02 OpenSSH_9.9p1, OpenSSL 3.3.2 3 Sep 2024 debug1: Reading configuration data /root/.ssh/config debug1: /root/.ssh/config line 284: Applying options for ams02 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 22: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: Connecting to ngbjd5vpxamy5d63hcflinghioo2qa5e75uiysscmo4ml5qd4rpaobid.onion [127.42.42.0] port 60113. debug1: Connection established. debug1: identity file /root/.ssh/oams002_2 type 0 debug1: identity file /root/.ssh/oams002_2-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.9 kex_exchange_identification: banner line contains invalid characters banner exchange: Connection to 127.42.42.0 port 60113: invalid format MSG2 (OK): localhost:~# torify ssh -v ams02 OpenSSH_9.9p1, OpenSSL 3.3.2 3 Sep 2024 debug1: Reading configuration data /root/.ssh/config localhost:~# torify ssh -v ams02 OpenSSH_9.9p1, OpenSSL 3.3.2 3 Sep 2024 debug1: Reading configuration data /root/.ssh/config debug1: /root/.ssh/config line 284: Applying options for ams02 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 22: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: Connecting to ngbjd5vpxamy5d63hcflinghioo2qa5e75uiysscmo4ml5qd4rpaobid.onion [127.42.42.0] port 60113. debug1: Connection established. debug1: identity file /root/.ssh/oams002_2 type 0 debug1: identity file /root/.ssh/oams002_2-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.9 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.9 debug1: compat_banner: match: OpenSSH_9.9 pat OpenSSH* compat 0x04000000 debug1: Authenticating to ngbjd5vpxamy5d63hcflinghioo2qa5e75uiysscmo4ml5qd4rpaobid.onion:60113 as 'xxxxxxxxxx' debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: sntrup761x25519-sha512 debug1: kex: host key algorithm: ssh-ed25519 debug1: kex: server->client cipher: chacha20-poly1305(a)openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305(a)openssh.com MAC: <implicit> compression: none --x9p

3 2

Re: Having trouble with setting up a relay in a censored country.
by Marco Moock 15 Jan '25

15 Jan '25

Am 15.01.2025 um 16:25:42 Uhr schrieb nyyymi: > > Please post your torrc (without comments). > > and the IP addresses of the machine. > Ip is 192.168.1.113. This is a private IPv4 address, unreachable from the internet by design. You need to set up port forwarding in your router to make it reachable. Did you do that? If your ISP provides IPv6, you need to create a firewall rule in your router to allow access. Because that doesn't use NAT, no port forwarding is needed. > I've let the relay run for a bit, errors started > to accumulate. "Problem bootstrapping. Stuck at 5% (conn): Connecting > to a relay. (Connection timed out; TIMEOUT; count 25.." and "25 > connections died in state connect()ing with SSL state (no SSL object)" Please test ncat -v tr.dorfdsl.de 9001 If that doesn't work, those problems must be first fixed. -- Gruß Marco Send unsolicited bulk mail to 1736954742muell(a)cartoonies.org

1 0

Re: Having trouble with setting up a relay in a censored country.
by Marco Moock 15 Jan '25

15 Jan '25

Am Wed, 15 Jan 2025 16:01:44 +0000 schrieb nyyymi <nyyymi(a)protonmail.com>: > Nickname is nyymi. It doesn't show up on the relay search That is an indicator that something isn't working. Please post your torrc (without comments). and the IP addresses of the machine.

1 0

Having trouble with setting up a relay in a censored country.
by nyyymi 15 Jan '25

15 Jan '25

Hello. For the past few days I've been trying to open a tor-relay on my old laptop running arch. The tor service starts fine but when I check nyx no traffic goes through me, both download and upload is 0. Nyx shows Unknown:portnumber. I doubt that the port is closed or somehow unavailable since arch's defaults are wide open. And for some reason my tor version (0.4.8.13) shows up as "unknown" as well. I thought the issue may lie in torproject's ban in Russia but somehow other people run relays just fine? (https://metrics.torproject.org/rs.html#search/country:ru) I've set up obsf4 as well but It didn't change anything Im quite new in all of this so bear with me. Thanks -Arttu

3 2

Question: Relay speed South Africa
by Carlo P. 15 Jan '25

15 Jan '25

Hello experts, I have, from the same provider, two VPS with same specs (also same port speed of 200MBit/s, verified via speedtest-cli) - one in Germany, one in South Africa. Whilst the German one behaves as expected (two fast relays on it), the two relays in South Africa won't really get up to speed - barely traffic, and advertised bandwidth below 2MB/s . In general, search for country:za on metrics does not really look too impressive. Do you have any idea about the reason, i.e. why, despite the VPS having the bandwidth, the relays do not get up to speed? Thanks - C. -- Sent with https://mailfence.com Secure and private email

3 2

My web-bridges looks offline in the Relay Search
by Brook Rameev 10 Jan '25

10 Jan '25

Hello! Today all my web tunnel relays become offline according to https://metrics.torproject.org/rs.html#search/BrookRameev (my web tunnel bridges have the 'W' suffix). But they are surely online (except BrookRameev7W, which is surely dead). I see traffic on them, I see no problems in logs, nothing changed in their configuration. I also checked them using tor browser. All of them "went down" at the same time: " 1 hour 17 minute and 48 seconds" from the current moment. The problem relates only to webtunnels, ordinal relays work normally. Good luck.

4 5

Tor node shutdown
by Tschador 30 Dec '24

30 Dec '24

FYI: My Tor node »TorMachine« (6A7551EEE18F78A9813096E82BF84F740D32B911) will be shut down on 2024-12-31. Sorry folks – but I'm too old for the job. Good luck and all the best wishes for the future!

3 2

Re: Strange UFW logs from another Tor node - update.
by code9n＠pm.me 30 Dec '24

30 Dec '24

On Thursday, December 26th, 2024 at 12:00, tor-relays-request(a)lists.torproject.org <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 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: What're these ufw block logs saying? (George Hartley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Dec 2024 19:55:08 +0000 > From: George Hartley hartley_george(a)proton.me > > Subject: [tor-relays] Re: What're these ufw block logs saying? > To: "tor-relays(a)lists.torproject.org" > tor-relays(a)lists.torproject.org, "code9n(a)pm.me" code9n(a)pm.me > > Message-ID: <9ct9ASpMXXnKRo6w2spT3sRh5hspGh1EqSneiQFDwbhNlI4ZZLyU8F2f3 > 3x_KowFg5e-IYk7P0soKNit50FrGm61lKh50WazDZNkCyfJ5qs=(a)proton.me> > > Content-Type: multipart/signed; protocol="application/pgp-signature"; > micalg=pgp-sha512; boundary="------b4924ec6e97f2ee894d2a6644c496d719be > 5fc5bbba1fc1072274ea1ae63bf7c"; charset=utf-8 > > Hello, > > this is weird indeed, but the packet size is interesting. > > For example, using the tool MTR, you can trace the route to another host using different protocols: > > 1.) ICMP being the obvious default. > 2.) TCP. > 3.) UDP. > > If all these TCP packets were just below 100 bytes, that would be my guess. > > Looking up the relay, there is a name, e-mail contact and PGP key ID for this node operator: > > "Tom" > tom(a)kh6ilt.org > 0x620836CF > > Just ask this operator first to check his server for something that could cause this, and if he is running something special alongside Tor. > > Then, if that does not sufficiently explain or resolve the spurious packets, I would recommend to install tcpdump, and to use a syntax like: > > > sudo tcpdump tcp and src host 155.138.146.249 and not dst port 443 -w dump.pcap > > > You will need elevated privileges in order to run tcpdump. > > This will guarantee to exclude all legitimate Tor traffic originating from his server by excluding destination port 443, and log the remaining packets to file "dump.pcap". > > You can add the -i <interface> parameter to the beginning of the tcpdump argument list if you have multiple public interfaces. > > > Like so: > > tcpdump -i eth0 <other arguments> > > > Once the dump is finished, you can send signal 2 / SIGINT if the process is running in the background, or simply press CTRL + C.. both ways lead to a graceful exit of tcpdump: > > > kill --signal 2 tcpdump > > > Now you can inspect the traffic using a GUI tool like Wireshark (highly recommended) which can parse .pcap files and decode / recognize many types of packets. > > Please report back what you find! > > All the best, > -GH > > > On Monday, December 23rd, 2024 at 6:46 PM, code9n via tor-relays tor-relays(a)lists.torproject.org wrote: > > > Hi, > > > re. my (guard / middle relay) : 181.215.226.65 : 443 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… > > > I'm getting traffic from another (non-exit) relay : 155.138.146.249 : 9001 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… ( CCed) > > > always from port 9001 but to different, high number destination (on my vps) ports which ufw is blocking. > > This isn't Tor traffic I'm blocking, right? That would only come to my ORport? Is this abuse attempts? Under the cover of Tor relay traffic? They're quite infrequent (sample) : > > > Dec 23 14:33:29 xxxxxxxx kernel: [2228957.705152] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:33:34 xxxxxxxx kernel: [2228962.788380] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:52:36 xxxxxxxx kernel: [2230104.586835] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:53:16 xxxxxxxx kernel: [2230144.487410] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 14:53:54 xxxxxxxx kernel: [2230183.086653] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:16:42 xxxxxxxx kernel: [2231550.336547] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 > > > Dec 23 15:18:15 xxxxxxxx kernel: [2231644.112246] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:22:31 xxxxxxxx kernel: [2231900.117391] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 > > > Dec 23 15:42:30 xxxxxxxx kernel: [2233098.835686] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:43:34 xxxxxxxx kernel: [2233162.852181] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Dec 23 15:45:42 xxxxxxxx kernel: [2233290.874044] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=0 RES=0x00 ACK PSH RST URGP=0 > > > Dec 23 16:14:43 xxxxxxxx kernel: [2235032.148940] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=1124 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=47586 WINDOW=1027 RES=0x00 ACK PSH URGP=0 > > > Thanks, > > > Pete > >

1 0

Re: Question about middle relays and common web usage annoyances
by Zachary 29 Dec '24

29 Dec '24

I wanted to chime in. I run an entry-middle relay in my basement connected to 300mbps fiber. It doesn’t push much traffic but it’s mine and I’m proud. The bank where I do my banking blocked our IP. After carefully explaining the situation to their IT team, they contacted their web host and had them whitelist my IP. It changed recently because I registered a new router on my ISP’s network, and they happily whitelisted that one too. My bank is a small town bank where everyone knows everyone, and I’m sure it would be much harder at some big corporate bank. Nonetheless, it’s always possible to make a change! Zachary

1 0

Question about middle relays and common web usage annoyances
by tor＠computhings.be 26 Dec '24

26 Dec '24

Hello, I'm located in Belgium. I keep two small middle relays (no exit, not even guard)… https://metrics.torproject.org/rs.html#details/89B4597169A9DBB171F0B4629C73… https://metrics.torproject.org/rs.html#details/07E3A0DC6AD4A5F07D1AF942626E… If I browse the web using a common browser using the basic services of the ISPs (no torbrowser, no tor network) and at least since may 2023, I've observed that some websites (banks, federal services,…) simply don't respond when I want to open their webpages. If I use another IP from the same locations (using vpn, ssh proxy, whatever), those same websites simply respond and works without issue. If I switch back to the local ISP IP, those are unreachable, and so on. If I contact those ISPs or the banks IT services, for them there are no problem. For me, it's clear that hosting simple middle relays puts my ISPs IPs to some black lists handled by who knows who. If hosting basic middle relays is blocking common web services, it will be hard / nearly impossible for me to encourage family, friends or customers to host a basic middle relays. Maybe there is no need for more and more middle relays, I don't know. Does someone encounter the same kind of annoyances ? regards, tierce

6 5

What're these ufw block logs saying?
by code9n＠pm.me 24 Dec '24

24 Dec '24

Hi, re. my (guard / middle relay) : 181.215.226.65 : 443 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… I'm getting traffic from another (non-exit) relay : 155.138.146.249 : 9001 : http://hctxrvjzfpvmzh2jllqhgvvkoepxb4kfzdjm6h7egcwlumggtktiftid.onion/rs.ht… ( CCed) always from port 9001 but to different, high number destination (on my vps) ports which ufw is blocking. This isn't Tor traffic I'm blocking, right? That would only come to my ORport? Is this abuse attempts? Under the cover of Tor relay traffic? They're quite infrequent (sample) : Dec 23 14:33:29 xxxxxxxx kernel: [2228957.705152] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:33:34 xxxxxxxx kernel: [2228962.788380] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=37256 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:52:36 xxxxxxxx kernel: [2230104.586835] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:53:16 xxxxxxxx kernel: [2230144.487410] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 14:53:54 xxxxxxxx kernel: [2230183.086653] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=55546 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:16:42 xxxxxxxx kernel: [2231550.336547] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 Dec 23 15:18:15 xxxxxxxx kernel: [2231644.112246] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:22:31 xxxxxxxx kernel: [2231900.117391] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=40998 WINDOW=0 RES=0x00 ACK RST URGP=0 Dec 23 15:42:30 xxxxxxxx kernel: [2233098.835686] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:43:34 xxxxxxxx kernel: [2233162.852181] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Dec 23 15:45:42 xxxxxxxx kernel: [2233290.874044] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=588 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=32822 WINDOW=0 RES=0x00 ACK PSH RST URGP=0 Dec 23 16:14:43 xxxxxxxx kernel: [2235032.148940] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:b0:d2:70:e4:5d:37:86:2c:2c:08:00 SRC=155.138.146.249 DST=181.215.226.65 LEN=1124 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=9001 DPT=47586 WINDOW=1027 RES=0x00 ACK PSH URGP=0 Thanks, Pete

2 1

An update regarding the raid in August
by Artikel 5 e.V. 24 Dec '24

24 Dec '24

Hello everyone! The holidays and the 38C3 are coming up. Unfortunately nobody from our organization will be able to attend the congress in person this year. In case that the police raid in August is going to be a topic for the relay operators meetup, we would like to provide you with a small update regarding the current state here. The legal complaint procedure is still ongoing but last week -after several delays- we were finally able to get access to the court records for the case. We are not allowed to (and will not) directly quote/publish any of this material. We can however make the following information public at this point: - This case is about an (unsuccessful) cybergrooming attempt from Q2/2024. - We have a list of IP-Adresses supposedly used by the perpetrator. - Only one of them is one of our exit nodes. - Others point to other exit nodes. - Some of these other exit nodes are also run by German organizations. - To our knowledge, none of these other organizations were visited like we were. - In contrast to what the prosecution stated as part of the complaint procedure, several pages in the case file clearly state that they knew and fully understood that the server in question was never located at the home/mail address of our organization. - This was clear even before the case was handed off to the local department responsible for our current registered address. - At least some of the people involved also fully understand Tor and the implications. - As we suspected, they also knew (and documented) upfront that this was a home address and not some sort of rented office or server farm. - In combination, it looks a lot like several involved parties did not fully read and/or understand the entire file before playing their part in the puzzle. It pretty much confirms what we already suspected. Whether all this is a simple result of repeated organizational failure, unfortunate lack of technical understanding or even malicious intent against us or the Tor network in general, is an interpretation we will leave up to you. Just be aware that if you are operating Tor exits in Germany, this could currently happen to you as well - even if you follow ALL the best-practices rules and recommendations currently out there. Maybe we just have the "luck" of being registered at the wrong city with the wrong people working on these cases. Maybe not. In any case... enjoy the holidays and (if you attend) the congress in Hamburg as well. Kind regards, Gero for Artikel 5 e.V.

1 0

Re: Question about middle relays and common web usage annoyances
by Isaac Grover, Aileron I.T. 24 Dec '24

24 Dec '24

Good morning tierce, I suspect that the sites you're unable to access are using https://www.dan.me.uk/dnsbl or another blocklist provider that naively blocks middle relays and/or entry relays instead of/in addition to exit relays. If you don't want to or can't pay for third-party hosting to move your middle relay outside your network, one solution would be to contact your ISP and move from your single IP address to a block of five IP addresses, with one IP address dedicated to your middle relay and the other IP addresses dedicated to your browsing and other traffic needs. Make your day great, Isaac Grover, President/vCIO Aileron I.T. – “ Because #ProactiveIsBetter ” O: 715-377-0440, F:715-690-1029, W: www.aileronit.com -----Original Message----- From: tor(a)computhings.be Hello, I'm located in Belgium. I keep two small middle relays (no exit, not even guard)… https://metrics.torproject.org/rs.html#details/89B4597169A9DBB171F0B4629C73… https://metrics.torproject.org/rs.html#details/07E3A0DC6AD4A5F07D1AF942626E… If I browse the web using a common browser using the basic services of the ISPs (no torbrowser, no tor network) and at least since may 2023, I've observed that some websites (banks, federal services,…) simply don't respond when I want to open their webpages. If I use another IP from the same locations (using vpn, ssh proxy, whatever), those same websites simply respond and works without issue. If I switch back to the local ISP IP, those are unreachable, and so on. If I contact those ISPs or the banks IT services, for them there are no problem. For me, it's clear that hosting simple middle relays puts my ISPs IPs to some black lists handled by who knows who. If hosting basic middle relays is blocking common web services, it will be hard / nearly impossible for me to encourage family, friends or customers to host a basic middle relays. Maybe there is no need for more and more middle relays, I don't know. Does someone encounter the same kind of annoyances ? regards, tierce ------------------------------ Subject: Digest Footer _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org ------------------------------ End of tor-relays Digest, Vol 167, Issue 13 *******************************************

1 0