Hello, I discovered a problem with the way rules are managed in IPFire. If I have a DNAT rule to get port 14000, from any, forwarded to an internal port to a specific IP, this rule gets added to NAT_DESTINATION under nat table of iptables. Now if I want to block certain source to that port, whatever way there is to declare it, even if put as a rule higher than the other one, it will be put in INPUTFW or FORWARDFW chain under filter table, which gets evaluated after the nat table, therefore it is not possible to filter packets before they get natted! The drop should be inside another chain or the table mangle. For the time being I added lines in firewall.local to add the drop in the mangle table. I think this should be adressed by IPFire and the rule GUI revised, so that a rule with no nat can be executed before the nat table. Best regards.
Hey Dominic, if I understand your report correctly, there is nothing we can do about it. This is the expected behaviour. The netfilter framework performs the NAT action first and then packets land in the filter table: > https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg If you want to filter those packets, you will have to make the NAT rule narrower that it won't NAT the packets you want to filter later, or specify more precise filter rules.
I do not agree. If a deny rule from the IPFire firewall rule page is done, it does not get a proper priority, which makes the firewall rule page useless for denying access! Presently, this router is being attacked by people from NL and RU, and I am unable to deny them access through the IPFire rule page, I have to manually set this rule in firewall.local file. Thankfully I know enough Linux command to be able to do that, I do not think it is to the grasp of every user using IPFire. This issue is for me a security issue and therefore makes it a very important one to be looked into. Best regards.
Dominic, please do not change the prioritization of this ticket. Could you please post all rules that you created, what has been created in iptables and what you expected instead to make it clear what this bug report is about?
Through the Firewall Rules web page of IPFire, I created a rule to permit all to connect to port 12050, then created a rule to block by GeoIP for NL on that port. The first rule appeared in the "Firewall Rules" section, and the second appeared in the "Incoming Firewall Access". This block rule never happens. I then went to see iptables and this is where I saw that the blocking rule is not in the right group to be processed. Blocking by GeoIP also do not work. I tried the "Firewall GeoIP block" and it does not block attemps from the countries selected. I can see in the firewall logs that the port is being DNAT from IP of those countries. To make the block work, I have to permit a country in a rule, and the other countries are then blocked, but it will be simpler for me to do the reverse, to select which country to block and not to select which to allow. This is an easy reproducible bug, for which I do not agree on the importance selected on this ticket.
Please post screenshots of the configured rules and the output of "iptables -L -nv" and "iptables -t nat -L -nv".
Closing this as there was no reply for ~ 1 year. Please re-test this with the latest Core Update and reopen, if necessary.