Abnormal Firewall-States since 0.4.9.10
Hi there, I want to report abnormal Firewall States since the update. Since a week or two, (I believe with 0.4.9.10) tor started to excessively use Firewall-States, far beyond what I observed beforehand. In normal operation, I observed about 20k - 45k Firewall States for the relay. Yesterday, before I installed the update, I had 190k Firewall States, related to Tor Relay Traffic. The days before it cycled from 120 - 145k States. Also far more than normal. Today, I see excessive Errors (> 20 Errors/Sek) in my Firewall, relating to use of invalid Firewall States (pf: BAD State..) - all are Tor Related Connections. It would be nice if anyone could have a look, if your connections increased also that much. I also wonder if this might be a type of attack? Regardless of the odd connections, the relay is running well, no CPU peaks and normal memory usage (602MB). Best regards and have a nice weekend! Joker
Hi all, I am observing the same behavior with one of my FreeBSD relays. All hover around 15k active TCP states according to the pf firewall, except one, which hovers around 90k TCP states. All run tor version 0.4.9.11. The affected relay's fingerprint is the following: CE0D31663C7CE954B1944B6D65449963F12BDF78 Other things I have observed: At 8 am UTC the CPU usage of the affected relay spiked sharply, while traffic simultaneously dropped significantly. At around 10:50 am UTC, outgoing Tor traffic dropped to around 5%, while incoming traffic sharply rised to 135% of normal network traffic. The relay was completely unresponsive up until around 4:22 pm UTC, when traffic returned to normal, except for the 6x increase in TCP states. I suppose my relay was hit by some kind of DoS attack? In the syslog I can see pf firewall entries about hitting max states, which are at 100.000 concurrent states, which is abnormal. Another thing I've seen is that some other Tor relays have between 10 to 200 TCP states, even though they only have 1-8 Tor sessions running from their source IP addresses. Strange, but unrelated: - There hundreds of IPs from the same /24 networks accessing my Tor relays, all hosted on Contabo, which don't seem to be Tor Relays, but also don't look look like Tor bridges either (?). - All of them account to around 6k TCP states, all wit around 50. I don't know what I should to with this information, but maybe someone finds this interesting. Cheers, ZR On Saturday, July 4th, 2026 at 11:20, ProSecureRelays via tor-relays <tor-relays@lists.torproject.org> wrote:
Hi there,
I want to report abnormal Firewall States since the update.
Since a week or two, (I believe with 0.4.9.10) tor started to excessively use Firewall-States, far beyond what I observed beforehand.
In normal operation, I observed about 20k – 45k Firewall States for the relay.
Yesterday, before I installed the update, I had 190k Firewall States, related to Tor Relay Traffic.
The days before it cycled from 120 – 145k States. Also far more than normal.
Today, I see excessive Errors (> 20 Errors/Sek) in my Firewall, relating to use of invalid Firewall States (pf: BAD State..) – all are Tor Related Connections.
It would be nice if anyone could have a look, if your connections increased also that much. I also wonder if this might be a type of attack?
Regardless of the odd connections, the relay is running well, no CPU peaks and normal memory usage (602MB).
Best regards and have a nice weekend!
Joker
Hi Zwiebelrouter, interestingly, I saw the same Contabo Adresses, and as you said, they were tor unrelated. However, I thought this might be a “Client” connecting to me, so then it would be a legit connection not coming from a relay. In the same time, I experienced a lot of portscans, I checked my IPS Alarms and two of them where Contabo Adresses. The first scan came from a French Site, the second from Germany. But this might be due to the simple fact, that Contabo has only “EU” as Region, so its kinda random where the rented VPS is started. But maybe there is a specific “enemy” that is using Contabo VPS to try and overwhelm espescially cost effective VPS-Relays, as in their nature there is not much resource headroom for such garbage. I checked the states 5 Minutes ago, and it even got worse, with 225k Open TCP Connections, however my maximum is beyond 2M States. The known attack behind this behavior is state table exhaustion, where your Firewall gets overwhelmed with useless TCP-Connections till there is no state left for legit traffic. I use syncookies for this, meaning if the state table exceeds my threshold, syn-cookies will be used instead of the state table, thus, an overflow should be prevented. Maybe this could be an effective option to protect your relay, it should be possible to implement without additional software on Free-BSD based relays. Or you could increase the size of the state table in exchange for CPU-Time and RAM. Pretty annoying. Thanks for your feedback and best regards, Joker P.S. I just checked a bit further and from the Contabo Subnets, e.g. 13.140.189.0 – 13.140.191.254 alone, more than 100k TCP Connections, but they come from various IPs, I picked four random IPs and none of them were listed as relay. And they had, as you said, about 200 – 250 TCP Connections each, as in your case. Very suspicious.. Von: zwiebelrouter via tor-relays [mailto:tor-relays@lists.torproject.org] Gesendet: Dienstag, 7. Juli 2026 23:20 An: support and questions about running Tor relays (exit, non-exit, bridge) Cc: ProSecureRelays; zwiebelrouter Betreff: [tor-relays] Re: Abnormal Firewall-States since 0.4.9.10 Hi all, I am observing the same behavior with one of my FreeBSD relays. All hover around 15k active TCP states according to the pf firewall, except one, which hovers around 90k TCP states. All run tor version 0.4.9.11. The affected relay's fingerprint is the following: CE0D31663C7CE954B1944B6D65449963F12BDF78 Other things I have observed: At 8 am UTC the CPU usage of the affected relay spiked sharply, while traffic simultaneously dropped significantly. At around 10:50 am UTC, outgoing Tor traffic dropped to around 5%, while incoming traffic sharply rised to 135% of normal network traffic. The relay was completely unresponsive up until around 4:22 pm UTC, when traffic returned to normal, except for the 6x increase in TCP states. I suppose my relay was hit by some kind of DoS attack? In the syslog I can see pf firewall entries about hitting max states, which are at 100.000 concurrent states, which is abnormal. Another thing I've seen is that some other Tor relays have between 10 to 200 TCP states, even though they only have 1-8 Tor sessions running from their source IP addresses. Strange, but unrelated: - There hundreds of IPs from the same /24 networks accessing my Tor relays, all hosted on Contabo, which don't seem to be Tor Relays, but also don't look look like Tor bridges either (?). - All of them account to around 6k TCP states, all wit around 50. I don't know what I should to with this information, but maybe someone finds this interesting. Cheers, ZR On Saturday, July 4th, 2026 at 11:20, ProSecureRelays via tor-relays <tor-relays@lists.torproject.org> wrote: Hi there, I want to report abnormal Firewall States since the update. Since a week or two, (I believe with 0.4.9.10) tor started to excessively use Firewall-States, far beyond what I observed beforehand. In normal operation, I observed about 20k – 45k Firewall States for the relay. Yesterday, before I installed the update, I had 190k Firewall States, related to Tor Relay Traffic. The days before it cycled from 120 – 145k States. Also far more than normal. Today, I see excessive Errors (> 20 Errors/Sek) in my Firewall, relating to use of invalid Firewall States (pf: BAD State..) – all are Tor Related Connections. It would be nice if anyone could have a look, if your connections increased also that much. I also wonder if this might be a type of attack? Regardless of the odd connections, the relay is running well, no CPU peaks and normal memory usage (602MB). Best regards and have a nice weekend! Joker
Sharing a hypothesis: This is likely not the 0.4.9.10 upgrade — your own numbers point that way: the state counts were already elevated in the days before you updated (120–145k, and 190k the day before, against your 20–45k norm). The timing instead lines up with the network-wide circuit-building DoS wave running since Jun 25 23:00 UTC (the "Circuit-building DoS wave: 20x peak, 8x sustained circuits on guard relays" thread on this list). From Tor's public archives alone: relays signing overload-general climbed from a 2–3% baseline to 12.2% of the network (1,254 relays) on Jul 12, and Running-flag churn roughly tripled — saturated relays failing the directory authorities' reachability probes while still relaying. A full state table is the same failure taken further — nothing new can connect — which would explain a relay dropping off entirely for hours once it hits its state-table max, as reported later in this thread. On the ~200–250 connections per source address: that would be consistent with Tor's stock defense if that machine runs 4–5 relay instances. DoSConnectionMaxConcurrentCount (consensus default 50) is enforced per tor process, not per host, so N co-hosted relays legally accept 50×N connections from a single source. Worth checking how many relays share that host. We think that per-process enforcement is a real gap — it's one of the changes we've suggested to the Tor Project, with the rest of what we've measured: * https://1aeo.com/blog/defending-against-circuit-dos-june-2026.html * Network-wide picture, from public data alone: https://1aeo.com/blog/tor-network-dos-wave-june-2026.html Attaching two charts from public Tor data about the network that might help frame what's happening broadly. On Tuesday, July 7th, 2026 at 3:54 PM, ProSecureRelays via tor-relays <tor-relays@lists.torproject.org> wrote:
Hi Zwiebelrouter,
interestingly, I saw the same Contabo Adresses, and as you said, they were tor unrelated.
However, I thought this might be a “Client” connecting to me, so then it would be a legit connection not coming from a relay.
In the same time, I experienced a lot of portscans, I checked my IPS Alarms and two of them where Contabo Adresses.
The first scan came from a French Site, the second from Germany. But this might be due to the simple fact, that Contabo has only “EU” as Region, so its kinda random where the rented VPS is started.
But maybe there is a specific “enemy” that is using Contabo VPS to try and overwhelm espescially cost effective VPS-Relays, as in their nature there is not much resource headroom for such garbage.
I checked the states 5 Minutes ago, and it even got worse, with 225k Open TCP Connections, however my maximum is beyond 2M States.
The known attack behind this behavior is state table exhaustion, where your Firewall gets overwhelmed with useless TCP-Connections till there is no state left for legit traffic.
I use syncookies for this, meaning if the state table exceeds my threshold, syn-cookies will be used instead of the state table, thus, an overflow should be prevented.
Maybe this could be an effective option to protect your relay, it should be possible to implement without additional software on Free-BSD based relays.
Or you could increase the size of the state table in exchange for CPU-Time and RAM.
Pretty annoying.
Thanks for your feedback and best regards,
Joker
P.S. I just checked a bit further and from the Contabo Subnets, e.g. 13.140.189.0 – 13.140.191.254 alone, more than 100k TCP Connections, but they come from various IPs, I picked four random IPs and none of them were listed as relay.
And they had, as you said, about 200 – 250 TCP Connections each, as in your case. Very suspicious..
Von: zwiebelrouter via tor-relays [mailto:tor-relays@lists.torproject.org] Gesendet: Dienstag, 7. Juli 2026 23:20 An: support and questions about running Tor relays (exit, non-exit, bridge) Cc: ProSecureRelays; zwiebelrouter Betreff: [tor-relays] Re: Abnormal Firewall-States since 0.4.9.10
Hi all,
I am observing the same behavior with one of my FreeBSD relays.
All hover around 15k active TCP states according to the pf firewall, except
one, which hovers around 90k TCP states. All run tor version 0.4.9.11.
The affected relay's fingerprint is the following:
CE0D31663C7CE954B1944B6D65449963F12BDF78
Other things I have observed:
At 8 am UTC the CPU usage of the affected relay spiked sharply, while
traffic simultaneously dropped significantly.
At around 10:50 am UTC, outgoing Tor traffic dropped to around 5%,
while incoming traffic sharply rised to 135% of normal network traffic.
The relay was completely unresponsive up until around 4:22 pm UTC,
when traffic returned to normal, except for the 6x increase in TCP states.
I suppose my relay was hit by some kind of DoS attack?
In the syslog I can see pf firewall entries about hitting max states,
which are at 100.000 concurrent states, which is abnormal.
Another thing I've seen is that some other Tor relays have
between 10 to 200 TCP states, even though they only have 1-8
Tor sessions running from their source IP addresses.
Strange, but unrelated:
- There hundreds of IPs from the same /24 networks accessing
my Tor relays, all hosted on Contabo, which don't seem to be
Tor Relays, but also don't look look like Tor bridges either (?).
- All of them account to around 6k TCP states, all wit around 50.
I don't know what I should to with this information, but maybe
someone finds this interesting.
Cheers, ZR
On Saturday, July 4th, 2026 at 11:20, ProSecureRelays via tor-relays <tor-relays@lists.torproject.org> wrote:
Hi there,
I want to report abnormal Firewall States since the update.
Since a week or two, (I believe with 0.4.9.10) tor started to excessively use Firewall-States, far beyond what I observed beforehand.
In normal operation, I observed about 20k – 45k Firewall States for the relay.
Yesterday, before I installed the update, I had 190k Firewall States, related to Tor Relay Traffic.
The days before it cycled from 120 – 145k States. Also far more than normal.
Today, I see excessive Errors (> 20 Errors/Sek) in my Firewall, relating to use of invalid Firewall States (pf: BAD State..) – all are Tor Related Connections.
It would be nice if anyone could have a look, if your connections increased also that much. I also wonder if this might be a type of attack?
Regardless of the odd connections, the relay is running well, no CPU peaks and normal memory usage (602MB).
Best regards and have a nice weekend!
Joker
Hi, yes your right – I saw the spike pretty early but wasn’t on the right track at first. To my defence. I thought I might be possbile that the other relays (which might were updated before mine) were cause of the issue. My current conclusions: - Obviously all relay families affected (Linux, BSD, Windows) - Attack comes primarily from Contabo VPS Subnets (Contabo AS) mostly from 13.140.128.0/18, 212.41.0.0/16, 212.47.0.0/16 - Current Measurement: 250K TCP Connections from Contabo AS - Attack burns CPU Cycles but does not affect normal operation (for me) - Attack might not be „Code-related“ and thus the version change was likely irrelevant. Also, the connections seem to build up very fast, I had to restart the relay due to CPE changes yesterday, today we‘re back at 309k TCP Connections total, which is insane for the short uptime. Regards, Joker Von: Tor at 1AEO [mailto:tor@1aeo.com] Gesendet: Dienstag, 14. Juli 2026 15:35 An: support and questions about running Tor relays (exit, non-exit, bridge) Cc: 'ProSecureRelays' Betreff: Re: [tor-relays] Re: Abnormal Firewall-States since 0.4.9.10 Sharing a hypothesis: This is likely not the 0.4.9.10 upgrade — your own numbers point that way: the state counts were already elevated in the days before you updated (120–145k, and 190k the day before, against your 20–45k norm). The timing instead lines up with the network-wide circuit-building DoS wave running since Jun 25 23:00 UTC (the "Circuit-building DoS wave: 20x peak, 8x sustained circuits on guard relays" thread on this list). From Tor's public archives alone: relays signing overload-general climbed from a 2–3% baseline to 12.2% of the network (1,254 relays) on Jul 12, and Running-flag churn roughly tripled — saturated relays failing the directory authorities' reachability probes while still relaying. A full state table is the same failure taken further — nothing new can connect — which would explain a relay dropping off entirely for hours once it hits its state-table max, as reported later in this thread. On the ~200–250 connections per source address: that would be consistent with Tor's stock defense if that machine runs 4–5 relay instances. DoSConnectionMaxConcurrentCount (consensus default 50) is enforced per tor process, not per host, so N co-hosted relays legally accept 50×N connections from a single source. Worth checking how many relays share that host. We think that per-process enforcement is a real gap — it's one of the changes we've suggested to the Tor Project, with the rest of what we've measured: * https://1aeo.com/blog/defending-against-circuit-dos-june-2026.html * Network-wide picture, from public data alone: https://1aeo.com/blog/tor-network-dos-wave-june-2026.html Attaching two charts from public Tor data about the network that might help frame what's happening broadly. On Tuesday, July 7th, 2026 at 3:54 PM, ProSecureRelays via tor-relays <tor-relays@lists.torproject.org> wrote:
Yeah, this matches what a bunch of us have been seeing. The elevated state counts were already climbing in the days before 0.4.9.10, so the version bump itself doesn’t look like the trigger. Timing lines up with the circuit-building DoS wave that’s been running since late June (the one that pushed overload-general from the usual 2-3 % up past 12 % of the network). A full state table is just the same saturation taken one step further — once you hit the limit nothing new can connect and the relay drops offline for a while, exactly like the multi-hour outage some people reported. Contabo ranges are definitely carrying a big chunk of it. Same pattern others mentioned: lots of IPs from the same /24s, none of them relays, each holding 50–250 connections. That’s consistent with the current DoSConnectionMaxConcurrentCount limit being enforced per Tor process rather than per host — spin up a few instances on one VPS and you can park a few hundred connections from a single source without ever tripping the defense. Feels like a real gap. On the practical side, if you’re on FreeBSD/pf and still have headroom, just raise the state limit and turn on syncookies once you cross a threshold. That kept things usable for me even when the table was well into the hundreds of thousands. “Sloppy” states on the ORPort rules can also quiet the BAD State noise if you’re seeing sequence complaints. MetricsPort is worth turning on so you can watch the actual onionskin drops and connection counters instead of guessing from the heartbeat numbers. Restarting clears the pile-up for a bit, but the connections come right back while the wave is still going. Longer term the real fixes have to come from Tor itself (host-wide connection caps, better idle circuit cleanup under pressure, aggregate rate limits, etc.). Those are already being talked about, so hopefully something lands before this becomes the new normal. Annoying as hell, but at least the relay itself is still doing its job once the firewall stops choking.
participants (4)
-
jmhbm＠duck.com -
ProSecureRelays -
Tor at 1AEO -
zwiebelrouter