Unresolvable source alias!
-
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?
-
@Antibiotic I'm still finding my way around pfblocker and pfsense in general.
Good question. I still want to limit inbound port 25 to not only domestic mta's but also want to exclude harmful or those rated poorly.
How would I implement that?
-
@Antibiotic said in Unresolvable source alias!:
why action "deny both"! What the reason to block inbound, if its block by firewall itself?
@GPz1100 is allowing port 25 inbound, but blocking the "bad people lists" is presumably above the rule allowing port 25.
If someone has no inbound NAT port forwards or firewall rules on WAN, then it is unnecessary to add more block rules.
-
Exactly!
The question is, is it possible to create an alias containing nested aliases? For example, !PRI1 and pfB_NAmerica_v4? Meaning not in PRI1 list and in the NA list? Or would this still be two rules. I think the "quick" option would be applicable but that's available only for floating rules.
-
@GPz1100 I don't know a direct answer to your question, but I would arrange the rules in order and not try to do that with aliases.
You can use Alias Native instead of Deny Both which only creates an alias, and does not create rules. Then you can create your own rules in whatever order you want.
Quick is on by default for all rules except floating rules. It just means, first match wins.
https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html#quick