Messages

Hi, I have that problem too.

It seems strange to me too, I have to add the rule explicitly
They are allowed but type 130 is not.

From all to all 1,2,135,136
specific, from fe80::/10 to fe80::/10, ff02::/16 128,133,134,135,136

the second rule is out 128,129,,133,134,135,136

Hi everyone, this packet the firewall is blocking is an ICMP type 130 packet. This packet is sent every 125 seconds. It's from my ISP's Cisco.
Opnsense doesn't allow Type 130 by default.

Cisco MLD
General Query (Type 130)
Sent to learn about listeners on the attached link
Sets the Multicast Address Field to zero
Sent every 125 seconds

https://www.cisco.com/c/dam/global/sk_sk/assets/expo2011/pdfs/IPv6_multicast_security_Stefan_Kollar.pdf

I have managed to make the connection more or less stable, explicitly adding FF02:0:0:0:0:1:FF00::/104. Now I don't lose IPv6 over time.
Thank you for your work.

I think the problem is the NICs. I226-V version V2.17-0. I had to configure sysctl to be stable and fast.
hw.igc.max_interrupt_rate: 20000
hw.igc.enable_aim: 0

In this screenshot, version 2 is requested but I do not receive anything.

root@firewall:~ # netstat -sp icmp6
ісmpб:

97 calls to icmp_error
0 errors not generated in response to an icmp6 message
0 not generated because of rate limitation
Output histogram:
packet too big: 94
router solicitation: 1
router advertisement: 40
neighbor solicitation: 10
neighbor advertisement: 6
MLDV2 listener report: 10
0 messages with bad code fields
0 messages ‹ minimum length bad checksums
0 messages with bad length
0 total packets dropped due to failed ND Presolut

Input histogram:
unreach: 41
time exceed: 1
router solicitation: 1
router advertisement: 7025
neighbor solicitation: 6
neighbor advertisement: 5
Histogram of error messages to be generated:
3 no route
0 administratively prohibited
0 beyond scope
0 address unreachable
0 port unreachable
94 packet too big
0 time exceed transit
0 time exceed reassembly
0 erroneous header field
0 unrecognized next header
0 unrecognized option
0 redirect
0 unknown
0 message responses generated
0 messages with too many ND options
0 messages with bad ND options
0 bad neighbor solicitation messages
0 bad neighbor advertisement messages
0 bad router solicitation messages
0 bad router advertisement messages
0 bad redirect messages
0 default routers overflows
0 prefix overflows
0 neighbour entries overflows
0 redirect overflows

Hello, version 2 of Multicast is icmpv6 type 143, is it necessary for the proper functioning of IPv6?
Freebsd doesn't recognize it:

Num  Abbrev.     Description
        1     unreach     Destination unreachable
        2     toobig     Packet too big
        3     timex        Time exceeded
        4     paramprob     Invalid IPv6 header
        128  echoreq     Echo service request
        129  echorep     Echo service reply
        130  groupqry     Group   membership query
        130  listqry     Multicast listener query
        131  grouprep     Group   membership report
        131  listenrep     Multicast listener report
        132  groupterm     Group   membership termination
        132  listendone     Multicast listener done
        133  routersol     Router solicitation
        134  routeradv     Router advertisement
        135  neighbrsol     Neighbor solicitation
        136  neighbradv     Neighbor advertisement
        137  redir        Shorter route   exists
        138  routrrenum     Route   renumbering
        139  fqdnreq     FQDN query
        139  niqry        Node information query
        139  wrureq     Who-are-you request
        140  fqdnrep     FQDN reply
        140  nirep        Node information reply
        140  wrurep     Who-are-you reply
        200  mtraceresp     mtrace response
        201  mtrace     mtrace messages

It's true, thanks

Hello, I have updated to 25.3.1 and have read the release notes.
fixes the state tracking for ICMPv6 neighbor discovery packets through pf.
I have looked in /tmp/rules.debug

