XMLRPC sync not syncing rules after upgrade from 1.2.3 to 2.0

dlawless

Hardware: 2x alix2d3 boards

Followed the instructions outlined online for the upgrade (http://doc.pfsense.org/index.php/Upgrade_Guide#Upgrading_CARP). Upgraded Master first to 2.0 then upgraded secondary. CARP fail over is working just fine, however rule syncing and other actions that would mirror the Master to the Slave are not working and I am receiving this error…..

Acknowledge All: [sync_settings] An Authentication failure occurred while trying to access https://xx.xx.xx.xx:443 (pfsense.host_firmware_version)

I have tried the following….

-Upgrade Master first and then Slave (recommended route)
-Upgrade Slave first and then Master
-Cleared all states from both firewalls
-Removed all settings and interfaces related to CARP and re-add
-Created a different admin user and changed the syncing user
-Verified root password used to sync
-Verified the traffic is not being blocked
-Verified the version of Alix bios is 0.99h

I am very lost ??? and can not seem for the life of me to get these Alix boxes to sync the rules. Any help would be very appreciated.

dotdash

I would try disabling sync, then blowing away the secondary and loading 2.0 fresh. Then set up the secondary from scratch. It shouldn't take long, just get the interfaces and the sync configured and it will replicate the rules.

dlawless

Thank's dotdash, that seemed to do the trick. Is there a way I could have gone into the config.xml file and stripped out what was causing it not to sync?

jnorell

I have what sounds like the same symptom from doing upgrades in previous 2.0-RC stages; I'm on 2.0-RELEASE on master and backup now, and the sync doesn't work. I've traced it to the secondary blocking port 443 from the master so far, but can't tell why/where.

On mine, disabling all firewalling on the secondary will allow sync to start working. I have a single firewall rule on the (dedicated) sync interface, that allows everything. Port 80 is allowed, and http request there replies with a redirect to https. But port 443 connections are blocked on the secondary, they show up in the firewall logs (and clicking the Easy Rule to allow traffic adds another rule that should also allow the traffic, but it doesn't).

I might give up and load a new install on the secondary and see what that does.

mrmark

Hi,
I experienced the same problem as dlawless and I set the secondary server to Factory Defaults and recreated all my interfaces (3 physical interfaces and 9 VLAN:s). After that the sync worked as before (in 1.2.3). However, I then added "Synchronize Users and Groups", "Synchronize Certificates", "Synchronize IPsec", "Synchronize OpenVPN" and "Synchronize DHCPD" and then the synchronisation problem reoccurs.
I found out that on the secondary firewall the Remote System Username field were by default prefilled with "admin". I cleaned out the field and now the sync seems to work but I still get errors in the log.

php: : An error code was received while attempting Filter sync with username admin https://192.168.xx.x:444 - Code 2: Invalid return payload: enable debugging to examine incoming payload
php: : New alert found: An error code was received while attempting Filter sync with username admin https://192.168.xx.x:444 - Code 2: Invalid return payload: enable debugging to examine incoming payload

Any ideas anyone?

How do I "enable debugging to examine incoming payload"?

Many thanks in advance.

jnorell

@mrmark:

I cleaned out the field and now the sync seems to work but I still get errors in the log.

php: : An error code was received while attempting Filter sync with username admin https://192.168.xx.x:444 - Code 2: Invalid return payload: enable debugging to examine incoming payload
php: : New alert found: An error code was received while attempting Filter sync with username admin https://192.168.xx.x:444 - Code 2: Invalid return payload: enable debugging to examine incoming payload

Any ideas anyone?

That's a separate issue, where the Remote System Username is ignored and 'admin' username is now hard-coded into the requests.

http://redmine.pfsense.org/issues/1971
http://redmine.pfsense.org/issues/1736

My understanding is the only option for carp sync to work right now is to enter the admin's password into your carp config (the username doesn't matter), which of course stores it in plain text in your config file backups. I tried to take all privileges away from 'admin' and create another account with a different username to be the real administrator to help with this, but I still seems to have full access under 'admin'. So it looks like non-encrypted config backups are now a very bad thing, with the plain-text admin password in them, which is too bad….

mrmark

Thanks a lot for the clarification about the username.
It wasn't my intention to confuse the dialog, I hope I didn't. :)

However I am very interested in figuring out why I get these error messages:
php: : An error code was received while attempting Filter sync with username admin https://192.168.xx.x:444 - Code 2: Invalid return payload: enable debugging to examine incoming payload
php: : New alert found: An error code was received while attempting Filter sync with username admin https://192.168.xx.x:444 - Code 2: Invalid return payload: enable debugging to examine incoming payload
The sync seems to work even with those errors but how can I be sure? Primarily I would like to solve what's causing those.

Am I in the wrong forum? It all started however after the upgrade from 1.2.3-Release to 2.0-Release.

Many thanks in advance?

jnorell

Hey, for the record, the two issues are related. It turns out that my port 443 connections being firewalled was caused by the hard-coded admin username in carp sync – after the carp syncing had failed enough times (15 times, per the log message), sshlockout blocked my carp master from talking to my carp backup.

You can see and remove the block on the carp backup at Diagnostics > Tables > webConfiguratorlockout.

I suppose you wouldn't have this problem if you did carp sync on the LAN. Honoring the webConfigurator anti-lockout rule for the carp Synchronization Interface might be a nice feature.

Petrus4

I know this thread is old, but I just wanted to comment that I ran into this issue also and noticed that on the the 2.0 version there is a setting under on primary node goto Firewall –> Virtual IP's --> Carp --> scroll down to "remote system password" here you can enter the new system password.