CARP 2 different PFSense Versions
-
Yes, it works flawlessly. CARP is a standard, it does not depend on pfSense Version.
Rather XMLRPC Sync could make troubles here. -
https://doc.pfsense.org/index.php/Redundant_Firewalls_Upgrade_Guide
Code was added in 2.2.5 to prevent XMLRPC sync to a newer version so you should be good to go.
As always, have known-good 2.2.6 install media and a copy of both configs handy.
-
Yes, it works flawlessly. CARP is a standard, it does not depend on pfSense Version.
Rather XMLRPC Sync could make troubles here.Quick question based on your response, or if anyone else knows.
Since CARP does not depend on the version of PfSense, if the firewalls are different versions (FW1 2.2.6 Master, FW2 2.3.2 Backup) will the states sync if I have to flip between the firewalls?
I want to upgrade my current setup (FW1 2.2.6 Master, FW2 2.2.6 Backup). I want to upgrade FW2 (backup)(I will do this by putting my FW2 into maintenance mode). After the upgrade, I want to flip from FW1(now 2.2.6) to FW2 (now 2.3.2) (I will take maintenance mode off from FW2 and then put FW1 into maintenance mode). Since one of the firewalls will usually always be on maintenance mode due to the upgrades, will the system states sync still?
Thanks… -
This says no. Going major version to major version should be done during a maintenance window.
https://doc.pfsense.org/index.php/Redundant_Firewalls_Upgrade_Guide
-
This says no. Going major version to major version should be done during a maintenance window.
https://doc.pfsense.org/index.php/Redundant_Firewalls_Upgrade_Guide
Thank you SIR. Much appreciate your help.
-
As the guide linked by Derelict tells us, you have to ensure that both boxes has an equal interface configuration to provide syncing states.
Also you should upgrade FW1 at first to ensure keep the states synced. FW1 should put in "Persistent CARP maintenance mode" while upgrading.
After you can release the maintenance mode and if it works well also upgrade FW2. -
Actually, it is usually recommended to upgrade the secondary, make sure everything looks good (packages install, etc) then enter maintenance mode on the primary. If things don't work out, fail back by disabling maintenance mode on the primary.
This is mostly because if you have to run on the old system (the one that hasn't been upgraded yet) for any length of time while whatever problems the upgrade created are corrected it is better that this be the primary unit so configuration changes can be made and they will all be XMLRPC synced to the secondary when it is brought back online.
State sync is a great thing, but it tends to be over-valued. Users reloading browsers and getting immediately reconnected is certainly better than not. Especially when talking about something like a failed upgrade that might result in minutes or hours of downtime otherwise.
-
Thank you guys.
I chose to upgrade the Backup Firewall first.
My steps for anyone that might be interested are:
1. No firewall changes during the upgrade process.
2. Take a snapshot of both firewalls.
3. Make sure the firewalls have been synced and that rules, package configs, etc are correct on both sides.
4. Enter Main Mode on Backup Firewall.
5. Upgrade Backup Firewall.
6. Check VIPs, CARP, and package configs.
7. Test the backup firewall for 24 hours make sure DMZs, etc are working properly by doing a manual route to the secondary firewall.
8. Take Backup Firewall off of Main Mode.
9. Put Primary Firewall in Main Mode.
10. Make sure secondary firewall took over all VIPs, etc.
11. TEST, TEST, TEST, TEST everything.
12. Wait for a production day (usually Monday), and give it 30 mins after people come in. Check to make sure everything is working properly.
13. If not, fail back to the previous Primary Firewall.
14. If yes, then give it 24 hours, monitor the new firewall.
15. Upgrade now backup firewall.
16. Check VIPs, packages, and CARP.
17. Flip back to the previous Primary Firewall.Those are my steps….
-
Looks perfect. You do not need to put the secondary into and out of maintenance mode but it shouldn't hurt anything either.
And it all worked? Phone didn't ring?
-
Sorry long weekend with this upgrade.
Well so far the upgrade worked, but, some of the packages didn't do so well.
Squid and Squidguard didn't want to work. I had to run some command to remove pbi links of some sort.
At this point I'm still under 2.2.6 because we still doing testing, and because syslog-ng will NOT run under 2.3.2.
I was able to get syslog-ng running with no issues in 2.3.1. The moment I updated with the latest patch to 2.3.2, syslong-ng stopped working and I cannot see any logs showing any errors about it.
And its driving me nuts. I don't know how to fix that. I was able to post a question in another thread and I'm hoping someone could help me with that.
But the upgrade was quick about 35 mins and when I did flip from Master to Backup, no ping loss, worked flawlessly. Unfortunately I had to flip back to Master firewall due to too many issues, which I hope I can resolve soon.
Thanks for all your help guys…
