Upgrade pfsense CE 2.7.0 to 2.7.1
-
@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! -
@reberhar said in Upgrade pfsense CE 2.7.0 to 2.7.1:
The source is not ANY.
What exactly is the rule you are using there?
-
@stephenwInterface
I think the 12.0.0.0 ones are for the firewall. I have included the lan ones, but I don't think the problem lives there.
Roy
DisabledDisable this rule
Do not NATEnabling this option will disable NAT for traffic matching this rule and stop processing Outbound NAT rules
In most cases this option is not required.
Interface
WAN
The interface on which traffic is matched as it exits the firewall. In most cases this is "WAN" or another externally-connected interface.
Address Family
IPv4+IPv6
Select the Internet Protocol version this rule applies to.
Protocol
Any
Choose which protocol this rule should match. In most cases "any" is specified.
Source
Network or Alias
Type
127.0.0.0
/
8
Source network for the outbound NAT mapping.
Port or Range
Destination
Any
Type
/
24
Destination network for the outbound NAT mapping.
Port or Range
Not
Invert the sense of the destination match.
Translation
Address
WAN address
Type
Connections matching this rule will be mapped to the specified address. If specifying a custom network or alias, it must be routed to the firewall.
Port or Range
Enter the external source Port or Range used for remapping the original source port on connections matching the rule.Port ranges are a low port and high port number separated by ":".
Leave blank when Static Port is checked.
Static Port
Misc
No XMLRPC Sync
Prevents the rule on Master from automatically syncing to other CARP members. This does NOT prevent the rule from being overwritten on Slave.
Description
Auto created rule - localhost to WAN
A description may be entered here for administrative reference (not parsed).Interface
WAN
The interface on which traffic is matched as it exits the firewall. In most cases this is "WAN" or another externally-connected interface.
Address Family
IPv4+IPv6
Select the Internet Protocol version this rule applies to.
Protocol
Any
Choose which protocol this rule should match. In most cases "any" is specified.
Source
Network or Alias
Type
127.0.0.0
/
8
Source network for the outbound NAT mapping.
Port or Range
Destination
Any
Type
/
24
Destination network for the outbound NAT mapping.
500
Port or Range
Not
Invert the sense of the destination match.
Translation
Address
WAN address
Type
Connections matching this rule will be mapped to the specified address. If specifying a custom network or alias, it must be routed to the firewall.
Port or Range
Enter the external source Port or Range used for remapping the original source port on connections matching the rule.
Port ranges are a low port and high port number separated by ":".
Leave blank when Static Port is checked.
Static Port
Misc
No XMLRPC Sync
Prevents the rule on Master from automatically syncing to other CARP members. This does NOT prevent the rule from being overwritten on Slave.
Description
Auto created rule for ISAKMP - localhost to WAN
A description may be entered here for administrative reference (not parsed).
WAN
The interface on which traffic is matched as it exits the firewall. In most cases this is "WAN" or another externally-connected interface.
Address Family
IPv4+IPv6
Select the Internet Protocol version this rule applies to.
Protocol
Any
Choose which protocol this rule should match. In most cases "any" is specified.
Source
Network or Alias
Type
10.5.0.0
/
24
Source network for the outbound NAT mapping.
Port or Range
Destination
Any
Type
/
24
Destination network for the outbound NAT mapping.
500
Port or Range
Not
Invert the sense of the destination match.
Translation
Address
192.168.1.254 (WAN VIP)
Type
Connections matching this rule will be mapped to the specified address. If specifying a custom network or alias, it must be routed to the firewall.
Port or Range
Enter the external source Port or Range used for remapping the original source port on connections matching the rule.Port ranges are a low port and high port number separated by ":".
Leave blank when Static Port is checked.
Static Port
Misc
No XMLRPC Sync
Prevents the rule on Master from automatically syncing to other CARP members. This does NOT prevent the rule from being overwritten on Slave.
Description
Auto created rule for ISAKMP - LAN to WANAnd
Interface
WAN
The interface on which traffic is matched as it exits the firewall. In most cases this is "WAN" or another externally-connected interface.
Address Family
IPv4+IPv6
Select the Internet Protocol version this rule applies to.
Protocol
Any
Choose which protocol this rule should match. In most cases "any" is specified.
Source
Network or Alias
Type
10.5.0.0
/
24
Source network for the outbound NAT mapping.
Port or Range
Destination
Any
Type
/
24
Destination network for the outbound NAT mapping.
Port or Range
Not
Invert the sense of the destination match.
Translation
Address
192.168.1.254 (WAN VIP)
Type
Connections matching this rule will be mapped to the specified address. If specifying a custom network or alias, it must be routed to the firewall.
Port or Range
Enter the external source Port or Range used for remapping the original source port on connections matching the rule.Port ranges are a low port and high port number separated by ":".
Leave blank when Static Port is checked.
Static Port
Misc
No XMLRPC Sync
Prevents the rule on Master from automatically syncing to other CARP members. This does NOT prevent the rule from being overwritten on Slave.
Description
Auto created rule - LAN to WAN
A description may be entered here for administrative reference (not parsed). -
Really hard to read that and know for sure. A screenshot would be better.
But... that looks OK as far as I can see.
-
I am unable to upgrade from 2.7.0. Running 'certctl rehash' has not resolved anything for me. Update system log:
Updating repositories metadata...
Updating pfSense-core repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: . done
Processing entries: . done
pfSense-core repository update completed. 4 packages processed.
Updating pfSense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: ...... done
Processing entries:
Processing entries............. done
pfSense repository update completed. 549 packages processed.
All repositories are up to date.
Upgrading -upgrade... failed.
