Tor stop working without stop the process or give an error message?

Hi,

I’ve noticed a strange problem with my Tor Node. I can’t say when this problem started, as I haven’t been running the node all the time for the last few months, but for the last few weeks the Tor node just goes to sleep after a few days/hours after it was started.
The Tor process is still running, I don’t get any error messages in the log that really justify the termination, the heartbeat only shows that there are fewer and fewer connections until finally there are no more, but the node has been offline for a long time, so I always notice this far too late.
Why is the node rejected by the network? Does anyone have an idea?

Edit:
Ok, I found the problem, there was no iptables rule for tor_input and tot_output, but how can that be?

Ok, I did a little research in my environment and the problem was a script that restarts the firewall with

/etc/init.d/firewall restart

and this command deletes the iptable rules for the tor relays tor_input and tor_output.

Is this an error? Normally these rules should be set again when the firewall is restarted manually, shouldn’t they? Could someone confirm this behavior?
Or do I need to dig deeper to find the reason why these rules are missing after restarting the firewall?

To get the rules back, I stop and start the Tor process in the web GUI via status/services (cgi-bin/services.cgi)
This is the best way to avoid rewriting my (custom) torrc file.

Hi @mumpitz ,
haven´t seen this topic but good that you linked it in another one.

So i was digging a little around and can confirm this behavior but only for an
/etc/init.d/firewall restart
(restart is the same function than start called ‘iptables_init’) but with a
/etc/init.d/firewall reload
or a system reboot the Tor IPTable entries survive. Can you confirm this ?
So the firewall initscript calls the ‘iptables_init’ function by restarting it and flushes all chains and create new Tor inbound and Tor outbound chains but does not include the rules defined in the Tor initscript.

First a question. If you execute your ASN_Script and use instead of a restart a ‘/etc/init.d/firewall reload’ does this work for you ?

Apart from my question a possible fix for this problem could be →

  1. Make a backup of the existing firewall initscript
cp /etc/rc.d/init.d/firewall /etc/rc.d/init.d/firewall.orig

and try this patch

--- /etc/rc.d/init.d/firewall_orig	2024-01-15 09:21:41.929508410 +0100
+++ /etc/rc.d/init.d/firewall	2024-01-15 10:09:21.613656976 +0100
@@ -25,6 +25,7 @@
 eval $(/usr/local/bin/readhash /var/ipfire/ppp/settings)
 eval $(/usr/local/bin/readhash /var/ipfire/ethernet/settings)
 eval $(/usr/local/bin/readhash /var/ipfire/optionsfw/settings)
+eval $(/usr/local/bin/readhash /var/ipfire/tor/settings)
 IFACE=`/bin/cat /var/ipfire/red/iface 2> /dev/null | /usr/bin/tr -d '\012'`
 if [ -z $IFACE ]; then
 	IFACE="red0"
@@ -387,6 +388,11 @@
 	# run captivectrl
 	/usr/local/bin/captivectrl
 
+	# If Tor or Tor relay is enabled run it
+	if [ "${TOR_RELAY_ENABLED}" = "on" -a -n "${TOR_RELAY_PORT}" ]; then
+		/usr/local/bin/torctrl restart 1> /dev/null
+	fi
+
 	# POLICY CHAIN
 	iptables -N POLICYIN
 	iptables -A INPUT -j POLICYIN

If you want to give it a shot.

Best,

Erik

Another problem with a manual
/etc/init.d/firewall restart
is firewall.local and IPSet sets in there. While debugging the firewall initscript the following appears

+ /usr/local/bin/firewallctrl
ipset v7.17: Set cannot be destroyed: it is in use by a kernel component
ERROR: ipset destroy companies

which results in in a

+ /usr/local/bin/firewallctrl
+ IPSETCOMPANY=/sbin/iptables
+ IPT=/sbin/iptables
+ case "$1" in
+ /etc/sysconfig/firewall.local stop
+ IPSETCOMPANY=/sbin/iptables
+ IPT=/sbin/iptables
+ case "$1" in
+ /sbin/iptables -F CUSTOMFORWARD
+ /sbin/iptables -F CUSTOMINPUT
+ /sbin/iptables -F CUSTOMOUTPUT
+ /etc/sysconfig/firewall.local start
+ IPSETCOMPANY=/sbin/iptables
+ IPT=/sbin/iptables
+ case "$1" in
+ /sbin/iptables -I CUSTOMFORWARD -m set --match-set companies dst -j REJECT
iptables v1.8.9 (legacy): Set companies doesn't exist.

Try `iptables -h' or 'iptables --help' for more information.
+ /sbin/iptables -I CUSTOMINPUT -m set --match-set companies src -j REJECT
iptables v1.8.9 (legacy): Set companies doesn't exist.

Try `iptables -h' or 'iptables --help' for more information.
+ /sbin/iptables -I CUSTOMOUTPUT -m set --match-set companies dst -j REJECT
iptables v1.8.9 (legacy): Set companies doesn't exist.

Try `iptables -h' or 'iptables --help' for more information.

and i think you know this problem.

So answering to your statement in here → Weird problem how should I proceed? - #13 by mumpitz
“I was convinced that it had something to do with the ASN script, but it was your script. Both at the same time does not work.”
this is not true, both scripts should work together without problems but mine does not with a firewall restart like the Tor rules also does not work with.

Have for the firewall.local problem currently no fix but may time will tell or may others have earlier one ?! Let´ see.

Best,

Erik

yes both works fine

I edit the script and replace restart with reload and it works

I added this patch and after restarting the tor entries are also not gone, so it works too.

Yes this appears every time after the ASN_script where I thought the error came from, but only if your script had previously customized the firewall.local.

So I run your script again, and then the ASN_Script (with firewall reload) and get also this error

ipset v7.17: Set cannot be destroyed: it is in use by a kernel component
ERROR: ipset destroy companies

so reload and restart does not work with your script and the ASN_Script together…

So for the first one → [v2] Firewall initscript: Restore Tor IPTable rules by manual firewall restart - Patchwork
thanks @ms for your helpful comments :wink: (at a beneath one dont know about a possible release date for this).

Another one is the problem with firewall.local and IPSet sets in it. Digging into this a little deeper, rules.pl does not register them as used sets whereby IMHO the ipset_get_sets function is responsible for that since they are not registered the ipset_cleanup function tries to destroy them but (the only entry i found), those sets should not be destroyed →

therefor we have a good companion with rules.pl since it delivers also a possiblity to restore those IPSet sets (no need anymore for ‘/etc/sysconfig/rc.local’ entries!?).

Long story short. Does someone have an idea of how we do this :grin: ?

Am on the road again for some days without Net and may someone comes around with some ideas also we speak here about true “Improvement of usability” again IMHO :innocent:.

Best,

Erik

1 Like

Patch has been merged in origin/next → git.ipfire.org Git - ipfire-2.x.git/commit .

Best,

Erik

P.S.: A fix for the firewall.local problem comes soon but also in another topic.

1 Like

Hi @ummeegge can you plz link this other thread?

If i have the time for it, yes.

@ummeegge I have an e-mail with an answer from you, but don’t see it here.
Deleted?

Hi,
yes have deleted the last one since a bug in the fix :wink: has been shown up. Have tried to figure it a little out what´s going on and made a description which needs to be investigated further.
In here → 13563 – IPSet sets in firewall.local getting destroyed if the firewall will be restarted you can check it out, comment and or test it too.

Best,

Erik