One Firewall Rule Being Troublesome
-
@cmb:
Can't seem to replicate the problem with the missing LAN IP. Probably some kind of race condition I'd guess. Does seem to be cosmetic since by the time the system finishes booting it'll have the IP there and have the ruleset reloaded.
Phil, what'd you do to replicate? And on what kind of system? I'm testing on relatively fast hardware or VMs on fast systems, maybe something replicable on an ALIX or something?
NOYB: All 6 of the crash reports from your IP today are just notices trying to send something and failing to resolve DNS.
Warning: dns_get_record(): DNS Query failed in /etc/inc/notices.inc
what do you have configured for notifications?
Okay sounds like then the crash reports were not related to the firewall rule issue. The notifications settings would have been the same as they were on 2.2.6. Never changed them and they were working.
Due to those, and slow boot at certain points, most noticeably starting cron, I just decided to install fresh.
Not getting the crash reports, nor slow boot, now. But still get the notice about the firewall rule.As mentioned earlier these same rules work fine on VirtualBox VM; Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz 2 CPUs: 1 package(s) x 2 core(s).
This is a Dell Inspiron 5100; Intel(R) Pentium(R) 4 CPU 2.66GHz. Full install on USB flash drive.
-
The crash reports apparently were due to Growl being enabled with a bogus "IP Address" (domain name) that couldn't be resolved.
The !LAN address firewall rule notification still an issue.
-
I have the same firewall rule under 2.3 using any instead of LAN and it seems to work fine.
-
I have the same firewall rule under 2.3 using any instead of LAN and it seems to work fine.
It's not the same firewall rule if it is using any instead of !LAN address. It's the !LAN address that has the problem. As I think it was cmb mentioned it is likely a race issue that "LAN address" isn't quite available in time for the initial loading of the rules. But then later it is. Don't think "any" would suffer from such, and I know an alias doesn't.
-
So does !LAN relate to only IP addresses defined to pfsense? I am not sure. I would think "any" would be a better choice since it would cover any foreign networks and block DNS for them as well.
-
"LAN address" is the IP address of the pfSense LAN interface.
So the rule blocks all packets that have a destination port of 53 (DNS) combined with a destination address other than the pfSense LAN interface. Thus the only allowed DNS is that which is provided by pfSense. In this case DNS Resolver (unbound).
Any would also block LAN based DNS requests to pfSense. That is not desired. Desire is for all DNS request to be blocked except those to pfSense.
-
"LAN address" is the IP address of the pfSense LAN interface.
So the rule blocks all packets that have a destination port of 53 (DNS) combined with a destination address other than the pfSense LAN interface. Thus the only allowed DNS is that which is provided by pfSense. In this case DNS Resolver (unbound).
Any would also block LAN based DNS requests to pfSense. That is not desired. Desire is for all DNS request to be blocked except those to pfSense.
You could also redirect these other DNS requests back to pfSense. For IPv4 that is…
https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense
-
I get it. It is inverse of LAN. I tested on my pfsense.
-
You could also redirect these other DNS requests back to pfSense. For IPv4 that is…
https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense
Prefer anything, apps, device, etc. attempting to use DNS not supplied by the local network, result in a fail.
-
Phil, what'd you do to replicate? And on what kind of system? I'm testing on relatively fast hardware or VMs on fast systems, maybe something replicable on an ALIX or something?
It was in a VirtualBox VM on my Windows10 laptop. I just tried rebooting it twice again and can't get the error to happen again. But for some reason the VM is booting much faster than usual at the moment, so maybe it is a timing thing.