A communications error occurred while attempting xmlrpc sync

math

Hello nwt_admin,

I've the same problem with this version (2.1 adm64b) and a similar architecture.

And like you I searched in many forums but no solutions found.

Can you explain how you have resolved this problem ?

Thanks

cr_hyland

Having this issue too on a previously perfect Carp setup with 2.0x before updating to 2.1

Since the update xmlrpc sync refuses to work and also sync for pfblocker fails.

Anyone any clues?

jimp

An error during XMLRPC sync and an error during FILTER sync are two very different things and can happen for two very different reasons.

XMLRPC sync is the actual configuration copy from primary to secondary. The filter sync step is when the secondary reloads a few areas after the sync happened. A filter sync error on its own would indicate that the configuration synchronized but reloading those settings produced an error somewhere on the secondary.

In either case, make sure that you have checked the system logs on the secondary for potential issues.

cr_hyland

The exact error we are seeing is this

10-03-13 14:38:42 [ A communications error occurred while attempting XMLRPC sync with username admin http://172.17.1.2:80.]

Usernames have been checked and double checked. Firewalls rebooted and update 2.1 firmware reapplied several times but no joy.

This is all i see in the logs on master firewall
Oct 2 15:53:38 php: rc.filter_synchronize: New alert found: A communications error occurred while attempting XMLRPC sync with username admin http://172.17.1.2:80.
Oct 2 15:53:38 php: rc.filter_synchronize: A communications error occurred while attempting XMLRPC sync with username admin http://172.17.1.2:80.
Oct 2 15:53:38 php: rc.filter_synchronize: XML_RPC_Client: Connection to RPC server 172.17.1.2:80 failed. Operation timed out 103

Theres nothing in the logs on the slave.

nwt_admin

Just as an FYI I was receiving BOTH the XMLRPC and FILTER error messages.

For those that are still having this issue: what caused this error to occur? In my situation, it was my own doing as I changed the admin password without changing it anywhere else within the SYNC. Even after fixing the password throughout pfSense, the issue still persisted. What I ended up doing was rebuilding the SYNC interface (completely remove it and recreate it) and then restarted the slave machine. Upon reboot, boom…no more XMLRPC issues.

This may not solve everyone's problem, but it's definitely an easy first step to take.

jimp

Make sure the GUI is running on the same port on both systems, and that you have a firewall on the interface in question on the secondary to accept that traffic. It looks like it's either hitting the wrong port or the firewall on the secondary is dropping the packet.

cr_hyland

Ok so this seems to be down to the firewall rules on the slave dropping traffic (thanks jimp).

Seeing in the logs traffic being dropped from carp ip one to carp ip two even though there is an allow all rule on the carp interface which worked perfectly before 2.1.

Also the rule being triggered is @39 block drop in log quick proto tcp from webconfiguratorlockout:1to any port = http label "webConfiguratorlockout"

Tried disabling the antilockout rule for web configurator but it didn't help.</webconfiguratorlockout:1>

jimp

The anti-lockout rule allows access to the GUI port
The webConfiguratorlockout table is populated with IPs that fail GUI auth several times in a row.

For the firewall rules, make sure you read the 2.1 release notes, we did put a note in there about the rules needing changed if you didn't have a pfsync rule already.

ceylani

Another reason is that if you didn't add a gateway record for each subnet, a route record for each subnet may have been created (all of its subnet can be routed to default gateway) in the route table on secondary server. Actually it doesn't need to routing on broadcast network.
For example:
WAN : 192.168.1.5 -> default GW -> 192.168.1.1
SYNC: 172.16.1.1 -> no GW
LAN: 10.10.10.1 -> no GW

Sometimes PfSense assign a gateway for SYNC or LAN subnets in the route table as automatically.
For example: 172.16.1.0/30 GW 192.168.1.1

So secondary server takes over the CARP IP status as MASTER to itself. Also there are some packet loss on the networks. I had added new gateways for each subnet and my all problems solved by itself :)

gordc

I was able to resolve this issue by assigning two new IP addresses to the carp interfaces.

Master was 172.30.4.2 - changed to 172.30.4.3
Secondary was 172.30.4.3 changed to 172.30.4.4

This seems to have fixed the problem.

Kipp

Also see thread http://forum.pfsense.org/index.php/topic,68439.0.html, if the suggestions in this thread don't help as they may be similar issues.