Upgrade pfsense CE 2.7.0 to 2.7.1
-
None of my secondary HA machines can see the update and rehashing the certificates doesn't help.
I am wondering if it has something to do with my policy routing? So what is the URL for the update server so I can run a test with my alias list? I suppose I can just temporarily disable the policy routing rule on my secondary server, but to fix the problem I would need that URL. ... I just realized that it would have to be done on my primary server I think.
-
@stephenkwabena said in Upgrade pfsense CE 2.7.0 to 2.7.1:
certctl rehash
This worked for us. Thank you.
-
@SteveITS said in Upgrade pfsense CE 2.7.0 to 2.7.1:
@stephenkwabena
https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#troubleshooting
“Due to changes in pkg, the new version of pkg may not be able to properly locate and use the CA trust store when running on the previous version before upgrading.If the firewall is unable to load packages or check for updates after selecting the CE 2.7.1 upgrade branch, run certctl rehash from the console, a root shell prompt, or via Diagnostics > Command Prompt. This will allow pkg to utilize the system certificates until the next reboot.”
Monday Afternoon I noticed another "Wrinkle" within my attempts for at upgrading/package installs (within various pfSense CE/Plus Instances, both Real and Virtual):
Attempts to upgrade pkg-1.20.8_1 to pkg-1.20.8_2 were FAILING!!!Later in the Day Netgate released pkg-1.20.8_3, which appears to have "Fixed" this "CA trust store" Issue???
Now I find CE 2.7.0 is NOT as "Useful", without running running "certctl rehash" from the console, a root shell prompt, or via Diagnostics > Command Prompt: Otherwise Access to Updates and/or Packages are NOT be possible (even though pfSense might still be running well)!!! NOTE: "certctl rehash" is "Temporary" and has to run following a Boot/Reboot!!!
Therefore running "certctl rehash" (if required) and upgrading CE 2.7.0 to CE 2.7.1 might be the "Better" Option???
-
This post is deleted! -
@LHoust said in Upgrade pfsense CE 2.7.0 to 2.7.1:
Now I find CE 2.7.0 is NOT as "Useful", without running running "certctl rehash" from the console, a root shell prompt, or via Diagnostics > Command Prompt: Otherwise Access to Updates and/or Packages are NOT be possible (even though pfSense might still be running well)!!! NOTE: "certctl rehash" is "Temporary" and has to run following a Boot/Reboot!!!
If you want to remain on 2.7.0 and have pulled in the newer pkg version you will need to set the repo back to 2.7.0 then rehash the certs and force upgrade pkg back to the version from that:
1.19.1_2.Then you should be able to pull in other pkgs and will not need to rehash certs again.
-
@reberhar I was able to do the updates by putting the primary server on standby and, when the secondary server was acting as primary server, I could do and did updates to these units as well.
I did make the mistake of trying to do updates of packages from the package manager without doing the system update first, notably NUT. I did set the system back to 2.7.0 to fix that. All the package updates came with the system update, again, including the NUT 2.8.2, which I wanted because of problems with NUT and Cyberpower. It is early, but things seem better now.
-
If only the primary nodes can see the package servers that's often a sign that the outbound NAT rules are over-matching and translating traffic from the firewall itself to the CARP VIP. That breaks connectivity for the the backup node.
-
@stephenw10 Thanks ... I suspect that it is a firewall rule. That I am sending the firewall to the Virtual IPs is possible I suppose. I do have an aliases with both lan numbers, primary and secondary, so that I can access the secondary via the tunnels. I will study them to see what the impact is. The outbound NAT is a very busy place for my systems.
Thanks for pointing me in toward the likely direction of the problem.
Interestly I did not have this problem before 2.7.0, thus my thought that it does have to do with the firewall and the more strict enforcement of the rules.
I may have found it. The translation address is the virtual IP. This would do as you say. Then only the primary node can receive the update messages.
Translation
Address
192.168.1.254 (WAN VIP)
Type
Connections matching this rule will be mapped to the -
I updated with no issues
-
I just tried second time and no way. I had home router based on Intel NUC + USB NIC as a WAN. This was worked on 23.05+ and also on 2.7.0 that I migrated to. When I try upgrade to 2.7.1, upgrade goes without issue, NUC will reboot and start. Unfortunately it seems like there is problem... pFsense hangs after while. It is not fully hang, but I do not have possibility to login to GUI, there is "502 Bad gateway" message. No packages get installed, interfaces ar enot working correctly.. I didnt find solution yet how to get it working.
So I again take USB mem stick and install 2.7.0, which is working correctly. Any idea ? Seems like a lot of changes in "minor" update was done , it should not be 2.7.1, but 2.8.0...
-
@reberhar said in Upgrade pfsense CE 2.7.0 to 2.7.1:
I may have found it. The translation address is the virtual IP. This would do as you say. Then only the primary node can receive the update messages.
Translation
Address
192.168.1.254 (WAN VIP)
Type
Connections matching this rule will be mapped to theUsually when we see this the rule has a source of 'any' which is almost always wrong.
-
@GeorgeCZ58 said in Upgrade pfsense CE 2.7.0 to 2.7.1:
So I again take USB mem stick and install 2.7.0, which is working correctly. Any idea ?
Did you try installing 2.7.1 clean?
-
@GeorgeCZ58 said in Upgrade pfsense CE 2.7.0 to 2.7.1:
So I again take USB mem stick and install 2.7.0, which is working correctly. Any idea ? Seems like a lot of changes in "minor" update was done , it should not be 2.7.1, but 2.8.0...
In my own testing with a Fresh Installation of CE 2.7.0 within a VM: I was able to confirm what stephenw10 mentioned:
If you want to remain on 2.7.0 and have pulled in the newer pkg version you will need to set the repo back to 2.7.0 then rehash the certs and force upgrade pkg back to the version from that: 1.19.1_2.
Then you should be able to pull in other pkgs and will not need to rehash certs again.
The Day following CE 2.7.1's Announcement, there were already some System Patches, therefore if you are able to install the "System_Patches" Package and apply them (and Reboot), some of those Patches might apply to this case with your Intel NUC?
Last week with CE 2.7.0 (before I knew about having to rehash the certs following every Boot/reBoot or downgrading to pkg-1.19.1_2), a Fresh Installation of CE 2.7.1 is what had worked for me with my ZimaBoard.
-
@stephenw10 I will try. So practicaly I will do the same, but will not apply old config... we will see.
-
@GeorgeCZ58 said in Upgrade pfsense CE 2.7.0 to 2.7.1:
@stephenw10 I will try. So practicaly I will do the same, but will not apply old config... we will see.
That is the "Power" of pfSense, your OLD Config should work just fine!
-
@SteveITS Thank you!
Precisely the error
Precisely the solution. -
Can the config from 2.7.0 be used in 2.7.1?
-
@Waqar-UK yes, in general restoring to a later version is fine: https://docs.netgate.com/pfsense/en/latest/backup/restore-different-version.html
-
@stephenw10 Actually this rule was created by the wizard when I setup HA. The source is not ANY.
I can understand why this does what it does. I am puzzling how to exactly repair this. Of course the wizard was written by the good netgate folks.
@reberhar said in Upgrade pfsense CE 2.7.0 to 2.7.1:
I may have found it. The translation address is the virtual IP. This would do as you say. Then only the primary node can receive the update messages.
Translation
Address
192.168.1.254 (WAN VIP)
Type
Connections matching this rule will be mapped to theUsually when we see this the rule has a source of 'any' which is almost always wrong.
-
This post is deleted!
