This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Firmware Up2Date installation failed - after upgrade to UTM 9.709-3

Hi list,

with previous version I had 95% up2date failture from UTM, message being all 5 servers not responding. I updated manually the 2 FW version before this one. Now that I installed 9.709-3 version, I get tones of

Firmware Up2Date installation failed: IPS pattern installation was not successful but will keep trying to install. During this time IPS might not be active. Please inspect the UTM if you keep getting this message!
Please check the up2date log file for detailed information

Also, the pattern version stay since ages at 205945 - Your patterns are up to date which is false based on othe UTM.

This version is a Home version. On other UTM (with licences) I face the same problem that up2date never show up new firmware version, have to execute them manually.

The Home version is running ipv4 and ipv6, others only ipv4.

Thanks for any hint

Daniel


This thread was automatically locked due to age.
Parents
  • Hallo,

    was sagt denn das up2date-log ?


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • Logs:

    2022:02:25-18:44:53 guava audld[26056]: 3. Modules::Audld::Authentication::start:68() /</sbin/audld.plx>Modules/Audld/Authentication.pm
    2022:02:25-18:44:53 guava audld[26056]: 4. main::main:187() audld.pl
    2022:02:25-18:44:53 guava audld[26056]: 5. main::top-level:40() audld.pl
    2022:02:25-18:44:53 guava audld[26056]: |=========================================================================
    2022:02:25-18:44:53 guava audld[26056]: id="3703" severity="error" sys="system" sub="up2date" name="Authentication failed, no valid answer from Authentication Servers"
    2022:02:25-18:44:53 guava audld[26056]:
    2022:02:25-18:44:53 guava audld[26056]: 1. Modules::Logging::alf:100() /</sbin/audld.plx>Modules/Logging.pm
    2022:02:25-18:44:53 guava audld[26056]: 2. Modules::Audld::Authentication::start:72() /</sbin/audld.plx>Modules/Audld/Authentication.pm
    2022:02:25-18:44:53 guava audld[26056]: 3. main::main:187() audld.pl
    2022:02:25-18:44:53 guava audld[26056]: 4. main::top-level:40() audld.pl
  • 2022:02:25-18:44:53 guava audld[26056]: id="3703" severity="error" sys="system" sub="up2date" name="Authentication failed, no valid answer from Authentication Servers"

    There is your error.  You can't reach the auth servers possibly due to a DNS issue.  Might need to see more of the log other than what you posted.

    OPNSense 64-bit | Intel Xeon 4-core v3 1225 3.20Ghz
    16GB Memory | 500GB SSD HDD | ATT Fiber 1GB
    (Former Sophos UTM Veteran, Former XG Rookie)

  • Don't think this is the issue (or DNS error comes from the upgrade) as (check for update is set to each 15 min):

    . remember that with previous version 95% of the upgrade failed with "all 5 servers not responding" which means 5% OK
    . no DNS changes made after the upgrade
    . the message doesn't appear on each tries eg. sometimes 30 min without failure message
    . I changed the update time to daily, still get the message each 5 minutes
    . a ipv4 ping to www.sophos.com or an ipv6 traceroute to www.sophos.com *from UTM tools* are OK
    . pattern version doesn't upgrade too  

    Problem lies somewhere else ...

  • . remember that with previous version 95% of the upgrade failed with "all 5 servers not responding" which means 5% OK

    "all 5" - that's not 95%, that's 100%.  What do you mean 95% and 5%?  If it says all, that means all.

    . a ipv4 ping to www.sophos.com or an ipv6 traceroute to www.sophos.com *from UTM tools* are OK

    Pings and traceroutes to a website doesn't mean that Up2Date should be accessible.  That just means that ICMP is acknowledging a response and giving you the TTL response.

    I agree that Pattern version isn't updating, as per another post we've been speaking in, and hopefully someone at Sophos will address.  The pattern version lack of updating and your Up2Date problem may be related to each other.  More updated UTMs seem to be stuck at 206808 (mine is as well).

    OPNSense 64-bit | Intel Xeon 4-core v3 1225 3.20Ghz
    16GB Memory | 500GB SSD HDD | ATT Fiber 1GB
    (Former Sophos UTM Veteran, Former XG Rookie)

  • Pings and traceroutes to a website doesn't mean that Up2Date should be accessible.  That just means that ICMP is acknowledging a response and giving you the TTL response.

    But means that DNS is working as you supposed a DNS issue ;)

    I found another strange behavior with this: as told, despite the fact that update should be done daily, it's not. But it's regulary. For instance, this night it was each hours at H@12min H@17min @22min H@28min H@33min and from here it jump to H+1@12min aso. But after 3 hours, 1 min is added which means it started at H@13min H@18min H@23min H@28min H@33min and than jumpt to H+1@13min aso.

    Very very strange

  • "all 5" - that's not 95%, that's 100%.  What do you mean 95% and 5%?  If it says all, that means all.

    It means that 95% of the time up2date failed with the error that all 5 servers are not responding, 5% of the time it runs smoothly

  • zurück zum Thema ...

    Die erfolgreichen up2date Verbindungen sollten bei nahezu 100% liegen. Sonst ist etwas faul.

    1. DNSSEc ist nicht aktiviert? Funktioniert es mit 1.1.1.1 als DNS-Server besser?

    2.ein "Parent proxy" ist nicht unter up2date/advanced eingetragen?

    3. was für ein Gerät steht "vor" der Firewall?


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • I connect to UTM and ran audld.plx -level d as root from command line. In out put I see

    >>> Modules::Audld::LocalRestriction::_seek_own_country::130()
    Could not connect to Server us1.utmu2d.sophos.com (status=500 Can't connect to us1.utmu2d.sophos.com:443 (timeout)).

    >>> Modules::Audld::LocalRestriction::_seek_own_country::130()
    Could not connect to Server us2.utmu2d.sophos.com (status=500 Can't connect to us2.utmu2d.sophos.com:443 (timeout)).

    >>> Modules::Audld::LocalRestriction::_seek_own_country::130()
    Could not connect to Server sg1.utmu2d.sophos.com (status=500 Can't connect to sg1.utmu2d.sophos.com:443 (timeout)).

    >>> Modules::Audld::LocalRestriction::_seek_own_country::130()
    Could not connect to Server eu1.utmu2d.sophos.com (status=500 Can't connect to eu1.utmu2d.sophos.com:443 (timeout)).

    >>> Modules::Audld::LocalRestriction::_seek_own_country::130()
    Could not connect to Server eu2.utmu2d.sophos.com (status=500 Can't connect to eu2.utmu2d.sophos.com:443 (timeout)).

    Which are the errors shown in previous UTM version. That mean that problem is the same that I had since monthes (95% of the time I saw this error) and that with the last version the message is just another one. Bad.

    host us1.utmu2d.sophos.com
    us1.utmu2d.sophos.com has address 54.214.16.252
    us1.utmu2d.sophos.com has IPv6 address 2a01:729:16e:10:ff:0:36d6:10fc

    or

    host eu1.utmu2d.sophos.com
    eu1.utmu2d.sophos.com has address 79.125.21.244
    eu1.utmu2d.sophos.com has IPv6 address 2a01:729:16e:10:ff:0:4f7d:15f4

    which means not a DNS error. CIsco router in bridge mode, UTM is has direct connection to Internet. The problem arise with 9.708.6, was working well with previous version.

  • Well, you missed the point.  Ping != DNS resolution.  That is ICMP_ECHO requests being fulfilled or not fulfilled. It will use hosts file information, being DNS cache, and thus pings the last known IP.  The reply is just the TTL response of the last known IP address.

    So no, ICMP doesn't equate to DNS directly. I also said 'possibly', not 'definitely'.

    At any rate, yes you have an issue with Up2Date, and others do as well (pattern updates not working correctly) as outlined in other posts.

    The later post you made is why I also previously stated that we needed more information from your logs:

    >>> Modules::Audld::LocalRestriction::_seek_own_country::130()

    I don't know if that reads the same is how I am interpreting it because I've not seen this before, but it reads like there is a restriction in place of where you can get your Up2Date files, and maybe why your failure % is so high.  I don't know what country your UTM is in.  Could be reaching out to other remote domains because the one you would normally get your Up2Date is unavailable?  Dirk or someone else might know more on that.

    OPNSense 64-bit | Intel Xeon 4-core v3 1225 3.20Ghz
    16GB Memory | 500GB SSD HDD | ATT Fiber 1GB
    (Former Sophos UTM Veteran, Former XG Rookie)

  • UTM is in France. I setted up another server with UTM9 on the same location *WITHOUT* ipv6 and being _behind_ the faulty UTM: up2date works without problem . Please notice that error is "500 timeout" and host cmd shows the -I hope- right IPs.

    Is there a way to force ipv4 for up2date ?

Reply
  • UTM is in France. I setted up another server with UTM9 on the same location *WITHOUT* ipv6 and being _behind_ the faulty UTM: up2date works without problem . Please notice that error is "500 timeout" and host cmd shows the -I hope- right IPs.

    Is there a way to force ipv4 for up2date ?

Children