Good evening, Apologies as this is likely the incorrect way to do things. I'm not fantastic with mailing lists. I saw on tor forum that some people were getting these netscan emails from hetzner. https://forum.torproject.org/t/tor-relays-abuse-report-from-relays-in-family... I got my first a few months ago and I just got my second one about an hour ago. Both times it was to the 1st amendment group IP addresses. Last time I just clicked their check button and it passed and then I gave reasoning in the next link. For some reason it doesn't seem to be liking when I click the first link this time and keeps saying not solved. I don't know what my best course of action is. I've gotten 2 reports for hetzner for a guard and 0 for netcup for an exit relay :( I saw in the forum post (which is to a clone of the mailing list) about temporarily blocking tor but that feels a bit deceptive so I don't really want to go down that route. The best thing though it may be a long process as there may be a potential harm to how circuits are built negatively affecting user anonymity is for the tor program to operate in a manner so that it doesn't look like a netscan to some sensitive providers like hetzner even though we know it isn't a netscan anyways. If this issue keeps coming up with hetzner I may look at not hosting a tor relay with them because I have a lot of stuff on this server like my personal website and project mirrors and such and don't want those to be negatively affected due to a unjust IP ban by hetzner for running a tor relay. Any advice? Kind regards, Diyar Ciftci
Unfortunately, Hetzner is raising false positives. Not sure anybody has reached out to Hetzner in attempts to correct their systemtic issue? Operating the largest group of Guard relays on Tor at the moment, I receive emails from Tor operators wondering why Hetzner is reporting abusive behavior. I have not heard of any other provider sending these types of abuse emails that Hetzner is. Picking a provider who is more friendly to Tor traffic, including not sending false positive abuse emails, and has fewer operating Tor relays to increase diversity is likely a good outcome. Most agree that blocking legitimate Tor relay traffic is not an ideal solution. Most detailed analysis I've seen has been here: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/105 Let us know all know how it sorts out and how we can help. Hope you keep running Tor relays! On Sunday, December 28th, 2025 at 1:36 PM, Diyar Ciftci via tor-relays <tor-relays@lists.torproject.org> wrote:
Good evening,
Apologies as this is likely the incorrect way to do things. I'm not fantastic with mailing lists. I saw on tor forum that some people were getting these netscan emails from hetzner. https://forum.torproject.org/t/tor-relays-abuse-report-from-relays-in-family...
I got my first a few months ago and I just got my second one about an hour ago. Both times it was to the 1st amendment group IP addresses. Last time I just clicked their check button and it passed and then I gave reasoning in the next link. For some reason it doesn't seem to be liking when I click the first link this time and keeps saying not solved. I don't know what my best course of action is. I've gotten 2 reports for hetzner for a guard and 0 for netcup for an exit relay :( I saw in the forum post (which is to a clone of the mailing list) about temporarily blocking tor but that feels a bit deceptive so I don't really want to go down that route. The best thing though it may be a long process as there may be a potential harm to how circuits are built negatively affecting user anonymity is for the tor program to operate in a manner so that it doesn't look like a netscan to some sensitive providers like hetzner even though we know it isn't a netscan anyways.
If this issue keeps coming up with hetzner I may look at not hosting a tor relay with them because I have a lot of stuff on this server like my personal website and project mirrors and such and don't want those to be negatively affected due to a unjust IP ban by hetzner for running a tor relay.
Any advice?
Kind regards, Diyar Ciftci
Hello, It's worth noting that these abuse reports are not a Hetzner issue. They, just like all major operators have a legitimate reason to keep monitoring their network. This is also not just about all Tor operators. These abuse reports are issued as a result of the operation of a single Tor operator. All the abuse reports I receive (and frequently) are for 64.65.62.0/24 and less frequently from 64.65.1.0/24 and 96.9.98.0/24 all of which are served and operated by a single Tor operator. If out of over 9400 Tor relays in operation, only the ones operated by a single operator cause these reports, it is safe to assume it's not necessarily Tor related but operator related. There are major operators operating great number of IP addresses and I can safely say I have never received an abuse report regarding any of those. My guess is that each of these blocks of IPs are served on a single server. Each time the server is rebooted the network loses a whole block of Tor relays -- and not so gracefully -- and due to the number of those servers, Each operator that's connected to those IP addresses keep sending packets to port 443 (Or Port) in an attempt to discover what happened and try to reconnect. Those multiple attempts on the whole block of IP addresses justifiably are flagged as port scans of a whole block. Perhaps shutting down each relay individually and gracefully before a reboot could allow the network to adjust to the loss gradually? The most recent abuse report I received was for 64.65.62.0/24 about 3 days ago and looking at those relays you can tell the server was rebooted at that time. Unfortunately because I was away and didn't have time to respond to the report, one of my IP addresses was blocked and my relay become inoperable. It is now unblocked (took about a few minutes to get it unblocked) and all is well but this whole thing is becoming quite annoying and I can't blame Hetzner for that and I can certainly not ask them to change their whole security practice pretending that this a Tor issue when it's something that's caused by a single operator. As for how to deal with it, simply click on the retest link in the abuse report. The ticket will be closed and they'll ask for a statement from you and you can copy and paste the same response over and over again and you'll be fine. Cheers On 12/24/2025 6:39 PM, Diyar Ciftci via tor-relays wrote:
Good evening,
Apologies as this is likely the incorrect way to do things. I'm not fantastic with mailing lists. I saw on tor forum that some people were getting these netscan emails from hetzner. https://forum.torproject.org/t/tor-relays-abuse-report-from-relays-in-family...
I got my first a few months ago and I just got my second one about an hour ago. Both times it was to the 1st amendment group IP addresses. Last time I just clicked their check button and it passed and then I gave reasoning in the next link. For some reason it doesn't seem to be liking when I click the first link this time and keeps saying not solved. I don't know what my best course of action is. I've gotten 2 reports for hetzner for a guard and 0 for netcup for an exit relay :( I saw in the forum post (which is to a clone of the mailing list) about temporarily blocking tor but that feels a bit deceptive so I don't really want to go down that route. The best thing though it may be a long process as there may be a potential harm to how circuits are built negatively affecting user anonymity is for the tor program to operate in a manner so that it doesn't look like a netscan to some sensitive providers like hetzner even though we know it isn't a netscan anyways.
If this issue keeps coming up with hetzner I may look at not hosting a tor relay with them because I have a lot of stuff on this server like my personal website and project mirrors and such and don't want those to be negatively affected due to a unjust IP ban by hetzner for running a tor relay.
Any advice?
Kind regards, Diyar Ciftci
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Repeating email threads - here's the previous one covering the same topics: https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torpr... The internet and Tor operate with an understanding any relay at any point in time can be unreachable. Thousands of hosting providers for Tor relays and only Hetzner sends false abuse reports. 3 days ago the datacenter had an emergency maintenance power event, the day before Christmas in a country that celebrates Christmas, and took all the servers in their rack offline with no notice. We had the opportunity to spend hours on Christmas day getting the server back online because, as it turns out, the technician accidentally "bumped" the NIC and disconnected our server as well, all while handling their original emergency maintenance power event. For past events, we've seen upstream switches go offline dropping BGP routes and Ubuntu 24.04 default installs with only Tor running suddenly crash. On Sunday, December 28th, 2025 at 10:30 PM, Chris Enkidu-6 via tor-relays <tor-relays@lists.torproject.org> wrote:
Hello,
It's worth noting that these abuse reports are not a Hetzner issue. They, just like all major operators have a legitimate reason to keep monitoring their network. This is also not just about all Tor operators. These abuse reports are issued as a result of the operation of a single Tor operator.
All the abuse reports I receive (and frequently) are for 64.65.62.0/24 and less frequently from 64.65.1.0/24 and 96.9.98.0/24 all of which are served and operated by a single Tor operator.
If out of over 9400 Tor relays in operation, only the ones operated by a single operator cause these reports, it is safe to assume it's not necessarily Tor related but operator related. There are major operators operating great number of IP addresses and I can safely say I have never received an abuse report regarding any of those.
My guess is that each of these blocks of IPs are served on a single server. Each time the server is rebooted the network loses a whole block of Tor relays -- and not so gracefully -- and due to the number of those servers, Each operator that's connected to those IP addresses keep sending packets to port 443 (Or Port) in an attempt to discover what happened and try to reconnect. Those multiple attempts on the whole block of IP addresses justifiably are flagged as port scans of a whole block. Perhaps shutting down each relay individually and gracefully before a reboot could allow the network to adjust to the loss gradually?
The most recent abuse report I received was for 64.65.62.0/24 about 3 days ago and looking at those relays you can tell the server was rebooted at that time. Unfortunately because I was away and didn't have time to respond to the report, one of my IP addresses was blocked and my relay become inoperable. It is now unblocked (took about a few minutes to get it unblocked) and all is well but this whole thing is becoming quite annoying and I can't blame Hetzner for that and I can certainly not ask them to change their whole security practice pretending that this a Tor issue when it's something that's caused by a single operator.
As for how to deal with it, simply click on the retest link in the abuse report. The ticket will be closed and they'll ask for a statement from you and you can copy and paste the same response over and over again and you'll be fine.
Cheers
On 12/24/2025 6:39 PM, Diyar Ciftci via tor-relays wrote:
Good evening,
Apologies as this is likely the incorrect way to do things. I'm not fantastic with mailing lists. I saw on tor forum that some people were getting these netscan emails from hetzner. https://forum.torproject.org/t/tor-relays-abuse-report-from-relays-in-family...
I got my first a few months ago and I just got my second one about an hour ago. Both times it was to the 1st amendment group IP addresses. Last time I just clicked their check button and it passed and then I gave reasoning in the next link. For some reason it doesn't seem to be liking when I click the first link this time and keeps saying not solved. I don't know what my best course of action is. I've gotten 2 reports for hetzner for a guard and 0 for netcup for an exit relay :( I saw in the forum post (which is to a clone of the mailing list) about temporarily blocking tor but that feels a bit deceptive so I don't really want to go down that route. The best thing though it may be a long process as there may be a potential harm to how circuits are built negatively affecting user anonymity is for the tor program to operate in a manner so that it doesn't look like a netscan to some sensitive providers like hetzner even though we know it isn't a netscan anyways.
If this issue keeps coming up with hetzner I may look at not hosting a tor relay with them because I have a lot of stuff on this server like my personal website and project mirrors and such and don't want those to be negatively affected due to a unjust IP ban by hetzner for running a tor relay.
Any advice?
Kind regards, Diyar Ciftci
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
That's understandable and stuff happens. I too live in a country that celebrates Christmas which is why I didn't respond to the abuse report and my IP was blocked. That being said we should avoid making unsubstantiated claims. saying:
These emails suggest Hetzner monitors flow-level data (e.g., NetFlow), which raises concerns about potential exposure of >Tor traffic characteristics.
sounds funny. Any Network admin worth their salt managing a large network will know they should protect the network from port scanners otherwise any schmuck can rent a VPS and start port scanning other networks, so based on your claim all competent network admins should be a danger to Tor Network. As for your other claim, I decided to do a relay search. Out of over 9400 Tor relays 407 of them are operated out of Hetzner (As24940). You as a single Tor operator control around 750 relays give or take. Which one would you say is a bigger security risk? On 12/29/2025 1:56 AM, Tor at 1AEO wrote:
Repeating email threads - here's the previous one covering the same topics: https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torpr...
The internet and Tor operate with an understanding any relay at any point in time can be unreachable.
Thousands of hosting providers for Tor relays and only Hetzner sends false abuse reports.
3 days ago the datacenter had an emergency maintenance power event, the day before Christmas in a country that celebrates Christmas, and took all the servers in their rack offline with no notice. We had the opportunity to spend hours on Christmas day getting the server back online because, as it turns out, the technician accidentally "bumped" the NIC and disconnected our server as well, all while handling their original emergency maintenance power event.
For past events, we've seen upstream switches go offline dropping BGP routes and Ubuntu 24.04 default installs with only Tor running suddenly crash. On Sunday, December 28th, 2025 at 10:30 PM, Chris Enkidu-6 via tor-relays <tor-relays@lists.torproject.org> wrote:
Hello,
It's worth noting that these abuse reports are not a Hetzner issue. They, just like all major operators have a legitimate reason to keep monitoring their network. This is also not just about all Tor operators. These abuse reports are issued as a result of the operation of a single Tor operator.
All the abuse reports I receive (and frequently) are for 64.65.62.0/24 and less frequently from 64.65.1.0/24 and 96.9.98.0/24 all of which are served and operated by a single Tor operator.
If out of over 9400 Tor relays in operation, only the ones operated by a single operator cause these reports, it is safe to assume it's not necessarily Tor related but operator related. There are major operators operating great number of IP addresses and I can safely say I have never received an abuse report regarding any of those.
My guess is that each of these blocks of IPs are served on a single server. Each time the server is rebooted the network loses a whole block of Tor relays -- and not so gracefully -- and due to the number of those servers, Each operator that's connected to those IP addresses keep sending packets to port 443 (Or Port) in an attempt to discover what happened and try to reconnect. Those multiple attempts on the whole block of IP addresses justifiably are flagged as port scans of a whole block. Perhaps shutting down each relay individually and gracefully before a reboot could allow the network to adjust to the loss gradually?
The most recent abuse report I received was for 64.65.62.0/24 about 3 days ago and looking at those relays you can tell the server was rebooted at that time. Unfortunately because I was away and didn't have time to respond to the report, one of my IP addresses was blocked and my relay become inoperable. It is now unblocked (took about a few minutes to get it unblocked) and all is well but this whole thing is becoming quite annoying and I can't blame Hetzner for that and I can certainly not ask them to change their whole security practice pretending that this a Tor issue when it's something that's caused by a single operator.
As for how to deal with it, simply click on the retest link in the abuse report. The ticket will be closed and they'll ask for a statement from you and you can copy and paste the same response over and over again and you'll be fine.
Cheers
On 12/24/2025 6:39 PM, Diyar Ciftci via tor-relays wrote:
Good evening,
Apologies as this is likely the incorrect way to do things. I'm not fantastic with mailing lists. I saw on tor forum that some people were getting these netscan emails from hetzner. https://forum.torproject.org/t/tor-relays-abuse-report-from-relays-in-family...
I got my first a few months ago and I just got my second one about an hour ago. Both times it was to the 1st amendment group IP addresses. Last time I just clicked their check button and it passed and then I gave reasoning in the next link. For some reason it doesn't seem to be liking when I click the first link this time and keeps saying not solved. I don't know what my best course of action is. I've gotten 2 reports for hetzner for a guard and 0 for netcup for an exit relay :( I saw in the forum post (which is to a clone of the mailing list) about temporarily blocking tor but that feels a bit deceptive so I don't really want to go down that route. The best thing though it may be a long process as there may be a potential harm to how circuits are built negatively affecting user anonymity is for the tor program to operate in a manner so that it doesn't look like a netscan to some sensitive providers like hetzner even though we know it isn't a netscan anyways.
If this issue keeps coming up with hetzner I may look at not hosting a tor relay with them because I have a lot of stuff on this server like my personal website and project mirrors and such and don't want those to be negatively affected due to a unjust IP ban by hetzner for running a tor relay.
Any advice?
Kind regards, Diyar Ciftci
_______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Chris Enkidu-6 wrote:
As for your other claim, I decided to do a relay search. Out of over 9400 Tor relays 407 of them are operated out of Hetzner (As24940). You as a single Tor operator control around 750 relays give or take. Which one would you say is a bigger security risk?
To be fair, a relay operator running hundreds of relays is less likely to be a risk because they are less likely to be monitoring or exporting traffic flows. That's not to say that monitoring traffic flows is bad, but if someone came up to a relay operator and said "hey, send us highly detailed traffic statistics and metadata and some money and we'll alert you if we detect anything suspicious", the operator is more likely to report the offer here than to sign a contract and call it good business sense. Ability to correlate traffic != willingness to engage in activities that would make traffic correlation feasible. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmlSPxoACgkQBh18rEKN 1gtyTw/+McpObgvN1Zf4PYqMLOaG51LhCjdejz+Urs+ndoDEepVsNHNr8IM4em8A 0GvT/Ig9H5Hywmnb6X8GYXOCmo13Jfn76KARzbFQA6NswSzgEeYpbeug5g/PV5jx I1bwSu67+WwDd5yT1FbcpyrfZoD0/vZtv3uhXrmEGts8PHkt+6dOwaYQgW/+GO9u /VmCtcFCy2BUID4/dHXuEFhGUOXyzxN1OW2Hs+/739jUU7gHZ1wyX0fWj3yZYpRf WePiinVQez5zvRDGh6KyHq4OOV47oc1/hUT8BXZF2FNSrHZHO28cgPB+TBrQk5Q7 40RXP/WdwT6kS92l/zi0INM+ZQDH9NPJSXpRR6CnUueoILyVO/gHninI8oRzWRtG S+T8HPjUzRbhgJ2fUBlaVXNu8SUwA518Z6+cLNAXfyF4GsABlWJsM9bRSdKRR+v7 pkWR/dT/f/Jir2CzThKoetLM/3PXXE6nU+TuZZK6QTVulQIS5to3qGnXrqsEfHhB M76OHjNKeXs0jmdDd9FEC4hQDLF4S4ix1fi74NIt3+ZEMENB5OrL4cqrx24uo5gp 5f63ow4wkHNVFjoR9pAdLJMyiJ78xbQ6lQDNS7PHPq7QXbrvM5ohN4KEChkvdT2I 1tbsiWCqfkaYjJlGH3jb4WC50gV/JO68maC7EliJMkZZab/AdAw= =3XBS -----END PGP SIGNATURE-----
The concern is how flow-level telemetry is interpreted and what it can expose when applied to Tor traffic. NetFlow-style data is not neutral from a privacy perspective. While it doesn’t include payloads, it does expose timing, fan-out, retry behavior, and correlation patterns. When retained or disclosed — intentionally or otherwise — that metadata can reveal Tor traffic characteristics and failure-mode behavior that would not exist at all if such flow data were not collected. So the issue isn’t that NetFlow exists, but that: It enables misclassification of normal Tor reconnection behavior during outages, and It creates an additional metadata surface that can be analyzed or requested. For context, we don't log traffic and don't run NetFlow. Relay count alone is a limited indicator of concentration risk. Concentration risk is modeled via families (looking forward to "Happy Families"!) and weighting, and the Network Health team actively vets large operators. Best, Tor at 1AEO On Monday, December 29th, 2025 at 12:43 AM, forest-relay-contact--- via tor-relays <tor-relays@lists.torproject.org> wrote:
Hello.
Chris Enkidu-6 wrote:
As for your other claim, I decided to do a relay search. Out of over 9400 Tor relays 407 of them are operated out of Hetzner (As24940). You as a single Tor operator control around 750 relays give or take. Which one would you say is a bigger security risk?
To be fair, a relay operator running hundreds of relays is less likely to be a risk because they are less likely to be monitoring or exporting traffic flows. That's not to say that monitoring traffic flows is bad, but if someone came up to a relay operator and said "hey, send us highly detailed traffic statistics and metadata and some money and we'll alert you if we detect anything suspicious", the operator is more likely to report the offer here than to sign a contract and call it good business sense.
Ability to correlate traffic != willingness to engage in activities that would make traffic correlation feasible.
Regards, forest
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. Tor at 1AEO wrote:
NetFlow-style data is not neutral from a privacy perspective. While it doesn’t include payloads, it does expose timing, fan-out, retry behavior, and correlation patterns. When retained or disclosed — intentionally or otherwise — that metadata can reveal Tor traffic characteristics and failure-mode behavior that would not exist at all if such flow data were not collected.
Most uses of NetFlow are not "monitor timing on all packets" but things like "give statistics on one out of every N packets". When N is large enough, it's not practical to use it for traffic correlation attacks in that situation. Not that everyone runs it in sampled mode, of course... Not to mention, there's no reason to suggest that Hetzner got any of that information from NetFlow itself. They could have simply gotten it from a set of NetFilter (e.g. iptables) rules running on the host node that log whenever certain behavior is detected. If anything, that would be more plausible as it does not require exporting traffic when the host node itself is perfectly capable of doing analysis on its own. I agree that widespread use of NetFlow (and cflowd and all that jazz) is an issue, but I disagree that Hetzner's ability to detect certain types of traffic behavior indicates use of NetFlow or any similar technology. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmlSSyYACgkQBh18rEKN 1gtiBQ//VinMxjLsN30n+tZDLPPbF/qerLSlK3NwzXy8pk7vXkLyuPLIzb2K9PVm V39VQ/zz2urlg5HYsBd0lScdKCWSNDsl+VdMx0cMvDfsYlhA4FHSZUJF8E6LQDq2 xmAqDZDLbQnypkiD8NEOXggqpgsCJbc6pnMJLiOBGqQ0vevdOX250uVl1HG7jTHa QiehgKfHAoZ/PlefdoOgjACGtV3iHqBW9t2ZTljetGWEF8Bon7aU0wJgX8IqK1Lt xOoknYFnoNHTXYDcuK1Ze5JqiYFWjQ9dYfsAhhCz1F9MRjk4w8FUGagOQiCieX3L nkUt4LAGkdAerUYN+2kk34WEs2pnTCWAeGztIG80GB2lq0jaZQGYU1Wu9JzKSQON o4R0sU9TMZjCqG6ZvuS1OlXbooO3xhgJAZsAw+zXZNfhY+iuMS3QoiCa/2wP7AwM 6CsPrnqDKGyHxyGdYR/QJ+3CDAYVtf9eR4bOTWBKHoMBpNNgGcIDr0EVtIvOySt4 ckD75LrfuZFkSW6oeOWKPi2YS2rzFlpnU0XDEkMAzaGEC0CTUGO82L5Fv/G4gPh/ MqEjM2NOZmtl3rcren376taUyR/N5Qi5wWi3nhPBNpXbHGcBdOaclEShgwEUOp+R uOsyChddK25OO831patX5rMFJwwgli0R1/1D2nFkpnyfgDPbEZw= =NIkP -----END PGP SIGNATURE-----
Hi! Got the same email. The problem is that they only have Peering and Transit in USA not in Europe. The moment the problem occurred the only Upstream they had was B2 Net Solutions Inc. Hetzner monitors for netscans and the rule triggers because there is no BGP route to those IPs on their routers since they are only reachable in the USA. I just blocked the ranges to prevent the relay from being shut down. ufw deny out to 64.65.0.0/22 ufw deny out to 64.65.62.0/23 ufw deny out to 96.9.98.0/24 ufw deny out to 216.181.20.0/24 I also reported it to bad-relays but since this is only a problem on Hetzner I doubt this is a problem for the network. Cheers! Tobias
On 25. Dec 2025, at 00:39, Diyar Ciftci via tor-relays <tor-relays@lists.torproject.org> wrote:
Good evening,
Apologies as this is likely the incorrect way to do things. I'm not fantastic with mailing lists. I saw on tor forum that some people were getting these netscan emails from hetzner. https://forum.torproject.org/t/tor-relays-abuse-report-from-relays-in-family...
I got my first a few months ago and I just got my second one about an hour ago. Both times it was to the 1st amendment group IP addresses. Last time I just clicked their check button and it passed and then I gave reasoning in the next link. For some reason it doesn't seem to be liking when I click the first link this time and keeps saying not solved. I don't know what my best course of action is. I've gotten 2 reports for hetzner for a guard and 0 for netcup for an exit relay :( I saw in the forum post (which is to a clone of the mailing list) about temporarily blocking tor but that feels a bit deceptive so I don't really want to go down that route. The best thing though it may be a long process as there may be a potential harm to how circuits are built negatively affecting user anonymity is for the tor program to operate in a manner so that it doesn't look like a netscan to some sensitive providers like hetzner even though we know it isn't a netscan anyways.
If this issue keeps coming up with hetzner I may look at not hosting a tor relay with them because I have a lot of stuff on this server like my personal website and project mirrors and such and don't want those to be negatively affected due to a unjust IP ban by hetzner for running a tor relay.
Any advice?
Kind regards, Diyar Ciftci _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
On 29.12.2025 03:24 Tobias Sachs via tor-relays wrote:
I just blocked the ranges to prevent the relay from being shut down.
ufw deny out to 64.65.0.0/22 ufw deny out to 64.65.62.0/23 ufw deny out to 96.9.98.0/24 ufw deny out to 216.181.20.0/24
I can ping 64.65.0.0 via the publicly available RIPE/GLOBALPLING probes. Are you sure this is a persistent routing issue?
No, do not expect a persistent routing issues to the 4 listed /24s. Two temporary provider caused outages, specifically, emergency maintenance before Christmas, and an outage before New Year’s; root cause is still under investigation, with only a physical link loss on provider equipment confirmed so far. On Monday, December 29th, 2025 at 3:17 AM, Marco Moock via tor-relays <tor-relays@lists.torproject.org> wrote:
On 29.12.2025 03:24 Tobias Sachs via tor-relays wrote:
I just blocked the ranges to prevent the relay from being shut down.
ufw deny out to 64.65.0.0/22 ufw deny out to 64.65.62.0/23 ufw deny out to 96.9.98.0/24 ufw deny out to 216.181.20.0/24
I can ping 64.65.0.0 via the publicly available RIPE/GLOBALPLING probes.
Are you sure this is a persistent routing issue? _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
participants (6)
-
Chris Enkidu-6 -
Diyar Ciftci -
forest-relay-contact＠cryptolab.net -
Marco Moock -
Tobias Sachs -
Tor at 1AEO