XMLRPC Stops Running
-
I have two firewalls successfully configured with CARP/pfsync. If I restart both firewalls, the sync works fine for a while.
If I start making a few changes to aliases or rules, the first few seem to sync fine, but then xmlrpc seems stop running (no entries for either success or failure in System log) and the rules/alias changes don't make it to the backup firewall.
I've tried re-saving the settings on the CARP tab, as well as disabling/re-enabling sync, and nothing seems to trigger it to run again. The only thing that seems to fix it is a restart.
I've tried two different crossover cables and the interface statistics don't show any errors. I can "openssl s_client -connect 172.16.5.2:443" from 172.16.5.1 with no issue, so it's not connectivity/firewall rules.
I think it simply stops running, but I'm not sure what triggers it to run. I don't see anything about it in /etc/crontab.
Any ideas what I can do to manually trigger a sync or fix the schedule?
-
I've noticed that a side effect of this is that any rules changes don't work until the sync starts working again (reboot).
-
Does anyone know if there is a way to initiate the xmlrpc sync through the "Command" dialog on the web GUI?
-
I think I figured this out.
Go to: Diagnostics->Command
Under "PHP Execute" use the following (substituting IP, password, sections, and port for your environment):
$sections[] = 'filter'; carp_sync_xml('https://172.16.5.2', 'password', $sections, 443);"sections" can be set to one or multiple of the following (I think):
filter
nat
aliases
dhcpd
wol
shaper
staticroutes
virtualip
load_balancer
ipsec
dnsmasq
schedules -
I haven't seen this happen on any CARP pairs that I have worked with, but none of mine are using HTTPS for the web interface. If there is a problem, it is likely with that, but I don't know what percentage of CARP users in the wild use HTTPS. If there was a problem in general, it seems there would have been more widespread reports.
Can you revert your WebGUI settings to plain HTTP for a while to see if the problem goes away?
-
I will try this and post my results. Thanks.
-
This is exactly what happened to me. I changed from HTTP to HTTPS via port 4433 on one pfsense machine (forgot to update the second one) and the sync would no longer happen. I reverted back to HTTP and the sync happened immediately.
-
Thanks jimp, so far so good on this. HTTP seems to clear it up.
I'd prefer HTTPS, but a functioning system is more important at this point.
-
I've setup a hundred plus systems that sync with HTTPS. You just have to ensure the primary and secondary are using the same protocol and port, if they aren't, it'll fail.
-
They were definitely both using HTTPS on port 443 with identical passwords.
The weird thing is that there were no errors indicating success or failure in the System Log. If it claimed bad password or can't connect, then I would have something to work with.
Instead, I'd make a change and nothing would happen.
Also strange was that it would work for a while after a reboot, so it wasn't completely non-functional, it just stopped working after a while? shrug
