(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp?
thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans…
body starts with : “We have indications that there was an attack from your server. Please take all necessary measures to avoid this in the future and to solve the issue.”
I get them from time to time and the address always is for major Tor operators who host numerous Tor servers on the whole block such as 64.65.1.0/24 , 64.65.62.0/24 , 96.9.98.0/24 , etc… These are not related to the operators filing an abuse report. These are automatically generated reports based on the behavior of your server and they are generally wrong because their automated system is simply too sensitive and comes up with a lot of false positive.
Simply block outgoing packets to the /24 block at the firewall level. Then click on the link they sent you to retest. It will be automatically tested and comes up clear. Then send them a message using the second link and tell them you blocked it at the firewall level and they’ll close the ticket.
You can later remove the firewall rule and get on with you life. I’ve given up arguing with them about how and why they’re wrong. They even once admitted that it was a false report and told me not to bother. In fact I just got another abuse report for an IP that’s already blocked at the firewall level. They are telling me that my server is scanning port 74 of a range of IPs when outgoing port 74 is explicitly blocked on my server and it simply can’t go out.
···
On 10/15/2025 2:02 AM, Dimitris T. via tor-relays wrote:
Hey all,
got an abuse report today from Hetzner concerning one middle relay we’re running there.
(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
anyone else got similar abuse reports? or someone here from this relay family, that can clear things out with this isp?
thinking of replying to hetzner accordingly, let them know (with metrics link), that these are tor relays with 443 port open/accepting our middle relay connections, not port scans…
best,
d.
_______________________________________________
tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org)
To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)
I received the same abuse report from Hetzner. I’m running a relay as well. Interestingly, I get an abuse report about a port scan every few months, but the IPs in question always belong to the Tor network. In the past, this explanation has always been sufficient for them to close the report.
You certainly did miss the important part. You may want to read it again.
···
On 10/15/2025 5:04 AM, R0cketCloud TOR Team wrote:
Chris, this is horrible advice. You're effectively promoting to become a bad node by knowingly and wilfully prohibiting circuits to certain exits.
Run this thought a bit further, eventually you will have banned all exits (and likely some middles too) and your node is effectively useless.
I sincerely hope I missed a /s somewhere here.
/r0cket
On Wednesday, October 15, 2025 08:05 UTC, Chris Enkidu-6 via tor-relays [<tor-relays@lists.torproject.org>](mailto:tor-relays@lists.torproject.org) wrote:
I get them from time to time and the address always is for major Tor
operators who host numerous Tor servers on the whole block such as
64.65.1.0/24 , 64.65.62.0/24 , 96.9.98.0/24 , etc... These are not
related to the operators filing an abuse report. These are automatically
generated reports based on the behavior of your server and they are
generally wrong because their automated system is simply too sensitive
and comes up with a lot of false positive.
Simply block outgoing packets to the /24 block at the firewall level.
Then click on the link they sent you to retest. It will be automatically
tested and comes up clear. Then send them a message using the second
link and tell them you blocked it at the firewall level and they'll
close the ticket.
You can later remove the firewall rule and get on with you life. I've
given up arguing with them about how and why they're wrong. They even
once admitted that it was a false report and told me not to bother. In
fact I just got another abuse report for an IP that's already blocked at
the firewall level. They are telling me that my server is scanning port
74 of a range of IPs when outgoing port 74 is explicitly blocked on my
server and it simply can't go out.
On 10/15/2025 2:02 AM, Dimitris T. via tor-relays wrote:
Hey all,
got an abuse report today from Hetzner concerning one middle relay
we're running there.
allegedly, our relay has been port scanning (port 443 only) some
members of
[https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276429F3B03C92AA9327](https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276429F3B03C92AA9327)
(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
anyone else got similar abuse reports? or someone here from this relay
family, that can clear things out with this isp?
thinking of replying to hetzner accordingly, let them know (with
metrics link), that these are tor relays with 443 port open/accepting
our middle relay connections, not port scans...
best,
d.
_______________________________________________
tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org)
To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)
Chris, this is horrible advice. You're effectively promoting to become a bad node by knowingly and wilfully prohibiting circuits to certain exits.
Run this thought a bit further, eventually you will have banned all exits (and likely some middles too) and your node is effectively useless.
I sincerely hope I missed a /s somewhere here.
/r0cket
···
On Wednesday, October 15, 2025 08:05 UTC, Chris Enkidu-6 via tor-relays <tor-relays@lists.torproject.org> wrote:
I get them from time to time and the address always is for major Tor
operators who host numerous Tor servers on the whole block such as
64.65.1.0/24 , 64.65.62.0/24 , 96.9.98.0/24 , etc... These are not
related to the operators filing an abuse report. These are automatically
generated reports based on the behavior of your server and they are
generally wrong because their automated system is simply too sensitive
and comes up with a lot of false positive.
Simply block outgoing packets to the /24 block at the firewall level.
Then click on the link they sent you to retest. It will be automatically
tested and comes up clear. Then send them a message using the second
link and tell them you blocked it at the firewall level and they'll
close the ticket.
You can later remove the firewall rule and get on with you life. I've
given up arguing with them about how and why they're wrong. They even
once admitted that it was a false report and told me not to bother. In
fact I just got another abuse report for an IP that's already blocked at
the firewall level. They are telling me that my server is scanning port
74 of a range of IPs when outgoing port 74 is explicitly blocked on my
server and it simply can't go out.
On 10/15/2025 2:02 AM, Dimitris T. via tor-relays wrote:
>
> Hey all,
>
> got an abuse report today from Hetzner concerning one middle relay
> we're running there.
>
> allegedly, our relay has been port scanning (port 443 only) some
> members of
> Relay Search
>
> (just from family relays in 96.9.98.0/24 range, all using ORPort 443)
>
> anyone else got similar abuse reports? or someone here from this relay
> family, that can clear things out with this isp?
>
> thinking of replying to hetzner accordingly, let them know (with
> metrics link), that these are tor relays with 443 port open/accepting
> our middle relay connections, not port scans...
>
> best,
>
> d.
>
>
> _______________________________________________
> tor-relays mailing list -- tor-relays@lists.torproject.org
> To unsubscribe send an email to tor-relays-leave@lists.torproject.org
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
ok whatever chris said applies. no /24 block needed, our relay is down anyway (=runs on the clock w/ bandwidth meter).
so, replied to hetzner that this is normal tor traffic , not malicious (no port scans, noone got “offended” by it), hetzner re-check passed, and statement accepted.
seemed strange, cause it’s the 1st time we got such an abuse report.. and we’ve been running this relay since ‘tor challenge 2014’
thanks all for your answers, hopefully we can go on without getting too many of these false-positive abuse reports.
ciao,
d.
···
Στις 15/10/25 12:32, ο/η Chris Enkidu-6 via tor-relays έγραψε:
You certainly did miss the important part. You may want to read it again.
On 10/15/2025 5:04 AM, R0cketCloud TOR Team wrote:
Chris, this is horrible advice. You're effectively promoting to become a bad node by knowingly and wilfully prohibiting circuits to certain exits.
Run this thought a bit further, eventually you will have banned all exits (and likely some middles too) and your node is effectively useless.
I sincerely hope I missed a /s somewhere here.
/r0cket
On Wednesday, October 15, 2025 08:05 UTC, Chris Enkidu-6 via tor-relays [<tor-relays@lists.torproject.org>](mailto:tor-relays@lists.torproject.org) wrote:
I get them from time to time and the address always is for major Tor
operators who host numerous Tor servers on the whole block such as
64.65.1.0/24 , 64.65.62.0/24 , 96.9.98.0/24 , etc... These are not
related to the operators filing an abuse report. These are automatically
generated reports based on the behavior of your server and they are
generally wrong because their automated system is simply too sensitive
and comes up with a lot of false positive.
Simply block outgoing packets to the /24 block at the firewall level.
Then click on the link they sent you to retest. It will be automatically
tested and comes up clear. Then send them a message using the second
link and tell them you blocked it at the firewall level and they'll
close the ticket.
You can later remove the firewall rule and get on with you life. I've
given up arguing with them about how and why they're wrong. They even
once admitted that it was a false report and told me not to bother. In
fact I just got another abuse report for an IP that's already blocked at
the firewall level. They are telling me that my server is scanning port
74 of a range of IPs when outgoing port 74 is explicitly blocked on my
server and it simply can't go out.
On 10/15/2025 2:02 AM, Dimitris T. via tor-relays wrote:
Hey all,
got an abuse report today from Hetzner concerning one middle relay
we're running there.
allegedly, our relay has been port scanning (port 443 only) some
members of
[https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276429F3B03C92AA9327](https://metrics.torproject.org/rs.html#search/family:7EAAC49A7840D33B62FA276429F3B03C92AA9327)
(just from family relays in 96.9.98.0/24 range, all using ORPort 443)
anyone else got similar abuse reports? or someone here from this relay
family, that can clear things out with this isp?
thinking of replying to hetzner accordingly, let them know (with
metrics link), that these are tor relays with 443 port open/accepting
our middle relay connections, not port scans...
best,
d.
_______________________________________________
tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org)
To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)
_______________________________________________
tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org)
To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)
I'm tempted to agree with Chris. Though, the real solution is to apply with your regional IR for your own IP block. That would solve 99% of issues for Tor operators, but the club might be a little more exclusive. I'm not sure what's better for the network ultimately. I have a meeting with ARIN today, à propos of this mail particular list.
~KJ
Chris, this is horrible advice. You're effectively promoting to become a bad node by knowingly and wilfully prohibiting circuits to certain exits.
Run this thought a bit further, eventually you will have banned all exits (and likely some middles too) and your node is effectively useless.
I sincerely hope I missed a /s somewhere here.
/r0cket
···
-------- Original Message --------
On Wednesday, 10/15/25 at 06:38 R0cketCloud TOR Team via tor-relays <tor-relays@lists.torproject.org> wrote:
On Wednesday, October 15, 2025 08:05 UTC, Chris Enkidu-6 via tor-relays <tor-relays@lists.torproject.org> wrote:
I get them from time to time and the address always is for major Tor
operators who host numerous Tor servers on the whole block such as
64.65.1.0/24 , 64.65.62.0/24 , 96.9.98.0/24 , etc... These are not
related to the operators filing an abuse report. These are automatically
generated reports based on the behavior of your server and they are
generally wrong because their automated system is simply too sensitive
and comes up with a lot of false positive.
Simply block outgoing packets to the /24 block at the firewall level.
Then click on the link they sent you to retest. It will be automatically
tested and comes up clear. Then send them a message using the second
link and tell them you blocked it at the firewall level and they'll
close the ticket.
You can later remove the firewall rule and get on with you life. I've
given up arguing with them about how and why they're wrong. They even
once admitted that it was a false report and told me not to bother. In
fact I just got another abuse report for an IP that's already blocked at
the firewall level. They are telling me that my server is scanning port
74 of a range of IPs when outgoing port 74 is explicitly blocked on my
server and it simply can't go out.
On 10/15/2025 2:02 AM, Dimitris T. via tor-relays wrote:
>
> Hey all,
>
> got an abuse report today from Hetzner concerning one middle relay
> we're running there.
>
> allegedly, our relay has been port scanning (port 443 only) some
> members of
> Relay Search
>
> (just from family relays in 96.9.98.0/24 range, all using ORPort 443)
>
> anyone else got similar abuse reports? or someone here from this relay
> family, that can clear things out with this isp?
>
> thinking of replying to hetzner accordingly, let them know (with
> metrics link), that these are tor relays with 443 port open/accepting
> our middle relay connections, not port scans...
>
> best,
>
> d.
>
>
> _______________________________________________
> tor-relays mailing list -- tor-relays@lists.torproject.org
> To unsubscribe send an email to tor-relays-leave@lists.torproject.org
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Tell them that this traffic is intended and you run TOR.
I don't recommend doing that, because an outbound netscan is neither
intended, nor might it be real to begin with. I have seen these reports
crop up between ca. 2-4 times per month for guard and middle nodes.
Looked like spoofed TCP traffic, which Hetzner's monitoring attributed
to hosts based on IP address alone. I interpret this as an attempt of
some third party to cause trouble for Tor operators aiming to stir up
conflicts with the ISP.
Keep in mind that while Hetzner does not prohibit Tor nodes, they do
prohibit disruptive use of their infrastructure. That includes port
scans. I find that the best course of action is to calmly process the
automated reports within the allotted timespan, verify/confirm that your
server did not in fact cause any malign traffic, and file it under "shit
happens". Yes, it is annoying, but I can understand that Hetzner is
trying to prevent being seen as a source of abusive behaviour.
-Ralph
···
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
I agree with that assessment. This is not normal Tor traffic. Not sure about this particular Abuse notice but the ones I get always include both port 443 and 74. Tor has no business sending traffic to port 74 and even if these scans were relay discovery scans, They should point to the ORPort and not exclusively to port 443.
Once you click on the retest link, you’ll get a notice within a few minutes informing you that the ticket has been closed. The next step which is your statement is just a legal formality. Personally, I don’t try to argue my point or try to convince them of anything. They don’t care and there’s not much they can do. I just tell them I mitigated the problem and then I can go about my business and I’ll be done wasting my time.
···
On 10/15/2025 6:56 AM, Ralph Seichter via tor-relays wrote:
* Marco Moock via tor-relays:
Tell them that this traffic is intended and you run TOR.
I don't recommend doing that, because an outbound netscan is neither
intended, nor might it be real to begin with. I have seen these reports
crop up between ca. 2-4 times per month for guard and middle nodes.
Looked like spoofed TCP traffic, which Hetzner's monitoring attributed
to hosts based on IP address alone. I interpret this as an attempt of
some third party to cause trouble for Tor operators aiming to stir up
conflicts with the ISP.
Keep in mind that while Hetzner does not prohibit Tor nodes, they do
prohibit disruptive use of their infrastructure. That includes port
scans. I find that the best course of action is to calmly process the
automated reports within the allotted timespan, verify/confirm that your
server did not in fact cause any malign traffic, and file it under "shit
happens". Yes, it is annoying, but I can understand that Hetzner is
trying to prevent being seen as a source of abusive behaviour.
-Ralph
_______________________________________________
tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org)
To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)
> I agree with that assessment. This is not normal Tor traffic.
> Not sure about this particular Abuse notice but the ones I get always
> include both port 443 and 74.
> Tor has no business sending traffic to port 74
i think you have a little error in that representation.
got the same abuse report.
but the 74 is the packet size, not the desitnation port.
so rather all fine and looks like legal tor traffic and still a false positive on hetzners side to me?
cheers
Jan
···
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Well, there's more, is there not? Hetzner reports of this kind typically
list a whole range of destination IP addresses, i.e. portscans for
network ranges (class C being pretty common).
so rather all fine and looks like legal tor traffic and still a false
positive on hetzners side to me?
Portscans are /not/ fine. If you are not running an exit node, there is
no reason for your node to connect to port 443 on a whole range of
target hosts. That traffic is either spoofed, or something is very wrong
on your node.
However, if you are running an exit node, you can pretty much bet that
some bozos will abuse it to run portscans. Occupational hazard. And it's
not fine either.
-Ralph
···
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
EXTEND cells can actually contain arbitrary addresses, and AFAIK tor will actually try to connect to them and speak the Tor protocol. If the address doesn't belong to a real relay, at best it will complete the TLS handshake[1] and bail out.
[1] I'm actually not 100% sure if it will even complete it when connecting to something that isn't a tor relay. I only tested this (locally) against a port that nothing was listening on.
···
On 10/20/25 12:29, Ralph Seichter via tor-relays wrote:
Portscans are /not/ fine. If you are not running an exit node, there is
no reason for your node to connect to port 443 on a whole range of
target hosts. That traffic is either spoofed, or something is very wrong
on your node.
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
EXTEND cells can actually contain arbitrary addresses, and AFAIK tor
will actually try to connect to them and speak the Tor protocol.
How likely is it that this will result in >100 closely related IP
addresses being targeted over the span of minutes, and all of them on
port 443, I wonder?
-Ralph
···
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Am 20.10.25 um 12:29 schrieb Ralph Seichter via tor-relays:
Well, there's more, is there not? Hetzner reports of this kind typically
list a whole range of destination IP addresses, i.e. portscans for
network ranges (class C being pretty common).
hey hey
i run a relay, not an exit node.
the report from hetzner was both times ~300 lines long
and so on
*all* of those addresses are tor relay both times according to [1] and [2] and according the the same sides their torport is 443.
my speculation is still in the direction that they're maybe doing maintenance, taking down all nodes, and then my relay tries to connect to them and gives up after three times.
still nothing i'd see as bad behavior?
Portscans are /not/ fine. If you are not running an exit node, there is
no reason for your node to connect to port 443 on a whole range of
target hosts. That traffic is either spoofed, or something is very wrong
on your node.
as said, the destination ip/port are *always* valid tor nodes, so i do not see this as port scan.
However, if you are running an exit node, you can pretty much bet that
some bozos will abuse it to run portscans. Occupational hazard. And it's
not fine either.
if i'd run an exit node i'd wonder about nothing and tbh i'd also not let it run via hetzner. as there i'd expect problems of other kind on a daily basis. i', very thanktful for all the exit node operators.
cheers
Jan
[1] Relay Search
[2] Relay Search
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
*all* of those addresses are tor relay both times according to [1] and
[2] and according the the same sides their torport is 443.
Nice! If you invested the time to verify that this was Tor-to-Tor
traffic, and it caused a false alarm in Hetzner's monitoring, you can
tell them just that and go back to well deserved sleep.
-Ralph
···
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Hetzner is issuing "netscan abuse" complaints because their automated systems misunderstand normal Tor behavior (TCP/SYN packets to [offline] relays).
In response, we are now discussing banning Tor nodes that go down for routine maintenance. This is the wrong solution. We would be actively "lobotomizing" network diversity because of one provider's flawed policy.
The problem is Hetzner's surveillance. Any provider that constantly stores and analyzes netflow data to this degree is a risk.
Instead of punishing Tor diversity, we should reduce the impact of Hetzner. I propose all Hetzner-hosted relays get the MiddleOnly flag and be barred from becoming Guard nodes.
I sincerely hope the network-health team sees the gravity of this. If we knowingly ban our own relays over this, we are fundamentally undermining the network.
When did we become the censors?
/r0cket
···
On Monday, October 27, 2025 21:20 UTC, Toralf Förster via tor-relays <tor-relays@lists.torproject.org> wrote:
On 10/22/25 6:52 AM, Tor at 1AEO via tor-relays wrote:
> No other provider appears to exhibit these same issues with this traffic
> pattern.
I got 3 abuse complaints related to 64.65.0.0/24, 64.65.61.0/24 and
96.9.98.0/24 in the past couple of weeks.
> Open to any guidance or suggestions on how best to mitigate this.
My personal solution attempt as of today is in [1]. For that I added
EGRESS_SUBNET_SLEW="45.84.107.0 64.65.0.0/23 64.65.60.0/22
96.9.98.0 109.70.100 171.25.193.0 185.220.101.0 192.42.116.0"
/opt/torutils/ipv4-rules-egress.sh start
to the init script of a bare metal server hosting 5 Tor relays. After
reboot it took about 10 min for the iptables stats to calm down [2].
--
Toralf
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Why are so many people choosing Hetzner for TOR nodes, especially
non-exits?
Many, many VPS companies are just resellers of Hetzner. There have been
more than a few times where I had to check a company's looking glass
just to find out that their IPs are on AS24940. I doubt most of these
people are going to hetzner.com directly to buy their VPSes.
Regards,
forest
···
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
Στις 28/10/25 13:14, ο/η Marco Moock via tor-relays έγραψε:
···
Am 28.10.2025 um 07:48:47 Uhr schrieb R0cketCloud TOR Team via > tor-relays:
Instead of punishing Tor diversity, we should reduce the impact of
Hetzner. I propose all Hetzner-hosted relays get the MiddleOnly flag
and be barred from becoming Guard nodes.
Why are so many people choosing Hetzner for TOR nodes, especially
non-exits?
hetzner is the cheapest provider around (for certain things, like dedicated servers)...
hetzner is also not exit-node friendly, so non-exits it is.
2c.
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
The problem is Hetzner's surveillance. Any provider that constantly stores and analyzes netflow data to this degree is a risk.
Hetzner is a huge provider with diverse networks. I can't blame them for
trying to keep it secure in whatever way they see fit. People are not
going to change providers because you say so. They choose what works for
them or they stop contributing.
Instead of punishing Tor diversity, we should reduce the impact of Hetzner. I propose all Hetzner-hosted relays get the MiddleOnly flag and be barred from becoming Guard nodes.
To be honest having a handful of operators controlling such great number
of exit nodes and exit traffic on the Tor network to a point that a
simple maintenance can create this kind of effect in my view is just as
much of a security risk.
I use Hetzner because I have a bare metal server with 12 IPv4 addresses
that runs a bunch of things including Tor nodes and it relays about 160
TB up and 160 TB down of Tor traffic each month, all for a total cost of
60 Euros. There's no way I can do that on cheap VPS. Any time you feel
like banning Hetzner I'd be glad to shut them down and move on. I choose
where I run my server and no amount of Good / Bad ISP lists made by
those who are out of touch with reality of what the average volunteer
has to deal with is going to make me change my mind.
And no, I'm not promoting banning those IP addresses. This is not
limited to Exit nodes. It's related to single operators holding great
number of IP addresses on a single server and that's where the problem
lies. Once a single server goes down, it will have a major effect. In
fact I received a new one for 64.65.62.0/24 two days ago for the third
time in a couple of months. The whole /24 block has been down for over 2
days and they're not even Exit nodes. Dealing with Hetzner Abuse emails
is quite easy. In fact they closed the ticket without me having to even
answer.
···
On 10/28/2025 3:48 AM, R0cketCloud TOR Team via tor-relays wrote:
I sincerely hope the network-health team sees the gravity of this. If we knowingly ban our own relays over this, we are fundamentally undermining the network.
When did we become the censors?
/r0cket
On Monday, October 27, 2025 21:20 UTC, Toralf Förster via tor-relays <tor-relays@lists.torproject.org> wrote:
On 10/22/25 6:52 AM, Tor at 1AEO via tor-relays wrote:
No other provider appears to exhibit these same issues with this traffic
pattern.
I got 3 abuse complaints related to 64.65.0.0/24, 64.65.61.0/24 and
96.9.98.0/24 in the past couple of weeks.
Open to any guidance or suggestions on how best to mitigate this.
My personal solution attempt as of today is in [1]. For that I added
EGRESS_SUBNET_SLEW="45.84.107.0 64.65.0.0/23 64.65.60.0/22
96.9.98.0 109.70.100 171.25.193.0 185.220.101.0 192.42.116.0"
/opt/torutils/ipv4-rules-egress.sh start
to the init script of a bare metal server hosting 5 Tor relays. After
reboot it took about 10 min for the iptables stats to calm down [2].
--
Toralf
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
and tbh i'd also not let it run via hetzner. as there i'd expect problems of other kind on a daily basis. i', very thanktful for all the exit node operators.