[SOLVED] Cannot drop ICMPv6 TIME EXCEEDED packets sent by the firewall itself

[LHSFK]

OPNsense Version: OPNsense 25.1.1-amd64 
OPNsense WAN Address: 1111:111:1111:d00:be24:11ff:fec8:2995 
Downstream Gateway WAN Address: 1111:1111:1111:d80::ed01 

Firewall Rules (Floating Rules): 
1. Drop | Source: Firewall Interface: WAN,LAN | Direction: OUT | IPv6 Protocol: ICMPv6 | Type: Destination Unreachable 
2. Drop | Source: Firewall Interface: WAN,LAN | Direction: OUT | IPv6 Protocol: ICMPv6 | Type: Time Exceeded 
3. Drop | Destination: Firewall Interface: WAN,LAN | Direction: IN | IPv6 Protocol: ICMPv6 | Type: Echo Request 
4. Drop | Source: Downstream Router Interface: WAN,LAN | Direction: OUT | IPv6 Protocol: ICMPv6 | Type: Destination Unreachable 
5. Drop | Source: Downstream Router Interface: WAN,LAN | Direction: OUT | IPv6 Protocol: ICMPv6 | Type: Time Exceeded 
6. Drop | Destination: Downstream Router Interface: WAN,LAN | Direction: IN | IPv6 Protocol: ICMPv6 | Type: Echo Request 

Issues:

Problem with blocking MTR:

The current rules successfully block ping and traceroute/tracert, but fail to block mtr.
The firewall does not drop ICMPv6 Time Exceeded packets generated by itself. According to firewall logs, only the first Time Exceeded packet is blocked, but subsequent packets are ignored. However, packet captures show that the firewall is continuously sending ICMPv6 Time Exceeded packets externally, allowing mtr to detect the path.
Ineffective blocking of Echo Reply:

Attempts to block ping by dropping Echo Reply packets are ineffective. It appears that OPNsense has limited control over outbound ICMPv6 packets generated by itself, even when rules are explicitly configured.

[pfry]

[...] It appears that OPNsense has limited control over outbound ICMPv6 packets generated by itself, even when rules are explicitly configured.

Have a look at the "Automatically generated rules". You cannot override them with floating or interface rules, so: correct.

[franco]

I'm not even sure you can prevent the kernel from emitting these messages since they don't run through the firewall:

https://github.com/opnsense/src/blob/b8ab1d06e8048a6/sys/netinet6/ip6_fastfwd.c#L150-L151


Cheers,
Franco

[LHSFK]

Okay, in future updates of OPNsense, could hooks be added to intercept these packets directly generated by the kernel?

[franco]

Since this is far from OPNsense core territory and hasn't changed in decades I doubt it will change now.


Cheers,
Franco

[Patrick M. Hausen]

Most parts of ICMPv6 are mandatory as per the RFCs so I figure that's the reason why filtering them is not implemented. Lessons learned from overzealous admins blocking ICMP for IPv4 ;-)

[LHSFK]

Although the RFC standard mandates it, I believe that as a professional firewall system, Opnsense should have the ability to intercept all data packets between network interfaces. For instance, "MikroTik RouterOS", as a professional router system, its firewall can intercept such data packets generated by the kernel. I think Opnsense, as a professional firewall system, should also have the ability to take over these data packets.

[franco]

Ah, the but-aren't-you-taking-security-seriously argument in the face of a complicated task that somebody else should do in their spare time perhaps?


Cheers,
Franco

[LHSFK]

I understand. My sincere apologies, and thank you for your response.

[franco]

You can try to bring up the topic with FreeBSD but I doubt this will gain immediate traction. Depending on what you do a transparent filtering bridge may be more what you're looking for than a router.


Cheers,
Franco