Restore config backup on XG7100 gives "The configuration could not be restored"



  • I've been running pfSense quite happily for 2 years now on an old Dell Optiplex 755. Business grows and so do requirements. We therefore upgraded to a Netgate XG-7100. I was hoping to import the config from pfSense on the new machine which would end in somewhat of a mess due to different interface configurations but it would save a ton of work. I've done this before with other systems without any big issue.

    Unfortunately the XG7100 refuses to use the config XML. All it gives me is a "The configuration could not be restored" after the upload which is as helpfull as *****.
    I've tried opening the config files with a text editor but they seem like valid XML files to me, a lint tool seems to agree with me.
    Both machines are running 2.4.4-RELEASE.

    Can anyone advice on how do I move on from here? Is there any way to analyse what the issue is?



  • Hmm, and I managed to fix it as well. Here's some info for who's interested.

    I found that the XML config contained one HTML line at the end:

    <script type="text/javascript">CsrfMagic.end();</script>
    

    This quite old post below was helpful in finding the solution. Uploading the xml and running the PHP config_validate() function. It showed an "Invalid document end at line 7516" which pointed me to the script tag.
    I get the feeling the config backup might have an issue there. Too bad the configuration restore interface was crap at helping me diagnose this issue.

    Ref. https://forum.netgate.com/topic/64818/restore-1-2-3-config-to-2-1-fails-the-configuration-could-not-be-restored/5


  • Rebel Alliance Developer Netgate

    That wouldn't normally happen with the config backup. Somehow that bit of JS snuck in there. We have seen 1-2 other reports of that but so far I don't think anyone here has managed to reproduce it. IIRC it was isolated to maybe one browser on one operating system (Safari, maybe?) but isn't hitting reliably enough that we can reproduce it and see what is happening.

    If you take a new backup, does it also have that at the end? If so, what operating system and browser are you using?



  • Thanks for your response @jimp. Just tried it again and the <script> tag is present only in full backup, partial backups are free of it.
    Quite common combination of OS/Browser; Windows 10 Pro and Chrome 70.0.3538.77


  • Rebel Alliance Developer Netgate

    Hmm, and it doesn't happen here with the same combination. Maybe a browser add-on (ad blocker, script blocker, password manager, etc), can you try starting without add-ons to see if it still happens?

    Or try a different browser to see if it happens there as well.



  • Chrome keeps doing it in incognito mode and also when started with --disable-extensions. Firefox 62.0 and Edge 17.17134 don't add the tag.


  • Rebel Alliance Developer Netgate

    Strange. I'm not seeing how that could end up in the file without it being based on the contents of the config. If that were the case, it would be in every copy not just from Chrome.

    Just in case it is that, you can install the system patches package and try this little diff to see if it helps:

    diff --git a/src/usr/local/www/diag_backup.php b/src/usr/local/www/diag_backup.php
    index fc141ac46b..e1977afe8a 100644
    --- a/src/usr/local/www/diag_backup.php
    +++ b/src/usr/local/www/diag_backup.php
    @@ -164,6 +164,8 @@ if ($_POST) {
     			}
     
     			if (!$input_errors) {
    +				/* Do not allow CSRF to alter the downloaded file */
    +				$GLOBALS['csrf']['rewrite'] = false;
     
     				//$lockbckp = lock('config');
    


  • Applied the patch (verified it on the filesystem) but the download still contains the script tag.