Guest User!

You are not Sophos Staff.

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

Update V 18 MR-1 to MR-5 failed and became unreachable

Hi,

are there any known issues regading updating a XG 135w firewall from Version 18 MR-1 to MR-5?

Today I was updating a remote site. After that the update the firewall was not reachable via the external and internal (IPSec) inerface. I (almost) expected that on the internal Interface as this is IPSec. However the tunnel should have been rebuilded automatically.

I was really surprised that I could not been reached through the WAN Interface and the is really a problem as this is a remote site in the Netherlands (I am in Germany). I tested this successfully before the update. The MR-5 was not shown in the Update dialog and needed to be downloaded from the website and uploaded and booted in the second slot of the firewall. 

I also did a test on another firewall. The Update from MR-3 -> MR-4 worked without any issues. I was not able to do V18 MR-1 to V18 MR-5 testing on this firewall as the MR-1 was not available. Only V18 MR-4 & MR-5 are downloadable. Also on this firewall the MR-5 was not displayed for the update.

Best regards,
BeEf



This thread was automatically locked due to age.
  • Hello BerndFeist

    I advise you to open a support ticket .. 
    I had a similar experience in updating to MR5: the firewall however restarted with the default configuration!
    I opened a support case; in the meantime I reverted to version 18.MR4

    Bye
  • Hello Bernd,

    Thank you for contacting the Sophos Community.

    Sorry to hear you had issues upgrading to MR5, MR5 is available on the website, and being rolled out in phases to the XGs.

    Do you happen to know what is the current status of the device? did it default to factory?

    Can you open a case share the case ID and provide the following log /log/migration.log

    Also, if you have SNMP configured, try removing them before the upgrade and check if you can upgrade. (If possible).

    Regards, 

  • Hello GabrieleT, how did you switch 18 MR-4? I have another firewall here and when booting it I have no chance to boot into the other image. I see the BIOS screen and the next step is already the boot prompt of the 18 MR-5.
    I am able to login to the console via USB Keyboard but was not able to figure out how to boot into the other image. There are two images displayed the older one in slot 1 the newer in slot 2.Also doing a quick google search did not reveal something helpful.

  • Hello Emmanuel,

    the firewall is on a remote side with no IT staff in a different country and through corona not really reachable. I assume that the config was not trasferred but I did no factory default (just uploading and booting into the second image).

    Unfortunately I could not figure out how to boot in the old image (with a second, local firewall). It runs through to the boot screen ov 18 MR-5 without being able to select the old image.

    We are already in some support escalation mode and all tickets go through our partner. I informed him yesterday and I assume he opened a ticket. However we do not see these tickets.

    We had SNMP configured on the firewall. Is there any known issue with this?

    Regards,
    Bernd


  • By clicking space on the keyboard while boot process, you enter the SFloader. There you should be able to load another Firmware.

    https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/learningContents/LoadingFirmwareSFLoader.html

    But the /log/migration.log should show you the reason, the firewall cannot migrate.

    We saw an issue with a invalid SNMP Config, which broke the migration. So if you have multiple SNMP Servers configured on XG, this could be a easy way to fix this. 

  • Hello LuCar Toni,

    indeed we use SNMP to monitor the firewall. But this is working - so no misconfiguration or so. If you want I can send you the migrate.log in a personal note. It says duplicate key or something like that. 

    Later on I tried to install the backup on a second firewall. It failed as well. This firewall kept his former configuration.

    The process off the backup installation visibly looked okay for me in both cases (update and restore). Upload with some message and then some waiting loop from 0%-100% - either to wait for the reboot or to implement the changes. Except that the result was not what I have expected.

    For me it looks like as if the config is broken at some point and leads to a rollback in case of the update as well as in the upload of the backup ...


    You should document somewhere how to get the grub bootscreen (i used the way to boot from the webinterface once I figured out that the firewall was in the default config after the update. however the password was migrated to the MR-5 installation).



    Best regards,
    BeEf

  • I'd also suggest that the update process should check everything before and run only if all prerequisites are met.

    Just updating and hoping that everything works and letting the user back with a pile of  glass will severely harm the reputation of the product.

    Better to get some error and no update than to have an unreachable firewall afterwards ...

  • With Lucar's recommendations, in the installation of my client, I deleted the entries under Administration > SNMP > "Comunity", I upgraded to 18.0MR5 and now it works! Thank you

  • About the point "invalid config". It seems like there is a edge case of duplicated SNMP Server within the same community. This is generally speaking not the best config. Do you have this kind of config? Multiple SNMP Servers within one community? 

  • There is a duplicated server but not in the same community (see screenshot) - this the config you mean?

    Most of our other firewalls have similar configuration but pointing to different servers. The reason is historical. Our Monitoring System PRTG can be configured in two layers. In the beginning we had just one sensor on the main server. As the number of servers growed we switched from a single server / sensor to multiple sensors reporting to a central server. This was also the point when the community name changed. 

    However I can not see that this is really faulty (especially when pointing to different servers) ... or should block an update of the firewall. If there are database tables for that in 18 MR-1 schouldn't there also be database tables for it in 18 MR-5?

    To resolve I will delete one of the entries, backup the config and try to import it on the local firewall to see whether this is working. Did I get this right?