OPNsense Forum

Hello,

After having read the "hot" topic about automatically generated rule, I had a look at the generated rules on my opnsense instance. I was surprised to see that two "CARP default" rules are generated for each interface.

As I'm not using CARP, nor virtual IPs, this looked strange, so I clicked on the looking glasses icon next to the two rules, which lead me to a "page not found" (firewall_virtual_ip.php).

If there was no "looking glass" and no "page not found" I would have said nothing, but this looks like a UI bug to me. Or am I missing something ?

Note: Since I started writing this post, I checked the github repository and someone suggested to only add these rules only if Virtual IP interfaces are configured. However he got no answer since last may. https://github.com/opnsense/core/issues/6556

Thanks in advance and kind regards,

M.

There is also https://github.com/opnsense/core/issues/6539

In practice more tickets do not help with the discussion.


Cheers,
Franco

@Franco: I read the ticket you're providing, let me quote some messages AdShellevis sent to rudiservo the author of the ticket I was writing about:

Quote
the ticket is for a different issue

Quote
Please keep discussions on the forum.

Quote
don't mind if you open a new ticket for it to put it up for debate

In the end rudiservo did it and it resulted in the ticket I linked in my question. He never got an answer since May. He forgot to link back his ticket to the ticket you're mentioning. I just added the link to make things clear.

In other words:

• The ticket you're referring to is for a different issue
• I have not created a new ticket, I linked to the ticket which has been open in May about the issue I'm talking about
• this is an open topic
• i reopen the discussion here on the forum as requested on github

That being said:

• why is there a "page not found" when clicking on the looking glass ?
• If it is due to the fact that no virtual IP are configured: why having the CARP rules being generated if CARP is not configured ?
• If it is mandatory for some reason I cannot yet understand: why having a looking glass next as it leads to a page not found?

To me it looks like there is a bug somewhere:

• There should not be a "page not found" OR
• There should not be CARP generated rules if CARP is not used OR
• There should not be a looking glass next to the rule

Or maybe I'm missing something. If that's the case, please explain.

1. https://github.com/opnsense/core/commit/d9fcc0bbbf0
2. Why yes. Why not is the same type of question. It will probably lead to disruption somewhere depending on this (inherited?) default.
3. Why will nobody report a bug about this to have it fixed? Why must it be me? ;)


Cheers,
Franco

Are the rules really generated for each interface?

From what I see, the rules are generated in "Firewall: Rules: Floating" and because "any interface" is set there, all other interfaces inherit these rules.

@67 pass log quick inet6 proto carp from any to ff02::12 keep state label "8536b4a11fbacd6adaebd0cf9d91aeeb"
@68 pass log quick inet proto carp from any to 224.0.0.18 keep state label "05400a7f8083285e1da2257e85fecd27"

Also the rules have the protocol CARP set and multicast destinations ff02::12 and 224.0.0.18, which is very restrictive. They're link local addresses and not routed. (Unless in very specific setups that have the goal of routing multicast traffic). So I think the rules are rather safe and should have no impact on security.

Bonus:

There's also two auto generated NAT and RDR rules:
@0 no nat proto carp all
@0 no rdr proto carp all

Well, I see the two "CARP defaults " rules on all my interfaces: WAN, LAN, DMZ, all vlans, OpenVPN, and even Loopback. If they are only generated once as floating then inherited, fine.

The question was about the rationale for having these two rules (+ the NAT ones @Monviech spotted).

• Generating them when having at least one virtual IP with CARP mode declared in "/ui/interfaces/vip" is understandable and required.
• But if no virtual IP in CARP mode are declared I don't understand the rationale, and thus I suggest to have it would be great if someone could have a look at the ticket #6556 (see first post).
  

But again, maybe I'm missing something.

I think you could follow the same argument about other auto generated rules too. For example, why are there all those "IPv6 RFC4890 requirements (ICMP)" if somebody doesn't even use IPv6?

I think it's a design choice to prevent common mistakes generating lots of support.

I'm not choosing a side here though, just contributing my opinion.

(My opinion is I like those rules because they save me time and prevent human error while not impacting security)

Not only that, it generates generic rules on all interfaces, do not open stuff where you don't need be open.

Quote from: Monviech on September 26, 2023, 04:05:52 PM
I think you could follow the same argument about other auto generated rules too. For example, why are there all those "IPv6 RFC4890 requirements (ICMP)" if somebody doesn't even use IPv6?

I think it's a design choice to prevent common mistakes generating lots of support.

I'm not choosing a side here though, just contributing my opinion.

(My opinion is I like those rules because they save me time and prevent human error while not impacting security)

Indeed, this might also apply to the case you just listed.

I'm not against generating rules whenever it allows to avoid common mistakes: that's a great helper feature which needs to be kept. I'm against generating them when they are not needed as it has a performance impact and configuration readability impact.

Regards,

I see the point about having the ref link that leads to a page where the rule can't even be disabled. I'm not sure why it's there then in the first place.


Cheers,
Franco

I want to add a little broader picture, since I've made two GUI extensions in the new IPsec MVC model and view part of the OPNsense firewall. Everything there looked very clean, easily maintainable, and even with my limited knowledge of programming it was easy with the help of AdSchellevis to implement a new feature.

Then I thought, how about I look at the Firewall. There's this button that enables and disables logging, it would be neat to have in the NAT rules as well. That's the first time I saw the old structure thats slowly but surely superseded by the great MVC approach. I have seen the https://github.com/opnsense/core/tree/master/src/www firewall*.php files, that combined model, view and controller in different files that seem to cross recerence each other. I would need weeks to understand this, those files don't look easily maintainable.

So, coming from that perspective, it makes sense that those firewall*.php files aren't edited a lot. Because right now they're in a good known state, and all bigger changes influence the most basic function of the firewall for all users.

My personal opinion would be, that the maintainability of those parts should have priority over changing things that don't even improve security by thaaaat much.

Which means, maybe if there's the conversion of those firewall parts to mvc at some point, it will be way easier to create new model and view parts that influence the controller part below to autocreate rules or prevent it from doing so.