Le 8 mai 2014 à 12:37, Mark Tinka <mark.ti...@seacom.mu> a écrit : > On Thursday, May 08, 2014 12:25:54 PM Olivier Mascia wrote: > >> Are there other documentation on ICMPv6 filtering, >> without dropping essential functionality, in the >> specific context of pfSense 2.1.x? > > My personal opinion, we already killed IPv4 by filtering > ICMP (and thereby, killing pMTU). Let's not repeat that in > IPv6. > > That said, ICMPv6 is different from ICMPv4, as it ensures > link reachability among hosts (ARP is gone, as you know). > > It would be nice for pfSense, perhaps, to provide rate > limits that would help ensure ICMPv6 isn't abused, but does > not cut off service. > > That said, if you do want to filter ICMPv6, be sure to (at > least) allow the following ICMPv6 messages: > > echo-reply > echo-request > membership-query > membership-report > membership-termination > neighbor-advertisement > neighbor-solicit > router-advertisement > router-solicit > time-exceeded > > Mark.
Thanks for this advice. On the WAN interface, I’m currently allowing full ICMPv6 in, albeit only from Global Unicast and Multicast addresses. That is: only from 2000::/3 and ff00::/8. The intention was to limit at least requests from WAN side using spoofed local addresses. I’m pretty confident that I do not break (too) many things this way (am I wrong?). I’m also logging these packets with some alerts from my syslog server if their rate suddenly raise. Rate limits, at least on replies, *should* be inherent to the implementation of ICMPv6 as far as I have read (don’t remember where though). Is this enforced in pfSense, I don’t currently know. __ Olivier Mascia tipgroup.com/om _______________________________________________ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
