2.4.4 ICMPv6 Firewall Rules?

[beremonavabi]

On pfSense 2.4.4-RELEASE (amd64), what kind of ICMPv6 rule should I add to Firewall > Rules > WAN? I've seen some posts saying to just do a flat allow of all incoming ICMP traffic on both IPv4 and IPv6:

		States	Protocol	Source	Port	Destination	Port	Gateway	Queue	Schedule	Description	Actions
IPv4+6 ICMP
any
*	*	*	*	*	none	 	Allow All Incoming ICMP	    

and a set of far more restrictive rules like:

		States	Protocol	Source	Port	Destination	Port	Gateway	Queue	Schedule	Description	Actions
IPv6 ICMP
echorep, echoreq, timex, toobig
*	*	LAN net	*	*	none	 	Allow Specific Incoming IPv6 ICMP to LAN	   
		0 /0 B
IPv6 ICMP
echorep, echoreq, timex, toobig
*	*	WAN address	*	*	none	 	Allow Specific Incoming IPv6 ICMP to Router	   

I much prefer the restrictive ones. But, what do I actually NEED?

[sigi]

There is a good'ol rfc that is still explaining this exactly:
https://tools.ietf.org/html/rfc4890#section-4.3

[JKnott]

IPv6 relies much more on ICMP than IPv4. Generally you don't need to block much, if anything. As mentioned in that RFC, ICMPv6 includes protections, such as that 255 hop count, that ensure messages don't come from beyond the next device.

[beremonavabi]

@sigi said in 2.4.4 ICMPv6 Firewall Rules?:

There is a good'ol rfc that is still explaining this exactly:
https://tools.ietf.org/html/rfc4890#section-4.3

Thanks for that source. In my case (just a single site (home) with a few computers and devices on the local network), it looks like I definitely need to allow the following into the WAN interface:

• Echo Reply
• Echo Request
• Parameter Problem (invalid IP header)
• Time Exceeded
• Packet Too Big
• Destination Unreachable

I definitely need to NOT allow the following into the WAN interface:

• Node Information Request
• Node Information Reply

If I had multiple sites that needed to communicate (i.e., if my pfSense were a Firewall/Bridge), I'd need to allow:

• Neighbor Advertisement
• Neighbor Solicitation
• Redirect
• Router Advertisement
• Router Solicitation

That still leaves the following from pfSense's list of ICMP Subtypes:

• FQDN Reply (not mentioned in document)
• FQDN Query (not mentioned)
• Group Membership Query (not mentioned)
• Group Membership Report (not mentioned)
• Group Membership Termination (not mentioned)
• Multicast Listener Done (will be dropped anyway)
• Multicast Listener Report (will be dropped anyway)
• Multicast Listener Query (will be dropped anyway)
• Mtrace Messages (not mentioned)
• Mtrace Resp (not mentioned)
• Who Are You Reply (not mentioned)
• Who Are You Request (not mentioned)

I assume I can safely NOT allow them into the WAN interface.

[beremonavabi]

