- tor-relays - lists.torproject.org

QUESTION: OBFS4 on secondary IP and NAT
by C. Pe. 07 Aug '25

07 Aug '25

Dear experts, I have a special question, for which I could not find 100% clear documentation after a research. Situation: - VPS with more than one IPv4 and IPv6 address - IPv4 within the VPS is private class-A only (i.e. 10.x address), so port binding happens to the private Class-A - External IPv4 is linked outside the VPS to the private Class-A - of course, VPS is externally reachable by the external IPv4 - I would like to use a secondary IPv4, i.e. NOT the one, which is shown, when you run the command 'curl -4 icanhazip.com' from within the VPS) - I would like to use a secondary IPv6, i.e. NOT the one, which is shown, when you run the command 'curl -6 icanhazip.com' from within the VPS) Let's assume, for my example only, I have the following secondary IP addresses : - external IPv4 7.8.9.10 - internal IPv4 10.0.0.7 - IPv6 [2345:bad:face::] Let's further assume, my ORPort was 1234 and the obfs4 port was 4321 In order to have TOR distribute the correct bridge line "obfs4 7.8.9.10:4321 <...>", is the following torrc config correct? BridgeRelay 1 ORPort 7.8.9.10:1234 NoListen ORPort 10.0.0.7:1234 NoAdvertise ORPort [2345:bad:face::]:1234 Address 7.8.9.10 Address [2345:bad:face::] OutboundBindAddress 10.0.0.7 OutboundBindAddress [2345:bad:face::] ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 10.0.0.7:4321 ExtORPort auto ContactInfo johndoe(a)nowhere.org Nickname MyCoolBridge With this config, I indeed am able to connect to the bridge using the "obfs4 7.8.9.10:4321 <...>" bridge line, but is this line also communicated like that by the bridge distributor, or do I need to adapt the above config to ensure proper distribution? Thanks & regards, C. -- Sent with https://mailfence.com Secure and private email

5 8

FW: RE: Re: Re: QUESTION: OBFS4 on secondary IP and NAT
by C. Pe. 06 Aug '25

06 Aug '25

Seems I only answered to George, instead of all, sorry. ---------------------------------------- Betreff: FW: RE: Re: [tor-relays] Re: QUESTION: OBFS4 on secondary IP and NAT Von: C. Pe. <peca-relay(a)mailfence.com> An: George Hartley <hartley_george(a)proton.me> Datum: 05.08.2025, 14:41:41 I am of course not the expert here. However - NoAdvertise and NoListen are usually combined in two consecutive ORPort statements. This is done to in fact to tell Tor to "listen to ip:port A, but advertise ip:port B", so there definitely is an advertisement of the relay. A relay works fine with that and the "relay piece of a bridge" (so to say) also works well. But yes, there indeed IS some hassle with the bridge distribution (see also my other post, which still waits moderator approval). Question remains: Is that a known "shortcoming" for pluggable transports, or is there a special way needed to configure this properly? So we seem to have two issues with bridge setup, NAT and binding to specific IP: 1. Not possible to properly advertise/distribute obfs4 external IP, if obfs4 port binding to internal IP. 2. In such cases, bridge distribution does not happen. I have, based an observation from another bridge without NAT, even the impression, that specifying a specific IP instead of 0.0.0.0 or [::] in the ServerTransportListenAddr causes a bridge distribution "none". Maybe a bug? C. On August 5, 2025 at 4:46 AM, George Hartley <hartley_george(a)proton.me> wrote: Is this not the purpose of NoAdvertise? You use that flag if you want a private bridge (for example, to give to your friends). Using both NoAdvertise and NoListen on an OBFS4 bridge behind NAT can make BridgeDB treat your bridge as “no distribution.” Because NoAdvertise strips the bridge descriptor from publication, and NoListen prevents the ORPort from binding on your public interface, BridgeDB can’t see or test your bridge. As a result, it marks its distribution status as “None.” The easiest fix is to forward your ORPort through NAT and remove (or at least temporarily disable) those flags so your bridge descriptor is published and reachable. Once BridgeDB can reach and verify your ORPort, it will resume distributing your bridge normally. If you’d like more control, you can also set a specific BridgeDistribution method (for example, moat) in your torrc. Regards George On Tuesday, August 5th, 2025 at 3:46 AM, Gary C. New via tor-relays <tor-relays(a)lists.torproject.org> wrote: I'm seeing a similar issue with a recently configured OBFS4 bridge using NAT, NoAdvertise, NoListen, and distribution status displaying as "None." On Sunday, August 3, 2025 at 12:36:37 PM MDT, C. Pe. via tor-relays <tor-relays(a)lists.torproject.org> wrote: Is there maybe another issue with rdsys being "stuck" ? I have again a new/renewed bridge in distribution status "None" since some days and https://bridges.torproject.org/status?id=<fingerprint> shows for all bridges the last testing two days ago (According to your below statement, updates should appear latest after 4h) Thanks & regards, C. Am 31.07.2025 um 13:12, meskio via tor-relays <tor-relays(a)lists.torproject.org> schrieb: You can always check if the bridgeline distributed by rdsys is correct by visiting: https://bridges.torproject.org/status?id=<your hashed or not fingerprint> This should display one bullet point per IP/transport, so in your case two, one for IPv6 and another for IPv4. Take into account that it might take up to 4h for this page to be updated when you do changes. -- Sent with https://mailfence.com Secure and private email _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email -- Sent with https://mailfence.com Secure and private email

2 1

Tor People @ WHY2025
by Alexander Hansen Færøy 01 Aug '25

01 Aug '25

Hey Relay Operators, I'll be at the upcoming WHY2025 hacker camp in the Netherlands. WHY2025 is an excellent opportunity to do a Relay Operator meetup at some point during the camp days. Who else from here is going? At the latest CCCamp, we did a meetup at the BornHack village, but we did receive some negative feedback on the noise level in that general area, so I was thinking of investigating if there is a quieter place with some good seating where we could host the meetup this time, and announce the time and location here on the list. Suggestions of locations are most welcome. I recently received a link from tornth on #tor-relays on IRC/Matrix to https://wiki.why2025.org/Project:Tor_Relays, where it's relatively easy to add "Tor Relays" as a project from your WHY2025 wiki account. Cheers, Alex -- Alexander Hansen Færøy

1 0

Usefulness of independent Snowflake network?
by Jonah Aragon 27 Jul '25

27 Jul '25

Hi all, I’ve spent some time setting up a standalone Snowflake network this week, mainly for my own practice. Basically what I have is: - A Snowflake broker working with domain fronting on a CDN other than CDN77, and of course Amp Cache. - Two Snowflake bridges, https://metrics.torproject.org/rs.html#search/Triplebit%20transport:snowfla… - A handful of proxies with high-speed/no-NAT connections configured to use this network instead of the default. And everything works perfectly in stable Tor Browser. I was mostly curious about what the performance would look like, and of course it is better since I’m the only one using it :) I was thinking that a potential use could be to have a Snowflake network that has no browser extension proxies or proxies behind NAT, only standalone daemons on high-performance networks from operators willing to contribute. My theory is that there are some people who would benefit from a Snowflake bridge with performance more in line with obfs4 or WebTunnel, which may or may not really be true. What I’m wondering is, do you think this is a concept worth pursuing, or do I just leave it as a weekend experiment? Obviously a big advantage is lost by having fewer proxies compared to the current Snowflake network, which would make it easier to enumerate. I think a big advantage gained as a bridge operator is being able to publish the bridge line publicly and take advantage of domain fronting without actually proxying Tor traffic through a CDN. I can change the IPs of my bridges by swapping out proxies, without bridge users needing to update their bridges in their client, which seems like a win. What I don’t know: - Could this actually provide the same or greater value than just contributing more standalone Snowflake proxies to the public network? - Is this worthwhile compared to simply running WebTunnel bridges? - Is there one other relay association perhaps willing to volunteer to run a bridge on this network, and are there other relay associations or individuals willing and able to contribute only high-performing and standalone proxies to it? Let me know what you think! Best, Jonah

1 0

Re: webtunnel bridges for the telegram distributor
by George Hartley 24 Jul '25

24 Jul '25

Thanks, I agree that obfs4 looks like "random data" so it is relatively easy to block with middle-boxes or deep packet inspection. George On Monday, July 21st, 2025 at 1:19 PM, meskio <meskio(a)torproject.org> wrote: > Quoting George Hartley (2025-07-18 05:32:28) > > > > Russia is extending their Tor block[0]. Currently, they block Fully > > > Encrypted >Protocols like obfs4 on some mobile networks[1]. > > > > Does this also apply to obfs4 bridges with timing and packet-size obfuscation > > enabled on both client and server side (iat-mode=2)? > > > Yes, is not that they are detecting obfs4 as a protocol, but they block anything > that looks like random and they can't recognize. > > > -- > meskio | https://meskio.net/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > My contact info: https://meskio.net/crypto.txt > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Nos vamos a Croatan.

1 0

facing out the moat bridge distributor
by meskio 23 Jul '25

23 Jul '25

tl;rd: if you have a bridge configured with "BridgeDistribution moat" remove this config option from torrc so it can be reassigned to another distributor or replace "moat" by "settings". In December we shutted down bridgedb[0] and stopped distributing "moat" bridges. The distributor that the Tor Browser uses automatically "settings"[1]. We hold the existing moat bridges without being distributed as they were still used by people around the world. So censors can't find them and users can still use them without getting blocked. As the usage of those bridges has declined now we decided to redistribute those bridges and automatically assign them either to the "settings" or "telegram"[2]. The only bridges that are not automatically reassigned are the ones with a configuration "BridgeDistribution moat". rdsys will not assign to any distributor bridges that have "BridgeDistribution" assigned to an unexisting distributor. If you run such bridge please remove the BridgeDistribution config line in torrc or change it an existing distributor so your bridge get distributed. If you want to hold your bridge undistributed is better to configure it with "BridgeDistribution none". Thank you. [0] https://blog.torproject.org/making-connections-from-bridgedb-to-rdsys/ [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/dis… [2] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/233 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

webtunnel bridges for the telegram distributor
by meskio 21 Jul '25

21 Jul '25

Hello, Russia is extending their Tor block[0]. Currently, they block Fully Encrypted Protocols like obfs4 on some mobile networks[1]. For a while, WebTunnel has been a good alternative, but since June, Roskomnadzor has enumerated some WebTunnel bridges and blocked them by domain name[2]. Bridge operators can bypass this block by creating a new subdomain or using a new domain for their WebTunnel bridge. We are working on multiple solutions for this problem. And one of them is to start distributing WebTunnel bridges over Telegram[3]. In the past, our Telegram distribution bot has proved to be fairly resistant to the attempts to enumerate bridges made by the Russian censor. But to be able to do that, we first need to have enough bridges assigned to that distributor. We are looking for a minimum of 30 bridges assigned to this distributor. If you are in the capacity to host a WebTunnel bridge, please do so! You can follow the documentation on the Community portal[4] and configure your WebTunnel bridge with this option in your torrc: BridgeDistribution telegram Or if you're using our Docker container, you will need to add the lines below to your .env file: OBFS4_ENABLE_ADDITIONAL_VARIABLES=1 OBFS4V_BridgeDistribution=telegram It is ok if your WebTunnel bridge is on the same IP address of another existing WebTunnel bridge as long as is in a different subdomain name, for example www1.example.com. As the censor is blocking the bridges by domain name and not by IP. Please avoid hosting your bridge with Hetzner, Digital Ocean, OVH and do not use Cloudflare DNS, as there are reports of these are being targeted and blocked by DPI[5]. Thank you. [0]https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/i… [1]https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/i… [2]https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/i… [3]https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/158 [4]https://community.torproject.org/relay/setup/webtunnel/ [5]https://github.com/net4people/bbs/issues/490 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

5 6

new OBFS4 bridges with bridge distribution method "None" since a couple of days
by C. Pe. 15 Jul '25

15 Jul '25

