I run a relay in my home network. The relay runs on my router (self build opnsense machine). Details of my relay indicate that initially it progressed the usual live cycle of a relay. Then all connections drop. Consensus rates dropped and it stopped being chosen as guard. It changes to Unmeasured Nothing has been changed on the end of configuration or internet connection. The advertised bandwidth stayed roughly the same (I have 200MBit cable and ususally do get the full speed; the relay is not restricted on bandwidth-use).

In comparison: a relay that I ran until July last year with the same configuration never suffered this behavior.

Any help is dearly appreciated! Thank you.

  • 1
    Your relay seems to be getting a low consensus weight since a majority of the bandwidth authorities are measuring your relay (warning: large webpage size) as having a low bandwidth. I'm not sure why this is the case, if you're familiar with Python you could try using the stem library to build a circuit through your relay and test the performance. If no one answers here, you might get more help on the #tor-relays irc channel on OFTC.
    – Steve
    Commented Mar 22, 2020 at 6:34
  • Thanks alot for your insights and for the link. This is strange since I ususally have 200Mbit down and 50 Mbit upstream available. I'll look into it -- my python skills are not existent so I'lL have to pass on your troubleshooting suggestions. Commented Mar 22, 2020 at 19:35
  • I just wrote a script to test relays and I'm only able to create circuits if your relay is the first hop (the guard). If I attempt to create a circuit with your relay as the middle, the circuit times out. If I replace your relay with another relay, the circuit builds fine. Maybe double check your firewall rules? Is your public IP address on any IP blacklists?
    – Steve
    Commented Mar 25, 2020 at 19:20
  • Thank you for your effort in testing. I serached and found my public IP on github.com/firehol/blocklist-ipsets/blob/master/dm_tor blocklist. The odd thing is that it used to work -- and without changes to config, ports, etc. it stopped. Commented Mar 26, 2020 at 7:42

2 Answers 2


I have run a Tor relay for fifteen years, and I am seeing a similar issue with my relay. For privacy reasons, I apologize in advance for not listing my relay's nickname. According to Tor Metrics, on 2020-02-26 both my relay and your relay began receiving a Consensus Weight of 20 (Additional Flag: Unmeasured). Both of our relays are non-exit, middle-nodes with similar Advertised Bandwidth. The Exit Policy reject configuration is identical. Your relay has one Alleged Family Member, but my relay does not. Both of our relays are IPv4 only. My relay is in the US, and yours is in Germany. Your Consensus Weight shows a steady value of 20 over the past month, but mine has fluctuated approximately every three days between a normal (for my relay) Consensus Weight and 20 (effectively unmeasured), and this has been going on since 2020-02-26. I made no changes to my relay or network configuration immediately before the issue.

I have been watching Consensus Health for my relay daily over the past month. My relay is always measured by bwauth moria1 and bwauth faravahar. Occasionally, my relay is also measured by bwauth bastet with a bw=20. For my relay, I think bastet is part of the problem.

Unlike many other relays, my relay is not being measured by either bwauth maatuska or bwauth longclaw. This unmeasured state is not helping my relay's Consensus Weight.

On 2020-02-26, my relay was running Tor on Linux, but I updated it to a few days later.

My flags have been constant over the past month: Fast, Running, Stable, V2Dir, Valid, and HSDir (except for after Tor restarts and Linux kernel update/reboots).

My relay is behind a highly restrictive (ingress and egress) firewall, but all of the published dirauth and bwauth servers are allowed. This has been in place for years, and there have been no published dirauth and/or bwauth changes (server, IP address, port) that I can find.

According to Sebastian Hahn, there is a recent issue with bwauth gabelmoo: https://lists.torproject.org/pipermail/tor-relays/2020-March/018241.html

I realize that this does not solve your issue, but I thought we could compare notes.

  • Thank you for your input! It is odd that we both can pinpoint the date when the problems start. The new family member was added after my post here to rule out config/hardware issues. I just kept it running for the last week or so. Commented Mar 25, 2020 at 11:23
  • I noticed another semi-commonality. You mentioned OPNsense which I understand is a fork of pfSense. My relay is running behind a pfSense router/firewall. Is your relay running behind either OPNsense or pfSense?
    – tirvgqnf
    Commented Mar 25, 2020 at 20:28
  • Note that relays are allowed to use any ports they want, so blocking egress ports will cause circuits to fail as you'll be unable to connect to many other relays. For example common OR ports are: 9100, 9010, 9001, 80, 443, etc. If bandwidth authorities are unable to build a circuit through your relay, you'll end up with a low consensus weight.
    – Steve
    Commented Mar 25, 2020 at 20:46
  • Steve, thank you for the reminder to review the list of relays and their ports. I used the following (warning for large page): torstatus.rueckgr.at/index.php?SR=ORPort&SO=Desc When I started running a relay, the majority of relay ORPorts were on TCP port 9001, but over the years that has changed.
    – tirvgqnf
    Commented Apr 5, 2020 at 8:44
  • Due to the lack of time on my end, I did not further look into a solution. i set up a second relay on another device to rule out hardware issues. It -- as well -- got a low bw consent. Since two days now, without any further actions on my side, both relays are recovering and gaining in BW consent. The new relay also has been awarded a guard flag. So I guess the initial problem was related to a problem with bwauth (as @tirvgqnf mentioned). However, I cannot be sure. Thank you both alot for the effort you put in my problem! Commented Apr 9, 2020 at 7:05

