Le 14 mai 2014 à 03:37, Chris Buechler c...@pfsense.com a écrit :
IMO, I agree that it's best to let ICMP flow free on IPv6. ICMP has had
a bad reputation for a long time, and it's mostly undeserved in recent
times.
Jim
How should I interpret the code you pointed to?
That pfSense do
On 21-5-2014 9:11, Olivier Mascia wrote:
Le 14 mai 2014 à 03:37, Chris Buechler c...@pfsense.com
mailto:c...@pfsense.com a écrit :
IMO, I agree that it's best to let ICMP flow free on IPv6. ICMP
has had
a bad reputation for a long time, and it's mostly undeserved in
Le 21 mai 2014 à 09:23, Seth Mos seth@dds.nl a écrit :
The ICMPv6 traffic that's considered required for things to function
properly is automatically allowed.
Excellent. Thanks!
The rules should automatically allow ICMP6 echo, packet to big and
neighbor discovery on the link-local
On Thursday, May 8, 2014, Olivier Mascia o...@tipgroup.com wrote:
Le 8 mai 2014 à 20:05, Jim Pingle li...@pingle.org javascript:; a
écrit :
Code of interest here:
https://github.com/pfsense/pfsense/blob/master/etc/inc/filter.inc#L2644
IMO, I agree that it's best to let ICMP flow free
Hello,
What about RFC 4890 and pfSense configuration of complex ICMPv6 filtering rules?
Could it be possible to define a rule where multiple ICMPv6 types might be
checked at once?
For instance setting up a single rule to allow Type 1, 2, 3, 4, 128 and 129?
Instead of needing to create as many
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
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
On Thursday, May 08, 2014 12:51:05 PM Olivier Mascia wrote:
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.
That's alright.
Rate limits, at least on
On 08/05/2014 11:51, Olivier Mascia wrote:
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.
I don't think you'll see any packets with multicast source addresses.
It's possible you
On May 8, 2014 12:05:34 PM CDT, Brian Candler b.cand...@pobox.com wrote:
On 08/05/2014 11:51, Olivier Mascia wrote:
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.
I don't think you'll
Le 8 mai 2014 à 19:05, Brian Candler b.cand...@pobox.com a écrit :
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.
I don't think you'll see any packets with multicast source
On 5/8/2014 1:16 PM, Adam Thompson wrote:
Sorry for the late addition... Perhaps this was already covered, but if not:
Please don't filter ICMPv6. This is one of the key points every
intro-to-v6 class teaches: IPv6 actually *needs* ICMPv6 to function in
pretty much every situation.
The
On Thursday, May 08, 2014 08:05:03 PM Jim Pingle wrote:
IMO, I agree that it's best to let ICMP flow free on
IPv6. ICMP has had a bad reputation for a long time, and
it's mostly undeserved in recent times.
+1.
Mark.
signature.asc
Description: This is a digitally signed message part.
Le 8 mai 2014 à 20:05, Jim Pingle li...@pingle.org a écrit :
Code of interest here:
https://github.com/pfsense/pfsense/blob/master/etc/inc/filter.inc#L2644
IMO, I agree that it's best to let ICMP flow free on IPv6. ICMP has had
a bad reputation for a long time, and it's mostly undeserved in
14 matches
Mail list logo
