3 ms·
ICMPv6 was designed to be a bit more robust than the v4 variant and I believe it is considered OK to allow all. I have six WANs at work - four FTTC 80/20Mbs-1,
by gerdesj 3y ago
ICMPv6 was designed to be a bit more robust than the v4 variant and I believe it is considered OK to allow all.
I have six WANs at work - four FTTC 80/20Mbs-1, a 1Gbs-1 leased line and a 1000/300Mbs-1 FTTP job. All have IPv6 apart from the FTTP. I only push through the leased line /48 to inside but I do experiments with the IPv6 on the others. I have a /56 IPv6 at home too, for at least 10 years.
I have allowed all ICMPv6 on two out of the four FTTC lines and not noticed much difference. The other two only allow "useful" ICMP, where useful is similar to this: http://firehol.org/guides/icmpv6-recommendations/ http://firehol.org/guides/icmpv6-recommendations/
Let your external router do the hard work. Your web server on the inside should allow all ICMPv6 in both directions. Just because it has a globally routeable IPv6 address(es) it is not on the outside. Your webserver's firewall is a host one, not an external router one. There is a big difference. Your webserver might be configured to think about itself only and your router's firewalling might consider everything from a high level.
I don't think you need a complicated policy on your webserver but one that stops you accidentally exposing, say, a MariaDB/MySQL to the outside world because you bind it to all interfaces instead of just ::1.
- adamddev1 3y ago> Just because it has a globally routeable IPv6 address(es) it is not on the outside. Your webserver's firewall is a host one, not an external router one. Interesting, so with my VPS on Vultr, there'd be an external firewall that takes care of the messier filtering?