Green is a fine LAN, but in BLUE are maybe kiddys 
I try to deny the access to the IPfire WebUI from the BLUE LAN. I found [wiki.ipfire.org - Blue Access] in the wiki.
Bad I get this message if I follow the recommendation.
iptables: Bad rule (does a matching rule exist in that chain?)
I think there are some steps missed until this rule can set.
1 Like
I believe you do not have to use the console for this rule. You can set it up from the Web User Interface.
Source: standard network - blue
Destination: firewall (BLUE or ALL)
Protocol: TCP
Destination Port:444
Drop OR Reject
Keep in mind that if you use Squid, you need to secure also the access to WUI through the proxy using ACL (Access Control Lists).
2 Likes
I think that the rule has to be put in firewall.local with a custom chain because it is allowed in a firewall rule that occurs before the WUI table is reached. Not 100% certain but that is my understanding.
Can you please show the contents of your firewall.local file.
#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
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
iptables -D CUSTOMINPUT -s 192.168.23.0/24 -p tcp -d 192.168.23.2 --dport 444 -j DROP
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
It was C&P from the wiki. Afterwards I have edited the IP nothing else.
Yes, now I remember this detail. I take back my answer. Thank you for the correction.
EDIT: I documented this in the wiki: wiki.ipfire.org - Blue Access
@cfusco @bonnietwin
Do end-of-line characters make a difference to the interpretation of the contents of the firewall.local file?
So I followed the same approach on my system using C&P from the wiki and then just changing the ip address sections.
I ran start and stop on it and it executed without any issues.
Just to confirm, 192.168.23.2 is the ip address of your blue interface on IPFire.
1 Like
if the rule already exists in different chain or table can give that error. Maybe @berny has this rule in the WUI too?
Also, the rule does not exists the first time the script is stopped, giving the error. Subsequent start/stop should work. To search for a similar rule somewhere else:
iptables -L -n | grep "192.168.23.0/24.*192.168.23.2.*tcp.*dpt:444"
1 Like
I don’t know. Maybe. I used C&P also but this was done on a Linux system. If @berny did it on a Windows system that might make a difference but I am not sure I would expect the error shown then. That error seems to indicate that there is already a rule in place that is dealing with the same issue already in the CUSTOMINPUT chain.
2 Likes
How do you restart?
I used:
# /etc/rc.d/init.d/firewall restart
Yes, indeed.
The way to check.
I ran the stop command on the firewall.local and then on the WUI menu - Firewall iptables I selected CUSTOMINPUT in the top table and pressed the update button. I got the following
Then I ran the start command to load the rule and got
If @berny looks at the CUSTOMINPUT chain in the iptables menu section after running firewall.local stop then it will show what is already present there.
EDIT:
and of course running the firewall.local start command and then re-checking the CUSTOMCHAIN to see if anything is different.
2 Likes
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 …