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

[mumpitz]

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?

[mumpitz]

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.

[ummeegge (Erik Kapfer)]

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

[ummeegge (Erik Kapfer)]

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

[mumpitz]

@ummeegge

/etc/init.d/firewall reload
or a system reboot the Tor IPTable entries survive. Can you confirm this ?

yes both works fine

@ummeegge

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 ?

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

@ummeegge

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

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

@ummeegge

and i think you know this problem.

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…

[ummeegge (Erik Kapfer)]

So for the first one → [v2] Firewall initscript: Restore Tor IPTable rules by manual firewall restart - Patchwork
thanks @ms for your helpful comments (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 →

@mumpitz

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

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 ?

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 .

Best,

Erik

[ummeegge (Erik Kapfer)]

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.

[mumpitz]

Hi @ummeegge can you plz link this other thread?

[ummeegge (Erik Kapfer)]

If i have the time for it, yes.

[mumpitz]

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

[ummeegge (Erik Kapfer)]

Hi,
yes have deleted the last one since a bug in the fix 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

[ummeegge (Erik Kapfer)]

Hi @mumpitz ,
long time ago i know but this bug 13563 – IPSet sets in firewall.local getting destroyed if the firewall will be restarted falls not long ago between my feed again and was trying a liitle more again, which currently works so far. Am not sure if you want to go into a testing round or if you in general interested in it but if, here you can find the patch

--- /usr/lib/firewall/rules.pl-core198	2025-12-28 10:31:10.750417082 +0100
+++ /usr/lib/firewall/rules.pl	2025-12-29 14:08:51.465424186 +0100
@@ -89,6 +89,7 @@
 my $configgrp		= "${General::swroot}/fwhosts/customgroups";
 my $netsettings		= "${General::swroot}/ethernet/settings";
 my $blocklistfile   = "${General::swroot}/ipblocklist/settings";
+my $ipset_local_conf	= "/etc/ipset/ipset.conf";
 
 &General::readhash("${General::swroot}/firewall/settings", \%fwdfwsettings);
 &General::readhash("${General::swroot}/optionsfw/settings", \%fwoptions);
@@ -163,6 +164,9 @@
 	# Handle ipblocklist.
 	&ipblocklist();
 
+	# Load and protect custom IPSet sets
+	&load_custom_ipsets();
+
 	# Reload firewall policy.
 	run("/usr/sbin/firewall-policy");
 
@@ -801,6 +805,52 @@
 	}
 }
 
