What hidden rules are created for ICMPv6 and DHCPv6
-
First, the ICMP test of that site is strictly ping (ICMP Echo Request/Echo Reply)… there are many other ICMP packets that may or may not be blocked, so it's not even a really good test, just an easy test to perform.
If you're allowing IPv6 ICMP Echo Request into WAN via pfSense but still not coming up green, then it's likely your local firewall on your computer preventing the packets from getting in.
That being said... pfSense does have some hidden rules regarding some IPv6 ICMP traffic that are in place... those are IPv6 ICMP packets that are more important to IPv6 functioning properly (like for RA and NDP, among other things).
These are only present once...
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 stateThese are repeated for fe80::/10 to ff02::/16, the src/dest swap of that, and all are repeated again for pass in (changing echorep to echoreq)
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 stateThere are also some rules if you're using DHCPv6. I'm just lazy tonight and don't want to edit my prefix out, so I won't be pasting those. :)
-
@JKnott: I'm very aware that blocking ICMPv6 is bad. I also disabled W10 firewall and still got the yellow filtered result.
@virgiliomi: As mentioned, I don't think it is W10 firewall. I also know that it is a simple test, but if I'm failing that simple test, I have a problem! I very much appreciate your listing the hidden rules. I see that the rules you list don't include echo-req inbound. Perhaps that is the problem? I ask where it was that you found these, so I can look at my own.
Still looking for where the ICMPv6 is being dropped. Firewall logs do show dumped ICMPv6 packets dumped, though the log doesn't tell too much (type etc). Guess I will have to get tcpdumps and look at them…
Any more ideas would be helpful (e.g. were are the hidden rules visible) but I certainly thank you all for your help.
-
Ooh, I hate to say what I just tried. I had W10 firewall disabled (all 3) and I added the following rule on the WAN interface: Allow, Proto:ICMPv6 (all), any source, any destination. Ouch, waaaay too permissive, but it was for a test. Then I got the green reachable on the ICMPv6 of ipv6-test site. So clearly it is pfSense stopping it. My WAN rules are easy to follow (see attached image) and I don't think they are wrong.
Any idea why default pfSense isn't good enough? I did upgrade to 2.4 rather than reinstall but I can't see that being it.
This brings up the comment I had earlier that I didn't see echo-req, echo-rep in the default rules mentioned above. Any idea why not? I'm pretty sure they are required by RFC4890 sect 4.3.1
 -
