• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Unable to check for updates after upgrading to pfSense+ 22.01 when using SmartDNSProxy

Scheduled Pinned Locked Moved DHCP and DNS
4 Posts 2 Posters 1.2k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • Y
    yugisop
    last edited by yugisop Feb 26, 2022, 2:24 AM Feb 26, 2022, 2:22 AM

    Hi guys,
    I just upgraded from 2.5.2 to 2.6 and switched to pfSense+ v22.01 however dashboard reports "Unable to check for updates".
    082be685-fe29-41a9-ac57-a806638bb45f-image.png
    Troubleshooting the issue has shown that the problem appears to be DNS related, however using option 13 from the shell to perform the check for updates works fine.

    I'm using DNS resolver with upstream SmartDNSProxy servers as follows:
    d5f91845-1dfe-4b19-8cb3-93d445e0324d-image.png

    In DNS resolver log, once the Dashboard page is loaded, I see pfSense performing lookups for the following domains which are all successful:
    firmware.netgate.com
    files00.netgate.com
    files01.netgate.com

    Where it gets weird is that pfSense+ tries to lookup / reverse lookup Google's DNS servers and SmartDNSProxy refuses these queries which bring the software update check to a screeching halt.
    49a05d66-51c3-464c-9289-66093819f107-image.png

    Adding 2 domains bypass for Google's reverse DNS in unbound as below fixes the error:
    0740cda1-046c-4f9f-b996-9c8751f93f66-image.png

    1c0c55e9-eb2d-4bf4-a6df-51d144d95ab5-image.png

    but WHY / HOW?? What is the relevance of Google's reverse name lookup to the update process??

    This was not an issue before on 2.5.2 so why now?

    M 1 Reply Last reply Apr 5, 2022, 11:29 AM Reply Quote 0
    • M
      michael_samer @yugisop
      last edited by Apr 5, 2022, 11:29 AM

      Hello yugisop
      unluckily I've the same problem since my move to 22.01 (while the others worked as expected).
      Because of an old proxy auth. Bug in pfsense we decided to use our own squid proxy to work around that bug. Since the Update we are unable to check for update (while the check works on a proxyless Inet site as it should) without a "unable to check for updates" while checking. Option 13 works like a charm, but I fear for a deeper problem. We are using SG3100 and XG7100 all as LAN-2-LAN Firewall.
      In the squid log I see running checks against netgate URLs which all succeeds. Because the GUI check is so fast reporting an "unable" I checked DNS as well and as we have DNS via proxy it fails.

      As your system is looking to have free Inet access (far away from our site) I wonder what fails but same outcome.
      Cheers
      Michael

      M 1 Reply Last reply Apr 5, 2022, 12:28 PM Reply Quote 0
      • M
        michael_samer @michael_samer
        last edited by Apr 5, 2022, 12:28 PM

        P.S. I forgot: We used this patch entries to fix the really stupid function to get going again:
        CATAR_DNS_Patch.png

        M 1 Reply Last reply Apr 6, 2022, 4:58 AM Reply Quote 0
        • M
          michael_samer @michael_samer
          last edited by Apr 6, 2022, 4:58 AM

          Hi yugisop
          aftr a bit of search I found the guilty config in

          /usr/freebsd-dist/base/etc/inc/system.inc
          ...
          function check_dnsavailable($proto='inet') {

           if ($proto == 'inet') {
               $gdns = array('8.8.8.8', '8.8.4.4');
          

          ...

          So it seems they check if a DNS is available and then decide whatever about it.

          Cheers
          Michael

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received