22.05-RELEASE (amd64) Unable to check for updates?

TAC57

@SteveITS In System / General Setup / DNS Servers I changed 9.9.9.9 to 1.1.1.1 and ran the command above with @1.1.1.1 and got the following:

;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out
;; no servers could be reached

stephenw10

Can you query either of those from a host behind pfSense?

TAC57

@stephenw10
This from my windows command prompt:
Microsoft Windows [Version 10.0.19045.3031]
(c) Microsoft Corporation. All rights reserved.

C:\Users\Tom>ping 9.9.9.9

Pinging 9.9.9.9 with 32 bytes of data:
Reply from 9.9.9.9: bytes=32 time=266ms TTL=57
Reply from 9.9.9.9: bytes=32 time=15ms TTL=57
Reply from 9.9.9.9: bytes=32 time=15ms TTL=57
Reply from 9.9.9.9: bytes=32 time=16ms TTL=57

Ping statistics for 9.9.9.9:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 266ms, Average = 78ms

C:\Users\Tom>ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=267ms TTL=57
Reply from 1.1.1.1: bytes=32 time=16ms TTL=57
Reply from 1.1.1.1: bytes=32 time=15ms TTL=57
Reply from 1.1.1.1: bytes=32 time=15ms TTL=57

Ping statistics for 1.1.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 267ms, Average = 78ms

C:\Users\Tom>ping 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=14ms TTL=115
Reply from 8.8.8.8: bytes=32 time=13ms TTL=115
Reply from 8.8.8.8: bytes=32 time=14ms TTL=115
Reply from 8.8.8.8: bytes=32 time=14ms TTL=115

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 14ms, Average = 13ms

C:\Users\Tom>ping acb.netgate.com

Pinging acb.netgate.com [208.123.73.212] with 32 bytes of data:
Reply from 208.123.73.212: bytes=32 time=39ms TTL=51
Reply from 208.123.73.212: bytes=32 time=39ms TTL=51
Reply from 208.123.73.212: bytes=32 time=38ms TTL=51
Reply from 208.123.73.212: bytes=32 time=39ms TTL=51

Ping statistics for 208.123.73.212:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 38ms, Maximum = 39ms, Average = 38ms

TAC57

@SteveITS I have DNS resolver enabled. What is the easiest way to turn all this off?

And this has to be related:
An error occurred while uploading the encrypted Netgate pfSense Plus configuration to https://acb.netgate.com/save ( Unable to resolve acb.netgate.com ) @ 2023-05-28 16:49:05

stephenw10

Do you have the DNS resolver set to forwarding mode though?

If you do try just unchecking that so it resolves directly.

TAC57

@stephenw10 It was, unchecking made no difference.

stephenw10

Hmm. Just to be clear is that failing to resolve any host? Even when resolving directly?

That sounds like it must be something blocking DNS requests from the firewall. But I expect anything doing that to apply to NAT'd traffic from clients behind it also.

TAC57

@stephenw10 I'm sorry but I don't understand your question. Is there a screenshot you'd like to see or some setting I can change that might solve this issue.

BTW I ran the dig command from a Raspberry Pi on my network:
crites@raspberrypi:~ $ dig +short @9.9.9.9 firmware.netgate.com
208.123.73.207
208.123.73.209

crites@raspberrypi:~ $ dig +short @9.9.9.9 acb.netgate.com
208.123.73.212

I have a basic homelab setup with some desktop computer, TrueNAS server running Plex, and some IOT stuff.

SteveITS

@TAC57 You’ve posted DNS to third party servers works from devices on LAN but not pfSense. Which implies something is blocking it. Can you post your LAN rules and any floating rules, and routes (diagnostics menu)?

stephenw10

I meant does Diag > DNS Lookup fail for any host or just firmware.netgate.com?

Are you running Snort or Suricata?

TAC57

@stephenw10 Before rebooting I'd get the Unable to check for updates and DNS Lookup would not report anything from any host. On rebooting pfsense it now reports on the latest version. And DNS Lookup does report back (see below) and it reports back from google.com

I am running Snort.

TAC57

@SteveITS I'm not running any floating rules. Can DM you my routes?

LAN rules:

SteveITS

@TAC57 and were those DNS IPs on the Snort alert page? That’s why I asked about Snort above. Reading back it sounds like a restart fixed it in January also. Restarting would empty the Snort block table.

stephenw10

Yup, disable Snort. Reboot. Retest.

TAC57

@SteveITS
I've been running Snort forever. I'll disable it and see what happens.

TAC57

@stephenw10 I disabled Snort, rebooted and still unable to check for updates. Also, DNS Look up doesn't return any IPs.

stephenw10

Make sure the Snort block table is actually cleared, assuming you had Snort in blocking mode. Check Diag > Tables > Snort2c.

Snort pulls new signatures automatically. It can start alerting/blocking things that were previously fine without warning!

TAC57

@stephenw10 Snort2c table is empty.

I've disabled Snort and have rebooted pfsense.

pfsense is still reporting 'Unable to check for updates'.

Diag / DNS Lookup times out with firmware.netgate.com, google.com, 8.8.8.8. It took about 3 minutes to get the message 'Host "firmware.netgarte.com" cound not be resolved.'

I can ping any of these host from a Raspberry Pi and replys.

To switch from the Status / Dashboard screen to the System / Update screen takes 1.5 minutes and then about another 30 seconds to report that it's Unable to check for updates.

I'm also still getting the notice "An error occurred while uploading the encrypted Netgate pfSense Plus configuration to https://acb.netgate.com/save ( Unable to resolve acb.netgate.com ) @ 2023-05-30 16:53:11"

I'm running pfsense on a Zima SBC:
Intel(R) Celeron(R) CPU N3450 @ 1.10GHz
4 CPUs : 1 package(s) x 4 core(s)
AES-NI CPU Crypto: Yes (active)
IPsec-MB Crypto: Yes (inactive)
QAT Crypto: No

These are my installed packages / Services:

stephenw10

Oh you're not using the resolver (Unbound) at all. You're using the forwarder (DNSMasq).

In that as a test I would try disabling DNSMasq and enabling Unbound and see if that makes any difference. With that it should resolve directly.

DefenderLLC

@stephenw10 Plus he’s running practically running every pfSense package!