Thinking about this a bit more, the pair of rules I noted in my OP (which I've modified as per the above and am using) are separated into one for traffic going to the LAN and one for the router, itself. Is there any reason for that? In my case, on my SG-4860, my WAN port is going to my cable modem and the internet. Everything else (all my internal stuff) is off my LAN port. Since the two rules are identical except for the destination, I should be able to replace them with one rule with the destination set to anything (i.e., "*"). Right? There's nothing special about including the WAN Address but not the WAN net there, is there?

[JKnott]

@beremonavabi said in 2.4.4 ICMPv6 Firewall Rules?:

If I had multiple sites that needed to communicate (i.e., if my pfSense were a Firewall/Bridge), I'd need to allow:

Neighbor Advertisement
Neighbor Solicitation
Redirect
Router Advertisement
Router Solicitation

If you block those you will definitely kill IPv6. Neighbor Adversiments & Solicitations are the equivalent of IPv4 ARP. Without them you have nothing. Same for Router Advertisement and Solicitation.

[beremonavabi]

@jknott said in 2.4.4 ICMPv6 Firewall Rules?:

@beremonavabi said in 2.4.4 ICMPv6 Firewall Rules?:

If I had multiple sites that needed to communicate (i.e., if my pfSense were a Firewall/Bridge), I'd need to allow:

Neighbor Advertisement
Neighbor Solicitation
Redirect
Router Advertisement
Router Solicitation

If you block those you will definitely kill IPv6. Neighbor Adversiments & Solicitations are the equivalent of IPv4 ARP. Without them you have nothing. Same for Router Advertisement and Solicitation.

From what I can make out of this section:

https://tools.ietf.org/html/rfc4890#page-15

Those are needed within the local network (probably not the correct wording). But, unless we're in a Firewall/Bridge situation, they should never come in (or go out) the WAN interface:

"4.3.3. Traffic That Will Be Dropped Anyway -- No Special Attention
Needed

The messages listed in this section are all involved with local
management of nodes connected to the logical link on which they were
initially transmitted. All these messages should never be propagated
beyond the link on which they were initially transmitted. If the
firewall is a firewall/bridge rather than a firewall/router, these
messages should be allowed to transit the firewall as they would be
intended for establishing communications between the two physical
parts of the link that are bridged into a single logical link.

During normal operations, these messages will have destination
addresses, mostly link local but in some cases global unicast
addresses, of interfaces on the local link. No special action is
needed to filter messages with link-local addresses in a firewall/
router. As discussed in Section 4.1, these messages are specified so
that either the receiver is able to check that the message has not
passed through a router or it will be dropped at the first router it
encounters...."

So, they don't need to be allowed in a WAN firewall rule (on my simple setup).

[JKnott]

@beremonavabi said in 2.4.4 ICMPv6 Firewall Rules?:

@jknott said in 2.4.4 ICMPv6 Firewall Rules?:

@beremonavabi said in 2.4.4 ICMPv6 Firewall Rules?:

If I had multiple sites that needed to communicate (i.e., if my pfSense were a Firewall/Bridge), I'd need to allow:
Neighbor Advertisement
Neighbor Solicitation
Redirect
Router Advertisement
Router Solicitation

If you block those you will definitely kill IPv6. Neighbor Adversiments & Solicitations are the equivalent of IPv4 ARP. Without them you have nothing. Same for Router Advertisement and Solicitation.

From what I can make out of this section:
https://tools.ietf.org/html/rfc4890#page-15
Those are needed within the local network (probably not the correct wording). But, unless we're in a Firewall/Bridge situation, they should never come in (or go out) the WAN interface:

They are required on every link. If you look at the packets with Wireshark, you'll see many of them, such as those advertisements and requests, have a hop limit set to 255. This means it's impossible for them to have come from anything other than an adjacent device. Any other hop limit makes those ICMPv6 messages invalid and will be discarded Those ICMPv6 messages are NEEDED for IPv6 to work.

[johnpoz]

The icmpv6 rules that are required for IPv6 to work are allowed but hidden, just like dhcp is when you enable dhcp.. There is no need to worry about setting rules to allow the required stuff for IPv6 to function.

They do this from keeping users from shooting themselves in the foot..

[beremonavabi]

@jknott

I agree. Those ICMP packets are needed within the local network. All I'm doing is not allowing them to come into the WAN interface from the outside (which, for me, is the internet (only)). I've got no rule anywhere that blocks ICMP packets within the network (on my sole active, LAN, interface).

[JKnott]

@beremonavabi said in 2.4.4 ICMPv6 Firewall Rules?:

All I'm doing is not allowing them to come into the WAN interface from the outside

What part of essential do you not understand? They're used on the WAN link just as on the LAN. There is already protection to keep them from coming from beyond an adjacent device through the hop limit, which must be 255 on a valid ICMPv6 message. Fire up Wireshark or Packet Capture on the WAN port to see them. You'll see they are intended for your firewall and have a hop limit of 255. The way that works is if the packet has a hop limit of 255, it can't have come from any other than the adjacent device. For it to have passed through a router, it would have entered the router with a hop limit of 0, which the router would then discard. If a packet with any other hop limit makes it through the router, it would have a value other than 255, which would also caused it to be discarded as invalid. You're trying to protect against a problem that doesn't exist.

[beremonavabi]

Neighbor Advertisement
Neighbor Solicitation
Redirect
Router Advertisement
Router Solicitation

As far as I can see, all of those are solely of use on the local network (one, single segment -- which is all I have):

https://www.computernetworkingnotes.com/networking-tutorials/ipv6-neighbor-discovery-protocol-explained.html

AFAIK, they're used on the WAN link only if I have other subnets that communicate through that interface,
I don't. To me, the outside of the WAN interface is just the internet. And, nothing on the internet should legitimately be sending those to enter my WAN link (again, that I know of). And, as you've said, if something did, it should be discarded by pfSense as it entered. Nothing of mine is on anything but the LAN. AFAIK, the only adjacent devices I care about are internal to the LAN and will happily send those ICMP packets across the LAN without interference. Why would I want to add rules to my WAN's firewall so those packets can come in when I could more easily just leave them off and, with no effort on my part, ensure they never get in regardless of whether or not pfSense should drop them anyway because of the 255 hop limit?

Can you give me a concrete example of how my not allowing those ICMP subtypes into my WAN interface from the internet is breaking anything? That's a real question. I honestly can't think of anything on the internet that would need "a set of messages and processes defined in RFC 4861 that determine relationships between neighboring nodes" (from that link, above) on my local network. But, I'm not an expert.

[beremonavabi]

@jknott

Perhaps we're focusing on different elements. I'm focusing on what's allowed into the LAN. Are you worried about what's happening at the pfSense level? Here are my current rules:

WAN:

I can't see why any of those Neighbor Discover subtypes should be allowed into LAN net (the first rule). But, are you saying they need to be allowed into the WAN address (the second rule)? By blocking them there, am I preventing pfSense from finding external neighbors and routes?

[johnpoz]

You can put the rules there all you want - the hidden rules are hidden ;) And are going to happen before you..