+###############################################################################
+#
+# load_custom_ipsets()
+#
+# Register IPSet sets referenced in firewall.local and load them from
+# /etc/ipset/ipset.conf. This protects custom sets from being destroyed
+# during firewall restart.
+#
+###############################################################################
+sub load_custom_ipsets {
+	my %referenced_sets = ();
+	
+	# 1. Find all sets referenced in firewall.local
+	if (-f '/etc/sysconfig/firewall.local') {
+		open(my $FWL, "<", '/etc/sysconfig/firewall.local') or do {
+			print "[DEBUG] Cannot open firewall.local: $!\n" if $DEBUG;
+			return;
+		};
+		
+		while (my $line = <$FWL>) {
+			while ($line =~ /--match-set\s+(\S+)/g) {
+				my $setname = $1;
+				$referenced_sets{$setname} = 1;
+				print "[DEBUG] Found set reference: $setname\n" if $DEBUG;
+			}
+		}
+		
+		close($FWL);
+	}
+	
+	# 2. Register referenced sets for protection
+	foreach my $setname (keys %referenced_sets) {
+		$ipset_loaded_sets{$setname} = 1;
+		print "[DEBUG] Protected set: $setname\n" if $DEBUG;
+	}
+	
+	# 3. Load sets from ipset.conf (if file exists)
+	if (-f $ipset_local_conf && -s $ipset_local_conf) {
+		print "[DEBUG] Loading sets from $ipset_local_conf\n" if $DEBUG;
+		system("$IPSET restore -exist -f $ipset_local_conf 2>/dev/null");
+	}
+	
+	print "[DEBUG] Protected custom sets: " . join(', ', sort keys %referenced_sets) . "\n"
+		if $DEBUG && keys %referenced_sets;
+}
+
 sub get_protocols {
 	my $hash = shift;
 	my $key = shift;

Changes in short:

This patch extends rules.pl to:

1. Detect IPSet sets referenced in firewall.local
2. Register them in %ipset_loaded_sets for protection
3. Load them while reboot/boot from /etc/ipset/ipset.conf
4. Reload goes no via rules.pl no rc.local needed anymore but if it exists, also no problem.

Please use testing system for this if wanted.

Best,

Erik

[mumpitz]

Hi thank you for your message.

I only have one system, no testing system, so i will do it live then.

At the moment all works fine with my firewall i guess.

So if i want to do the patch i have to add this green text in my file /usr/lib/firewall/rules.pl

I will do small research for the right commands and test it. I think after editing i must restart, give me some time, i will give feedback in this year 2025 ;D

[ummeegge (Erik Kapfer)]

You are welcome and great to hear . Yes the green text are the changes but i have pushed them now also to Git git.ipfire.org Git - people/ummeegge/ipfire-2.x.git/commit . The diff can be found here git.ipfire.org Git - people/ummeegge/ipfire-2.x.git/blobdiff - config/firewall/rules.pl and the whole modified rules.pl (copy and paste ready) in raw format here https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=blob_plain;f=config/firewall/rules.pl;h=ebcee2e934f3535fcbc3fbb66702b4a6e6e92c3e;hb=6d5ab1654f674a3ea1e2dec4c6ea83067061dd01 .

Please backup your existing rules.pl .

or the whole command list:

# Backup
cp -a /usr/lib/firewall/rules.pl /usr/lib/firewall/rules.pl.bak

# Load and Copy new version
wget -O /usr/lib/firewall/rules.pl \
  "https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=blob_plain;f=config/firewall/rules.pl;h=ebcee2e934f3535fcbc3fbb66702b4a6e6e92c3e;hb=6d5ab1654f674a3ea1e2dec4c6ea83067061dd01"

# Permission
chown root:root /usr/lib/firewall/rules.pl
chmod 755 /usr/lib/firewall/rules.pl

As a sidenote, you can also enable the debugging in rules.pl for a first overview by changing the DEBUG line git.ipfire.org Git - people/ummeegge/ipfire-2.x.git/blob - config/firewall/rules.pl from ‘0’ to ‘1’ so no changes will be made, this is a kind of dry run. To arm it use ‘0’ . Set´s from firewall.local should also survive reboots also without restore entries from rc.local …

Hope it works as it should .

Best and a happy new year to you and all the others ,

Erik

[mumpitz]

@ummeegge

and the whole modified rules.pl (copy and paste ready) in raw format here

Sorry, but, If I don’t have permission to access the file, do I need an account, or how can I download the file?

greetz

[bonnietwin (Adolf Belka)]

The file is in raw format on an html page so just select all and copy and then paste into a file on your own system and label it rules.pl

Then transfer to your ipfire system after taking a backup copy of the existing file.

[mumpitz]

Oh sorry, please excuse me, i tried to download with my browser, but here I get access denied message.

Did not noticed that all commands are noted here, thanks for that, so follow the instructions did a rebot and nothing

I see no difference, all services runs as always, tor proxy is running as well. Something I had to look closer?

[ummeegge (Erik Kapfer)]

So this is a first great step . The patch have something to do with the IPSet set´s in firewall.local, may you remember, at that time there was the company_blocker around whjich uses FW rules with IPSet sets. If you check the Bug which i linked above, you will get the insides but we worte here also about that.

Best,

Erik

[mumpitz]

Ok i remember.

But first the ASN_script was removed in fcrontab, how does this happen without I get the Info, with the ipfire updates?

Second I only use the tor proxy and have no longer a tor node.

I started tor, did a check if firewall rules are in iptables, started the ASN_script manually, did fcrontab -e to add the script again. After this i did a restart. And the iptables rules are still there.

So it seems to.work.

[bonnietwin (Adolf Belka)]

@mumpitz

But first the ASN_script was removed in fcrontab, how does this happen without I get the Info, with the ipfire updates?

The root fcrontab was updated with an entry for the suricata-reporter report that is issued at 9:00 am daily if daily report has been enabled and the weekly/monthly if those are enabled.

Also if fcrontab is updated the standard fcrontab we define also will get updated.

To use fcrontab entries that stay in place follow the instructions that are in the IPFire documentation.

https://www.ipfire.org/docs/pkgs/fcron

This details how to create a non root fcrontab which will nbot get replaced and also how to add it to the users backup list to get it backed up with everything else.

The main fcrontab will probably get changed again with CU199 when it is released as the daily suricata-reporter timing has been changed to earlier in the day from users requests.