Outbound ping blocked

revengineer

@johnpoz Thank you for the tips on how to find the associated blocking rule. Unfortunately, there have been so many blocks that all my filter.log.* files only go back several hours but not to yesterday morning. So I will have to wait until the problem reoccurs. I may need to the weekend to play with this.

@SteveITS The next time this occurs, I will check for a change of the IPv6 address. I believe that I checked the last for letters and there was no change. But this is preliminary and I certainly did not check the entire address.

I will post back here when I have an update. In the meantime, I appreciate the troubleshooting tips described above.

revengineer

Finally, the problem returned. The rule that triggered this action is:

@137 block drop out log quick inet6 proto ipv6-icmp from any to 2606:4700:4700::1111 icmp6-type echoreq label "gateway monitoring" ridentifier 1000016411

I do not see such rule in my set. Does this help for diagnostic?

EDIT: In Routing, I see that my gateway address for IPv6 is currently listed as "dynamic". I believe that this is usually not the case.

EDIT2: Rebooted, gateway back to green, firewall no longer triggered, gateway now has an IPv6 address again (no longer dynamic).

johnpoz

@revengineer said in Outbound ping blocked:

I do not see such rule in my set

not all rules are shown in the gui.. You can view the full rule list here

https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html

I don't have a lot of experience with IPv6 from isp.. I use a he tunnel, where everything is static setup so nothing changes.

But isn't that address cloudflare IPv6 address? Are you using that for monitoring vs just whatever your normal IPv6 gateway would be from your isp?

revengineer

@johnpoz Thank you for the hints. I used the command

pfctl -sa

to grab the complete rule set. There are currently no block rules for icmp traffic and the label "gateway monitoring" cannot be found. So the reboot must have cleared this rule, which seems to imply that it get dynamically generated. The next time this issue reoccurs, I will try the above command again to verify that the blocking rule is in the listing.

Indeed, I use the cloudflare IPv6 DNS server address to verify that the IPv6 gateway is up. My internet provider (Xfinity in the US) changed their network early this year, and since then, their IPv6 gateways are not pingable anymore. So I had to choose another address based on recommendation from someone in previous thread on this message board.

I do not have much experience with IPv6 either. I just set up the gateway because the internet provider is assigning both IPv4 and IPv6 addresses. If I were not a little OCD, I would perhaps ignore it. But understanding the issue would be useful for my education.

pkx232c

Hello,

Same issue here, a "gateway monitoring" rule blocks IPv6 gateway monitoring.
Removing the monitor address from the gateway configuration and re-adding it causes the rule to disappear and monitoring works again until next interface reset.

The issue began after upgrade to 2.8.0 and is still here in 2.8.1.

Best regards,

Ed

revengineer

The problem has reoccurred. The command "pfctl -vvsr" yields among others this rule:

@137 block drop out log quick inet6 proto ipv6-icmp from any to 2606:4700:4700::1111 icmp6-type echoreq label "gateway monitoring" ridentifier 1000016411
  [ Evaluations: 203232    Packets: 107858    Bytes: 5285042     States: 0     ]
  [ Inserted: uid 0 pid 0 State Creations: 0     ]
  [ Last Active Time: Mon Sep 22 19:23:06 2025 ]

I am not sure how this got created. What is the command to manually delete this one rule?

Thank you.

johnpoz

@revengineer if the rule is a hidden rule created by "something" I am not aware of a way to delete it other than having the whatever create it not create it.

Would make no sense to create a block rule to what your trying to monitor. I have no rules called gateway monitoring.. And I monitor my ipv6 gateway.

revengineer

@johnpoz Thanks for the response. This must then be a bug in pfSense. I guess there is nothing I can do other than reboot to make the rule go away.

johnpoz

@revengineer the trick is to figure out where it is coming from. Not sure how to figure out what could of created it. But would assume if it labeled it gateway monitoring - that has to come from somewhere.

It could be a bug that creates a block vs what I would think a better idea of an allow rule, to make sure you could always ping what your wanting to monitor.. But it doesn't make a lot of sense to be honest, since there is already a hidden rule that allows pfsense itself to do whatever it wants outbound. Which is where the monitoring would come from - ie dpinger.

# let out anything from the firewall host itself and decrypted IPsec traffic
pass out  inet all keep state allow-opts ridentifier 1000016215 label "let out anything IPv4 from firewall host itself"
pass out  inet6 all keep state allow-opts ridentifier 1000016216 label "let out anything IPv6 from firewall host itself"

Other thing about the rule that you posted that is odd - is why would it be logged?

Have you looked in /tmp/rules.debug - this is a full listing of the rules, and shows the rules pfsense creates on its own that are hidden, like when you enable dhcp server, hidden rules are created on the interface you enable dhcp on so it is sure to work, etc.

marcosm

Following up from:
https://redmine.pfsense.org/issues/16821

Essentially when the filter is reloaded (i.e. the rules are generated and loaded) there are some checks to determine if it's possible to monitor the gateway accurately. For the "gateway monitoring" block rule to not be added the following is necessary at the time the filter reloads:

The gateway IP must be valid.
The monitoring IP must be valid.

The redmine issue states "dpinger is running with the correct bind address and monitor target". That likely means that the block rule was added because the gateway address was unavailable. I expect for the filter to have been reloaded once the DHCP interface was ready; it seems like that didn't happen.

With some additional logging perhaps we can better understand what may be happening. The following patch can be applied on 26.03. To test, add and apply it with the System Patches package and make sure that logging (Status > System Logs > Settings > Default Log Level) has been set to at least "Notice". Once the issue reoccurs, get all of the system log files (/var/log/system.log*), compress them, and share the archive for review.
Patch: https://nc.netgate.com/nextcloud/s/gCLiC7DeMQedYGr
Logs upload: https://nc.netgate.com/nextcloud/s/ZsjmKBpcqji3tnw