You do understand that difference between pinging pfsense wan IPv6 address and a clients right..
You would have to allow that IPv6 through to the client address if you want it to pass ping test..
-
Any idea why default pfSense isn't good enough?
Nothing wrong with pfSense. That site worked properly with Linux and also with W10 after I disabled the Windows firewall.
-
If pfsense allowed ping or anything through to ipv6 behind it out of the box that would be wrong. So yes if your going to want to get to an IPv6 device behind pfsense you would have to create the firewall rules for what you want to allow through.
I allow icmp and traceroute and ntp through to my ntp server that serves ntp to the pool on ipv6. But no other clients can be pinged from outside, etc.
Where in the rfc does it state that global IP address has to answer ping? You will notice pfsense allows access to ping its address on link local address fe80….
-
Where in the rfc does it state that global IP address has to answer ping?
The ICMP RFC 792 was written way back before the Internet was made public, with all it's risks. Back then, it was considered a trusted network, connecting researchers, etc.. It would have never occurred to them, back then, to block anything, beyond using passwords to access servers. However, with IPv6, ICMP is used for so much that blocking it can cause problems. One example is Path MTU discovery, which is mandatory on IPv6 and frequently used on IPv4. It requires "too big" messages be sent back to the source. There are others things such as destination unreachable ICMP messages that should be sent back to the source. So, while it might not be desirable to pass ping, blocking ICMP in general is a bad idea.
-
Completely agree with you… I always open up ping - its a HUGE troubleshooting tool that is too valuable to turn off.
But a firewall that allowed ICMP through out of the box to stuff behind it would not actually be a firewall ;)
Any firewall that allowed through traffic to stuff behind it without acknowledgement from the owner/admin of the firewall would be foolish.
The pfsense rules allow the stuff to its WAN from the locally connected link local network to function correctly. Allowing ping to its global IP if hidden would be a violation of trust of the makers of the firewall to the users of the firewall.
If you want to allow ping to your global address be it on the wan or behind pfsense you would need to allow this.
-
If you want to allow ping to your global address be it on the wan or behind pfsense you would need to allow this.
I don't recall doing that, yet ICMP worked on the site.
I just tried an experiment. I tethered my notebook computer to my cell phone and was able to ping the IPv6 address of my home computer through pfSense. So, pfSense is not blocking pings to computers on my LAN.
-
You do understand that difference between pinging pfsense wan IPv6 address and a clients right..
You would have to allow that IPv6 through to the client address if you want it to pass ping test..
Yes, I totally understand that. I did say I was running my web test from W10 so I know I need rules to pass the ping through pfSense to the client.
Any idea why default pfSense isn't good enough?
Nothing wrong with pfSense. That site worked properly with Linux and also with W10 after I disabled the Windows firewall.
Ooh. Terrible wording on my part. I meant why my rules (hidden or explicit) on pfSense are not good enough. I am asking about what rules you have (success) that I don't (failure). These rules could be explicit (e.g. perhaps your W10 machine is "open" to the internet for other reasons) or implicit (i.e. hidden rules). If it is hidden rules (since you didn't mention any explicit ones) I wonder if I upgraded from a version that didn't have those rules and they didn't get added by the upgrade. If explicit rules, can you tell me what you used? Many other possibilities but let's start by knowing where your (and other's) "permit ping" rule is.
Where in the rfc does it state that global IP address has to answer ping? You will notice pfsense allows access to ping its address on link local address fe80….
Actually, section 4.3.1 of RFC4890 is not crystal clear. The section is "[transit] Traffic that must not be dropped" then they qualify ping as being only necessary for Teredo tunneling but continue by saying that it is no longer necessary to block otherwise (my words).
Completely agree with you [JKnott]… I always open up ping - its a HUGE troubleshooting tool that is too valuable to turn off.
What rule do you add?
-
I don't recall doing that, yet ICMP worked on the site.
I just tried an experiment. I tethered my notebook computer to my cell phone and was able to ping the IPv6 address of my home computer through pfSense. So, pfSense is not blocking pings to computers on my LAN.
Gotta say, your case implies the default rules are good enough (which I would find completely reasonable though it involves a default allow for traffic through). Still thinking hidden rules that never got updated is a possibility. Do you know your list of hidden rules?
@virgiliomi: where is it we would find the list of hidden rules and where they are created?
-
Ooh. Terrible wording on my part. I meant why my rules (hidden or explicit) on pfSense are not good enough. I am asking about what rules you have (success) that I don't (failure).
I don't have any rules, to my knowledge. I certainly didn't create any. All I had to do to pass that test was disable the W10 firewall. It worked fine, as is, on Linux. While there is a firewall running on the Linux computer, there are no rules relating to ICMP. As I mentioned in another note, I was able to ping my desktop computer from a computer tethered to my cell phone. This means the ping had to pass through pfSense and the Linux firewall.
Actually, section 4.3.1 of RFC4890 is not crystal clear. The section is "[transit] Traffic that must not be dropped" then they qualify ping as being only necessary for Teredo tunneling but continue by saying that it is no longer necessary to block otherwise (my words).
There's a bit more to it than that. Teredo is deprecated, so it no longer applies. However, the reason for blocking ping on IPv4, that is scanning for targets, is not a significant problem on IPv6, due to the huge address space. A single /64 has as many addresses as the entire IPv4 address space squared! Bottom line, if you're using Teredo, then you need to allow ping. Other than that, it's not an issue.
What rule do you add?
I just looked at my rules and found there is one that passes any ICMP on both IPv4 and IPv6. I don't recall adding that, so perhaps it's default?
-
I just looked at my rules and found there is one that passes any ICMP on both IPv4 and IPv6. I don't recall adding that, so perhaps it's default?
Ahh. The plot thickens. Where did you find that rule? In /tmp/rules.debug or elsewhere? You mention you don't recall adding it but is it easy to see if it is in your explicit rules in the GUI? Is it possible you added it at the command line?
Also, does it pass all ICMP from any to any (as I did in my simple test) or is it more restrictive?
-
I just looked at my rules and found there is one that passes any ICMP on both IPv4 and IPv6. I don't recall adding that, so perhaps it's default?
Ahh. The plot thickens. Where did you find that rule? In /tmp/rules.debug or elsewhere? You mention you don't recall adding it but is it easy to see if it is in your explicit rules in the GUI? Is it possible you added it at the command line?
Also, does it pass all ICMP from any to any (as I did in my simple test) or is it more restrictive?
I saw it in the GUI. I have never added a rule with the command line. As far as I know, any means any.
-
Anyone else have an ICMP rule by default in the GUI (WAN interface)? If you do, what is it?
-
There is NO default allow rules in the wan gui out of the box…
Out of the box on the wan would be block rfc1918 and bogon. There would no other rules there unless created by the user.
There are hidden rules say for dhcp when you enable dhcp on the wan. And there will be ipv6 rules for your wan link local if you have ipv6 enabled.
You can always view the full rule set here.
https://doc.pfsense.org/index.php/How_can_I_see_the_full_PF_rulesetIf your box is using teredo then all bets are off on the firewall rules since you just tunneled through it..
