Unresolvable source alias after upgrade to 23.09
-
My rule to allow pings from UptimeRobot stopped working following the upgrade from 23.05.1 to 23.09.
I am facing endless log spam of:
# Unresolvable source alias 'UptimeRobot' for rule 'Allow Uptime Robot pings' label "USER_RULE: Allow Uptime Robot pings"The alias uses
https://uptimerobot.com/inc/files/ips/IPv4andIPv6.txt. The rule is a quick pass floating rule configured to allow inbound IPv4 and IPv6 ICMP type echoreq from alias UptimeRobot on the WAN interface.An identical rule is working using an identical URL alias on a 23.05.1 node that has not been upgraded yet. I tested with changing the alias and rule to IPv4 only with no change in the outcome. I ripped and recreated the rule and the alias with no change.
This is a serious annoyance as it creates a false positive alert for that node as offline. It leaves me reluctant to upgrade customer devices if it is going to precipitate a false outage notifications on those nodes.
Does anyone know what changed in the latest release and, more importantly, how I can fix it?
-
@LinkP With pfBlocker I see no problems with that alias source.
-
@Bob-Dig This is just a standard firewall rule, not pfBlocker.
In
/tmp/rules.debugin the 23.05.1 node, I see the expected rule generated, but in the 23.09 node I see# Unresolvable source alias 'UptimeRobot' for rule 'Allow Uptime Robot pings' label "USER_RULE: Allow Uptime Robot pings"where the generated rule should be.Example rules (with redacted IPs) from working 23.05.1 node:
pass in quick on { vtnet0 } reply-to ( vtnet0 X.X.X.X ) inet proto icmp from $UptimeRobot to (self) icmp-type echoreq ridentifier 1560989549 keep state label "USER_RULE: Allow Uptime Robot pings" label "id:1560989549" pass in quick on { vtnet0 } reply-to ( vtnet0 fe80::dead:beef:1%vtnet0 ) inet6 proto ipv6-icmp from $UptimeRobot to (self) icmp6-type echoreq ridentifier 1560989549 keep state label "USER_RULE: Allow Uptime Robot pings" label "id:1560989549" -
@LinkP Try to force an update in pfblockerNG
-
@mcury What does pfBlockerNG have to do with this? This a regular firewall rule, not a pfBlocker rule.
The problem is now present in the other node following an upgrade from 23.05.1 to 23.09.
-
@LinkP said in Unresolvable source alias after upgrade to 23.09:
@mcury What does pfBlockerNG have to do with this? This a regular firewall rule, not a pfBlocker rule.
The problem is now present in the other node following an upgrade from 23.05.1 to 23.09.
Hi,
Did you try to make the Alias like this:
-
@LinkP said in Unresolvable source alias after upgrade to 23.09:
What does pfBlockerNG have to do with this?
I thought that this alias was created by pfblockerNG, my mistake.
-
I have put a pin in this as I have a much bigger problem now. The other node appears to have lost track of 85% of its disk and is only showing a 1.5GB volume mounted at / and is completely full.
I should not have been so enthusiastic about upgrading to 23.09.Edited to update: The disk issue was related to ZFS Boot Environments
H/T to @SteveITS for pointing me to these posts:
https://forum.netgate.com/post/1132635
https://forum.netgate.com/post/1118798 -
@LinkP said in Unresolvable source alias after upgrade to 23.09:
I have put a pin in this a I have a much bigger problem now. The other node appears to have lost track of 85% of its disk and is only showing a 1.5GB volume mounted at / and is completely full.
Hi Link. :)
If this is
Netgate hardwarepfSense Plus it may have leftover boot environments.
https://docs.netgate.com/pfsense/en/latest/backup/zfsbe/space.html
https://docs.netgate.com/pfsense/en/latest/troubleshooting/filesystem-shrink.htmlI don't know if pfSense is supposed to be cleaning up old ones, and if so at what interval, but I've seen a few posts where it seems not to...
@LinkP said in Unresolvable source alias after upgrade to 23.09:
Unresolvable source alias 'UptimeRobot'
Does Diagnostics/Tables show it?
-
I am also having simaler problem after updating. I have created a Custom Alias called Huntress and use the below URL to pull URl's from my GitHub. I get an error that says "Unresolvable destination alias 'Huntress' for rule 'Huntress Allow'". This rule was working before I upgraded (Previous v23.05.1).
https://raw.githubusercontent.com/csardoss/pflist/main/huntrss.io_list.txt
-
re: ZFS filling the drive:
https://forum.netgate.com/topic/181961/netgate-4100-out-of-diskbectl list
bectl destroy auto-default-20230629155043after freeing space, one can revert and re-upgrade:
https://docs.netgate.com/pfsense/en/latest/backup/zfsbe/loader.html -
Don't want to hijack the troubleshooting here, but just wanted to chime in that the exact same thing happened on my device after doing the upgrade to 23.09 as well. I get the error on all my regular url aliases, but not on my url table ones. Seems like this is happening to multiple people. (No pfBlockerNG here either). The aliases themselves update just fine, seems like it is just the firewall not able to get them properly.
-
@LinkP said in Unresolvable source alias after upgrade to 23.09:
Unresolvable source alias
FWIW they have four fixes for aliases:
https://docs.netgate.com/pfsense/en/latest/releases/23-09.html#aliases-tables¯\_(ツ)_/¯
Edit: meaning the code changed, may have broken something
-
Someone with this can file a report at redmine.pfsense.org
-
@csardoss said in Unresolvable source alias after upgrade to 23.09:
I am also having simaler problem after updating. I have created a Custom Alias called Huntress and use the below URL to pull URl's from my GitHub. I get an error that says "Unresolvable destination alias 'Huntress' for rule 'Huntress Allow'". This rule was working before I upgraded (Previous v23.05.1).
https://raw.githubusercontent.com/csardoss/pflist/main/huntrss.io_list.txt
Got the same error when my Alias was using URL (IPs). Then I change TYPE from URL (IPs) to URL Tables (IPs) and error gone.
-
Reported here: https://redmine.pfsense.org/issues/14947
-
S SteveITS referenced this topic on
-
Same issue here. URL Aliases can no longer be selected when creating a NAT rule, but can be selected when creating a firewall rule.
We had a NAT rule allowing only Cloudflare to access our on-prem webserver, which was broken by the update. In the meantime we have created a new alias with the IP's entered manually rather than pulling from https://www.cloudflare.com/ips-v4
Please could this be added to breaking changes here: https://docs.netgate.com/pfsense/en/latest/releases/23-09.html
-
Hi,
I don't have any problems like that on any of my Alias.
What is the different between "URL (IPs)" and "URL Table (IPs) in the Alias on the TYPE?This is an example of my Cloudflare Alias I use.
EDIT: Found it :)
-
@MoonKnight Ah, yes! URL Table(IPs) work, URL (IPs) does not!
Difference is explained here: https://docs.netgate.com/pfsense/en/latest/firewall/aliases.html#url-aliases
That's a much better workaround, thanks!
-
There's a patch in the above redmine so someone can test this by using System Patches and the ID in the redmine, a6cf534d0fa0297547f1e587a12729f9d7066bae.