HATEthePLOT, the problem with my relay appears to be corrected. All five active bwauth servers are measuring my relay. The three bwauth servers that were previously egress blocked by my firewall (pfSense) are measuring my relay at a low number, but I think this may be part of the lifecycle of a new relay:


Perhaps in a couple of weeks, my relay will be working better than ever.

Basically, I performed the following:

1) On the Linux server running the relay, I added Netfilter/iptables rules to block egress unless it was localhost, local network traffic, or from the service account running Tor.

2) On pfSense for the private IP address of the Linux server running Tor, I removed the egress rule port restrictions of TCP port 9001 and TCP port 9030.

3) I restarted the Linux server running Tor.

Following is a more detailed list of my Netfilter/iptables changes.

The Tor Project suggests "Blocking all local outbound non-Tor traffic with iptables":


# iptables -F OUTPUT
# iptables -A OUTPUT -j ACCEPT -m owner --uid-owner debian-tor
# iptables -A OUTPUT -j ACCEPT -o lo
# iptables -A OUTPUT -j ACCEPT -p udp --dport 123
# iptables -P OUTPUT DROP
# iptables -L -v

Instead, with the assumption that the service account is "debian-tor", and the local network is "", I used the following for Linux Mint 19.1:

sudo apt-get update && sudo apt-get install iptables-persistent netfilter-persistent

sudo iptables --list --line-numbers --verbose --exact
sudo iptables --flush INPUT
sudo iptables --append INPUT --jump ACCEPT --match state --state RELATED,ESTABLISHED
sudo iptables --append INPUT --jump ACCEPT --in-interface lo
sudo iptables --append INPUT --jump ACCEPT --source
sudo iptables --append INPUT --jump ACCEPT --protocol tcp --dport 9001
sudo iptables --append INPUT --jump ACCEPT --protocol tcp --dport 9030
sudo iptables --policy INPUT ACCEPT
sudo iptables --list --line-numbers --verbose --exact
sudo netfilter-persistent save

sudo iptables --list --line-numbers --verbose --exact
sudo iptables --flush OUTPUT
sudo iptables --append OUTPUT --jump ACCEPT --match state --state RELATED,ESTABLISHED
sudo iptables --append OUTPUT --jump ACCEPT --out-interface lo
sudo iptables --append OUTPUT --jump ACCEPT --destination
sudo iptables --append OUTPUT --jump ACCEPT --match owner --uid-owner debian-tor
# sudo iptables --append OUTPUT --jump LOG --log-prefix "iptables_DROP: "
sudo iptables --policy OUTPUT DROP
sudo iptables --list --line-numbers --verbose --exact
sudo netfilter-persistent save

sudo shutdown -r now

sudo iptables --zero

sudo watch iptables --list --line-numbers --verbose --exact

journalctl -fk -o short-iso

Please note that while I have created corresponding INPUT rules, my chain INPUT is using policy ACCEPT (blocking nothing for ingress). pfSense can handle ingress well enough, and Netfilter/iptables appears to be blocking non-Tor related egress traffic as expected.

I commented the LOG statement, but you can use it to troubleshoot DROP actions, if necessary.

HATEthePLOT, I hope this helps with your relay's issue.

  • Thank you for this extensive and detailed answer! I selected your first answer as correct one, since -- without any changes -- my relay is resuming to work. However, I am sure this solution might help other! Thank you again! Commented Apr 9, 2020 at 7:07
  • HATEthePLOT, you are very welcome, and thank you for making the original post confirming that I was not the only one seeing the measurement anomaly. On 2020-04-07, the bwauth configuration changed: 1) gabelmoo became a functional bwauth server, again. 2) dizum became a functional bwauth server.
    – tirvgqnf
    Commented Apr 13, 2020 at 8:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .