What hidden rules are created for ICMPv6 and DHCPv6
-
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..
