I just started playing with Gateway Groups and in the course of doing this I was experimenting with firewall rules for a particular subnet. I soon noticed the rules showing as enabled and disabled were not reflective of what the firewall was actually letting through. My frustration, self-doubt, and confusion ultimately led to this:
http://nothingunreal.com/dump/opnsense.2024-12-07.fwRuleDesync.PNG (http://nothingunreal.com/dump/opnsense.2024-12-07.fwRuleDesync.PNG)
(http://nothingunreal.com/dump/opnsense.2024-12-07.fwRuleDesync.PNG)
I don't have a certificate for https, sorry.The pings are coming from a VM on my so-called "DMZ" subnet to the OPNsense DMZ interface address. I would expect there to be no reply given the active rules.
- First I checked the automatic rules to see if somehow there was something in there that would let pings through. No, of course not.
- I tried restarting the firewall service via the services widget on the dashboard with no effect.
- I tried option 11 from the console to reload all service with no fix.
- I rebooted the system and then it works as expected and there is no ping reply from the firewall on that subnet.
I did a bunch of enabling, disabling, and applying of FW rules and rebooting. By no means exhaustive.
Ultimately it seems a rule controlling IPv4 ICMP traffic to an interface address may only get one successful toggle-and-apply but more often none, requiring a reboot for a change to take effect. I confirmed the same behavior on my VM incarnation of OPNsense. Both running 24.7.10_2
I don't mean exclusively "ICMP rules" but creating/enabling a blanket block or reject all protocols to the interface also fails to stop ping replies (as in the screenshot).
Simplest way to reproduce I can suggest is making a rule to pass or block pings to an interface, start a repeating ping from some host, and toggle the rule several times and see if the replies start and stop as you would expect.
I have not noticed unusual behavior from any other rules. They continue to pass or block, enable or disable as expected, on command.
p.s. Just as I'm wrapping up, it occurred to me to try a rule blocking ICMP to an external address. I started a ping to 8.8.4.4 then created a new rule to block the ping. No interruption. Reboot and the pings aren't going through.
https://forum.opnsense.org/index.php?topic=30962.0
P.S. There's been some discussion recently about state tracking for ping. It's fairly loose... so stopping ping and starting another one between the same hosts can continue to use a session established by the first ping.
Learning has always been slow and painful for me.
Thanks.
Quote from: dseven on December 08, 2024, 09:38:17 AM
https://forum.opnsense.org/index.php?topic=30962.0
P.S. There's been some discussion recently about state tracking for ping. It's fairly loose... so stopping ping and starting another one between the same hosts can continue to use a session established by the first ping.
so the behavior seems to be ping host OS / implementation specific?
Tested right now on a Mac everything works fine: Toggling on/off a block rule is reflected right away as long as
ping is restarted between:
for ((;;)) { ping -c 1 -t 1 9.9.9.9 | grep "0 packets\|from" ; sleep 1 ; } }
# note: zsh, ping / grep command notation for MacOS
I have the same issue happening. I am beginning to convert my home network over to opnsense. So naturally I dipped my toe in the water with a couple easy rules (pings) to make sure things work as I expect, before moving on to more complicated stuff.
And to my surprise, actually no, they're not working as I would expect - at least not with pings. As soon as any rule permits a ping to go through, that ping will remain in an allowed state until the opnsense system is rebooted, even after the original rule that allowed it is disabled or deleted.
Quote from: jtaylor on January 18, 2025, 10:00:04 PMAs soon as any rule permits a ping to go through, that ping will remain in an allowed state until the opnsense system is rebooted, even after the original rule that allowed it is disabled or deleted.
Instead of a reboot try Firewall > Diagnostics > States > Actions > Reset state table.
HTH
Patrick
Quote from: jtaylor on January 18, 2025, 10:00:04 PM...
And to my surprise, actually no, they're not working as I would expect - at least not with pings. As soon as any rule permits a ping to go through, that ping will remain in an allowed state until the opnsense system is rebooted, even after the original rule that allowed it is disabled or deleted.
A reboot is the most heavy-handed way to cause the state to be reset.
A complete reset of the state table is next. Both methods break all connections. Clients will retry (and fail) until they decide to re-establish connections from scratch. Per message on use of this functionality, it should probably be reserved for major updates to FW rules.
You can search the state table if you want to be more surgical (and you're in a hurry).
Or you can wait about 30 secs (after last ICMP echo reply) for the state to disappear. I believe there's a hint (age & expiry) in sessions but I have not bothered to experiment.