C&P brings an end of \r\n to the file.
-j DROP could result in -j DROP\r with an unknown target. But the error message doesn’t match this situation.
Just to complete the discussion. 
3 Likes
No. to test it just run /etc/sysconfig/firewall.local start for the first time.
EDIT:
I am not sure that restarting the firewall should be any different to what I ran.because somewhere the command to run firewall.local start must be run when IPFire is first booted.
However the above command was what I used an it worked for me in my test.
1 Like
I think the restart command is exactly the reason for the error. Restart means 1) stop, 2) start. When stop is executed, the rule is not yet in the chain, giving the error.
OK, this makes the difference. After that I do not get this message.
… but the reason? I don’t know. Before and afterwards I see the three chains (CUSTOMINPUT, CUSTOMFORWARD and CUSTOMOUTPUT )
Looks like /etc/sysconfig/firewall.local start only add these rule ‘on the fly’.
But, a
/etc/rc.d/init.d/firewall restart
shows the message again.
If I comment out the both lines from the firewall.local file and do a restart the message in question is not shown.
That might be so.
I just quickly looked in the code in the repo. The firewall initscript does not do anything with firewall.local
firewall.local is run when the initscripts are run when starting IPFire after the firewall initscript has run as it has then created the CUSTOMINPUT chain. However if you manually add a rule into firewall.local you can also manually start it.
So a
/etc/sysconfig/firewall.local start
followed by a
/etc/rc.d/init.d/firewall restart
should not show this message. wait a moment … nope. See below:
[sysconfig]# /etc/sysconfig/firewall.local
Usage: /etc/sysconfig/firewall.local {start|stop|reload}
[sysconfig]# /etc/sysconfig/firewall.local start
[sysconfig]# /etc/rc.d/init.d/firewall restart
Setting up firewall
iptables: Bad rule (does a matching rule exist in that chain?). [ OK ]
[sysconfig]#
If I run firewall.local stop so the CUSTOMINPUT rule is removed and then run firewall restart I also get that message.
After running firewall restart when I checked the CUSTOMINPUT chain in the iptables menu it had the rule loaded. So running firewall restart did trigger running firewall.local start.
There is something in the firewall initscript triggering that message but I have no idea what. The firewall initscript is quite long and complicated.
Try doing a reboot of IPFire and see if that message occurs when IPFire re-starts. It might be something that has been happening for a long while if you have rules in firewall.local but no one noticed it till now.
shouldn’t be reload instead of restart?
1 Like
Even on reboot this message is shown …
BTW: When doing a reload instead of a restart, as mentioned by cfusco, this message is not see.
So only on start there seems a rule without a chain …
YES. I can confirm that. When I moved a rule from firewall.local to rc.local the error disappeared. Whatever you put in firewall.local will trigger the error at boot time.
1 Like
You might have figured it…
I just tried that and got no error message.
the difference between restart (equivalent to start) and reload is that with reload iptable_red_up is run while with restart iptables_init is run, which completely clears all chains, including custom chains and then builds them up again.
1 Like
This is my firewall.local
#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
# begin igmpproxy
/usr/sbin/igmpproxy /etc/igmpproxy.conf &
/sbin/iptables -I IPTVINPUT -i red0 -d 224.0.0.0/4 -j ACCEPT
/sbin/iptables -I IPTVFORWARD -i red0 -d 224.0.0.0/4 -j ACCEPT
## end igmpproxy
;;
stop)
## add your 'stop' rules here
# begin igmpproxy
/sbin/iptables -D IPTVINPUT -i red0 -d 224.0.0.0/4 -j ACCEPT
/sbin/iptables -D IPTVFORWARD -i red0 -d 224.0.0.0/4 -j ACCEPT
killall igmpproxy
# end igmpproxy
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
At boot time, or doing firewall restart, I get a double dose of the error message. reload does not give the message. I completely forgot that I moved that rule to rc.local to avoiding seeing the message. I should have reported the problem, but it append a long time ago and I was not sure of what was the problem.
EDIT: this was previously discussed and @jon already came up with the same suggestion I proposed. My brain must have remembered that message without remembering the context. It was not an intuition from my part, just imperfect memory. However, I think that while this was an intuition from @jon in the right direction, the correct diagnosis of this problem is what @bonnietwin said in message 22.
EDIT2: if reported to bugzilla, this will likely be a straight up “won’t fix”. Should we document this in the wiki, in the firewall.local page?
4 Likes
I suspect that you are right on the bugzilla. Nothing is broken and stopping that message is likely not so easy to do in that firewall initscript.
I think a note in the wiki page is a good idea.
I found in the firewall initscript where it calls the firewallctrl program which runs the rules.pl code in safe mode and that code runs the firewall.local command with reload.
1 Like
I just found that this same message has also been seen historically with IPCop. Someone reported the same message 18 years ago.
The feedback there was that firewall. local is run with reload which is stop followed by start.
When firewall.local is run for the first time after a reboot (or a firewall restart) then there are no rules so the stop command has nothing to stop and comes up with the message of Bad rule. What I now realise is that the bit in brackets is actually a question. It is asking is the rule you are trying to remove actually in that chain and of course the answer is no because it is a fresh start.
That is exactly what @jon said in his earlier thread.
Anyway, as that issue has been present in the code for at least 18 years then I think your wiki message is absolutely the correct approach.
2 Likes
yes, but the way the error happens when you do firewall restart is different, right?
1 Like
No, that is what I have realised.
the iptables_init section for restart is the same as doing a reboot. It removes all chains and creates them again from fresh but they are all now empty.
Then the firewall initscript, via rules.pl, calls firewall.local reload which does a stop followed by a start command.
The stop command is telling iptables to remove this rule from the chain but that rule does not exist in the chain, hence you get “Bad rule” and then iptables asks - “does that rule actually exist in the chain that you are asking me to remove it from.” and the answer at that stage of running firewall.local is “no it doesn’t”
2 Likes
I probably need therapy. I cannot stand error messages, especially at boot. Thanks to all the participant to this thread now I know that the error can be corrected by modifying my firewall.local. No need to bother the developers of the project. I simply add an if statement before adding or removing any rule.
#!/bin/sh
# Used for private firewall rules
RULE_INPUT="-I IPTVINPUT -i red0 -d 224.0.0.0/4 -j ACCEPT"
RULE_FORWARD="-I IPTVFORWARD -i red0 -d 224.0.0.0/4 -j ACCEPT"
# See how we were called.
case "$1" in
start)
# add your 'start' rules here
# start igmpproxy
if ! pgrep -x "igmpproxy" > /dev/null
then
/usr/sbin/igmpproxy /etc/igmpproxy.conf &
else
echo "igmpproxy is already running"
fi
# Ensure the rules do not already exist
if ! /sbin/iptables -C $RULE_INPUT 2> /dev/null; then
/sbin/iptables $RULE_INPUT
fi
if ! /sbin/iptables -C $RULE_FORWARD 2> /dev/null; then
/sbin/iptables $RULE_FORWARD
fi
;;
stop)
# add your 'stop' rules here
# Only delete rules if they exist
if /sbin/iptables -C $RULE_INPUT 2> /dev/null; then
/sbin/iptables -D $RULE_INPUT
fi
if /sbin/iptables -C $RULE_FORWARD 2> /dev/null; then
/sbin/iptables -D $RULE_FORWARD
fi
# stop igmpproxy
if pgrep -x "igmpproxy" > /dev/null
then
killall igmpproxy || echo "Failed to kill igmpproxy"
else
echo "No igmpproxy process found to kill"
fi
;;
reload)
$0 stop
sleep 1
$0 start
# add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
This works and no errors!
Hmpf … you are the first. This is my edit:
#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
echo "start custom rules"
iptables -A CUSTOMINPUT -s 192.168.23.0/24 -p tcp -d 192.168.23.2 --dport 444 -j DROP
;;
stop)
## add your 'stop' rules here
echo "stop custom rules"
if iptables -C CUSTOMINPUT > /dev/null 2>&1; then
iptables -D CUSTOMINPUT -s 192.168.23.0/24 -p tcp -d 192.168.23.2 --dport 444 -j DROP
fi
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
Looks like I need therapy, too
2 Likes