Oddity, may (or may not) be directly related to pfBlockerNG and DNSBL VIP
-
All,
Will preface this by stating that there has not yet been an opportunity to build a fresh [vanilla] instance of pfSense to discern if its directly related to pfBlockerNG. The DNSBL and its VIP being allocated on the loopback ?might? have some implication (although being able to run on the loopback is demonstrably preferable).
What was witnessed, ssh'ing into the firewall, just after reboot completed:
Found this as a result of local (127.0.0.1) DNS resolution not working. eg: proper practice for a DNS server is that it should utilize itself (127.0.0.1) for its own DNS resolution. That said, realized that localhost was not even reachable via ping. (NOTE: 10.20.30.40 is the IP Address for the DNSBL webserver interface). (Wonder if the alias'd IP Address being applied or 'how' its applied to the loopback is part and parcel to the issue?).
Upon some cursory testing, removed pfBlockerNG and the issue was still present. Hence the reason for the comment that this may or may not be related to pfBlockerNG. While the ports are "hard-coded" for localhost, it would be nice if they simply 'defaulted' to 80/443 but remained configurable (as they are for other interfaces), eg: handling "localhost" with the same configurable options as any other interface for ports, etc.
As a [less than desirable] temporary fix to the issue, did implement two shellcmd actions (early and post filter) as "/sbin/ifconfig lo0 inet 127.0.0.1" and now things work. What's particularly strange (when doing initial testing, prior to shellcmds being used) is that after uninstalling pfBlockerNG and rebooting - 127.0.0.1 remains non-pingable. At least until you issue "ifconfig lo0 inet 127.0.0.1", at which point localhost works as expected.
Will need to spin up a vanilla instance to see if localhost is pingable without any packages being installed. That will determine if its an issue in core pfSense or artifact of a package. Then start installing package-by-package (doing a reboot after each package is installed and configured) to see when/where this issue occurs (if its not an issue in the vanilla instance).
For reference, instances where this would be problematic:
- Ability to use 127.0.0.1 as the DNS server (regardless of resolver [BIND/unbound])
- If BIND is necessary for DDNS and you need/want pfBlocker. eg: BIND -> 127.0.0.1 port <X> [unbound] for recursive lookups via unbound.
- Even without pfBlocker, utilizing unbound's recursive performance as upstream to BIND is worthwhile. Especially keeping it on the loopback to minimize "noise" on other interfaces to make packet dumps a "bit" easier to work with - avoiding unnecessary traffic on other interfaces, where possible.
- Any other application/service where the loopback is (or could be) utilized (even if for control)
From a config standardization and simplification perspective, the ability to use the loopback (where possible) is quite beneficial.
-
A ping to 127.0.0.1 should always work. Consider a non working 127.0.0.1 as a massive failure.
Way back, when I was using 2.6.0 ( or older ?) I saw this happening : no more 127.0.0.1.
Had to create it - as you did.Went to the forum, found that I was not the only one having this, so I did found a patch for it.
This package
isn't optional a,y more : you have to install it.
It will propose some build-in patches. Read about them all, and apply them all, or take your pick.
-
@justme2 Here is the answer as Gertjan said:
"A ping to 127.0.0.1 should always work. Consider a non working 127.0.0.1 as a massive failure."
