2.4.4 ICMPv6 Firewall Rules?
-
Thank you for the reply @johnpoz
I agree that is is easy enough to fix, and I end up getting the same test results as you once I allow ICMPv6 Any to Any.
I also get the same result with Hostname being "none." In my case, I get no answer with a public DNS like 8.8.8.8, but my pfSense DNS resolver does return an answer.
I do still have the question on what is required by IPv6 to function properly. Going back to a previous quote of yours in this thread:
The required icmpv6 stuff for ipv6 to work on wan - is there!!! Same goes for lan side for clients to find pfsense as their ipv6 gateway.. There is NOTHING you need to add..
All other to wan would be blocked out of the gate - if you want to allow actual ping response.. Then you can add that.. Same sort of thing goes if you want to allow into your lan from outside..That makes perfect sense. But does IPv6 want ICMPv6 to be allowed through the WAN in order for it to function properly? Because IPv6 seems to be functioning just fine without that rule. The only issue I've seen is this one site saying that test isn't passing. But who knows... I may have some issues where I can't connect properly to some IPv6 endpoints because they can't properly send ICMP packets and I'm simply reverting to IPv4 and not noticing any delays due to happy eyeballs.
-
ICMPv6 is important for Path MTU discovery since there's no fragmentation allowed in IPv6.
If you are to allow ICMP inbound (as it could come from an intermediate router) then the solution to address security concerns is to rate-limit ICMP requests to guard against flooding or scanning.
http://shouldiblockicmp.com/ is not a definitive source but it raises valid arguments in favor on reasonable inbound ICMP requests.
-
Thank you @lohphat, that link was helpful.
I'm on board with allowing and limiting. Is there a way to rate-limit ICMP requests within pfSense?
I see some advanced settings like "Max. src. conn. Rate" and "Max. src. conn. Rates" for my ICMP allow rule, but these limiters say they're for TCP only which won't help with ICMP.
-
@OffstageRoller said in 2.4.4 ICMPv6 Firewall Rules?:
I allow ICMPv6 Any to Any.
For my device called "Gauche", this will do :
I had to create a rule on the device, a PC, in the Windows firewall so it would accept ICMPv6 request from "all over the planet".
-
@johnpoz said in 2.4.4 ICMPv6 Firewall Rules?:
Other than the min required to say get an IPv6 address..
Don't forget about path MTU detection. You need to allow for that.
-
That is not an inbound thing.. That would be the client going outbound. Which default is any any!!
Their statement
"Your router or firewall is filtering ICMPv6 messages sent to your computer. An IPv6 host that cannot receive ICMP messages may encounter problems like some web pages loading partially or not at all."Is just full of SHIT.. you pinging me, has zero to do with anything... And all they are doing is pinging..
-
@johnpoz said in 2.4.4 ICMPv6 Firewall Rules?:
Is just full of SHIT.
I agree. The "hostname" known or not, and that ping-thing, do not belong on that test page ....
-
The VAST majority of users have zero control over their PTR.. And has zero to do with being a client on the internet.. Sure if your running a mail server or something then you need to make sure your PTR is in order.
Mine finely showed up on that site btw.. They must of cached the NX, since I had set it after got a none..
But they are clearly posting FUD that if your IP doesn't ping shit might not load.. That is just utter nonsense..
-
@johnpoz said in 2.4.4 ICMPv6 Firewall Rules?:
The VAST majority of users have zero control over their PTR.. And has zero to do with being a client on the internet.. Sure if your running a mail server or something then you need to make sure your PTR is in order.
That's exactly what I'm doing - have "MX servers" that have to be compliant, so PTR's have to get set correctly.
A rather exceptional situation and not important for the average SOHO user. -
@beremonavabi said in 2.4.4 ICMPv6 Firewall Rules?:
But, what do I actually NEED?
Going back to the OP from 2018, NOTHING is the answer here.. There is ZERO need to add any rules on the wan for IPv6 to function..
-
hey @johnpoz , is that true if you have internally hosted services that connections are initiated to from outside the local network too? I assume (perhaps wrongly) route size discovery is initiated by the requester.
-
@q54e3w said in 2.4.4 ICMPv6 Firewall Rules?:
I assume (perhaps wrongly) route size discovery is initiated by the requester.
Neither end initiates it. When a packet encounters a link with a smaller MTU, the router sends the "too big" message. Also, it is possible for the 2 ends to provide a different size MTU, so 1 end might get the MTU warning, but not the other.
-
@q54e3w said in 2.4.4 ICMPv6 Firewall Rules?:
is that true if you have internally hosted services
That would be unsolicited inbound traffic.. Then sure you would have to allow for whatever you want to allow for.. For example I setup pfsense to send rejects on trace route ports...
But out of the box, pfsense is not going to allow for any unsolicited inbound anything other than is required to allow for whatever to work.. If they didn't do that in the background automatic - the forum would be flooded with how to make X work because users are stupid, they don't search they don't read docs, etc.. So yes pfsense allows for the basic stuff to allow for X to work or otherwise they would be overwhelmed with how to make X works ;)
I really don't get how this is a question.. What firewall do you know of that allows X unsolicited in bound traffic. If any firewall software did that they for sure would get shit about it.
-
I'm running into this issue as well, a full two or three years later. The crux of the matter is that out of all of the options available, no combination of IPv6 (IP version) and (echorep, echoreq) allows IPv6 ICMPv6 packets. The PF rules match for IPv6 * * * to * * and the counter goes up on that rule. I have preceding rules that address IPv6 and ICMP *, as well as another IPv6 ICMP echoreq,echorep above it. Neither of those two counters have moved from zero.
What we need is the ability to select a Custom protocol and enter a value there, because ICMPv6 is not an option on the drop-down with ESP, AH, GRE, IPV6 (what does that even do with an IP type of IPv4?), etc.
Honestly, we need that ability on all the menus to support ancient protocols and random new ones.
-
@catonic said in 2.4.4 ICMPv6 Firewall Rules?:
because ICMPv6 is not an option on the drop-down
Sure it is.. What do you think ICMP is when you select IPv6?
Here created a test rule
[23.05.1-RELEASE][admin@sg4860.local.lan]/root: cat /tmp/rules.debug | grep "test icmpv6" pass in quick on $TEST inet6 proto ipv6-icmp from any to any ridentifier 1695465595 keep state label "USER_RULE: test icmpv6" label "id:1695465595" [23.05.1-RELEASE][admin@sg4860.local.lan]/rootThis thread is 3 some years old - if you are having a problem, it would be best if you actually give details of what your trying to accomplish, how and what you have done to test it.
There are also hidden rules that allow some icmpv6
# Allow only bare essential icmpv6 packets (NS, NA, and RA, echoreq, echorep) pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {129,133,134,135,136} ridentifier 1000000108 keep state pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {129,133,134,135,136} ridentifier 1000000109 keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000110 keep state pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000111 keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000112 keep state pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000113 keep stateHere I created a icmpv6 echo request rule, then sent some ipv6 pings..
And the counter goes up.
