2.4.4 ICMPv6 Firewall Rules?



  • @beremonavabi Maybe you should go once to cli or "Diagnostics / Command Prompt" and execute
    "pfctl -s rules" this will help you understand about hidden rules..


  • LAYER 8 Global Moderator

    @beremonavabi said in 2.4.4 ICMPv6 Firewall Rules?:

    "...pfSense automatically adds firewall rules on IPv6 enabled interfaces that permit NDP to function. "

    You have ZERO add which is what have been telling you ;)



  • @sigi said in 2.4.4 ICMPv6 Firewall Rules?:

    @beremonavabi Maybe you should go once to cli or "Diagnostics / Command Prompt" and execute
    "pfctl -s rules" this will help you understand about hidden rules..

    Thanks. According to that:

    Shell Output - pfctl -s rules
    ...
    pass quick inet6 proto ipv6-icmp all icmp6-type unreach keep state
    pass quick inet6 proto ipv6-icmp all icmp6-type toobig keep state
    pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state
    pass quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echorep keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echorep keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echoreq keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state
    pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type echoreq keep state
    pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routersol keep state
    pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routeradv keep state
    pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbrsol keep state
    pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbradv keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echoreq keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep state
    pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type echoreq keep state
    pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routersol keep state
    pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type routeradv keep state
    pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbrsol keep state
    pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type neighbradv keep state
    ...
    

    That makes much of this discussion moot. It looks like fSense defaults to allowing (with various restrictions):

    Packet Too Big
    Destination Unreachable
    Echo Reply
    Echo Request
    Neighbor Advertisement
    Neighbor Solicitation
    Router Advertisement
    Router Solicitation

    Oddly, of the Neighbor Discovery subset, it doesn't default to allowing Redirect. I wonder why? Of course, if it defaults to allowing those ICMPv6 subtypes into the system, why not those other "must pass" subtypes:

    Parameter Problem (invalid IP header)
    Time Exceeded?



  • @johnpoz Sorry for bumping this but is there a way to see "hidden" rules? The ICMPv6 "hidden" doesn't seem to allow echo reply so when it's said that pfSense has automatic rules for things to work, but things like echo doesn't work. This ambiguity is a source of some frustration.


  • LAYER 8 Global Moderator

    @lohphat said in 2.4.4 ICMPv6 Firewall Rules?:

    there a way to see "hidden" rules?

    https://docs.netgate.com/pfsense/en/latest/firewall/viewing-the-full-pf-ruleset.html

    [2.4.5-RELEASE][admin@sg4860.local.lan]/root: pfctl -sr | grep ipv6
    pass quick inet6 proto ipv6-icmp all icmp6-type unreach keep state
    pass quick inet6 proto ipv6-icmp all icmp6-type toobig keep state
    pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state
    pass quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state
    

    Echo reply is not a requirement for ipv6 to function. Other than at the link-local layer its not allowed automatic

    pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echorep keep state
    

    There are many more, just touching on the highlights..

    Out of the box it doesn't allow ping to wan on ipv4 either, etc.



  • @johnpoz Thank you! Just what I was looking for.

    When it comes to troubleshooting, knowing the actual rules vs implied is important.

    There are gray areas when it comes to implied functionality which could be handled better. e.g. if IPv6 is enabled then due to the inherent need to support multicast groups (e.g. in lieu of ARP) it's not obvious how much of multicast functionality is implied. Is all FE80::/10 traffic allowed? Is IGMPv6 automatically implied (or needed), etc.

    It would be nice to have an intro section covering just what is actually in play when VPN, IPv6, et al are enabled for each.



  • @johnpoz Here's an interesting find implying that pfSense still isn't multicast complete for either IPv4 or IPv6, in this case not supporting multicast membership management protocols.

    https://redmine.pfsense.org/issues/6228


  • LAYER 8 Global Moderator

    The way I read that since set to OS, is that freebsd doesn't support it as of yet. So not really a "pfsense" thing that could be fixed.



  • @johnpoz Agreed. I'm a bit surprised as FreeBSD is the basis for router code.

    But it does expose the lack of clarity of what functionality is or is not available. If a product claims to support IPv6 but is missing part of the protocol suite that needs to be documented somewhere instead of needing to hunt it down across several domains of dependency (OS, pfSense, OEM, etc.). Having a section listing known limitations, e.g. incomplete protocol suite/RFC implementation would REALLY help.


  • LAYER 8 Global Moderator

    I think your confused about multicast.. Routers don't need to do shit with that.. multicast is suppose to be on the L2...

    Membership management for multicast is not really something a router has to do or support.. Do that on your switch! ;) Ie your L2 device..



  • @johnpoz Not with IPTV. The multicast streams must pass the firewall. Also, if you have multicast inside the firewall they need to traverse VLANS. Where are the VLANS terminated? pfSense.

    Routers, and thus the reason IGMP proxy exists as a package, must be coordinated by all devices, especially routers, not just switches, when different segments must be traversed.


  • LAYER 8 Global Moderator

    That is why IPTV providers gives you their own shit ;)



  • @johnpoz Well even without IPTV, I've led multicast video deployments on internal enterprise networks, and as stated, traffic must traverse vlans and routers too. pfSense is a critical router if VLANS are terminated there.

    IPv4 made us complacent about multicast, it was easy to ignore, but with IPv6 it's an integral part of the protocol stack and piecemeal protocol stack implementations are not helping. We need to up our game.

    All I'm asking is for a call-out in the docs of where the known holes are instead of having to find them on our own.

    /end rant ;-)



  • @johnpoz said in 2.4.4 ICMPv6 Firewall Rules?:

    multicast is suppose to be on the L2...

    Multicast can pass through routers, but that must be arranged for. That is normally done with IGMP on IPv4 or MLD on IPv6.



  • @JKnott That's the point, MLDv2 is not supported on FreeBSD yet, thus pfSense can't handle the IPv6 multicast routing properly.

    https://redmine.pfsense.org/issues/6228



  • @JKnott Hmm. I just found this: https://www.freebsd.org/releases/8.0R/relnotes.html

    "The IGMPv3 and SSM (Source-Specific Multicast) including IPv6 SSM and MLDv2 have been added."

    Since pfSense is running on 11.x now (I think) then that feature request must be blocked by something else.



  • The confusion for me, comes from third party sites and their "tests."

    If I don't create a rule on my WAN to allow Any to my computer on ICMPv6, the following site will show a "not tested" for ICMP and instruct me to adjust my firewall:
    https://ipv6-test.com

    I see the rejected entry in my logs for that test.

    If I create the rule to allow that connection, I show as passing and I can see that request pass through my firewall to my computer.

    But that begs the question, what exactly are they testing? Are they sending a ping request without me initiating the connection? Because I believe that's not valid for how IPv6 is designed to work correct?

    Here's an example of what they show when I don't create a specific rule to allow ICMPv6 through my firewall:

    Screen Shot 2020-06-12 at 12.39.30 PM.jpg


  • LAYER 8 Global Moderator

    If you want to allow icmp through pfsense to your IPv6 clients - yes you would have to allow that.

    Pfsense out of the box does not allow icmp echo requests to it or through it out of the box.. Doing so would be a horrible IDEA.. Out of the box no unsolicited inbound traffic is allowed or answered..

    Other than the min required to say get an IPv6 address.. on your wan, which is not a echo request for sure.

    But its simple enough to fix - see my test..

    ipv6test.jpg

    I am curious how they are doing their PTR test though.. Because my IPv6 address does have a PTR setup..

    reverse.jpg
    ptr.jpg

    That resolves on the public internet, but they are saying there isn't one.. Maybe because it doesn't resolve? I will check on it later, and change it so forward matches and is valid domain see if that fixes their test site result.

    request pass through my firewall to my computer.

    You have to make sure the IP your pinging firewall also allows it... Just because you allow it through pfsense doesn't mean the clients firewall will answer.



  • 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 :

    897bb09f-f011-496f-b2bb-4441568f58e0-image.png

    c5dd0b9d-9eea-4737-8456-a53c6fb13c82-image.png

    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.


  • LAYER 8 Global Moderator

    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 ....


  • LAYER 8 Global Moderator

    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.


  • LAYER 8 Global Moderator

    @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.


  • LAYER 8 Global Moderator

    @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...

    traceroute.jpg

    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.


Log in to reply