# Tor stop working without stop the process or give an error message? **URL:** \ **Category:** Add-Ons\ **Created:** [5 December 2023 23:07 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697 "2023-12-05T23:07:37Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![mumpitz](https://community.ipfire.org/user_avatar/community.ipfire.org/mumpitz/32/15450_2.png) [@mumpitz](https://community.ipfire.org/u/mumpitz)\ **Post date:** [5 December 2023 23:07 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/1 "2023-12-05T23:07:37Z")
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? ---
**Author:** ![mumpitz](https://community.ipfire.org/user_avatar/community.ipfire.org/mumpitz/32/15450_2.png) [@mumpitz](https://community.ipfire.org/u/mumpitz)\ **Post date:** [6 December 2023 05:46 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/2 "2023-12-06T05:46:48Z")
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. ---
**Author:** ![ummeegge](https://community.ipfire.org/user_avatar/community.ipfire.org/ummeegge/32/12650_2.png) [@ummeegge](https://community.ipfire.org/u/ummeegge)\ **Post date:** [15 January 2024 18:54 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/3 "2024-01-15T18:54:25Z")
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](https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/firewall;h=50f2b3e029cfb833bfb4bff09ca783f0273b4af2;hb=HEAD#l50) all chains and create new Tor [inbound](https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/firewall;h=50f2b3e029cfb833bfb4bff09ca783f0273b4af2;hb=HEAD#l281) and Tor [outbound](https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/firewall;h=50f2b3e029cfb833bfb4bff09ca783f0273b4af2;hb=HEAD#l318) chains but does not include the rules defined in the [Tor initscript](https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/packages/tor;h=47797265cff631498f6d976ae1b177f61f7f1ecc;hb=refs/heads/core182#l33). 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 ```bash cp /etc/rc.d/init.d/firewall /etc/rc.d/init.d/firewall.orig ``` and try this patch ```bash --- /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 ---
**Author:** ![ummeegge](https://community.ipfire.org/user_avatar/community.ipfire.org/ummeegge/32/12650_2.png) [@ummeegge](https://community.ipfire.org/u/ummeegge)\ **Post date:** [15 January 2024 19:06 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/4 "2024-01-15T19:06:31Z")
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 ```bash + /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 ```bash + /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](https://community.ipfire.org/t/weird-problem-how-should-i-proceed/10792/13) “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 ---
**Author:** ![mumpitz](https://community.ipfire.org/user_avatar/community.ipfire.org/mumpitz/32/15450_2.png) [@mumpitz](https://community.ipfire.org/u/mumpitz)\ **Post date:** [15 January 2024 20:34 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/5 "2024-01-15T20:34:46Z")
> [@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 ```auto 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… ---
**Author:** ![ummeegge](https://community.ipfire.org/user_avatar/community.ipfire.org/ummeegge/32/12650_2.png) [@ummeegge](https://community.ipfire.org/u/ummeegge)\ **Post date:** [16 January 2024 19:44 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/6 "2024-01-16T19:44:54Z")
So for the first one → [[v2] Firewall initscript: Restore Tor IPTable rules by manual firewall restart - Patchwork](https://patchwork.ipfire.org/project/ipfire/patch/20240116152650.3478281-1-erik.kapfer@ipfire.org/) thanks @ms for your [helpful comments](https://patchwork.ipfire.org/project/ipfire/patch/20240116150810.3477551-1-erik.kapfer@ipfire.org/) 😉 (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](https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/firewall/rules.pl;hb=7270984c460653f2215271b86286f74e6e9fb6ca#l1012) function is responsible for that since they are not registered the [ipset\_cleanup](https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/firewall/rules.pl;hb=7270984c460653f2215271b86286f74e6e9fb6ca#l1113) function tries to destroy them but (the only entry i found), those sets should not be destroyed → > [@mumpitz](#): > > ```auto > 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](https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/firewall/rules.pl;h=7edb910e2d6e649396c38071380f796112d9e013;hb=7270984c460653f2215271b86286f74e6e9fb6ca) since it delivers also a possiblity to [restore](https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/firewall/rules.pl;h=7edb910e2d6e649396c38071380f796112d9e013;hb=7270984c460653f2215271b86286f74e6e9fb6ca#l1037) 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 ---
**Author:** ![ummeegge](https://community.ipfire.org/user_avatar/community.ipfire.org/ummeegge/32/12650_2.png) [@ummeegge](https://community.ipfire.org/u/ummeegge)\ **Post date:** [20 January 2024 12:21 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/7 "2024-01-20T12:21:08Z")
Patch has been merged in origin/next → [git.ipfire.org Git - ipfire-2.x.git/commit](https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=e5a77641f35ec41e2b4a20403e690f0c9c96cb42) . Best, Erik P.S.: A fix for the firewall.local problem comes soon but also in another topic. ---
**Author:** ![mumpitz](https://community.ipfire.org/user_avatar/community.ipfire.org/mumpitz/32/15450_2.png) [@mumpitz](https://community.ipfire.org/u/mumpitz)\ **Post date:** [20 January 2024 12:39 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/8 "2024-01-20T12:39:40Z")
Hi @ummeegge can you plz link this other thread? ---
**Author:** ![ummeegge](https://community.ipfire.org/user_avatar/community.ipfire.org/ummeegge/32/12650_2.png) [@ummeegge](https://community.ipfire.org/u/ummeegge)\ **Post date:** [25 January 2024 12:33 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/9 "2024-01-25T12:33:40Z")
If i have the time for it, yes. ---
**Author:** ![mumpitz](https://community.ipfire.org/user_avatar/community.ipfire.org/mumpitz/32/15450_2.png) [@mumpitz](https://community.ipfire.org/u/mumpitz)\ **Post date:** [2 February 2024 22:29 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/11 "2024-02-02T22:29:50Z")
@ummeegge I have an e-mail with an answer from you, but don’t see it here. Deleted? ---
**Author:** ![ummeegge](https://community.ipfire.org/user_avatar/community.ipfire.org/ummeegge/32/12650_2.png) [@ummeegge](https://community.ipfire.org/u/ummeegge)\ **Post date:** [3 February 2024 18:43 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/12 "2024-02-03T18:43:36Z")
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](https://bugzilla.ipfire.org/show_bug.cgi?id=13563) you can check it out, comment and or test it too. Best, Erik ---
**Author:** ![ummeegge](https://community.ipfire.org/user_avatar/community.ipfire.org/ummeegge/32/12650_2.png) [@ummeegge](https://community.ipfire.org/u/ummeegge)\ **Post date:** [30 December 2025 19:15 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/13 "2025-12-30T19:15:51Z")
Hi @mumpitz , long time ago i know but this bug [13563 – IPSet sets in firewall.local getting destroyed if the firewall will be restarted](https://bugzilla.ipfire.org/show_bug.cgi?id=13563) 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 ```diff --- /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 ---
**Author:** ![mumpitz](https://community.ipfire.org/user_avatar/community.ipfire.org/mumpitz/32/15450_2.png) [@mumpitz](https://community.ipfire.org/u/mumpitz)\ **Post date:** [31 December 2025 04:47 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/14 "2025-12-31T04:47:18Z")
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 ---
**Author:** ![ummeegge](https://community.ipfire.org/user_avatar/community.ipfire.org/ummeegge/32/12650_2.png) [@ummeegge](https://community.ipfire.org/u/ummeegge)\ **Post date:** [31 December 2025 09:11 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/15 "2025-12-31T09:11:34Z")
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](https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=6d5ab1654f674a3ea1e2dec4c6ea83067061dd01) . The diff can be found here [git.ipfire.org Git - people/ummeegge/ipfire-2.x.git/blobdiff - config/firewall/rules.pl](https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=blobdiff;f=config/firewall/rules.pl;h=ebcee2e934f3535fcbc3fbb66702b4a6e6e92c3e;hp=c414f172ce8fdbe58f5b2aa7fd446e11024c1d43;hb=6d5ab1654f674a3ea1e2dec4c6ea83067061dd01;hpb=4f8e2a859cb8995da5d45fa732403b38b73fc055) 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](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: ```bash # 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](https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=blob;f=config/firewall/rules.pl;h=ebcee2e934f3535fcbc3fbb66702b4a6e6e92c3e;hb=6d5ab1654f674a3ea1e2dec4c6ea83067061dd01#l32) 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 ---
**Author:** ![mumpitz](https://community.ipfire.org/user_avatar/community.ipfire.org/mumpitz/32/15450_2.png) [@mumpitz](https://community.ipfire.org/u/mumpitz)\ **Post date:** [31 December 2025 16:15 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/16 "2025-12-31T16:15:52Z")
> [@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 ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [31 December 2025 16:19 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/17 "2025-12-31T16:19:29Z")
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. ---
**Author:** ![mumpitz](https://community.ipfire.org/user_avatar/community.ipfire.org/mumpitz/32/15450_2.png) [@mumpitz](https://community.ipfire.org/u/mumpitz)\ **Post date:** [31 December 2025 19:56 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/18 "2025-12-31T19:56:26Z")
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? ---
**Author:** ![ummeegge](https://community.ipfire.org/user_avatar/community.ipfire.org/ummeegge/32/12650_2.png) [@ummeegge](https://community.ipfire.org/u/ummeegge)\ **Post date:** [2 January 2026 11:52 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/19 "2026-01-02T11:52:50Z")
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 ---
**Author:** ![mumpitz](https://community.ipfire.org/user_avatar/community.ipfire.org/mumpitz/32/15450_2.png) [@mumpitz](https://community.ipfire.org/u/mumpitz)\ **Post date:** [2 January 2026 16:46 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/20 "2026-01-02T16:46:37Z")
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. ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [2 January 2026 17:20 UTC](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697/21 "2026-01-02T17:20:30Z")
> [@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](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. [Next page](https://community.ipfire.org/t/tor-stop-working-without-stop-the-process-or-give-an-error-message/10697.md?page=2)