Being relatively new to Opnsense, I am perplexed as to why I can't get any rule to work with Opnsense, and after installing a default firewall and setting-up adapters, I then proceed to creating a simple rule to block a single device without any effect whatsoever.
That being said, I would add that I have moved the rule to the top of the list in the LAN ruleset page, followed by a reboot(just to be absolutely sure), the rule doesn't appear in any log, nor can I see any change in the network appliance(security camera).
Anyone have any suggestions as to why that is?
NB, have also tried conventional as well as floating rules, ipv4, as well as MAC assignments(for device), without any change or success
- I am truly stumped as to why this isn't working, and in-contrast with OpenWRT or Sophos, which work without issue whatsoever, create rule, hit apply etc
There are implementation details that could be causing your issue... but most are somewhat unlikely. You did say that you hit "Apply" - that's often missed. Changes that are applied generally take effect immediately (there are exceptions, but again they are uncommon). The UI is a bit inconsistent about requiring "Apply" after "Save" - it is dialog-dependent. But I imagine you'd notice your changes disappearing after a reboot.
The first thing I'd do is hit Firewall: Settings: Advanced, roll down to Logging, check 'em all, and Save. You can disable them later if you wish; I enable all logging (and use an SSD that can endure the constant writes). You should also enable logging within your own rules. Then sit in the Firewall: Log Files: Live View and watch for your packets. If they are passing through the filter rules, they should be logged.
In Firewall: Diagnostics: Statistics, go to the Rules tab - you can have a look at the ruleset. You should be able to locate your rules, and also check them for matches.
If you still can't see your issue, post more details about your config and topology and what you're seeing.
(Config that can prevent rules from functioning include Firewall: Settings: Advanced: Disable Firewall and attempting to filter on a bridge member interface.)
Correct, the fist question is, did you move it at the top and did you hit apply.
Second show that rule, make a picture and post it.
Regards,
S.
First-off, I just want to thank-you for taking the time to answer, I've been going nuts trying to figure this out lol
That said, I would also add that I can block the device(camera), in Zenarmor policy/device, without issue whatsoever
NB, my Opnsense/Zenarmor is on another Opnsense VM(same Proxmox), and is separate from this instance, though I did clone the original VM, and reinstalled Opnsense for testing
Quote from: pfry on January 11, 2025, 04:25:45 PMYou did say that you hit "Apply"
Yes, correct, each and every time :)
Quote...sroll down to Logging, check 'em all, and Save.
Check
QuoteIn Firewall: Diagnostics: Statistics, go to the Rules tab - you can have a look at the ruleset
Correct, in-that the rules can be seen under the filter listing - would also add that the alias' are showing good with 'pfctl -t <name> -T show' command
Quote...post more details about your config and topology and what you're seeing
Before getting into that, I would add that Zenarmors(Policy), can and will effectively block the device without issue, and on the very same hardware and setup
That said, I am running Opnsense in a Proxmox instance(VM), with an a-typical adapter setup(LAN/WAN), no fw restriction etc, whereas Opnsense itself is default, no config beyond basic wizard - no bogon, network restrictions etc
QuoteFirewall: Settings: Advanced: Disable Firewall and attempting to filter on a bridge member interface.)
Check
- hope this helps
NB, I opted out in posting screenshots in this particular response, and will provide any logs/screens upon request past this point, and in the event that something may jump-out with the above posted information
Well, the point of all of the logging was that every packet originating from or forwarded by OPNsense would hit a filter and show up in the logs. They should also be counted by pf. What are you seeing there?
Quote from: pfry on January 11, 2025, 06:08:37 PMWell, the point of all of the logging was that every packet originating from or forwarded by OPNsense would hit a filter and show up in the logs. They should also be counted by pf. What are you seeing there?
I see no sign of the device(IP) in: Firewall: Log Files: Live View whatsoever
I'm not at all familiar with virtual environments. I assume you can check ARP (Interfaces: Diagnostics: ARP Table, but it sounds like you prefer CLI). A traceroute should indicate whether the path is through OPNsense (via the trace itself and filter logs). Consider path asymmetry (not knowing your topology), particularly with a bunch of "pass" rules.
Also, your answer suggested that you do see traffic, just not your targeted element(s). Are the rules operating as you expect otherwise?
Quote from: pfry on January 11, 2025, 06:46:25 PMAre the rules operating as you expect otherwise?
I am please to announced that I have since resolved this particular challenge - the issue being due to several factors;
1. choosing OUT instead of IN, on the rule Direction - instinctive from other router software
2. Destination being set to 'Wan net', where this device required LAN level packet intervention
3. the need for resetting State Table, following rule change
These particular parameters, and in no particular order, were keeping the firewall rule from working as intended.
That said, and after adjusting and/or correcting the above, the device is no longer broadcasts outside world from LAN as intended.
And while it is obvious that this is on me, I'm left feeling as though State table rest should be part of the apply function
Quote from: JohnBee on January 11, 2025, 07:42:21 PM[...]
That said, and after adjusting and/or correcting the above, the device is no longer broadcasts outside world from LAN as intended.
[...]
I'm left feeling as though State table rest should be part of the apply function
I didn't even consider rule direction being an issue. I'm very explicit with my rules, so visualizing others' can be tough.
First: Gateway issue? Seems unlikely, but hey.
Second: So long as it's optional! But the option might be a nice convenience addition, a reminder. We can all use those occasionally. Also, resetting only appropriate state would be nice - not sure of the practicality of that. Three buttons: "Apply" "Apply and reset affected state" "Apply and reset all state"? (Big buttons...) Anyway, it's been discussed plenty, but I'd have to dig through it all (here, GitHub, and likely IRC, where I wouldn't see it). (Any participants reading this?)
Quote from: JohnBee on January 11, 2025, 07:42:21 PM1. choosing OUT instead of IN, on the rule Direction - instinctive from other router software
2. Destination being set to 'Wan net', where this device required LAN level packet intervention
If you had posted a screen shot of your rules list, that could have been spotted instantly. It's a common mistake.
OPNsense unfortunately has no concept of "from <zone> to <zone>" as it was called in Sidewinder. It's all IP addresses, so the Internet is by definition always "any".
Blocking OUT rather than IN seems unusual. If I interpret the need correctly, I too use an Opnsense internal firewall to stop an NVR from reaching the internet. First rule redirects NTP to local, next (IN) blocks any to any. Job done. No table reset was required. The NVR is reached by NAT in from local sources, being my trusted LAN or the VPN.
The IN OUT confusion is not uncommon for new users.
When people post their LAN -> WAN rules, I often see comments with out or outbound (looking at it from the perspective of their network), even when they have the correct direction.
With regards to Apply resetting the states, it's not going to happen.
It's actually pretty disruptive to all existing VALID traffic. All clients will try (and fail) to use their existing connections, retry a few times before they decide to start over. In the meantime, the live view will be inundated with state violtions.
IIRC, the "reset state table" button is pretty explicit that it should be reserved for significant changes to the FW rules.
This said, everybody can search the state table and surgically delete the entries that need to be reset.
You can as well reset only specific connections.... Either one by one or as a specific searched group.
Regards,
S.