Hi, would it be a good idea to change the automatically generated rules for RFC 4890?
# RFC 4890, section 4.4
pass quick inet6 proto icmp6 to { (self) ff02::/16 } icmp6-type \
{ 133 134 135 136 141 142 130 131 132 143 148 149 151 152 153 }
This is after martians.
# RFC 4890, section 4.3
pass quick inet6 proto icmp6 icmp6-type { 1 2 3 4 128 129 144 145 146 147 }
Is this a good idea ?
Is that just a quick idea or do you have specific concerns about what ICMPv6 traffic is currently allowed in OpnSense?
Especially, do you think, that the current OpnSense rules are a) too narrow (i.e. keeps you from doing something that the RFC suggests should be allowed) or b) too broad (i.e. they allow traffic that should be blocked for security reasons)?
BTW: what you see here:
2025-06-09 01_24_47-WAN _ Rules _ Firewall _ OPNsense.mgsoft – Mozilla Firefox.png
is quite unspecific, as you can see when you look at "pfctl -s rules | fgrep ipv6-icmp":
pass in quick inet6 proto ipv6-icmp all icmp6-type unreach keep state label "edc74900ef9803130063a2c556f8deb5"
pass in quick inet6 proto ipv6-icmp all icmp6-type toobig keep state label "edc74900ef9803130063a2c556f8deb5"
pass in quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state label "edc74900ef9803130063a2c556f8deb5"
pass in quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state label "edc74900ef9803130063a2c556f8deb5"
pass out quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type echoreq keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass out quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type echorep keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass out quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type routersol keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass out quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type routeradv keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass out quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type neighbrsol keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass out quick inet6 proto ipv6-icmp from (self) to fe80::/10 icmp6-type neighbradv keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass out quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type echoreq keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass out quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type echorep keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass out quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type routersol keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass out quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type routeradv keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass out quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type neighbrsol keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass out quick inet6 proto ipv6-icmp from (self) to ff02::/16 icmp6-type neighbradv keep state label "3db2f5c2a6d87c6283f0c09d7de4d275"
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echoreq keep state label "8a95206598ee8821126b16907a2c01f1"
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state label "8a95206598ee8821126b16907a2c01f1"
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state label "8a95206598ee8821126b16907a2c01f1"
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state label "8a95206598ee8821126b16907a2c01f1"
pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state label "8a95206598ee8821126b16907a2c01f1"
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echoreq keep state label "8a95206598ee8821126b16907a2c01f1"
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state label "8a95206598ee8821126b16907a2c01f1"
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state label "8a95206598ee8821126b16907a2c01f1"
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state label "8a95206598ee8821126b16907a2c01f1"
pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep state label "8a95206598ee8821126b16907a2c01f1"
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type echoreq keep state label "12c905bd2ba70be7bfb61d98edfe6f9d"
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routersol keep state label "12c905bd2ba70be7bfb61d98edfe6f9d"
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routeradv keep state label "12c905bd2ba70be7bfb61d98edfe6f9d"
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbrsol keep state label "12c905bd2ba70be7bfb61d98edfe6f9d"
pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbradv keep state label "12c905bd2ba70be7bfb61d98edfe6f9d"
pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type echoreq keep state label "d8801e9d70a36766b6dbdb15195ba745"
pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routersol keep state label "d8801e9d70a36766b6dbdb15195ba745"
pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routeradv keep state label "d8801e9d70a36766b6dbdb15195ba745"
pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbrsol keep state label "d8801e9d70a36766b6dbdb15195ba745"
pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbradv keep state label "d8801e9d70a36766b6dbdb15195ba745"
The icmp6-types and addresses are really quite more limited in scope than they seem in the web UI.
So, again: Are the rules too narrow or too broad? If you have any real concerns, you should do a feature request or bug report on Github.
Hi, sorry for the delay in replying, the Opnsense rules in IPv6 are fine, they work as expected, without problems, Opnsense only uses 1 2 128 133 134 135 136 and I think that conforming more closely to RFC 4890 would be more practical and a little more secure.
It can only be either more pratical if you missed something (and if so: what?) or more secure (if the rules allow too much at this time, and if so: what should be forbidden?).
They cannot be both at the same time.
So: What do you think exactly should be added or removed and for what reasons?
130 131 132 143 MLD version 2 is omitted, I think it's necessary. 1 2 128 should be after the Bogonsv6 block and private networks, 1 2 128 are not for local addresses.
This is an old discussion. In principle we should be able to cover the floating pass rules with interface-specific blocks, or at least a floating block (which would be much easier to implement). In practice, the likelihood of an ICMP attack from a blocked source vs. an unblocked one is... well, less. I allow some ICMP from the Internet as a matter of course, and I have not noted an identifiable ICMP attack in 20 years or so. Barring some new vulnerability, it's just another resource consumption DoS.
I understand, would it be useful to allow 130 131 132 143 for MLDv2?
Quote from: Javier® on June 09, 2025, 10:33:05 PMI understand, would it be useful to allow 130 131 132 143 for MLDv2?
I'd definitely pass on it as a default element (as I would with basically all default elements), but if you'd like to promote it as an option in the GUI, go for it.
Hello, I don't see 143 in Gui, it's not available for selection. Only Multicast Listener Report 131
I want to test if it works with my ISP, I get a 131 from my ISP every 2 minutes and I think the reason is that I don't have 143 open