How exactly is your firewall going to talk to the internet via IPv6 on the wan if you do not allow those - so its gateway can be found.. Um you do not need to allow anything other then echo through to your lan from the internet.. etc..

[JKnott]

@beremonavabi said in 2.4.4 ICMPv6 Firewall Rules?:

As far as I can see, all of those are solely of use on the local network (one, single segment -- which is all I have):

I just ran Packet Capture on my WAN interface and saw NS & NA messages. They are there because they are needed. As Johnpoz says, you can't block them anyway. So, what exactly is it you're trying to do? IPv6 relies much more on ICMP than IPv4 and quite frankly won't work without it. Perhaps you need to learn a bit more about IPv6. I can recommend O'Reilly's IPv6 Essentials.

[johnpoz]

Just at a loss to understanding what he is attempting to do..

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

Example I allow echoreq into my my ntp server IPv6 address from internet.. And to ping pfsense IPv6 wan side IP, etc. There is little reason to add any other rules..

[beremonavabi]

According to:

https://www.netgate.com/docs/pfsense/book/network/ipv6-subnets.html?highlight=icmpv6#neighbor-discovery

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

Am I supposed to be able to see that rule in my Firewall rules (I don't)? Or is it just an implied rule like the default deny on incoming traffic? Does that statement imply we don't need to add any special ICMPv6 rule at all?

[sigi]

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

[johnpoz]

@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 ;)

[beremonavabi]

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

[lohphat]

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

[johnpoz]

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

[lohphat]

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

[lohphat]

@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

[johnpoz]

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.

[lohphat]

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

[johnpoz]

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

[lohphat]

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

[johnpoz]

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

[lohphat]

@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 ;-)

[JKnott]

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

[lohphat]

@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

[lohphat]

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

[OffstageRoller]

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:

[johnpoz]

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

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

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.

[OffstageRoller]

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.

[lohphat]

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.

[OffstageRoller]

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.

[Gertjan]

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

[JKnott]

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