pass in log quick inet6 proto ipv6-icmp from {any} to {any} icmp6-type {1,2,135,136} keep state label "09af71b030142498e74912f2a9231e00" # IPv6 RFC4890 requirements (ICMP)
pass out log quick inet6 proto ipv6-icmp from {(self)} to {fe80::/10} icmp6-type {128,129,133,134,135,136} keep state label "247d6ba2cf9b0caa4e483f8f98f7a480" # IPv6 RFC4890 requirements (ICMP)
pass out log quick inet6 proto ipv6-icmp from {(self)} to {ff02::/16} icmp6-type {128,129,133,134,135,136} keep state label "247d6ba2cf9b0caa4e483f8f98f7a480" # IPv6 RFC4890 requirements (ICMP)
pass in log quick inet6 proto ipv6-icmp from {fe80::/10} to {fe80::/10} icmp6-type {128,133,134,135,136} keep state label "27d6e2944dd9de7c2bc048c4d1e9ad96" # IPv6 RFC4890 requirements (ICMP)
pass in log quick inet6 proto ipv6-icmp from {fe80::/10} to {ff02::/16} icmp6-type {128,133,134,135,136} keep state label "27d6e2944dd9de7c2bc048c4d1e9ad96" # IPv6 RFC4890 requirements (ICMP)
pass in log quick inet6 proto ipv6-icmp from {ff02::/16} to {fe80::/10} icmp6-type {128,133,134,135,136} keep state label "9d29c2425a82c03746ea76b6cbdaa92e" # IPv6 RFC4890 requirements (ICMP)
pass in log quick inet6 proto ipv6-icmp from {::} to {ff02::/16} icmp6-type {128,133,134,135,136} keep state label "8f5ab8e9f0470eb9496ed94ec777ecf6" # IPv6 RFC4890 requirements (ICMP)

the rules haven't changed.

Hi everyone, this packet the firewall is blocking is an ICMP type 130 packet. This packet is sent every 125 seconds. It's from my ISP's Cisco.
Opsense doesn't allow Type 130 by default.

Cisco MLD
General Query (Type 130)
Sent to learn about listeners on the attached link
Sets the Multicast Address Field to zero
Sent every 125 seconds

https://www.cisco.com/c/dam/global/sk_sk/assets/expo2011/pdfs/IPv6_multicast_security_Stefan_Kollar.pdf

Thanks for answering, the firewall rules /tmp/rules.debug (set skip on lo0). It is possible to change to (pass quick on lo0 keep state)

Hi, it is possible to return to the policy of lo0 explicitly following ?

Hello everyone, with the default firewall rule ff02::/16, there should be no problem for the firewall to accept ff02::1:ff00:1, I have locks every two minutes, I would have to update the card Drivers network ?, thanks

 block in on igc1: (class 0xe0, hlim 1, next-header Options (0) payload length: 32) fe80::2eb:d5ff:feed:2819 > ff02::1:ff00:1: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff00:1

igc0: <Intel(R) Ethernet Controller I226-V> mem 0x80800000-0x808fffff,0x80900000-0x80903fff at device 0.0 on pci2
igc0: EEPROM V2.17-0 eTrack 0x80000303
igc0: Using 1024 TX descriptors and 1024 RX descriptors
igc0: Using 4 RX queues 4 TX queues
igc0: Using MSI-X interrupts with 5 vectors
igc0: Ethernet address: xxxxxxxxxxxxx
igc0: netmap queues/slots: TX 4/1024, RX 4/1024

igc1: <Intel(R) Ethernet Controller I226-V> mem 0x80500000-0x805fffff,0x80600000-0x80603fff at device 0.0 on pci3
igc1: EEPROM V2.17-0 eTrack 0x80000303
igc1: Using 1024 TX descriptors and 1024 RX descriptors
igc1: Using 4 RX queues 4 TX queues
igc1: Using MSI-X interrupts with 5 vectors
igc1: Ethernet address: xxxxxxxxxxxxxx
igc1: netmap queues/slots: TX 4/1024, RX 4/1024

Hello everyone, my ISP sends me an ICMP ff02::1:f00:1, I have created a firewall rule in WAN to allow.
If i don't believe the rule my local network soon you do not have ipv6 internet access.

WAN --- allow --- ipv6-icmp ---- fe80::/10 ---->> ff02::1:ff00:0/104

As RFC 4291 section 2.7.1 states:

Solicited-node multicast address are computed as a function of a node's unicast and anycast addresses. A solicited-node multicast address is formed by taking the low-order 24 bits of an address (unicast or anycast) and appending those bits to the prefix FF02:0:0:0:0:1:FF00::/104.

Yes, maybe, but I prefer to do it like in IPv4
It works pretty well
I use the /128 address of the isp for dhcp6c, lan is fixed ipv6, while the devices are configured in SLAAC

to exit with the address of the isp, not the devices