Pass firewall rules are logged blocking packets, even after deleting the rule, after upgrade to 24.03
-
I upgraded today to pfsense 24.03 on netgate 7100. I noticed new firewall logs showing a pass firewall rule with the red X that the traffic is being blocked. I don't understand how a pass rule is blocking traffic?
The rule is to allow IGMP traffic from a subnet address to 224.0.0.0/4. I also tried allowing options in the advanced tab, but it was still showing the blocked traffic in logs. Then I tried disabling and enabling the rule, doing a Firewall Reload, and finally deleting the rule completely and then creating the a new rule with the same parameters.
Now I am getting blocked firewall logs for the deleted rule ID and the new rule, which both rules were set to pass. I'm thoroughly confused and don't know where else to troubleshoot this issue. I didn't have these logs occurring prior to the upgrade. I did a search through the config.xml file for the deleted rule, since it is still being logged, and the rule ID does not appear anywhere in the config.xml. This is still persistent even after a reboot.
Any recommendations?
-
@sgnoc it’s expected. https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options
We just created a specific block rule to not log it.
-
I still have no explanation for this one, but I managed to get the symptoms to go away.
After troubleshooting different options over the last several hours, I finally was able to get the existing rule to stop showing blocks on the firewall log by changing the source to any from the subnet. Then I was left with the phantom deleted rule that was still showing blocking. I performed another reboot, and that seemed to go away too.
After both were no longer alerting, I then changed the existing rule from any source back to the original subnet option, and it seems to still be functioning as expected. I verified by viewing the states table and it shows the previously blocked IPs with successful connections for IGMP on that subnet.
I have zero ideas what this was all about, other than some strange fluke. I've never seen this issue happen before, and don't really know why/how I got it resolved since it shouldn't have happened in the first place. Definitely odd a pass rule blocking traffic in the firewall logs, and then a deleted pass rule continuing to block traffic after filter reloads, and reboots. But in the end I got things working again. If anyone has any input on what may have caused it, I'm still very interested.
-
@SteveITS said in Pass firewall rules are logged blocking packets, even after deleting the rule, after upgrade to 24.03:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#packets-with-ip-options
One of the troubleshooting steps I did early on was to enable the IP Options under the advanced tab, and even after a filter reload (which should have happened after saving the rule, if I am thinking correctly) the rule was still blocking (with the IP Options checked).
The really odd thing was the deleted phantom rule continuing to block, but I did have the IP Options selected with the same result of blocked traffic and no states being created.
-
@sgnoc I may have misunderstood the question…
There was someone the other day where a rule loading error was causing confusion.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/firewall.html#new-rules-are-not-applied -
@SteveITS I can't explain it either. I didn't add or remove any rules. The only change was to upgrade from version 23 to 24.09, then I began showing block logs on a rule that was set up as a pass rule for IGMP traffic on one interface only.
I then tried a bunch of options to get the rule to work, eventually deleting the rule and creating a new identical rule. Then the phantom deleted and new rule were both blocking traffic, even though they were pass rules. I had the IP Option checked early on in one of the troubleshooting steps I was going through.
The only thing that has seemed to fix it was to change the existing pass rule source from the subnet 10.10.45.0/24 to any, and then reboot the router again (I rebooted previously too with no change in behavior).
Once I rebooted, the blocked traffic was resolved, so I changed the source from any back to the subnet. Now everything is working. I'm baffled, but it's solved and I can't repeat it, which isn't very helpful to anyone.
I appreciate the help with the articles. If there is any way I can try and provide additional details, I'd be happy to.
-
Same problem here. I have an explicit pass rule for IGMP traffic that I enabled IP options on. The traffic is passing (verified with a tcpdump filter of
igmp and ip[0] > 69) and yetfilterlogis still recording it as being blocked and filling up the logs. The traffic is matching the rule without a log option...This feels like a regression, but this bug says it's not.