Unresolvable source alias!
-
It is a bug? Created alias and all time this error!
-
@Antibiotic when you force-update pfBlocker does it show an error for that URL?
-
@SteveITS This is not pfBlockerNG rule. This is standard firewall rule in WAN
-
-
@Antibiotic said in Unresolvable source alias!:
@SteveITS This is not pfBlockerNG rule. This is standard firewall rule in WAN
Oh sorry, I was answering too quickly I guess.
Can you load the URL in your browser, and is it in the right format? (only IPs)
https://docs.netgate.com/pfsense/en/latest/firewall/aliases.html#url-table-aliases -
@SteveITS said in Unresolvable source alias!:
https://docs.netgate.com/pfsense/en/latest/firewall/aliases.html#url-table-aliases
Yes I can load to browser, format is going example:
ip,port,country
169.57.1.85,8123,US
64.238.140.247,3128,US
103.130.61.61,8081,ID
213.230.97.10,3128,UZ
118.173.56.31,80,TH
122.155.165.191,3128,TH
185.135.193.38,3128,PLAfter forced WAN gateway for this moment error is gone, will monitoring
-
@SteveITS Oh, after rebooting the same error(((
-
Your URL table alias file is not in the accepted format. It should contain only the following per the documentation @SteveITS linked. Did you follow his link and read the docs?
Here is the verbatim line from the documentation:
If URL Table (IPs) is selected, then the URLs must contain IP address, CIDR masked network entries, or FQDNs
The example you posted contains extraneous information on each line, and the very first line contains totally invalid data.
This would be a valid file format:
169.57.1.8
64.238.140.247
103.130.61.61
213.230.97.10Notice it cannot contain commas nor can it contain both IP addresses and ports in the same file. It is either URL IPs or URL Ports, but it cannot contain both.
Your life would be easier and your pfSense experience less burdensome if you would take the time to actually research and read the available documentation.
-
@SteveITS I'm seeing similar with 24.03. My use case is a geoip alias in a port forward.
Under nat ip is the private ip of the smtp server.
This is after a reboot, note the pfb_n.... is not a link. In testing, this effectively blocks all inbound smtp. If i do a forced update in pfblockerng, then it all works as expected.
Is there a way to force an update after a reboot?
Using "/usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php update >> /var/log/pfblockerng/pfblockerng.log" In a shellcmd command line or script does not work.
-
@GPz1100 I think I’ve seen that occasionally on a restart but not all the time. I just run an update. You could set pfB to update more frequently…
-
This rule does the same thing as the next hidden final rule : traffic is dropped, no action is takes, nothing is done, and this is good : you should spend as less CPU cycles a possible on useless traffic.
edit : I presume you have this one unchecked :
Oho .... you get this backwards !
As soon as these bad guys (see table) start to send loads of packets to you, you are logging this discarded traffic. Nice, you know where it came from. Less nice : read on.
If you are really get dossed, these guys get exactly what they are after : they introduce a bigger load on your system, and, big bonus : your firewall log files start to grow extremely fast.... The logs files are size checked and rotated if needed, true but ....
If if you really get dossed, the the number of log lines can get overwhelming.
If your WAN speed is big enough (1 Gbytes ) and you get 10 or 100 of thousands of packets to handle, and you want to log a line for each of them, your pfSense will become very busy ... and if things go wrong, you run out of disk space.
Log file rotation will take much more time if these files start to be huge.So, as said before : no rules on WAN, that's the safest setup
Ok, true, if you have a small pipe to the net, like a couple of Mbytes/sec, you don't risk much.
The dos will fill up the pipe of course, and your internet connection becomes worthless.That's why the best anti dos protection doesn't need any setup : just stay away from 'games', and if you have to, only play with adults, don't play with kids.
Don't mess around with anonymous.
Be friendly out there, bail out as soon as things get nasty. -
@Gertjan said in Unresolvable source alias!:
edit : I presume you have this one unchecked :
Where is this setting?
Ah , found in system log settings! Is it correct?
-
Yes, the log settings are under Status > System Logs > Settings
-
@Gertjan So, by your logic better to untick, no reason to log which blocked already by default? to reduce spam log, is it?
-
This post is deleted! -
@SteveITS said in Unresolvable source alias!:
@GPz1100 I think I’ve seen that occasionally on a restart but not all the time. I just run an update. You could set pfB to update more frequently…
Steve, that's not really a viable solution either. Even if I set it update hourly, if the system should be restarted at the start of the hour, no emails would arrive for an hour.
Generally the firewall is not restarted for weeks/months at a time, but the expectation is for it to be fully operational following a reboot.
-
@GPz1100 Yeah I don't disagree with that. But it doesn't seem to be consistent for us, is it every restart for you?
I always uninstall pfBlocker when upgrading, and even then the aliases sometimes survive the restart. So it just seems wildly inconsistent.
Q: How are are you creating them? We use the IPv4 tab directly:
@Antibiotic said in Unresolvable source alias!:
no reason to log which blocked already by default? to reduce spam log, is it?
That is what we do. Logging of default block rules, RFC1918, etc. can be enabled if it is ever necessary, for debugging.
-
I meant to add, in our case we have an external spam filter we use for all our clients, so when we had a mail server on premises we could allow only those IPs to connect on port 25.
-
It's happening on every single reboot (don't ask how many times i've rebooted to test). Pfblockerng is configured with the following (for now).
This is configured to apply under floating rules for wan (inbound) and lan interfaces (outbound). As I understand it, this is the first level of blocking.
Assuming a sending mta passes the above filter, then under geoip, I only want to receive email domestic mta's. Geoip is configured to only permit US/CA mail servers. I understand geoip isn't 100% accurate. There is a 2nd mx for the domain where these other mx's can connect to.
As for the issue at hand, I think I got it fixed. Using a cron @reboot job, a script containing the following is run.
sleep 120 /usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php update >> /var/log/pfblockerng/pfblockerng.log sleep 2 /usr/local/bin/php -f /etc/rc.filter_configureI suppose this could also be a shellcmd, but that would pause the firewall bootup. This way the script waits til 2 min post reboot, then updates pfblockerng and does a forced filter reload. In typical operation, it's not likely a forced filter reload will be necessary as something in the pfblockerng update will likely be changed, causing it to request a filter reload any way. In testing, nothing changed, so filter reloads did not occur, thus not applying the updated alias.
-
@GPz1100 why action "deny both"! What the reason to block inbound, if its block by firewall itself?
