- 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