Protocol hopopt

[Javier®]

Hello everyone, just one question, why is this protocol not allowed in Opnsense

RFC2710
MLD message types are a subset of the set of ICMPv6 messages, and MLD messages are identified in IPv6 packets by a preceding Next Header value of 58. All MLD messages described in this document are sent with a link-local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [RTR-ALERT] in a Hop-by-Hop Options header.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290407

[pfry]

Are you asking whether OPNsense is affected by the reported bug (which I can't conveniently view), or something else?

[Javier®]

Yes, I'm asking if it's affected and that's why the protocol isn't allowed.
I know that protocol has been a vulnerable point.
I think it's necessary for MLD to function properly.

[pfry]

OK, freebsd.org's "Anubis" bot detection bounces Brave. Grrr.

Anyway, I don't know enough about operating git to locate a commit by hash, so I can't tell when the bug was (supposedly) introduced. It was opened against and patched for 15.0.

But that says little about "OPNsense support", which could mean a couple of things, e.g.:

Base FreeBSD support: MLD appears to be built into the kernel, so support should be "generic FreeBSD 14.3". You might need to set some tunables for a specific application. I can't comment on option preservation in forwarded packets.

Filtering support: Outbound from the firewall should be allowed by the automatic outbound rule ("let out anything from firewall host itself"); this should also take care of outbound traversal, and session setup should handle inbound replies. For initial inbound you'd need an appropriate pass rule, likely with options enabled (under "Advanced features" in the rule definition). But that's a supposition, as I have not attempted to test such. (Note that the automatic rule allows options.)

So I don't see anything offhand other than the possible bug that would disallow MLD in OPNsense. I can't comment on the specifics of feature support and interoperability. Are you seeing an issue?

[Javier®]

I really appreciate the response.
I have no problems, Opnsense works perfectly.
I receive Hop-by-Hop packets and the firewall rejects them, but it doesn't affect the connection.
Thanks for everything.

[BrandyWine]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290407

It does say the bug fix is for version 15-current. I assume the commit hash the comment was for was a v15 commit?

Are we trying to figure out if the same problem is in 14.3?

Interesting I now see a release schedule for a v14.4

Here's the commit(hash)
https://cgit.freebsd.org/src/commit/?h=releng/15.0&id=530c2c30b0c75f1a71df637ae1e09b352f8256cb

The comments made in the bugs link seems to indicate they are not clear as to when the problem came about, was it working in this 530c2c hash commit, or did that commit cause the issue?

[Javier®]

This protocol isn't allowed for security reasons. It's fine, but it's obsolete nowadays. I'm referring to the blocking implemented by FreeBSD. It was vulnerable in MLDv1, but now it's more secure in MLDv2. This protocol is normally only used for MLDv2. It could be allowed in FreeBSD.

RFC 3810 & RFC 9777 (MLDv2) Section 7.4:
Upon reception of an MLD message that contains a Report, the router checks if the source address of the message is a valid link-local address, if the Hop Limit is set to 1, and if the Router Alert option is present in the Hop-by-Hop Options header of the IPv6 packet. If any of these checks fail, the packet is dropped.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290407

Denny Page:
IPv6 Multicast Listener Discovery packets, specifically Multicast Listener Reports, do not contain a Router Alert option as required by the Multicast Listener Discovery RFCs. The lack of a Router Alert option causes Listener Report packets to be discarded by receivers.

Packets that come in do have that option, you can see it in a log. The problem is that Freebsd doesn't recognize the Hop-by-Hop Options Header, and this packet is dropped.

[doktornotor]

Well, I would like to resurrect this topic. My problem is not that it is not allowed, my problem is that it is not allowed but it is impossible to create a manual rule to block HOPOPT without logging. Which is my case leads to tons of log spam. The only option is to disable the default deny rule logging which is sort of suboptimal.

The reason for this being (at least so for as the GUI is concerned) that the protocol is commented out in /etc/protocols (presumably since it conflicts with the IP "pseudoprotocol" 0).

Additionally, the traffic is misidentified in the firewall logs accordingly to the /etc/protocols issue...

Someone with a workaround for this? (Yeah I realize has been basically an upstream problem in libc since forever).

[pfry]

How annoying, especially since the synonym is apparently masked. (A single "protocols" list is ambiguous anyway.) I don't see an easy way to match it. pf should be able to handle "proto 0" syntax, but that's not a GUI option. You could create your own default deny rules that specify typical protocols, but that's not ideal as you generally want to log exceptions, not hide them.

[doktornotor]

Was not a (visible) issue with FreeBSD <=14.x AFAICT this at least wasn't logged until upstream once again "improved" pf. This causes issues with the other Sense as well...

(Also, there's no way to allow the traffic either, as you've rightly noted.)

Unfortunately, with a particular local ISP, this - even after other specific noise mutings, such as:

Code Select Expand

# grep noise /tmp/rules.debug
block in quick on igb0 reply-to ( igb0 192.0.2.1 ) inet proto udp from {any} to {255.255.255.255} port {10002} label "4ea66722-7f72-4d02-bfe9-341a670b6078" # Reduce log noise
block in quick on igb0 reply-to ( igb0 192.0.2.1 ) inet proto udp from {any} to {255.255.255.255} port {5678} label "379c467f-5758-48dd-9a65-2804f67db023" # Reduce log noise
block in quick on igb0 reply-to ( igb0 192.0.2.1 ) inet proto igmp from {any} to {224.0.0.1} label "c04eab15-ccd4-49af-b7b9-e0515ccb3e45" # Reduce log noise
block in quick on igb0 inet6 proto udp from {any} to {ff02::1} port {10002} label "7b9da65d-e25d-44b7-abaa-d6b157fa4cfb" # Reduce log noise
block in quick on igb0 inet6 proto udp from {any} port {5678} to {ff02::1} port {5678} label "b771a400-9e54-442d-8a94-9adf7e9a0052" # Reduce log noise

takes some 60-70% of the logs. (But at least the live view is sort of useable now, doesn't scroll out of the view faster than you can read, which was the state before implementing the above rules.)

pf should be able to handle "proto 0" syntax, but that's not a GUI option

Not convinced it'd match the traffic with this particular HOPOPT packet header. (Did not investigate the source code, though...)

[newsense]

Would it be an option to allow this traffic and redirect it to a virtual interface as a workaround ?

[doktornotor]

Well yes - if you can match it... but - AFAICT you cannot, as discussed above...