ICMPv6 filtering rule recommendation
-
How should I configure a rule to allow ICMPv6? Looking for recommendations.
-
There are already some hidden default rules in place that allow specific and important ICMPv6 types to pass. They are Host Unreachable (unreach), Packet too big (toobig), Neighbor Solicitation (neighbrsol), and Neighbor Advertisement (neighbradv).
Also enabled are echo requests/replies, router solicitation and router advertisement when originating from and/or addressed to either link-local or all-routers multicast addresses.
BTW, if you're asking this because of the ICMP test on ipv6-test.com showing filtered, all it tests is ICMP echo requests/replies (ping), which is not one of the important ICMP types for IPv6. Certainly you can allow ICMP Echo requests in and echo replies out if you want, but that just makes all of your devices using IPv6 visible to the world, as far as if they're online or not.
The full default rules, if you want to see them, are below…
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
-
Thanks. This detail is helpful.
-
In my opinion there isn't much reason to filter ICMPv6 traffic. The stupid and/or risky ICMP types were removed from the v6 version of the protocol and ping scanning a /64 network looking for online hosts would take a hilariously long time. Just shy of 60 million years at 100mbps of pure ICMPv6 traffic.
-
"Just shy of 60 million years at 100mbps of pure ICMPv6 traffic."
So, what you are saying is it can be done? haha
-
Sure its possible, just not exactly practical. Even a very large botnet with 20 gigabits per second of available bandwidth would take almost 300,000 years to do the job.
A /64 hides quiet hosts with search times that approach cryptographic levels without even trying. Larger subnet sizes just get silly. Ping scanning the /56 my ISP delegated to me with that same large botnet would take 76.8 million years. Throttle that back down to 100mpbs and it would take 15.36 billion years. For comparison, our sun only has about 5.4 billion years left at most before it does things that kill all life on earth.
-
I was kidding, of course. I think molesting ICMP in IPV6 isn't necessary and will likely break things if done.
-
@virgiliomi:
There are already some hidden default rules in place that allow specific and important ICMPv6 types to pass. They are Host Unreachable (unreach), Packet too big (toobig), Neighbor Solicitation (neighbrsol), and Neighbor Advertisement (neighbradv).
Thanks for the info virgiliomi!
I figured as much as even without explicitly allowing icmp6 traffic was allowed.
To add my 2 ct, I think one should only allow the bare minimum to pass as done by the hidden rule. ICMP has its dangers (smurf, redirect) and IETF recommends rate limiting or even blocking (in case of icmp4 type 5 redirect) most ICMP traffic. Since it's a draft it bis incomplete - a good read nevertheless [1].[1] https://tools.ietf.org/html/draft-ietf-opsec-icmp-filtering-04
-
The ICMP types you are referring to were removed from ICMPv6 for exactly the reasons you mentioned. There really isn't anything worth blocking aside from ping on a layer 3 device. There are ICMP types you might want to block on a switch, such as router advertisements, but that's layer 2 stuff.
And for the love of god don't rate limit ICMPv6 on your edge device. I knew a guy that rate limited ICMPv6 to 20 packets per minute on the linux router in his lab. He was then very confused when I brought down the entire lab by pinging his router from a windows machine with the -t option over IPv6.
Don't approach ICMPv6 with an ICMPv4 mentality. They are totally different protocols with totally different jobs that need to be handled in totally different ways.