A firewall administrator should have explicit control over all of the rules defined in a firewall they manage.
OPNSENSE should NOT automatically generate firewall rules.
It is especially poor for one of those rules to be the base rule that says pass any traffic to any destination where that traffic originates from the firewall.
There are two assumptions behind that which says that (i) all traffic from the firewall is traffic the firewall administrator would wish to allow to pass and (ii) a bad actor, knowing the nature of the system generated rules, would be incapable of duping the firewall to do things not intended by the firewall administrator or its designers.
Uh, no, not this again. Please.
Cheers,
Franco
Quote from: franco on October 06, 2025, 04:10:17 PMUh, no, not this again. Please.
Ah, but why would it continue to show up? So yes! Read it all again!
Quote from: RMLNZ on October 06, 2025, 03:33:30 PMA firewall administrator should have explicit control over all of the rules defined in a firewall they manage.
Agreed, but there is a bit of nuance. I'd be happier with the ability to simply add my own (namely a block rule at the top of the list). The design of pf makes this a bit of a pain in the ass to do cleanly, and of course there are legacy considerations.
Realistically the only inbound vulnerability is IPv6 ICMP. Now, I permit lots of ICMP as a matter of course, but it would be nice to cover it with a block. The actual chance of a meaningful exploit (DoS or resource consumption) is pretty minimal (address space under attack must be accessible to the attacker). Still, firewalls are a numbers game.
Quote[...]
It is especially poor for one of those rules to be the base rule that says pass any traffic to any destination where that traffic originates from the firewall. [...]
Yeah, here again, you could get very detailed with the outbound filter, but, yet again, it's difficult to impossible to do cleanly. And realistically you must trust your firewall. You can nitpick services, but the chance of a real exploit of the firewall that would be meaningfully affected by an outbound filter on the firewall itself is pretty small.
If I was designing a network filter, I'd plug the holes, because I could. And really for no other reason.
I might consider promoting alterations to the automatic rules (again), but I'd expect to have to fund and/or contribute (the code) to them. And, of course, they'd have to be accepted. I don't know that I have enough liquor, hookers, and bribe money.
So you have the awful rule "anything from the firewall may pass".
Point your PC clients at the firewall's DNS for DNS services.
The DNS server is part of the firewall and therefore its traffic is passed automatically.
Any rule you define at the floating or interface level filtering traffic on the outbound WAN to a defined external DNS server address [eg OpenDNS] will fail to filter your outbound DNS traffic
because it is passed based on the fundamentally flawed, higher priority, system generated "permit all from the firewall itself" rule.
I'll bet that the KGB/CCP just loves the fact that OPNSENSE runs an open gateway on the internal DNS server by default and you can't seem to delete that stupid base rule.
Oh yes, plenty of malware uses DNS to exfiltrate data by talking to its preferred DNS server. Nicht wahr ?
A key point is that a firewall should obey its own rules.
If there are missing rules and firewall stuff won't work, then the fix is to add or modify the rules so that it does work.
The ONLY rule that should exist by default at a system level on a firewall is:
- Block Everything on Every Interface whether Inbound or Outbound
Thereafter, traffic can only be passed by explicit approval of the firewall administrator.
Why ? A firewall is NOT meant to be a router. It is meant to be an obstruction first, foremost and always.
There is a need to define a new mode of OPNSense called "Strict Security Mode" which enforces one base rule of:
- Block Everything on Every Interface whether Inbound or Outbound
An installation step will require you to nominate a management interface so inbound SSH and HTTPS can be permitted on that interface (assume LAN).
A life saving console command should be available to "permit management access on interface x" in case you mess up your rules and find yourself in need of resurrection :)
OPNSense should also consider the risk of changes in its software introducing new "system generated rules" that contradict user (firewall administrator) wishes.
Please look at how the automatic generated rules are created.
Let's take the automatic out rule for example:
pass out log all flags S/SA keep state allow-opts label "1232f88e5fac29a32501e3f051020cac"
As you can see, pass out has no "quick" option defined, which means its a last matching rule - "AFTER" your already existing ruleset.
Which means, go to "Firewall - Rules - Floating" and create a rule like this:
block out quick log all flags S/SA keep state allow-opts label "1232f88e5fac29a32501e3f051020cac"
Quick matches first, you can overrule most of these automatically generated "last match (non quick)" rules with your own quick rules in Floating like this.
No need to get dramatic.
Automatic rules exist to get the firewall up and running quickly by offering minimal invasive rules for each protocol like DHCP -- should we expect everyone to go to the docs page and copy a rules block into their firewall?
> So you have the awful rule "anything from the firewall may pass".
One simple problem that Cedrik mentioned the fix for.
> Oh yes, plenty of malware uses DNS to exfiltrate data by talking to its preferred DNS server.
Disable DNS if you don't need it and/or deem it is not safe enough?
I'm not quite understanding the scope of this issue.
Quote from: Monviech (Cedrik) on October 07, 2025, 08:07:34 AM[...]As you can see, pass out has no "quick" option defined [...]
Ha! I keep missing that. I'm so accustomed to simple rule systems.
Note that I have no outbound rules, nor do I plan to create any. I simply log everything, and the default outbound rule is quite chatty (good old pf logging).
Quote from: franco on October 07, 2025, 08:38:30 AM[...]
I'm not quite understanding the scope of this issue.
This forum is just too convenient. I don't think discussion of this is entirely wasted bandwidth, but perhaps meyergru would be willing to add a "point 24 (https://forum.opnsense.org/index.php?topic=42985.0)": "Stop worrying and love the automatic rules - they are better considered than you think." I don't believe there is a single concise explanation of this in the docs (correct me if I'm wrong). The rule design, behavior, and actual risks are non-obvious, particularly to new users.
In my experience commercial firewalls tend to be much worse in this respect. Local rules tend to be fully or partially hidden and/or read-only, and logging is often at least partially suppressed. Only routers (e.g. Cisco, Juniper) offered full control, but I can't say if that's the case now, as their firewall architectures have evolved considerably since I used them.
> This forum is just too convenient.
Which is good :)
> Local rules tend to be fully or partially hidden
Interestingly enough the complaints for bad automatic rules started to rise with the fact that we made them visible in the GUI in OPNsense 19.7. It wasn't possible to review them before that and not sure how pfSense fares in this nowadays either. At one point someone blamed us for silly automatic rules threatening to rather use pfSense. It's difficult to make such stories up even if one tried.
Cheers,
Franco
I did worry the return of this topic would create another mini storm but didn't, which is good.
That said, the lines that caught my eye and got me wondering are these:
QuoteThere is a need to define a new mode of OPNSense called "Strict Security Mode" which enforces one base rule of:
Block Everything on Every Interface whether Inbound or Outbound
Is there any merit in considering very quickly if such an option can be considered IF is as simple as Option A (strict security mode) or B (default) and all option A does is skip the code that has the rules generation ?
What I mean is that if it's "easy" and low maintenance i.e. does not require to maintain two code sections, then it might provide what some people want to see.
And I get it that the current rules are very sensible and there is no actual need of this, but for the sake of allying the recurring queries.
I dont want another spot that can break access completely xD
People can lock themselves out with firewall rules if they want to.
People just love to check every setting that exists even if multiple warning popups warn them not to.
Fair enough.
Anyone who can create rules for ARP and ND from the top of their head and get it right without referring to the docs? Every firewall has automatic rules (like for these two protocols), OPNsense just decided to show them.
> Is there any merit in considering very quickly if such an option can be considered IF is as simple as Option A (strict security mode) or B (default) and all option A does is skip the code that has the rules generation ?
Good question. The basic design decision is scoping... globally or per interface? Default value of the pass out should be created, so you'd add one opt-out setting to each interface.
That's based on Cedriks assumption because the OP did not say clearly (although I suspect this is mainly for local services which only ever see the out direction of an interface since they originate on the firewall) of which rule we talk about. And now we only need a use case so we can explain it easily -- "do not allow all services on the firewall to reach out this interface"?
Cheers,
Franco
> Anyone who can create rules for ARP and ND from the top of their head and get it right without referring to the docs?
As a technical person it would maybe take at least an hour getting a very simple WAN - LAN IPv4 ready (DHCP outside, DHCP inside, routing ok) if no automatic rules were provided. If you then wanted to add them to the docs it would be a lengthy exposition dump and perhaps a typo or two getting them inserted. Everybody would ask them to be moved to the GUI as automatic settings because it seems like the best thing to do. :)
Cheers,
Franco
A good example to show where a lot of people struggle is NAT Reflection.
The documentation must go into a lot of detail.
This would be the exposition dump every single automatic rule would need that has a toggle to enable or disable. And the below is just for a single concept.
https://docs.opnsense.org/manual/how-tos/nat_reflection.html
That's why a reverse proxy is just so much better. After I realised what the automatic NAT reflection mechanism created on all of my interfaces, I instantly disabled it 🙂
Quote from: franco on October 07, 2025, 06:16:56 PM> Is there any merit in considering very quickly if such an option can be considered IF is as simple as Option A (strict security mode) or B (default) and all option A does is skip the code that has the rules generation ?
Good question. The basic design decision is scoping... globally or per interface? Default value of the pass out should be created, so you'd add one opt-out setting to each interface.
That's based on Cedriks assumption because the OP did not say clearly (although I suspect this is mainly for local services which only ever see the out direction of an interface since they originate on the firewall) of which rule we talk about. And now we only need a use case so we can explain it easily -- "do not allow all services on the firewall to reach out this interface"?
Cheers,
Franco
Yes exactly. You're right the requested scope hasn't been clearly defined but since the intent behind what was written was:
Quote from: RMLNZ on October 07, 2025, 03:57:14 AMSo you have the awful rule "anything from the firewall may pass".
..<snip>
If there are missing rules and firewall stuff won't work, then the fix is to add or modify the rules so that it does work.
The ONLY rule that should exist by default at a system level on a firewall is:
- Block Everything on Every Interface whether Inbound or Outbound
Thereafter, traffic can only be passed by explicit approval of the firewall administrator.
Why ? A firewall is NOT meant to be a router. It is meant to be an obstruction first, foremost and always.
<snip>
therefore the "Strict mode" would create none as per the OP's request. As to how useful that'll be is a side debate but would IMHO take away this recurring question. I suspect 99% of new users would either not chose it or have to re-install after realising how well the gun was aligned with a foot.
Quote from: Monviech (Cedrik) on October 07, 2025, 06:53:50 PMA good example to show where a lot of people struggle is NAT Reflection.
The documentation must go into a lot of detail.
This would be the exposition dump every single automatic rule would need that has a toggle to enable or disable. And the below is just for a single concept.
https://docs.opnsense.org/manual/how-tos/nat_reflection.html
I know I wouldn't want to take this path Cedrik. As before, I'm not advocating for it, but to have a thought for this reocurring question from those who think it is how they want it. If it is easy to implement, why not give them the dog's dinner they seem to crave?
Quote from: cookiemonster on October 07, 2025, 10:38:49 PM[...]
If it is easy to implement, why not give them the dog's dinner they seem to crave?
Heh. I hadn't really considered that solution, but... I'd do it. But I know exactly what I'm doing. Or, more correctly, I would figure it out. Any guesses as to what my super-custom rule set would look like?
I'd be ready for that ICMPv6 unreachable attack that has never occurred (to my knowledge, although I've only audited ICMPv4, and the last unreachable attack that I saw was ~20 years ago) and would consume minimal resources on my public servers (that have a bit more significant attack surface and their own firewalls). Oh - once I get IPv6 connectivity, because it's not available. Note that I would have to manually ban any attacker, because I have blanket pass rules for unreachables. Yeah... I'd still do it.
Thank you for the interesting and enlightening posts.
I agree there is immense value in the system generated rule sets to streamline enabling firewall features.
The examples showing the complexity the automated system encapsulates are very helpful.
I really like the way that some system rules are linked back to the enabling GUI fields.
Perhaps I could restate my suggestion as follows:
Add a new mode setting to OPNSENSE called Security Mode:
Default Security Mode - Current behaviour
Strict Security Mode - New behaviours/features to be:
- Default rule is that all traffic is blocked unless explicitly approved.
- The default system generated rule to pass any traffic from the firewall itself is removed.
- If a firewall service needs a rule to work, that rule must be created and approved by the firewall administrator.
- The system generated ruleset could include recommended rules required for firewall operation.
- The system generated rules are all created in a disabled state (except for the default administration access rules).
- The firewall administrator can choose to enable the system generated rules.
- If the firewall administrator wishes they can clone the system generated rules and edit them as they see fit.
Separately, it's suggested we have a new CLI command to "RecoverAdmin InterfaceName" to salvage administration access if a user locks themselves out. I guess this would inject floating, first in sequence quick rules limited to the specified interface.
Also, can we please expand on the description of how the quick / last match rules work ?
Also, can we add an option to the GUI to view the active rule set (eg view /tmp/rules.debug)
Does QUICK operate within a section ?
If no QUICK match is found in the section then is the section processed again looking for the last match ?
OR
Does QUICK operate across the entire rule set first ?
If no QUICK match is found in the ruleset then is the ruleset processed again looking for the last match ?
My two cents on this : my ISP force me to tag outbound icmpv6 RS/NS/NA to a certain COS priority, which I cannot do due to the automatic (quick) IPv6 RFC4890 rules. For now the only solution is to patch filter.lib.inc to add a rule before IPv6 RFC4890 automatic rules. Good thing with opnsense : you can patch some quite easy to read php files, still, it's a patch that might break after any opnsense update. I don't know if a per-interface opt-out setting for automatic rules or a way to add "advanced" rule before automatic rule is better, but I'd be happy with any of the two solution. It's not only about enabling/disabling rules but also about rule ordering +- quick flag. Automatic rule should however stay the default for at least basic firewall operation.
Quote from: RMLNZ on October 09, 2025, 01:18:01 AM[...]
Strict Security Mode - New behaviours/features to be:
- Default rule is that all traffic is blocked unless explicitly approved.
- The default system generated rule to pass any traffic from the firewall itself is removed.
- If a firewall service needs a rule to work, that rule must be created and approved by the firewall administrator.
- The system generated ruleset could include recommended rules required for firewall operation.
- The system generated rules are all created in a disabled state (except for the default administration access rules).
- The firewall administrator can choose to enable the system generated rules.
- If the firewall administrator wishes they can clone the system generated rules and edit them as they see fit.
The first automatic rule is "Default deny / state violation rule":
block drop in [log] inet all label "ecd3a310894625657c6591b80daa956a"
block drop in [log] inet6 all label "ecd3a310894625657c6591b80daa956a"
...So there's your default deny. Just leave that one.
Some of your points are procedural, not functional.
Cloning the ruleset manually is pretty easy; I don't know how difficult it would be to provide the GUI "clone" button for automatic rules. I would create interface rules (mostly), but some prefer floating. Hm: Perhaps, as you have above, include the standard automatic ruleset as floating rules. The user can then disable or delete them as desired. No special administration required.
To be a little more clear, I would propose converting the automatic rules to floating. No other change should be necessary*. This would also place the onus of locking the user out entirely on the user, as it would take a bit of configuration to do so.
* I'm making a significant assumption here, as I haven't used floating rules. Also, there are elements outside of the regular "Firewall: Rules" UI that would need to be considered if the automatic rules are nixed, such as "Interfaces: [NAME]" -> "Generic configuration" -> "Block private networks", "Firewall: Settings: Advanced" -> "Logging", "Firewall: Settings: Advanced" -> "Miscellaneous" -> "Disable anti-lockout", or "Services: Kea DHCP: Kea DHCPv4" -> "Firewall rules", to name a couple.
("Interfaces: [NAME]" -> "Generic configuration" -> "Block bogon networks" already has issues. I should propose funding a fix for that.)
Quote[...]
Also, can we add an option to the GUI to view the active rule set (eg view /tmp/rules.debug)
As in "Firewall: Diagnostics: Statistics" -> "rules"? Or something different?
The idea of an option to make the system generated rules "floating" is excellent and would give me what I want which is at heart full control of MY firewall which runs on MY network. The base block all rule could be generated as the only system generated rule.
I do think there is benefit in always being able to see what the officially recommended system generated firewall rules are so you can see how you have varied them.
Thinking about the logic behind such a change, given a "[Some sort of appropriate label] - not recommended" checkbox, you'd want to be able to check it, apply it, uncheck it, apply it, repeat - without particularly adverse effects.
1) For ultimate simplicity, simply vanish the non-configurable automatic rules on "check" and unvanish them on "uncheck".
2) In addition to #1, add a "clone" button to the automatic rules, which would edit a matching floating rule. I like this one.
[I had a buncha goofy stuff here related to rule conversion, recreation, etc., but complexity=pain.]
The configurable automatic rule behavior would not need to change - they already vanish/unvanish through a checkbox.
How does the UI handle an empty automatic ruleset?
And, of course, what am I missing?