Dear experts, according to the documentation, a new obfs4 bridge should get a bridge distribution method assigned after running a day. The two bridges listed below are running since more than a week and both still show "none" as bridge distribution method. (Probably due to that, they even don't get up to speed) Attempting to manually set the method in torrc does not change the situation... https://metrics.torproject.org/rs.html#details/76ADDDFD1C70D60BE6F524B111A3… https://metrics.torproject.org/rs.html#details/4FB2FA7B6678169B609B771F240B… Thanks in advance for any advice. C. -- Sent with https://mailfence.com Secure and private email

2 1

authority bandwidth measurements and latency
by Marco Moock 08 Jul '25

08 Jul '25

Hello! I operate 94DEAD24492D6D01E3DE614E8BE6B4035329A4D7 and I've seen various changes in the measured bandwidth in atlas. At the beginning, more than 10 MB/s were measured, now below 3. The machine itself didn't change, I can reach high up- and download rates if I transfer stuff via HTTP/FTP etc. I see that latency isn't that low (50ms https://atlas.ripe.net/measurements/116107380/results) and want to ask if that might be part of this situation. I dunno about the TCP settings of the authority bandwidth testing machines. Can anybody give some hints what's going on? -- Gruß Marco Send unsolicited bulk mail to 1751988041muell(a)stinkedores.dorfdsl.de

1 0

Add CGNAT 100.64.0.0/10 to Default Exit Relay Reject Policy
by admin＠likogan.dev 07 Jul '25

07 Jul '25

Hello, I've noticed that the non-publicly routable CGNAT subnet of 100.64.0.0/10 is not in the default exit policy reject list like 192.168/16 and 10/8 are. This range is not publicly routed, and should never need to be accessed from a Tor exit. Tailscale and other ISPs use this block. How many exit relays connected to a Tailscale network are unknowingly exposing all of their other Tailscale devices to the Tor network? ISPs may be less willing to allow exit relays if there are bots using Tor to toy with the ISPs 100.64/10 range. Maybe there is something I am missing for it to not be included? Thanks, Likogan.Dev

1 0

Tor relays on Android / Termux / Orbot
by ajxtaylor＠gmail.com 26 Jun '25

26 Jun '25

I'm trying to run a relay on my old Pixel 5 phone. Does anyone have recommendations or experience with this? It looks like Orbot won't be able to support running relays well since upstream support for it was removed: https://github.com/guardianproject/orbot-android/issues/1319#issuecomment-2… I tried Orbot anyway, and noticed my advertised bandwidth seems to come out to around only 2 MiB/s. I don't know what the limiting factor is: * I have power and ethernet plugged into it and it has nearly 1000 Mbps connection (as tested by my router's speed test, and I have a fiber internet connection). * In developer options I can see I'm using 4.8 / 7.8 GB RAM. * Not sure how to check CPU usage. The phone always feels cold though, so I doubt its using much CPU. * I know Android used to be limited to 1024 connectors / file descriptors, but I believe Pixel 3XL and above have that limit changed to 32768. * Max bandwidth / relay bandwidth are set to 40 MBytes (per second) in the custom torrc setting I'm trying out tor in Termux as an alternative. My one issue with Termux so far is it can't detect its own IPv6 address. The logs show it detects some other IPv6 address that doesn't show up as being assigned to my phone according to my router, and Tor logs say the ORPort isn't reachable on that address. I tried manually adding my phone's IPv6 address (according to my router) into the torrc ORPort config, and that worked, but might stop working once the IP rotates. (And side note, Orbot was able to detect the IPv6 address correctly.) I'm guessing Tor can't auto-detect it because of limitations of Termux. Network config isn't available within Termux unless the phone is rooted, as can be seen by attempting to run `ifconfig` and according to this reddit thread: https://www.reddit.com/r/termux/comments/1arucf7/ipv6_trouble/

1 0

New Tool: Tor Relay Leaderboards, Operator Metrics, & Network Health
by Tor at 1AEO 25 Jun '25

25 Jun '25

Hi All, Wanted to share an update on a new Tor metrics site we've launched: https://1aeo.com/metrics (updates every 30 min!) It builds on Allium (originally from git.jordan.im/allium, now end-of-life) and adds several new features—all powered by Tor Onionoo API (and more soon!) and open source for anyone to use, self-host, or build on. New Features - screenshots and some plain text Tor relay email list friendly versions below: - Operator Leaderboard (by AROI): See the top contributors across bandwidth, consensus weight, relay count, uptime, OS diversity, and geographic spread. Celebrating everybody's contributions! - Enhanced Operator Pages (by AROI): Quickly spot issues and compare operator setups across the Tor network. - Network Health Overview: Across all of Tor, show breakdowns of relay counts, bandwidth, uptime, operator diversity, AS and geo distribution, version compliance, and more. Goals: - Provide operators with new visibility into their relays and network-wide trends - Easily answer common questions without referring back to specifications and many page long text files - Push the boundaries of what “vibe” coding can do We’d love your feedback—especially through GitHub issues for tracking requests, bugs, or incorrect data: https://github.com/1aeo/allium/issues What’s Next: - Add support for consensus health parsing and other Onionoo endpoints (e.g. bandwidth stats) - Incorporate charts/graphs - Improve historical data tracking Hope it’s helpful, and open to suggestions from the community! Credits: Beyond Jordan's great open source work on Allium, many of the top operators have been reviewing and sharing feedback, AROI definition from Nusenu, Onionoo data, and many others! Top 5 Operators by Bandwidth (AROI) Rank Operator Relays Bandwidth Consensus Weight Guard/Mid/Exit Count Countries Platforms ----- -------------------------- ------- --------- ----------------- -------------------- --------- --------- 1 nothingtohide.nl 294 60.4 Gbit/s 6.61% 34 / 8 / 252 1 294 non‑Linux 2 quetzalcoatl‑relays.org 574 57.3 Gbit/s 3.80% 0 / 0 / 574 10 1 3 1aeo.com 566 53.3 Gbit/s 3.44% 293 / 273 / 0 2 1 4 prsv.ch 349 52.5 Gbit/s 4.26% 217 / 57 / 75 20 2 5 artikel10.org 128 30.2 Gbit/s 3.47% 0 / 0 / 128 1 1 Network Heavyweight Rankings Rank Operator Relays Net. Wt. Bandwidth G/M/E Countries---- ------------------------- ------ -------- ------------- --------- ---------- 1 nothingtohide.nl 294 6.55% 60.0 Gbit/s 34/8/252 1 2 prsv.ch 353 4.38% 51.3 Gbit/s 214/52/87 19 3 quetzalcoatl-relays.org 574 4.00% 58.1 Gbit/s 0/0/574 10 4 artikel10.org 128 3.47% 30.3 Gbit/s 0/0/128 1 5 1aeo.com 614 3.27% 54.2 Gbit/s 308/306/0 2 6 tor.r0cket.net 144 2.54% 28.2 Gbit/s 0/24/120 1 7 shadowbrokers.eu 32 2.25% 16.4 Gbit/s 3/0/29 3 8 applied-privacy.net 104 2.14% 21.3 Gbit/s 0/0/104 1 9 for-privacy.net 86 1.83% 20.1 Gbit/s 43/0/43 2 10 relayon.org 112 1.27% 17.5 Gbit/s 41/7/64 2 Exit Authorities Rank Operator Exits Exit % Tot. Auth. Exit BW Countries---- ------------------------- ------ ------- ----------- ------------ ---------- 1 nothingtohide.nl 252 14.44% 6.55% 51.1 Gbit/s 1 2 quetzalcoatl-relays.org 574 10.52% 4.00% 58.1 Gbit/s 10 3 artikel10.org 128 9.13% 3.47% 30.3 Gbit/s 1 4 tor.r0cket.net 120 6.69% 2.54% 26.9 Gbit/s 1 5 shadowbrokers.eu 29 5.71% 2.25% 15.7 Gbit/s 3 6 applied-privacy.net 104 5.64% 2.14% 21.3 Gbit/s 1 7 digitalcourage.de 30 2.95% 1.12% 9.2 Gbit/s 1 8 nos-oignons.net 54 2.78% 1.06% 11.3 Gbit/s 1 9 for-privacy.net 43 2.64% 1.83% 10.8 Gbit/s 2 10 prsv.ch 87 2.07% 4.38% 10.4 Gbit/s 19 Diversity Masters Rank Operator Relays Score Bandwidth Countries Platforms Unique AS---- ------------------------- ------ ------ ------------- ---------- ---------- ---------- 1 tor(a)zgato.ru 81 92.5 6.6 Gbit/s 26 1 39 2 prsv.ch 353 61.0 51.3 Gbit/s 19 2 20 3 Safe-mail 33 51.5 4.2 Gbit/s 16 1 18 4 your@e-mail 22 48.5 1.4 Gbit/s 13 1 21 5 nobody(a)tor.org 23 35.5 1.6 Gbit/s 8 1 18 6 a-n-o-n-y-m-e.net 17 35.5 1.9 Gbit/s 11 1 12 7 peca-relay 20 32.0 1.8 Gbit/s 10 2 9 8 freiraum 14 31.5 769.2 Mbit/s 10 1 10 9 FlashTor 11 31.0 289.5 Mbit/s 9 2 10 10 quetzalcoatl-relays.org 574 30.5 58.1 Gbit/s 10 1 9 Frontier Pioneers (Rare Countries) Rank Operator Rare Bandwidth Countries Specialization---- ------------------------- ----- ------------- ---------- ------------------------------- 1 freiraum 6 769.2 Mbit/s 6 AE, IN... 2 olokerunningtor 5 131.3 Mbit/s 5 AO, KE... 3 tor(a)zgato.ru 5 6.6 Gbit/s 4 EU, GE... 4 cembranutboys.com 3 211.5 Mbit/s 3 BZ, CW, TT 5 prsv.ch 8 51.3 Gbit/s 2 AM, TR 6 osservatorionessuno.org 2 1.2 Gbit/s 2 PT, TR 7 janfuger 2 193.4 Mbit/s 2 MK, TR 8 privacyhaven(a)duck.com 2 345.9 Mbit/s 2 IN, TR 9 email(a)airmail.cc 1 476.3 Mbit/s 1 AM 10 Safe-mail 1 4.2 Gbit/s 1 TR Network Veterans Rank Operator Relays Score Bandwidth Countries Platforms Specialization---- ------------------------------ ------ ------ ------------- ---------- ---------- --------------------- 1 tor(a)insc.de 1 6450 1.7 Mbit/s 1 1 6450 days * 1.0 2 tor-trouble 1 6105 198.7 Mbit/s 1 1 6105 days * 1.0 3 dennis 1 5469 66.8 Mbit/s 1 1 5469 days * 1.0 4 A1F1E776E110F29C 2 4884 51.4 Mbit/s 1 1 4884 days * 1.0 5 Jon Gjengset 1 4489 8.9 Mbit/s 1 1 4489 days * 1.0 6 Ranlvor 1 4248 44.2 Mbit/s 1 1 4248 days * 1.0 7 aholiday(a)yahoo.com 1 4096 931.8 Kbit/s 1 1 4096 days * 1.0 8 insomnia@orwell1984 1 4095 4.4 Mbit/s 1 1 4095 days * 1.0 9 tor(a)theyosh.nl 1 4082 79.7 Mbit/s 1 1 4082 days * 1.0 10 Ry4an Brase 1 4037 8.4 Mbit/s 1 1 4037 days * 1.0 On Monday, May 26th, 2025 at 11:44 PM, Tor at 1AEO via tor-relays <tor-relays(a)lists.torproject.org> wrote: > Couldn't find an updated single reference of Tor relay trackers. > Summarized up the main active trackers, as each varies slightly in data and presentation. > Please take a look and let me know if anything’s missing or needs updating. > > Tracker List: Table pasted below; screenshot attached > Also viewable on our blog (with working links): > https://1aeo.com/blog/navigating-tor-relay-trackers-measure-compare.html > > Our favorite: Allium – super easy to deploy, offers ASN and family-level summaries, and update interval is configurable (ours refreshes every 30 min): > https://1aeo.com/metrics/ > Source: https://git.jordan.im/allium/ > > Thanks for your input, and happy operating! > > > > Name > > Live May '25 > > Bandwidth > > Aggregate By Family or AS > > Top 10 > > Charts & Graphs > > Map/Geo Features > > Update Frequency > > Search & Filter > > Relay Details > > Historical Data > > Source Code > > Source Last Updated > > Tor Relay Search > > Yes > > Yes > > Yes > > Yes > > Yes > > No > > Continuously > > Nickname, Fingerprint, ASN, and more > > Bandwidth stats; Configuration; Uptime; Flags; Exit policy > > Bandwidth stats > > Partial > > 12/20 > > OrNetStats > > Yes > > Yes > > Yes > > Yes > > Yes > > No > > Monthly > > Operator > > Bandwidth, Configuration; Uptime; Flags; Exit policy > > Guard/Exit probability trends > > Partial > > 05/25 > > 0x7c0 Relay Metrics > > Yes > > Yes > > Yes > > Yes > > No > > No > > Hourly > > ASN; Families > > Bandwidth, Configuration; Uptime; Flags; Exit policy > > No > > Yes > > 06/24 > > Onionite > > Yes > > Yes > > No > > Yes > > No > > No > > On-demand > > Relays/Bridges search > > Bandwidth; Configuration; Uptime; Flags; Exit policy > > Bandwidth > > Yes > > 02/23 > > TorStatus > > Yes > > Yes > > No > > Yes > > No > > No > > ~15-minute > > Country; Flags; Contact > > Bandwidth, Configuration; Uptime; Flags; Exit policy > > No > > Yes > > 02/25 > > TorMap > > No > > — > > — > > — > > — > > — > > — > > — > > — > > — > > Yes > > 05/25 > > >

1 0

Request to redact reverse DNS (host name) for my relay
by Tor ITA Relay 25 Jun '25

25 Jun '25

Hello Tor Team, I am running a Tor relay and have noticed that the reverse DNS (host name) of my IP address is publicly shown on metrics.torproject.org. For privacy reasons, I would like to kindly request that the host name be redacted. Relay fingerprint: B8D94C8036FEE5253E32CA3158E916466191C407 Thank you very much for your time and support. Best regards, Gianluca

3 2

Some learning points and conclusions for our AMA
by Nothing to hide 21 Jun '25

21 Jun '25

Hi fellow operators, The first Ask Me Anything by Tor operators was held on 13-06-2025. The result can be viewed here: https://www.reddit.com/r/TOR/comments/1la9zgw/tor_operators_ask_me_anything/. We also made a quick evaluation for learning and improving the format going forward. This (and other AMA stuff) can be viewed here: https://codeberg.org/nothingtohide/TorAma/src/branch/main/250613-AMA-1/eval…. If you have any questions or suggestions, feel free to reach out. Have a great day, Nothing to hide

1 0

Attempting to create a relay with Orbot
by blueapple128 21 Jun '25

21 Jun '25

Hi, I am trying to use Orbot's "Enable your device to be a non-exit relay" option, but (after waiting enough hours) the relay's nickname fails to show up in Tor Metrics' Relay Search. How can I begin to debug this?

2 2

Tor Operators Ask Me Anything - 13-06-2025
by Nothing to hide 13 Jun '25

13 Jun '25

Hi Tor operators, We already briefly mentioned an upcoming Ask Me Anything (AMA) by Tor operators during the Tor Operator Meetup on the 10th of May. And now it's time for the announcement: https://www.reddit.com/r/TOR/comments/1krv4rt/tor_operators_ask_me_anything…. During this AMA, anyone can engage with us directly and ask us anything they're curious about. The following Tor operators are participating: R0cket, Nothing to hide, Artikel10 and CCC Stuttgart. The Ask Me Anything will be held on Friday 13 June 2025 between 08:00-23:00 UTC on /r/TOR. Feel free to ask your questions the 13th or to share this AMA with people or your communities. We also have a post on Mastodon to share: https://mastodon.social/@tor_ama/114545560947637613. We're experimenting with this format to see whether it benefits the community. Our goal is to provide answers and context about Tor, dispel myths and inspire more people to become Tor operators--or encourage current operators to expand their efforts, perhaps by scaling up or running exit relays. This initial AMA will help us learn from our mistakes and if successful, establish a regular series where other operators (of all shapes and sizes) can participate. We're looking forward to the 13th of June! And if anyone has questions about the AMA, feel free to ask them or send people our way :). Have a great day, Nothing to hide

1 1

upcoming CIISS update
by nusenu 11 Jun '25

11 Jun '25

Hi, I'm working on a new contactinfo information sharing specification version. Current version (2): https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/ Some likely changes will be: * add happy family proof https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/407/diffs * add signal username field https://support.signal.org/hc/en-us/articles/6712070553754-Phone-Number-Pri… * maybe add keyoxide field as suggested by boldsuck: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/iss… Feel free to send me your suggestions and opinions before 2025-06-30 by creating github issues or by replying to this thread. kind regards, nusenu -- https://nusenu.github.io

1 0

Observing Moria1’s Higher Missing-Relay Measured Rate (May 24–30 2025)
by Tor at 1AEO 04 Jun '25

04 Jun '25

Been exploring how each directory authority measures relays and noticed that, over the week of May 24–30, Moria1 consistently reports significantly fewer relays measured than its peers—about 6% missing versus ~3.5% for most other authorities (over 2 σ below the mean). Quick stats (May 24–30): - Moria1: Weekly missing avg = 556 relays, Z-score = 2.44 - All authorities: Mean missing = 314 relays, σ = 99 Attached the full spreadsheet, some tables, and charts below. Has anyone else spotted this pattern or have ideas why Moria1’s “number of relays voted about” is lower? Any insights or pointers would be greatly appreciated! Sharing on tor-relay list as the ticket that caught my attention doesn't allow me to comment as I'm not part of the "project": https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/90 Source: Used "Number of relays voted about" section of Consensus Health pages. Ex: https://consensus-health.torproject.org/consensus-health-2025-05-24-03-00.h… Attached xlsx with all the same data shared below. "Number of Relays Voted About" for May 24th to 30th 2025 Authority Weekly Missing Average Z-score moria1 556 2.44 longclaw 231 0.84 dizum 233 0.82 faravahar 263 0.51 tor26 363 0.49 maatuska 287 0.27 gabelmoo 292 0.23 bastet 296 0.18 dannenberg 308 0.07 Average 314 Standard Deviation 99 Authority 05-30-25 05-29-25 05-28-25 05-27-25 05-26-25 05-25-25 05-24-25 Average moria1 93.31% 93.90% 94.10% 93.86% 93.86% 94.09% 92.81% 93.71% tor26 95.05% 97.39% 96.28% 95.95% 95.95% 95.94% 94.56% 95.87% dizum 96.46% 97.78% 97.92% 97.83% 97.83% 97.84% 96.10% 97.40% gabelmoo 96.55% 96.92% 97.16% 96.83% 96.83% 96.81% 95.55% 96.66% dannenberg 95.60% 96.84% 97.19% 96.85% 96.85% 96.90% 95.73% 96.57% maatuska 96.17% 96.73% 97.37% 96.97% 96.97% 97.05% 95.73% 96.71% longclaw 97.12% 97.52% 97.74% 97.59% 97.59% 97.61% 96.36% 97.36% bastet 96.35% 96.83% 97.13% 96.83% 96.83% 96.80% 95.49% 96.61% faravahar 96.76% 97.26% 97.56% 97.10% 97.10% 97.27% 95.92% 96.99% Average 95.93% 96.80% 96.94% 96.64% 96.64% 96.70% 95.36% 96.43% 05-30-25 Total Running Missing 05-29-25 Total Running Missing 05-28-25 Total Running Missing 05-27-25 Total Running Missing 05-26-25 Total Running Missing 05-25-25 Total Running Missing 05-24-25 Total Running Missing moria1 9046 8441 605 moria1 8751 8217 534 moria1 8803 8284 519 moria1 8794 8254 540 moria1 8794 8254 540 moria1 8753 8236 517 moria1 8836 8201 635 tor26 9003 8557 446 tor26 8740 8512 228 tor26 8719 8395 324 tor26 8709 8356 353 tor26 8709 8356 353 tor26 8739 8384 355 tor26 8818 8338 480 dizum 9193 8868 325 dizum 8915 8717 198 dizum 8900 8715 185 dizum 8891 8698 193 dizum 8891 8698 193 dizum 8857 8666 191 dizum 8932 8584 348 gabelmoo 8951 8642 309 gabelmoo 8678 8411 267 gabelmoo 8718 8470 248 gabelmoo 8708 8432 276 gabelmoo 8708 8432 276 gabelmoo 8664 8388 276 gabelmoo 8743 8354 389 dannenberg 9191 8787 404 dannenberg 8916 8634 282 dannenberg 8902 8652 250 dannenberg 8893 8613 280 dannenberg 8893 8613 280 dannenberg 8858 8583 275 dannenberg 8939 8557 382 maatuska 8951 8608 343 maatuska 8678 8394 284 maatuska 8713 8484 229 maatuska 8705 8441 264 maatuska 8705 8441 264 maatuska 8655 8400 255 maatuska 8738 8365 373 longclaw 8951 8693 258 longclaw 8679 8464 215 longclaw 8718 8521 197 longclaw 8707 8497 210 longclaw 8707 8497 210 longclaw 8662 8455 207 longclaw 8743 8425 318 bastet 8950 8623 327 bastet 8675 8400 275 bastet 8718 8468 250 bastet 8707 8431 276 bastet 8707 8431 276 bastet 8661 8384 277 bastet 8743 8349 394 faravahar 8970 8679 291 faravahar 8748 8508 240 faravahar 8731 8518 213 faravahar 8721 8468 253 faravahar 8721 8468 253 faravahar 8678 8441 237 faravahar 8755 8398 357 consensus 8664 consensus 8446 consensus 8508 consensus 8465 consensus 8465 consensus 8428 consensus 8389 [image.png] [image.png]

2 1

Navigating Top Relay Trackers: Measure and Compare Tor Nodes
by Tor at 1AEO 27 May '25

27 May '25

Couldn't find an updated single reference of Tor relay trackers. Summarized up the main active trackers, as each varies slightly in data and presentation. Please take a look and let me know if anything’s missing or needs updating. Tracker List: Table pasted below; screenshot attached Also viewable on our blog (with working links): https://1aeo.com/blog/navigating-tor-relay-trackers-measure-compare.html Our favorite: Allium – super easy to deploy, offers ASN and family-level summaries, and update interval is configurable (ours refreshes every 30 min): https://1aeo.com/metrics/ Source: https://git.jordan.im/allium/ Thanks for your input, and happy operating! Name Live May '25 Bandwidth Aggregate By Family or AS Top 10 Charts & Graphs Map/Geo Features Update Frequency Search & Filter Relay Details Historical Data Source Code Source Last Updated [Tor Relay Search](https://metrics.torproject.org/rs.html) Yes Yes Yes Yes Yes No Continuously Nickname, Fingerprint, ASN, and more Bandwidth stats; Configuration; Uptime; Flags; Exit policy Bandwidth stats [Partial](https://github.com/torproject/metrics-web) 12/20 [OrNetStats](https://nusenu.github.io/OrNetStats/) Yes Yes Yes Yes Yes No Monthly Operator Bandwidth, Configuration; Uptime; Flags; Exit policy Guard/Exit probability trends [Partial](https://github.com/nusenu/OrNetStats) 05/25 [0x7c0 Relay Metrics](https://relays.0x7c0.com/) Yes Yes Yes Yes No No Hourly ASN; Families Bandwidth, Configuration; Uptime; Flags; Exit policy No [Yes](https://git.jordan.im/allium) 06/24 [Onionite](https://onionite.net/) Yes Yes No Yes No No On-demand Relays/Bridges search Bandwidth; Configuration; Uptime; Flags; Exit policy Bandwidth [Yes](https://github.com/lukechilds/onionite) 02/23 [TorStatus](https://torstatus.rueckgr.at/) Yes Yes No Yes No No ~15-minute Country; Flags; Contact Bandwidth, Configuration; Uptime; Flags; Exit policy No [Yes](https://github.com/paulchen/torstatus) 02/25 [TorMap](https://tormap.org/) No — — — — — — — — — [Yes](https://github.com/TorMap/tormap) 05/25 [image.png]

1 0

Tor Relay Deployment Dilemma: When to Not Pay for Underutilized Server Resources?
by Tor at 1AEO 23 May '25

23 May '25

Part 3 - Looking for feedback on our Tor relay configuration decision: Looking for guidance on optimizing server / bandwidth spending for Tor guard / middle relays across datacenters. Our current setup: - All same cost: Three servers in different datacenters, each with 10 Gbps unmetered bandwidth. - Identical hardware/software: Each server has 128 threads, 512GB–768GB RAM, and the same software stack. - Diversity benefits: Each server hosts fewer than 10 other relays, enhancing overall network diversity. - Primary differences: Geographic location and upstream peering/routing. Current Utilization: - Server 1: 2Gbps utilized (20% utilization) - Server 2: 6Gbps utilized (60% utilization) - Server 3: 8Gbps utilized (80% utilization) Overall, using 16 Gbps out of 30 Gbps purchased -- roughly half our bandwidth is idle / "wasted". Assuming we can't significantly optimize these servers any further and given the significant under utilization on Server 1 (80% idle) and Server 2 (40% idle), what would you do in this scenario? Some options we’re considering: - Consolidation: Paying only for the servers with the highest utilization. - Repurposing: Allocating the idle bandwidth to another purpose that benefits Tor (or a similar effort). - Reinvestment: Using the funds from Servers 1 and 2 to acquire additional high-utilization capacity (e.g., more of Server 3 configuration) to boost our overall contribution closer to 24 Gbps. - Other strategies: Any alternative approaches you might suggest. Appreciate any thoughts or best practices to help reduce wasted expenditure while maximizing the utility of our available resources. Thanks for your insights!

3 8

Seeking Advice on Running a Tor Exit Node in India
by RUSTEDUSTED 20 May '25

20 May '25

Dear Tor Operators, I hope this message finds you well. I am planning to set up a Tor exit node and would like to seek your valuable advice and guidance before proceeding. Specifically, I want to understand the following: - What are the essential technical and operational considerations I should be aware of before running an exit node? - Are there best practices or configurations you recommend to ensure the node runs securely and efficiently? - What kind of bandwidth allocation is ideal? I am considering allocating around 30-40 Mbps on my internet connection—would this be sufficient or optimal? - Could you please share insights on the legal responsibilities and potential risks involved with operating a Tor exit node in India? - Are there any specific resources, communities, or contacts you recommend I engage with for ongoing support? - (most importantly) what hardware accelerations should my device support?? is it fine if i run it on raspberry pi 5 or would it need a modern x86 CPU? I appreciate any advice or resources you can share. I am eager to contribute responsibly and effectively to the Tor network. Thank you very much for your time and help. Best regards, Pradnyesh Email: rustedusted(a)proton.me Location: Pune, India

3 2

Next Tor Relay Operator Meetup - Saturday, May 10th @ 1800 UTC
by gus 11 May '25

11 May '25

Hi! The next online relay operator meetup is happening on Saturday, May 10th, 2025 at 1800 UTC[1]. ## Agenda - Announcements - Happy Family and updates from Network Team - Tor @ Universities - Next Tor in-person events: WHY, Bornhack, DEF Con - Next Tor Relay Operator meeting Feel free to suggest and add other topics for the meetup on this issue here: https://gitlab.torproject.org/tpo/community/relays/-/issues/114 ## How to join Meetup details: - Room link: https://tor.meet.coop/gus-og0-x74-dzn - Date & Time: Saturday, May 10th, 2025 @ 18.00 UTC - Duration: 60 to 90 minutes - Tor Code of Conduct: https://community.torproject.org/policies/code_of_conduct/ - Registration: No need for a registration or anything else, just use the room link above. The room will open 10 minutes before the meetup starts. Gus [1] If you're confused about UTC and your timezone, anarcat maintains a cool project called undertime - https://gitlab.com/anarcat/undertime -- The Tor Project Community Team Lead

1 1

Patela: A basement full of amnesic servers
by Osservatorio Nessuno 07 May '25

07 May '25

Hi everyone! A while back, we announced[1] our project to set up a server facility in Italy to host Tor exit nodes. After several weeks of testing, we’re excited to share that our first nodes are now in production, running on our autonomous system. [2] Four of these nodes operate diskless thanks to System Transparency [3] and Patela [4], a small, pull-based tool we developed to configure exit nodes efficiently. To optimize this infrastructure, we’ve worked on multiple fronts, including mTLS for nodes authentication, TPM for crypto operation and nftables rules. In this post[5], we’ll explain how the system works, and we’d love to hear your thoughts and feedback via the mailing list. Now that we’ve completed this initial testing phase, our next goal is to acquire suitable hardware to increase bandwidth capacity. Stay tuned for updates! Bye b [1] - https://osservatorionessuno.org/blog/2024/12/how-to-bgp-from-your-basement-… [2] - https://metrics.torproject.org/rs.html#search/as:AS214094 [3] - https://docs.system-transparency.org/st-1.0.0/ [4] - https://github.com/osservatorionessuno/patela [5] - https://osservatorionessuno.org/blog/2025/05/patela-a-basement-full-of-amne…

2 2

How Best to Maximize Impact of $500/mo Budget?
by Tor at 1AEO 05 May '25

05 May '25

If you have a budget of $500/mo (EUR or USD, roughly) that could be used to strengthen Tor network, what would you use it for and why? Some ideas: Run new relays: Lease VPS or colocate hardware yourself Fund existing operators: Provide stipends or grants to help other operators Donate to the Tor Foundation: Support core development, research, and docs. Other ideas: e.g. donation platforms, bandwidth grants, research funding? Which approach (or mix) yields the best consensus-weight gain per dollar? Any tips on pitfalls, vetting, or recommended donation channels? I've been leaning towards running new relays since it seems to always benefit from more diverse growth but wondering what others think. Thanks for your insights!

2 1

Tor Relay Deployment Dilemma: Handle BGP yourself or have it done upstream to announce your own AS?
by Tor at 1AEO 02 May '25

02 May '25

I'm currently evaluating the best approach for having my AS announced with my owned (not rented) IPv4 addresses, and I've observed that hosting providers have different preferences for handling BGP sessions. For example, one provider requires that the BGP session be managed on the same server running the Tor relays, while another handles the announcement with my AS entirely on their side. This inconsistency makes it challenging to determine the most effective approach. I'm seeking guidance on the following points (or others you think are helpful): - When given the option: Should I manage the BGP session myself, or is it preferable to delegate it to the upstream provider whenever possible? - When required to manage BGP myself: - To conserve CPU/RAM resources for Tor, is it advisable to only use a default route (0.0.0.0/24) rather than a full routing table, relying on the upstream provider for full routing? - Under what circumstances should I implement multi-homed strategies myself versus allowing the upstream provider to manage them? - Are there best practices for route filtering or failover management? - What are your experiences regarding the compute and memory requirements for these configurations? - What are some preferred monitoring solutions? bgpmon.net doesn't seem free... Helpful read and suggestions at the end from this 6 year old article from nusenu, but couldn't find too much beyond this: https://nusenu.medium.com/how-vulnerable-is-the-tor-network-to-bgp-hijackin… I'm already using ROA and RPKI via ARIN for each /24 and limit max length to /24 to help as well. "The Tor exit fraction located in /24 prefixes is much higher than the guard capacity. So hijacks against exit capacity might be harder than attacks against guard capacity." - Seems also good to have /24 prefixes for guards, not just exits. Thanks!

2 2

relayor v25.0.0 is released
by nusenu 29 Apr '25

29 Apr '25

Hi, relayor v25.0.0 is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… Most notable changes: * Support the MyFamily successor "happy families". This new relayor feature is currently opt-in as it also requires an alpha release of tor. When happy families reaches a tor stable release we will enable it by default and make the opt-in setting obsolete. I'm not so happy about the details but I also didn't want to introduce new dependencies so relayor is copying the family key file for **every** tor instance - see the background here [1]. Happy families is especially useful for large operators running many tor instances. The MyFamily configuration is not replaced by happy families, both designs are used when happy families is enabled. * prometheus integration improvement (backward incompatible change): remove variable tor_prometheus_config_file. relayor makes use of prometheus conf.d folder support instead of generating the entire configuration, relayor only drops the scrape config files into a configurable folder where prometheus is expected to read them. See prometheus' global config: scrape_config_files [1] https://gitlab.torproject.org/tpo/core/tor/-/issues/41046 Changelog: https://github.com/nusenu/ansible-relayor/releases/tag/v25.0.0 kind regards, nusenu -- https://nusenu.github.io

1 0

Self hosting bridge at home - de-anonymization risk?
by bjewrn2a＠anonaddy.com 29 Apr '25

29 Apr '25

is there any documentation on self-hosting a bridge at home and using it for your own connections? I am trying to understand why this isn't a recommended setup, would it lead to de-anonymization? Why/how much? your traffic blends with other users directly via the same connection other users use your bridge on a regular basis together with you and your hidden services ISP monitoring of your exact connection times are made harder (not sure how much exactly) I don't understand why hosting a bridge outside of your geographic location is necessary? is it a problem that the first hop is from your own IP address if the other two hops are external? were there any studies or similar questions asked before? I couldn't find anything I can't find help anywhere, so would appreciate any advice

6 16

Tor Relay Deployment Dilemma: Colocation vs Dedicated Servers for 10 Gbps
by Tor at 1AEO 06 Apr '25

06 Apr '25

Part 2 - Looking for feedback on our Tor relay configuration decision: Assuming both options cost the same and provide the same aggregate bandwidth—and by “better,” I mean improved advertised bandwidth, reliability, and diversity—is it preferable to deploy: Option 2A: Colocation, where we own the hardware, for 2 x 10 Gbps, or Option 2B: Dedicated servers, where we rent the hardware, for 4 x 10 Gbps? We lean toward Option 2B because it offers higher total bandwidth and may provide enhanced hardware redundancy and scalability. Additionally, does the ideal choice depend on the relay's role (e.g., exit vs. guard/middle nodes)? Also, is there a more comprehensive way to define “better” for this context? We appreciate any suggestions or refinements

2 1

Open source scripts for parsing CollecTor Tor server descriptor files?
by Tor at 1AEO 04 Apr '25

04 Apr '25

Couldn't find open source scripts to download and parse metrics from CollecTor server descriptor files so started creating some with help of ChatGPT. It'd be great if these already existed somewhere to build from and contribute back to! Created something very basic to parse and group relays by family fingerprint showing contact info, aggregated observed bandwidth, average observed bandwidth, unique IPv4 count, and unique AS count. Will keep dumping code here: https://github.com/1aeo/relayradar/ What would be helpful to see that you can't find elsewhere? Ex: I want to summarize total bandwidth observed by relay family per AS to see how different providers are performing Source files: https://metrics.torproject.org/collector/recent/relay-descriptors/server-de… Some initial insights, might be specifically incorrect but should have the right magnitude, from parsing March 27th, 28th and 29th server descriptor files: March 28th 6814 number of unique IPv4 addresses ~900 number of unique ASN Screenshot attached of example output in .html and attached .html file Used a 3rd party API, ipinfo.io, to lookup AS per unique IP and they shared some more metrics below via images, based on the 3 days of server descriptor unique IP to AS lookup calls. Top 5 countries and cities, highly concentrated in Europe Top 5 companies, mostly hosting companies and 1AEO, us, as #3 (guessing by quantity of IP addresses) 38 mobile carrier IPs running relays [image.png] [image.png] [image.png] [image.png] [image.png]

1 0

Running an obfs4 Bridge behind a UniFi UXG
by Malcolm MacDonald 01 Apr '25

01 Apr '25

Hello All! Not sure if anyone else is running a bridge behind a UniFi UXG but in my Flow log I am seeing blocked items with the Category of "DShield Block List" and Signature of "ET DROP Dshield Block Listed Source group 1" and the connection is being blocked. I'm thinking these alerts can be set to Allow Signature? Am I wrong on this one? Malcolm

2 1

Re: Guidance on optimal Tor relay server configurations - Best CPUs to Lower Colocation Costs for 10Gbps+ Tor Relays
by Tor at 1AEO 01 Apr '25

01 Apr '25

AMD EPYC 8534P and AMD EPYC 9535 are the best CPUs to minimize monthly colocation cost, based on two main factors of power (watts) and rack size, for Tor relay servers at 10 Gbps+ with 128 threads. Power seems to be largest contributor to colocation cost and CPU seems to be largest contributor to power. Open to thoughts / additional insights to lower colocation costs. The comments about EPYC were very helpful, especially as I've only had Intel until now. I've started moving to EPYC 8534P. After comparing options, AMD’s EPYC line currently offers the most power-efficient CPUs for 128+ threads—outperforming even the new Xeon 6E cores in threads-per-watt (and threads-per-watt weighted by clock speed) from 200 to 500 watts TDP. Selection criteria: - >=128 threads - lowest TDP wattage (also using "AMD configurable TDP (cTDP)" - maximizing PCIe version (5.0) - PCIe lanes (>= x96) - DDR5 RAM capacity (>=576GB) - DDR5 RAM speed (>= 4800 MT/s) For scenarios needing more than 128 threads, consider: - AMD EPYC 9634: 168 threads, 2.25 GHz base, min TDP 240W - AMD EPYC 9845: 320 threads, 2.1 GHz base, min TDP 320W For older generation systems (PICe 4.0 or DDR4), EPYC 7702 and EPYC 7763 were best options. Brief table: Name Series # of CPU Cores # of Threads Base Clock Max. Boost Clock All Core Boost Speed L3 Cache Default TDP Min TDP AMD Configurable TDP (cTDP) Socket Count PCI Express® Version System Memory Type Memory Channels System Memory Specification Per Socket Mem BW AMD EPYC™ 8534P EPYC 8004 Series 64 128 2.3 GHz Up to 3.1 GHz 3.1 GHz 128 MB 200W 155 155-225W 1P PCIe® 5.0 x96 DDR5 6 Up to 4800 MT/s 230.4 GB/s AMD EPYC™ 9634 EPYC 9004 Series 84 168 2.25 GHz Up to 3.7 GHz 3.1 GHz 384 MB 290W 240 240-300W 1P / 2P PCIe® 5.0 x128 DDR5 12 Up to 4800 MT/s 460.8 GB/s AMD EPYC™ 9535 EPYC 9005 Series 64 128 2.4 GHz Up to 4.3 GHz 3.5 GHz 256 MB 300W 240 240-300W 1P / 2P PCIe® 5.0 x128 DDR5 12 Up to 6400 MT/s 614 GB/s AMD EPYC™ 9845 EPYC 9005 Series 160 320 2.1 GHz Up to 3.7 GHz 3.25 GHz 320 MB 390W 320 320-400W 1P / 2P PCIe® 5.0 x128 DDR5 12 Up to 6400 MT/s 614 GB/s ~200 AMD CPU full list: https://www.amd.com/en/products/specifications/server-processor.html >> On Friday, February 21st, 2025 at 2:40 AM, mail--- via tor-relays <tor-relays(a)lists.torproject.org> wrote: >> >>> Hi, >>> >>>> Summary from your email - did I miss anything? >>> >>> Yes, with the general disclaimer (not to sound like a lawyer) that your mileage may vary. For example we run everything bare metal on FreeBSD and run a mix of guard/middle/exit relays. Running the same workload virtualized or on another operating system may impact the performance/overhead (either positively or negatively). Also your RAM budget of 4 GB per relay may be a bit on the safe side, I don't think it would hurt to lower this. >>> >>>> What are the primary factors that justify running up to two Tor relays per physical core (leveraging SMT) versus a one-to-one mapping? >>> >>> Tor relays sadly don't scale well. They fluctuate on a daily basis (the Tor network as a whole does) and even their general utilization is kind of unpredictable. So I think there are two approaches to this: >>> >>> 1) Run 1 relay per physical core, accepting that your CPU will idle a large amount of the time (50%+ in our case). >>> >>> 2) Run multiple Tor relays per physical core until you saturate 90-95% of your CPU cycles, accepting additional system overhead/congestion. >>> >>> There is no right or wrong here. In our case we went with running multiple relays per core because we want to utilize the (very expensive) hardware we run on as much as possible. Every CPU cycle not spent on privacy enhancing services is a wasted CPU cycle from our point of view ;). >>> >>>> Is one-to-one mapping of Tor relay to core/thread the most compute- and system-efficient approach? >>> >>> Yes, this should lower the amount of congestion (interrupts and stuff). In this sense it can also be beneficial to lock your NIC/irq threads to specific cores. >>> >>>> Are the clock speeds you listed base or turbo numbers (3.4, 2.25 and 2.0 Ghz)? >>> >>> Base indeed. No CPU is able to consistently maintain their turbo speed on this many cores. When all cores are utilized, the base speed pretty much is the max speed in practice. >>> >>>> From your real world scenario #2 and advice for the "fastest/best hardware", would this type of server work well for a $20k budget? >>> >>> Looks like a capable server. That CPU looks powerful enough but keep in mind that it has a rather low clockspeed, so you will be running many medium speed relays. Nothing wrong with that since CPUs with this many cores simply don't/can't have high base clocks. Also I think 512 GB of RAM would be enough unless you run a *lot* of relays on it (which may be a viable strategy to utilize your CPU fully). >>> >>> Just a note: in my experience the Epyc platform (especially when self-build) provides a bit more bang for your buck. For example a AMD Epyc 9969 with 192 cores/384 threads(a)2.25 Ghz baseclock will probably outperform the Intel 6980P considerably (for Tor workloads at least), while being much cheaper (listing price at least). But of course this greatly depends on where you buy the server or parts so your mileage may vary. When I look around here locally a complete self-build system with the 192 core Epyc, 512 GB RAM and a 100 Gb/s NIC would cost ~12k excluding VAT before any tax benefits. But your proposed server will work perfectly fine as well so if you prefer a brand, go for it :). >>> >>>> Assuming one relay per core/thread, would this setup be capable of saturating 40 Gbps, given that 10 Gbps typically saturated with ~31.5 physical cores + ~31.5 SMT threads at 2 Ghz and thus 256 relays vs ~63 relays translates roughly to 4×10 Gbps = 40 Gbps? >>> >>> Assuming you get the Tor relays to saturate their cores, yes. That CPU should be able to push 40 Gb/s of Tor traffic. Our ~2019 64 core/128 thread Epyc pushes 10 Gb/s of Tor traffic on a bit less than half it's capacity. And your CPU is newer (better IPC hopefully if Intel finally stepped up their game since 2019), has much more cache and runs on DDR5 while having a bit lower base clock. So it should perform at least similar but probably better than ours. >>> >>> Do you have the network capacity covered already? If you plan to do 40 Gb/s, then you also need enough peers/upstream capacity. The required networking equipment and connections themselves for this can also be costly. >>> >>> Cheers, >>> >>> tornth >>> >>> Feb 20, 2025, 08:42 by tor(a)1aeo.com: >>> >>>> Excellent information, especially the real world scenarios! Exactly what I was looking for! >>>> >>>> Summary from your email - did I miss anything? >>>> >>>> To saturate 10 Gbps connection: >>>> 1) IPv4 Allocation: Use between 5 and 20. Much lower than 256 in a /24! >>>> 2) Tor Relay Count: Run roughly ~40 to ~150, depending on CPU clock speed, i.e. faster clock, fewer relays needed. >>>> 3) CPU Utilization: 1 Tor relay per physical core preferred but okay to scale to 1 Tor relay per threads/SMT as well, up to 2x Tor relays per core/thread >>>> 4) RAM requirements: Maintain a 4:1 RAM-to-core/relay ratio (4GB per core/relay), including extra 32GB per server to cover DoS, OS, networking, etc. overheads >>>> >>>> In general, some ideals but not required: >>>> CPU clock speed: Higher CPU clock speed, better relay performance >>>> RAM: Fewer relays, lower RAM requirements >>>> RAM: Add ~32GB to overall RAM capacity sizing for OS, DNS, networking, DoS, etc. >>>> IPv4: One IPv4 per relay with common traffic ports >>>> >>>> Scaling: Start with 1 Tor relay per physical core, then add 1 Tor relay per thread/SMT and stop at 2 Tor relays per each core / thread. >>>> >>>> What are the primary factors that justify running up to two Tor relays per physical core (leveraging SMT) versus a one-to-one mapping? >>>> Ex: 37-74 for ~18.5 physical + SMT and 63-126 for ~31.5 physical + SMT. >>>> >>>> Is one-to-one mapping of Tor relay to core/thread the most compute- and system-efficient approach? >>>> >>>> Are the clock speeds you listed base or turbo numbers (3.4, 2.25 and 2.0 Ghz)? I'm assuming base. Not sure if anybody has data on how these impact Tor relays? >>>> >>>> From your real world scenario #2 and advice for the "fastest/best hardware", would this type of server work well for a $20k budget? >>>> A single-socket Xeon 6980P (128 physical cores, 256 threads, base clock 2.0 GHz, turbo up to 3.9 GHz) with 1024GB DDR5 (maintaining a 4:1 ratio) and an AIOM Mellanox NIC be optimal? Assuming one relay per core/thread, would this setup be capable of saturating 40 Gbps, given that 10 Gbps typically saturated with ~31.5 physical cores + ~31.5 SMT threads at 2 Ghz and thus 256 relays vs ~63 relays translates roughly to 4×10 Gbps = 40 Gbps? >>>> >>>> For those curious, according to ChatGPT o3-mini-high deep research: >>>> 1) 20% cap on bandwidth contributions for exit relays is roughly 50+ Gbit/s for the largest operators. >>>> 2) 10% of Tor's consensus weight in terms of bandwidth for 2025 is roughly 90-95 Gbps of sustained bandwidth. In 2022, it would have been ~68 Gbps. >>>> I don't plan to have this issue any time soon, but good to be aware! >>>> >>>> Screenshots of the lengthy responses below and attached. >>>> >>>> [image.png] >>>> >>>> [image.png] >>>> [image.png] >>>> [image.png] >>>> >>>> Sent with[Proton Mail](https://proton.me/mail/home)secure email. >>>> >>>> On Tuesday, February 18th, 2025 at 2:23 PM, mail(a)nothingtohide.nl <mail(a)nothingtohide.nl> wrote: >>>> >>>>> Hi, >>>>> >>>>> Many people already replied, but here are my (late) two cents. >>>>> >>>>>> 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? >>>>> >>>>> "Optimal" depends on your preferences and goals. Some examples: >>>>> >>>>> - IP address efficiency: run 8 relays per IPv4 address. >>>>> - Use the best ports: 256 relays (443) or 512 relays (443+80). >>>>> - Lowest kernel/system congestion: 1 locked relay per core/SMT thread combination, ideally on high clocked CPUs. >>>>> - Easiest to manage: as few relays as possible. >>>>> - Memory efficiency: only run middle relays on very high clocked CPUs (4-5 Ghz). >>>>> - Cost efficiency: run many relays on 1-2 generations old Epyc CPUs with a high core count (64 or more). >>>>> >>>>> There are always constraints. The hardware/CPU/memory and bandwidth/routing capability available to you are probably not infinite. Also the Tor Project maximizes bandwidth contributions to 20% and 10% for exit relay and overall consensus weight respectively. >>>>> >>>>> With 256 IP addresses on modern hardware, it will be very hard to not run in to one of these limitations long before you can make it 'optimal'. Hardware wise, one modern/current gen high performance server only running exit relays will easily push enough Tor traffic to do more than half of the total exit bandwidth of the Tor network. >>>>> >>>>> My advice would be: >>>>> 1) Get the fastest/best hardware with current-ish generation CPU IPC capabilities you can get within your budget. To lower complexity with keeping congestion in control, one socket is easier to deal with than a dual socket system. >>>>> >>>>> (tip for NIC: if your switch/router has 10 Gb/s or 25 Gb/s ports, get some of the older Mellanox cards. They are very stable (more so than their Intel counterparts in my experience) and extremely affordable nowadays because of all the organizations that throw away their digital sovereignty and privacy of their employees/users to move to the cloud). >>>>> >>>>> 3) Start with 1 Tor relay per physical core (ignoring SMT). When the Tor relays have ramped up (this takes 2-3 months for guard relays) and there still is considerable headroom on the CPU (Tor runs extremely poorly at scale sadly, so this would be my expectation) then move to 1 Tor relay per thread (SMT included). >>>>> >>>>> (tip: already run/'train' some Tor relays with a very limited bandwidth (2 MB/s or something) parallel to your primary ones and pin them all to 1-2 cores to let them ramp up in parallel to your primary ones. This makes it *much* less cumbersome to scale up your Tor contribution when you need/want/can do that in the future). >>>>> >>>>> 4) Assume at least 1 GB of RAM per relay on modern CPUs + 32 GB additionally for OS, DNS, networking and to have some headroom for DoS attacks. This may sound high, especially considering the advice in the Tor documentation. But on modern CPUs (especially with a high clockspeed) guard relays can use a lot more than 512 MB of RAM, especially when they are getting attacked. Middle and exit relays require less RAM. >>>>> >>>>> Don't skimp out on system memory capacity. DDR4 RDIMMs with decent clockspeeds are so cheap nowadays. For reference: we ran our smaller Tor servers (16C(a)3.4Ghz) with 64 GB of RAM and had to upgrade it to 128 GB because during attacks RAM usage exceeded the amount available and killed processes. >>>>> >>>>> 5) If you have the IP space available, use one IPv4 address per relay and use all the good ports such as 443. If IP addresses are more scarce, it's also not bad to run 4 or 8 relays per IP address. Especially for middle and exit relays the port doesn't matter (much). Guard relays should ideally always run on a generally used (and generally unblocked) port. >>>>> >>>>>> 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? >>>>> >>>>> That greatly depends on the CPU and your configuration. I can offer 3 references based on real world examples. They all run a mix of guard/middle/exit relays. >>>>> >>>>> 1) Typical low core count (16+SMT) with higher clockspeed (3.4 Ghz) saturates a 10 Gb/s connection with ~18.5 physical cores + SMT. >>>>> 2) Typical higher core count (64+SMT) with lower clockspeed (2.25 Ghz) saturates a 10 Gb/s connection with ~31.5 physical cores + SMT. >>>>> 3) Typical energy efficient/low performance CPU with low core count (16) with very low clockspeed (2.0 Ghz) used often in networking appliances saturates a 10 Gb/s connection with ~75 physical cores (note: no SMT). >>>>> >>>>> The amount of IP addresses required also depends on multiple factors. But I'd say that you would need between the amount and double the amount of relays of the mentioned core+SMT count in order to saturate 10 Gb/s. This would be 37-74, 63-126 and 75-150 relays respectively. So between 5 and 19 IPv4 addresses would be required at minimum, depending on CPU performance level. >>>>> >>>>> RAM wise the more relays you run, the more RAM overhead you will have. So in general it's better to run less relays at a higher speed each than run many at a low clock speed. But since Tor scales so badly you need more Relays anyway so optimizing this isn't easy in practice. >>>>> >>>>>> 3) Same for a 20 Gbps connection, how many CPU cores, RAM and IPv4 addresses are required to saturate? >>>>> >>>>> Double the amount compared to 10 Gb/s. >>>>> >>>>> Good luck with your Tor adventure. And let us know your findings with achieving 10 Gb/s when you get there :-). >>>>> >>>>> Cheers, >>>>> >>>>> tornth >>>>> >>>>> Feb 3, 2025, 18:14 by tor-relays(a)lists.torproject.org: >>>>> >>>>>> 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](https://proton.me/mail/home)secure email.

1 0

Tor Relay Deployment Dilemma: Single 40Gbps Server or Four 10Gbps Machines?
by Tor at 1AEO 01 Apr '25

01 Apr '25

Looking for feedback on my Tor relay configuration decision: Assuming both options cost the same and provide the same aggregate bandwidth—and by “better,” I mean improved advertised bandwidth, reliability, and diversity—is it preferable to deploy: Option A: One hardware server on a 40Gbps link, or Option B: Four hardware servers, each on a 10Gbps link, located in different geographic areas and/or with different upstream providers? I lean toward Option B because it offers advantages in advertised bandwidth, reliability, and diversity. Additionally, does the ideal choice depend on whether the relays serve as exit nodes or as guard/middle nodes? Also, is there a more comprehensive way to define “better” for this context? I appreciate any suggestions or refinements!

2 2

Happy Families - Relay Operator Friendlyness
by nusenu 31 Mar '25

31 Mar '25

Hi Marco, moving the discussion from: https://gitlab.torproject.org/tpo/core/tor/-/issues/41033#note_3181625 to tor-relays as the features in the issue have already been implemented by Nick and the discussion has evolved into a more general direction. > I think many people have > HiddenService instances in addition to their relay instances. > HiddenService instances must then be configured not to use default > FamilyId * if tor automatically detect and use those. > Ultimately, > @nickm has to decide how much work he wants to put into c-tor. > (Especially auto detecting KeyDir on all OS requires a lot of time > to test.) Happy families is not relevant for onion services. I sense a misunderstanding of "FamilyId *". It only looks for family keys in the "keys" subfolder of a specific tor instance's DataDirectory or within the directory given in "FamilyKeyDirectory". See also the man page section: "KeyDirectory" because "keys" is just the default but can be configured. It does not search across the all "keys" subfolders of multiple tor instances on the same server, which would fail anyway with proper filesystem permissions, because one tor instance should not be able to read another tor instance's data directory if setup correctly. kind regards, nusenu -- https://nusenu.github.io

1 0

Self hosting bridge at home - de-anonymization risk?
by bjewrn2a＠anonaddy.com 30 Mar '25

30 Mar '25

> All Tor relays -- even non-exit relays -- are in a public list. Many > sites and services block access to all traffic coming from a Tor relay > IP address. Either they don't understand how Tor works or (more likely, > in my experience) they're just hostile to Tor. > > If you host a relay on your home IP, you'll likely find that you are > blocked from streaming services and other web sites (Cloudflare, for > one, facilitates this and by some reports they control about 30% of web > traffic). Thanks Ron, I will bear that in mind. Want to try it anyway and see how it goes.

1 0

Re: Self hosting bridge at home - de-anonymization risk?
by Zachary 29 Mar '25

29 Mar '25

Hello, I just wanted to make a comment on hosting a relay at home. > Many sites and services block access to all traffic coming from a Tor relay IP address Having hosted a relay at my house for over a year and in an institutional setting prior to that, I have ran into very few instances of this personally. It does indeed happen and often it's extremely hard to troubleshoot because you don't realize what the problem is. > If you host a relay on your home IP, you'll likely find that you are blocked from streaming services and other web sites I personally don't use many streaming services, but people I live with use them as their main source of entertainment. They haven't been blocked from any streaming services, at least so far. The only two things (that I remember/think are important) that I've been "banned" from for being a Tor Guard/Middle relay are: 1. Insurance company 2. My bank I live in a small town and have a good working relationship with my bank, who I was able to get in touch with their hosting provider to whitelist my IP (and when it rarely changes due to a router switch-out etc. they have been very good and whitelisted my new IP no questions asked.) As for the insurance company, which is a large nationwide provider, there is no feasible way to get in contact with anyone who even knows what I am talking about. The only solution to access them unfortunately is to use my phone as a cellular hotspot to get a different WAN IP. This doesn't always work because some routers don't announce themselves in a traceroute, but it can be very useful to run a traceroute to the website you are blocked on to see what router is actually blocking the traffic. That way when you contact the site operator you can point them in the right direction (if they are willing to help you.) If a website's upstream hosting provider is blocking the traffic, you would want to tell the website operator to tell their hosting provider that so they don't chase a red herring. I'm not downplaying your concerns, they are 100% valid, just sharing that in my experience it has been a non-issue (except the insurance company lol.) Of course, if my bank wasn't a small local organization and they weren't willing to assist, then it would be a different story entirely and I would feel very different about it. Just for perspective, my Pihole has caused vastly more issues cutting off legitimate content than being blocked for being a relay. Just wanted to share my thoughts. (: Zachary ----------- On Saturday, March 29th, 2025 at 7:00 AM, 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: Self hosting bridge at home - de-anonymization risk? > (Ron Risley) > 2. Re: Self hosting bridge at home - de-anonymization risk? (mpan) > 3. Self hosting bridge at home - de-anonymization risk? > (bjewrn2a(a)anonaddy.com) > 4. Re: Self hosting bridge at home - de-anonymization risk? > (gerard(a)bulger.co.uk) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 27 Mar 2025 07:50:44 -1000 > From: Ron Risley ronqtorrelays(a)risley.net > > Subject: [tor-relays] Re: Self hosting bridge at home - > de-anonymization risk? > To: tor-relays(a)lists.torproject.org > Message-ID: c1978073-7a34-4be4-ba69-feaada8028ac(a)risley.net > > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 3/26/25 11:56, bjewrn2a--- via tor-relays wrote: > > > That would incentivize users to also become > > relays - why isn't it recommended more often? > > > All Tor relays -- even non-exit relays -- are in a public list. Many > sites and services block access to all traffic coming from a Tor relay > IP address. Either they don't understand how Tor works or (more likely, > in my experience) they're just hostile to Tor. > > If you host a relay on your home IP, you'll likely find that you are > blocked from streaming services and other web sites (Cloudflare, for > one, facilitates this and by some reports they control about 30% of web > traffic). > > ------------------------------ > > Message: 2 > Date: Thu, 27 Mar 2025 19:59:48 +0100 > From: mpan tor-1qnuaylp(a)mpan.pl > > Subject: [tor-relays] Re: Self hosting bridge at home - > de-anonymization risk? > To: tor-relays(a)lists.torproject.org > Message-ID: 3c48cbbf-1693-4f05-ab6d-9e8032989848(a)mpan.pl > > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > > but what if you used tor normally, not through your own bridge, but through > > > > "regular" randomly chosen 3-hop circuits and at the same time run a tor relay > > > > (entry/middle) > > > > > This wouldn't require weakening the tor circuit model > > > anymore. Yes, this is correct. The more Tor traffic goes through the machine > > > that identifies you, the more confused an adversary is. It also makes > > > naïve correlation attacks impossible,⁽¹⁾ and increases cost of more > > > advanced ones. > > > > That is great news mpan, thank you. That would incentivize users to also become > > relays - why isn't it recommended more often? This is the first time I ever hear > > about it and it sounds like a powerful idea. Normally I only see tor relay > > operators claim that they run tor relays purely altruistically: > > https://www.reddit.com/r/TOR/comments/6znjkg/why_would_anyone_setup_a_tor_r… > > To know why Tor Project itself doesn’t speak on this matter, you’d > need to wait for a reply from somebody from the project. > > I may speculate, that the two topics are orthogonal: running a relay > and using Tor. They don’t interfere with each other. In your original > question they didn’t either. The problem was not running a relay and > using Tor, but using Tor with the number of hops effectively reduced. > > It would also be a poor advice, if directed towards a person wishing > to only connect to Tor. Running a relay from home isn’t without > downsides. Both for the operator (bandwidth use, facing hostility) and > the network itself (completely inexperienced person is an easier attack > target). > > > Are you aware of any articles from torproject or research papers confirming that > > hosting tor relay at your own IP does in fact help your own traffic blend in? > > I've looked through all tor proposals (https://spec.torproject.org/proposals) > > and many research papers (https://www.freehaven.net) and couldn't find any > > mentions of this? Specifically for Tor? No. For exactly the same reason I can’t point > > you to any research that confirms, that downloading 500 kB/s and 200 > kB/s over Tor requires 700 kB/s. It’s a trivial consequence of basic > knowledge for the given field. In this case probabilistics, flavored > with practicality of correlation attacks and with signal processing > basics (none of this in Tor specifically). > > > ------------------------------ > > Message: 3 > Date: Thu, 27 Mar 2025 22:08:31 +0000 > From: bjewrn2a(a)anonaddy.com > Subject: [tor-relays] Self hosting bridge at home - de-anonymization > risk? > To: tor-relays(a)lists.torproject.org > Message-ID: d0d4ecac8b6e815e6a1768fb7cf32523(a)anonaddy.com > > Content-Type: multipart/alternative; boundary=fOfmQjRb > > > My personal opinion is that hosting a bridge or middle at your home doesn't risk de-anonymizing > > > Thank you, I am counting on that too. However, I haven't seen it recommended anywhere else before. Are you aware of any articles or studies backing this up? If that's a preferred setup I would have expected it to be more popular? > > > I would host a tor exit at home if I could get extra IPv4 addresses > > > Interesting, I haven't thought about that.

1 0

Re: Self hosting bridge at home - de-anonymization risk?
by DiffieHellman 28 Mar '25

28 Mar '25

My personal opinion is that hosting a bridge or middle at your home doesn't risk de-anonymizing you unless you go misconfigure your client to use your bridge or specifically only your middle. Maybe there is a chance of deanoymisation if you happen to use your own middle inadvertently, but it seems changing the default configuration to exclude your own relay is more of a deanoymisation risk. Running a middle instead of a bridge will make extra work for any ISP or NSA snoop to determine which tor traffic is yours, as most of the tor traffic won't be yours and even some tor traffic from middles goes to guard relays, which will require filtering out to determine which is your tor traffic to guards. I would host a tor exit at home if I could get extra IPv4 addresses at a reasonable price, but I can't. -- Kind Regards, DiffieHellman

2 1

Got contacted by another relay operator
by tempemailoNiceRelays 27 Mar '25

27 Mar '25

We were contacted by another relay operator (Zakwan Kalb zk(a)onionmail.org) He told us that Torproject intentionally added two new flags to our relays (BadExit, MiddleOnly) and our relays cannot be used as exit or guard. We checked our relays on https://metrics.torproject.org/rs.html as he asked and found that these flags really exist and our relays only used as middle. Has anyone faced the same problem?

2 3

Re: Guidance on optimal Tor relay server configurations - Maximum 360 Tor relays allowed?
by Tor at 1AEO 24 Mar '25

24 Mar '25

New constraint - any guidance? Math seem right? All relay operators / families are limited to a maximum of ~360 Tor relays: https://gitlab.torproject.org/tpo/core/tor/-/issues/40837 I'll likely create an account to reply on the gitlab ticket too since looks like different audience than those replying here. Unfortunately, if the Tor network isn't efficient in using the bandwidth across ~4 x 10 Gbps servers then this limit will be reached, hindering known good operators, while not stopping malicious operators who don't follow the rules. Least efficient, ~512 CPU threads / relays for 4 x 10 Gbps (128 threads/relays per 1 x 10 Gbps server). Most efficient, ~320 CPU threads / relays for 4 x 10 Gbps (80 threads/relays per 1 x 10 Gbps server). Today, optimize Tor relay for the ~360 constraints: 1) Maximize bandwidth per CPU thread/core/relay with higher CPU base clock 2) Other hardware: Ensure sufficient RAM per Tor relays (4GB to 1 CPu thread) and good NIC. 3) Maximize network peering / routing strategies for Tor? Anything else? For #3, how best to optimize network routing / peering strategies for Tor relays? This email thread was optimizing around CPU threads and RAM but having plenty of CPU threads and RAM that might be insufficient with a poor network routing/peering strategy for Tor? Is there a reasonable way or some reliable way to quickly (less than a few months of running the relays) get in the correct range of how well the Tor network uses a specific server's available bandwidth? Ex: Route hops / ping times to directory / bandwidth authorities, confirming well known upstream providers (Cogent, etc.), and/or something else? Best strategy is month-to-month renting servers and running relays rather than signing 5 year contracts to end up somewhere with poor peering/routing for Tor? On Tuesday, February 25th, 2025 at 9:57 PM, Tor at 1AEO via tor-relays <tor-relays(a)lists.torproject.org> wrote: > Okay - makes sense on up to 2 Tor relays per physical core with the goal of not wasting CPU cycles, given the fluctuations of Tor and the expensive hardware. > > No, don't have all the network capacity covered and agree everything is costly. > > For 10 Gbps unmetered, not many options under $600/mo comfortable with Tor relays so I'm alternating between colocation and dedicated bare metal servers, depending on location, hardware availability, price, support to bring my own IPv4 and announce my ASN, some semblance of ASN and geographic diversity for Tor, etc. > > For 40 Gbps unmetered, not seeing much under $2k/mo. > > Open to suggestions / guidance on network capacity, colocation, and bare metal servers. Don't know what I don't know so maybe I should be asking other questions? > > When doing colocation, any suggestions on how best to set everything up? Router or only layer 3 switch or put compute node directly on internet connection? Worth using a transparent firewall/bridging, DMZ or NAT? > > On Friday, February 21st, 2025 at 2:40 AM, mail--- via tor-relays <tor-relays(a)lists.torproject.org> wrote: > >> Hi, >> >>> Summary from your email - did I miss anything? >> >> Yes, with the general disclaimer (not to sound like a lawyer) that your mileage may vary. For example we run everything bare metal on FreeBSD and run a mix of guard/middle/exit relays. Running the same workload virtualized or on another operating system may impact the performance/overhead (either positively or negatively). Also your RAM budget of 4 GB per relay may be a bit on the safe side, I don't think it would hurt to lower this. >> >>> What are the primary factors that justify running up to two Tor relays per physical core (leveraging SMT) versus a one-to-one mapping? >> >> Tor relays sadly don't scale well. They fluctuate on a daily basis (the Tor network as a whole does) and even their general utilization is kind of unpredictable. So I think there are two approaches to this: >> >> 1) Run 1 relay per physical core, accepting that your CPU will idle a large amount of the time (50%+ in our case). >> >> 2) Run multiple Tor relays per physical core until you saturate 90-95% of your CPU cycles, accepting additional system overhead/congestion. >> >> There is no right or wrong here. In our case we went with running multiple relays per core because we want to utilize the (very expensive) hardware we run on as much as possible. Every CPU cycle not spent on privacy enhancing services is a wasted CPU cycle from our point of view ;). >> >>> Is one-to-one mapping of Tor relay to core/thread the most compute- and system-efficient approach? >> >> Yes, this should lower the amount of congestion (interrupts and stuff). In this sense it can also be beneficial to lock your NIC/irq threads to specific cores. >> >>> Are the clock speeds you listed base or turbo numbers (3.4, 2.25 and 2.0 Ghz)? >> >> Base indeed. No CPU is able to consistently maintain their turbo speed on this many cores. When all cores are utilized, the base speed pretty much is the max speed in practice. >> >>> From your real world scenario #2 and advice for the "fastest/best hardware", would this type of server work well for a $20k budget? >> >> Looks like a capable server. That CPU looks powerful enough but keep in mind that it has a rather low clockspeed, so you will be running many medium speed relays. Nothing wrong with that since CPUs with this many cores simply don't/can't have high base clocks. Also I think 512 GB of RAM would be enough unless you run a *lot* of relays on it (which may be a viable strategy to utilize your CPU fully). >> >> Just a note: in my experience the Epyc platform (especially when self-build) provides a bit more bang for your buck. For example a AMD Epyc 9969 with 192 cores/384 threads(a)2.25 Ghz baseclock will probably outperform the Intel 6980P considerably (for Tor workloads at least), while being much cheaper (listing price at least). But of course this greatly depends on where you buy the server or parts so your mileage may vary. When I look around here locally a complete self-build system with the 192 core Epyc, 512 GB RAM and a 100 Gb/s NIC would cost ~12k excluding VAT before any tax benefits. But your proposed server will work perfectly fine as well so if you prefer a brand, go for it :). >> >>> Assuming one relay per core/thread, would this setup be capable of saturating 40 Gbps, given that 10 Gbps typically saturated with ~31.5 physical cores + ~31.5 SMT threads at 2 Ghz and thus 256 relays vs ~63 relays translates roughly to 4×10 Gbps = 40 Gbps? >> >> Assuming you get the Tor relays to saturate their cores, yes. That CPU should be able to push 40 Gb/s of Tor traffic. Our ~2019 64 core/128 thread Epyc pushes 10 Gb/s of Tor traffic on a bit less than half it's capacity. And your CPU is newer (better IPC hopefully if Intel finally stepped up their game since 2019), has much more cache and runs on DDR5 while having a bit lower base clock. So it should perform at least similar but probably better than ours. >> >> Do you have the network capacity covered already? If you plan to do 40 Gb/s, then you also need enough peers/upstream capacity. The required networking equipment and connections themselves for this can also be costly. >> >> Cheers, >> >> tornth >> >> Feb 20, 2025, 08:42 by tor(a)1aeo.com: >> >>> Excellent information, especially the real world scenarios! Exactly what I was looking for! >>> >>> Summary from your email - did I miss anything? >>> >>> To saturate 10 Gbps connection: >>> 1) IPv4 Allocation: Use between 5 and 20. Much lower than 256 in a /24! >>> 2) Tor Relay Count: Run roughly ~40 to ~150, depending on CPU clock speed, i.e. faster clock, fewer relays needed. >>> 3) CPU Utilization: 1 Tor relay per physical core preferred but okay to scale to 1 Tor relay per threads/SMT as well, up to 2x Tor relays per core/thread >>> 4) RAM requirements: Maintain a 4:1 RAM-to-core/relay ratio (4GB per core/relay), including extra 32GB per server to cover DoS, OS, networking, etc. overheads >>> >>> In general, some ideals but not required: >>> CPU clock speed: Higher CPU clock speed, better relay performance >>> RAM: Fewer relays, lower RAM requirements >>> RAM: Add ~32GB to overall RAM capacity sizing for OS, DNS, networking, DoS, etc. >>> IPv4: One IPv4 per relay with common traffic ports >>> >>> Scaling: Start with 1 Tor relay per physical core, then add 1 Tor relay per thread/SMT and stop at 2 Tor relays per each core / thread. >>> >>> What are the primary factors that justify running up to two Tor relays per physical core (leveraging SMT) versus a one-to-one mapping? >>> Ex: 37-74 for ~18.5 physical + SMT and 63-126 for ~31.5 physical + SMT. >>> >>> Is one-to-one mapping of Tor relay to core/thread the most compute- and system-efficient approach? >>> >>> Are the clock speeds you listed base or turbo numbers (3.4, 2.25 and 2.0 Ghz)? I'm assuming base. Not sure if anybody has data on how these impact Tor relays? >>> >>> From your real world scenario #2 and advice for the "fastest/best hardware", would this type of server work well for a $20k budget? >>> A single-socket Xeon 6980P (128 physical cores, 256 threads, base clock 2.0 GHz, turbo up to 3.9 GHz) with 1024GB DDR5 (maintaining a 4:1 ratio) and an AIOM Mellanox NIC be optimal? Assuming one relay per core/thread, would this setup be capable of saturating 40 Gbps, given that 10 Gbps typically saturated with ~31.5 physical cores + ~31.5 SMT threads at 2 Ghz and thus 256 relays vs ~63 relays translates roughly to 4×10 Gbps = 40 Gbps? >>> >>> For those curious, according to ChatGPT o3-mini-high deep research: >>> 1) 20% cap on bandwidth contributions for exit relays is roughly 50+ Gbit/s for the largest operators. >>> 2) 10% of Tor's consensus weight in terms of bandwidth for 2025 is roughly 90-95 Gbps of sustained bandwidth. In 2022, it would have been ~68 Gbps. >>> I don't plan to have this issue any time soon, but good to be aware! >>> >>> Screenshots of the lengthy responses below and attached. >>> >>> [image.png] >>> >>> [image.png] >>> [image.png] >>> [image.png] >>> >>> Sent with[Proton Mail](https://proton.me/mail/home)secure email. >>> >>> On Tuesday, February 18th, 2025 at 2:23 PM, mail(a)nothingtohide.nl <mail(a)nothingtohide.nl> wrote: >>> >>>> Hi, >>>> >>>> Many people already replied, but here are my (late) two cents. >>>> >>>>> 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? >>>> >>>> "Optimal" depends on your preferences and goals. Some examples: >>>> >>>> - IP address efficiency: run 8 relays per IPv4 address. >>>> - Use the best ports: 256 relays (443) or 512 relays (443+80). >>>> - Lowest kernel/system congestion: 1 locked relay per core/SMT thread combination, ideally on high clocked CPUs. >>>> - Easiest to manage: as few relays as possible. >>>> - Memory efficiency: only run middle relays on very high clocked CPUs (4-5 Ghz). >>>> - Cost efficiency: run many relays on 1-2 generations old Epyc CPUs with a high core count (64 or more). >>>> >>>> There are always constraints. The hardware/CPU/memory and bandwidth/routing capability available to you are probably not infinite. Also the Tor Project maximizes bandwidth contributions to 20% and 10% for exit relay and overall consensus weight respectively. >>>> >>>> With 256 IP addresses on modern hardware, it will be very hard to not run in to one of these limitations long before you can make it 'optimal'. Hardware wise, one modern/current gen high performance server only running exit relays will easily push enough Tor traffic to do more than half of the total exit bandwidth of the Tor network. >>>> >>>> My advice would be: >>>> 1) Get the fastest/best hardware with current-ish generation CPU IPC capabilities you can get within your budget. To lower complexity with keeping congestion in control, one socket is easier to deal with than a dual socket system. >>>> >>>> (tip for NIC: if your switch/router has 10 Gb/s or 25 Gb/s ports, get some of the older Mellanox cards. They are very stable (more so than their Intel counterparts in my experience) and extremely affordable nowadays because of all the organizations that throw away their digital sovereignty and privacy of their employees/users to move to the cloud). >>>> >>>> 3) Start with 1 Tor relay per physical core (ignoring SMT). When the Tor relays have ramped up (this takes 2-3 months for guard relays) and there still is considerable headroom on the CPU (Tor runs extremely poorly at scale sadly, so this would be my expectation) then move to 1 Tor relay per thread (SMT included). >>>> >>>> (tip: already run/'train' some Tor relays with a very limited bandwidth (2 MB/s or something) parallel to your primary ones and pin them all to 1-2 cores to let them ramp up in parallel to your primary ones. This makes it *much* less cumbersome to scale up your Tor contribution when you need/want/can do that in the future). >>>> >>>> 4) Assume at least 1 GB of RAM per relay on modern CPUs + 32 GB additionally for OS, DNS, networking and to have some headroom for DoS attacks. This may sound high, especially considering the advice in the Tor documentation. But on modern CPUs (especially with a high clockspeed) guard relays can use a lot more than 512 MB of RAM, especially when they are getting attacked. Middle and exit relays require less RAM. >>>> >>>> Don't skimp out on system memory capacity. DDR4 RDIMMs with decent clockspeeds are so cheap nowadays. For reference: we ran our smaller Tor servers (16C(a)3.4Ghz) with 64 GB of RAM and had to upgrade it to 128 GB because during attacks RAM usage exceeded the amount available and killed processes. >>>> >>>> 5) If you have the IP space available, use one IPv4 address per relay and use all the good ports such as 443. If IP addresses are more scarce, it's also not bad to run 4 or 8 relays per IP address. Especially for middle and exit relays the port doesn't matter (much). Guard relays should ideally always run on a generally used (and generally unblocked) port. >>>> >>>>> 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? >>>> >>>> That greatly depends on the CPU and your configuration. I can offer 3 references based on real world examples. They all run a mix of guard/middle/exit relays. >>>> >>>> 1) Typical low core count (16+SMT) with higher clockspeed (3.4 Ghz) saturates a 10 Gb/s connection with ~18.5 physical cores + SMT. >>>> 2) Typical higher core count (64+SMT) with lower clockspeed (2.25 Ghz) saturates a 10 Gb/s connection with ~31.5 physical cores + SMT. >>>> 3) Typical energy efficient/low performance CPU with low core count (16) with very low clockspeed (2.0 Ghz) used often in networking appliances saturates a 10 Gb/s connection with ~75 physical cores (note: no SMT). >>>> >>>> The amount of IP addresses required also depends on multiple factors. But I'd say that you would need between the amount and double the amount of relays of the mentioned core+SMT count in order to saturate 10 Gb/s. This would be 37-74, 63-126 and 75-150 relays respectively. So between 5 and 19 IPv4 addresses would be required at minimum, depending on CPU performance level. >>>> >>>> RAM wise the more relays you run, the more RAM overhead you will have. So in general it's better to run less relays at a higher speed each than run many at a low clock speed. But since Tor scales so badly you need more Relays anyway so optimizing this isn't easy in practice. >>>> >>>>> 3) Same for a 20 Gbps connection, how many CPU cores, RAM and IPv4 addresses are required to saturate? >>>> >>>> Double the amount compared to 10 Gb/s. >>>> >>>> Good luck with your Tor adventure. And let us know your findings with achieving 10 Gb/s when you get there :-). >>>> >>>> Cheers, >>>> >>>> tornth >>>> >>>> Feb 3, 2025, 18:14 by tor-relays(a)lists.torproject.org: >>>> >>>>> 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](https://proton.me/mail/home)secure email.

4 12

family-ids
by boldsuck 24 Mar '25

24 Mar '25

Yay, family key's are live: Implemented-In: Tor 0.4.9.1-alpha, Arti 1.4.1 https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/321-ha… https://community.torproject.org/relay/setup/post-install/family-ids/ Copy the MyFamilyKey.secret_family_key file into the KeyDir of _every_ _one_ of your relay. Oooh, damn it. No ansible. Happy copy pasting happy-families ;-) -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

6 8

Guidance on optimal Tor relay server configurations
by usetor.wtf 23 Mar '25

23 Mar '25

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](https://proton.me/mail/home) secure email.

8 20

Fw: tor-relay transmitted packets
by borisich76＠protonmail.com 15 Mar '25

15 Mar '25

Hello. How can I limit the number of transmitted packets to 190,000? The VPS server constantly turns on the network limitation due to the large number of transmitted packets. ------- Forwarded Message ------- От: borisich76(a)protonmail.com <borisich76(a)protonmail.com> Дата: пятница, 14 марта 2025 г., 11:44 Тема: tor-relay transmitted packets Кому: tor-relays(a)lists.torproject.org <tor-relays(a)lists.torproject.org> > Hello. How can I limit the number of transmitted packets to 190,000? The VPS server constantly turns on the network limitation due to the large number of transmitted packets.

2 1

Last days to join our WebTunnel bridges campaign!
by gus 07 Mar '25

07 Mar '25

Hello, We've reached our goal of 200 new WebTunnel bridges! But more bridges is always better, and there's still time to join the campaign and help Tor users bypass censorship. As a thank you, you'll also get a Tor t-shirt! Read our blog post & bridge campaign rules for participation: https://blog.torproject.org/call-for-webtunnel-bridges/ The campaign officially ends on March 10, 2025 at 23:59 UTC. :) Gus -- The Tor Project Community Team Lead

2 1

TorVault: Storing Relay Ed25519 Identity Keys on a Yubikey
by Clara Engler 26 Feb '25

26 Feb '25

Hi tor-relays@, I am Clara and work for The Tor Project, Inc. as part of the network team. As some of you may know, Tor supports a feature called "OfflineMasterKey"[1], which allows you to store the long-term Ed25519 identity key of a relay on a cold device, from which you will generate from time to time a medium-term signing key alongside a certificate signed by the identity key. While moving my server and re-installing my relay, I thought about using this feature, the recommended approach of using an offline computer seemed rather burdensome to me though. This made me think about how we could solve that issue by storing the Ed25519 identity key on a Yubikey and let it sign the relevant certificates. After a week, I came up with a tool called: TorVault[2]. It allows you to use the PIV module on your Yubikey for storing the identity key and signing medium-term certificates. The application itself handles the generation and signing of the medium-term key. The usage of the program is interactive and as follows: ```sh $ go build -o torvault cmd/torvault/*.go $ ./torvault 1. Yubico YubiKey OTP+FIDO+CCID choose a smart card: 1 choose a slot [9c]: choose an expiration date [2025-05-24]: choose a path for the identity public key [ed25519_master_id_public_key]: choose a path for the signing secret key [ed25519_signing_secret_key]: choose a path for the signing cert [ed25519_signing_cert]: ================================ smart card: Yubico YubiKey OTP+FIDO+CCID 31892185 slot: 0x9c public key: EVLS6NL8wastoApvJUPDzYxJ7FAdOx22RFpqtlzFGpA expiration date: Sat, 24 May 2025 00:00:00 UTC (1748044800) identity public key path: ed25519_master_id_public_key signing secret key path: ed25519_signing_secret_key signing cert path: ed25519_signing_cert ================================ is this correct? (y/n): y enter PIN: success! 🧅 $ systemctl stop tor $ cp ed25519_* /path/to/your/relay/keys $ systemctl start tor ``` In theory, one Yubikey can store up to 17 relay identity keys, before reaching its limit. Unfortunately, Ed25519 support is rather new in Yubikeys, so you will probably need a newer one (I developed it with firmware 5.7). Another thing you have to keep in mind is, that it is *not possible* to move an existing Ed25519 identity key to a Yubikey. This is a historical limitation of the way on how ctor stores Ed25519 keys. This means, you can only secure new relays with this feature, but not existing ones. Please also keep in mind that this feature requires you to keep an eye on the expiry date, as an expired certificate will render the relay to be unusable, which will in the long run result in its loss of the guard and other flags. I am also already using this in production for my own relay. Feedback is gladly welcome. Thank You Clara [1]: https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorRelaySecurity/Offl… [2]: https://gitlab.torproject.org/cve/torvault

3 3

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

26 Feb '25

Excellent information, especially the real world scenarios! Exactly what I was looking for! Summary from your email - did I miss anything? To saturate 10 Gbps connection: 1) IPv4 Allocation: Use between 5 and 20. Much lower than 256 in a /24! 2) Tor Relay Count: Run roughly ~40 to ~150, depending on CPU clock speed, i.e. faster clock, fewer relays needed.3) CPU Utilization: 1 Tor relay per physical core preferred but okay to scale to 1 Tor relay per threads/SMT as well, up to 2x Tor relays per core/thread 4) RAM requirements: Maintain a 4:1 RAM-to-core/relay ratio (4GB per core/relay), including extra 32GB per server to cover DoS, OS, networking, etc. overheads In general, some ideals but not required: CPU clock speed: Higher CPU clock speed, better relay performance RAM: Fewer relays, lower RAM requirements RAM: Add ~32GB to overall RAM capacity sizing for OS, DNS, networking, DoS, etc. IPv4: One IPv4 per relay with common traffic ports Scaling: Start with 1 Tor relay per physical core, then add 1 Tor relay per thread/SMT and stop at 2 Tor relays per each core / thread. What are the primary factors that justify running up to two Tor relays per physical core (leveraging SMT) versus a one-to-one mapping? Ex: 37-74 for ~18.5 physical + SMT and 63-126 for ~31.5 physical + SMT. Is one-to-one mapping of Tor relay to core/thread the most compute- and system-efficient approach? Are the clock speeds you listed base or turbo numbers (3.4, 2.25 and 2.0 Ghz)? I'm assuming base. Not sure if anybody has data on how these impact Tor relays? From your real world scenario #2 and advice for the "fastest/best hardware", would this type of server work well for a $20k budget? A single-socket Xeon 6980P (128 physical cores, 256 threads, base clock 2.0 GHz, turbo up to 3.9 GHz) with 1024GB DDR5 (maintaining a 4:1 ratio) and an AIOM Mellanox NIC be optimal? Assuming one relay per core/thread, would this setup be capable of saturating 40 Gbps, given that 10 Gbps typically saturated with ~31.5 physical cores + ~31.5 SMT threads at 2 Ghz and thus 256 relays vs ~63 relays translates roughly to 4×10 Gbps = 40 Gbps? For those curious, according to ChatGPT o3-mini-high deep research: 1) 20% cap on bandwidth contributions for exit relays is roughly 50+ Gbit/s for the largest operators. 2) 10% of Tor's consensus weight in terms of bandwidth for 2025 is roughly 90-95 Gbps of sustained bandwidth. In 2022, it would have been ~68 Gbps. I don't plan to have this issue any time soon, but good to be aware! Screenshots of the lengthy responses below and attached. [image.png] [image.png] [image.png] [image.png] Sent with[Proton Mail](https://proton.me/mail/home)secure email. On Tuesday, February 18th, 2025 at 2:23 PM, mail(a)nothingtohide.nl <mail(a)nothingtohide.nl> wrote: > Hi, > > Many people already replied, but here are my (late) two cents. > >> 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? > > "Optimal" depends on your preferences and goals. Some examples: > > - IP address efficiency: run 8 relays per IPv4 address. > - Use the best ports: 256 relays (443) or 512 relays (443+80). > - Lowest kernel/system congestion: 1 locked relay per core/SMT thread combination, ideally on high clocked CPUs. > - Easiest to manage: as few relays as possible. > - Memory efficiency: only run middle relays on very high clocked CPUs (4-5 Ghz). > - Cost efficiency: run many relays on 1-2 generations old Epyc CPUs with a high core count (64 or more). > > There are always constraints. The hardware/CPU/memory and bandwidth/routing capability available to you are probably not infinite. Also the Tor Project maximizes bandwidth contributions to 20% and 10% for exit relay and overall consensus weight respectively. > > With 256 IP addresses on modern hardware, it will be very hard to not run in to one of these limitations long before you can make it 'optimal'. Hardware wise, one modern/current gen high performance server only running exit relays will easily push enough Tor traffic to do more than half of the total exit bandwidth of the Tor network. > > My advice would be: > 1) Get the fastest/best hardware with current-ish generation CPU IPC capabilities you can get within your budget. To lower complexity with keeping congestion in control, one socket is easier to deal with than a dual socket system. > > (tip for NIC: if your switch/router has 10 Gb/s or 25 Gb/s ports, get some of the older Mellanox cards. They are very stable (more so than their Intel counterparts in my experience) and extremely affordable nowadays because of all the organizations that throw away their digital sovereignty and privacy of their employees/users to move to the cloud). > > 3) Start with 1 Tor relay per physical core (ignoring SMT). When the Tor relays have ramped up (this takes 2-3 months for guard relays) and there still is considerable headroom on the CPU (Tor runs extremely poorly at scale sadly, so this would be my expectation) then move to 1 Tor relay per thread (SMT included). > > (tip: already run/'train' some Tor relays with a very limited bandwidth (2 MB/s or something) parallel to your primary ones and pin them all to 1-2 cores to let them ramp up in parallel to your primary ones. This makes it *much* less cumbersome to scale up your Tor contribution when you need/want/can do that in the future). > > 4) Assume at least 1 GB of RAM per relay on modern CPUs + 32 GB additionally for OS, DNS, networking and to have some headroom for DoS attacks. This may sound high, especially considering the advice in the Tor documentation. But on modern CPUs (especially with a high clockspeed) guard relays can use a lot more than 512 MB of RAM, especially when they are getting attacked. Middle and exit relays require less RAM. > > Don't skimp out on system memory capacity. DDR4 RDIMMs with decent clockspeeds are so cheap nowadays. For reference: we ran our smaller Tor servers (16C(a)3.4Ghz) with 64 GB of RAM and had to upgrade it to 128 GB because during attacks RAM usage exceeded the amount available and killed processes. > > 5) If you have the IP space available, use one IPv4 address per relay and use all the good ports such as 443. If IP addresses are more scarce, it's also not bad to run 4 or 8 relays per IP address. Especially for middle and exit relays the port doesn't matter (much). Guard relays should ideally always run on a generally used (and generally unblocked) port. > >> 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? > > That greatly depends on the CPU and your configuration. I can offer 3 references based on real world examples. They all run a mix of guard/middle/exit relays. > > 1) Typical low core count (16+SMT) with higher clockspeed (3.4 Ghz) saturates a 10 Gb/s connection with ~18.5 physical cores + SMT. > 2) Typical higher core count (64+SMT) with lower clockspeed (2.25 Ghz) saturates a 10 Gb/s connection with ~31.5 physical cores + SMT. > 3) Typical energy efficient/low performance CPU with low core count (16) with very low clockspeed (2.0 Ghz) used often in networking appliances saturates a 10 Gb/s connection with ~75 physical cores (note: no SMT). > > The amount of IP addresses required also depends on multiple factors. But I'd say that you would need between the amount and double the amount of relays of the mentioned core+SMT count in order to saturate 10 Gb/s. This would be 37-74, 63-126 and 75-150 relays respectively. So between 5 and 19 IPv4 addresses would be required at minimum, depending on CPU performance level. > > RAM wise the more relays you run, the more RAM overhead you will have. So in general it's better to run less relays at a higher speed each than run many at a low clock speed. But since Tor scales so badly you need more Relays anyway so optimizing this isn't easy in practice. > >> 3) Same for a 20 Gbps connection, how many CPU cores, RAM and IPv4 addresses are required to saturate? > > Double the amount compared to 10 Gb/s. > > Good luck with your Tor adventure. And let us know your findings with achieving 10 Gb/s when you get there :-). > > Cheers, > > tornth > > Feb 3, 2025, 18:14 by tor-relays(a)lists.torproject.org: > >> 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](https://proton.me/mail/home)secure email.

3 3

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 22 Feb '25

22 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 14 Feb '25

14 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