Martin Andel
asked on
pfSense XML_RPC High Availability sync failing
I have two pfSense boxes in HA sync running the latest build (2.3.4-RELEASE amd64).
They work fine, acting in a master/slave private IP failover setup, but the XML_RPC connection over the HA link keeps failing with the following error:
The log on the master unit shows:
As a result of this, the interface firewall rules aren't being synced to the slave unit.
After googling the above error, I found that there used to be a bug in pfSense sometime ago, but I did not understand whether the fix for that isn't already included in my OS build or it's something I need to patch manually?
https://redmine.pfsense.or
They work fine, acting in a master/slave private IP failover setup, but the XML_RPC connection over the HA link keeps failing with the following error:
A communications error occurred while attempting XMLRPC sync with username jblokes https://slave.firewall.ip:443
The log on the master unit shows:
Jun 14 00:45:15 php-fpm 54775 /rc.filter_synchronize: New alert found: A communications error occurred while attempting XMLRPC sync with username jblokes https://slave.firewall.ip:443.
Jun 14 00:45:15 php-fpm 54775 /rc.filter_synchronize: A communications error occurred while attempting XMLRPC sync with username jblokes https://slave.firewall.ip:443.
Jun 14 00:45:15 php-fpm 54775 /rc.filter_synchronize: XML_RPC_Client: Connection to RPC server slave.firewall.ip:443 failed. Operation timed out 103As a result of this, the interface firewall rules aren't being synced to the slave unit.
After googling the above error, I found that there used to be a bug in pfSense sometime ago, but I did not understand whether the fix for that isn't already included in my OS build or it's something I need to patch manually?
https://redmine.pfsense.or
ASKER
Check if slave.firewall.ip resolve to an ip address and if the port 443 is open in the rules of slave firewall for that ip.
Hi, I can ping the slave ip 10.155.0.2 from the master unit (10.155.0.1) over the HA link, but cannot access port 443 there. The HA interface firewall rules on both ends are as follows:
What am I missing?
You set the source port instead of destination port on the third rule ?
ASKER
Hi, I have now tried just an "allow all" lazy rule as shown below but I still cannot make the two units to use HTTPS over the HA link.
On other interfaces they can talk even with the standard restrictive rules in place.
EDIT: I can now access the 443 port on the master unit from the slave unit, but not the other way around!
On other interfaces they can talk even with the standard restrictive rules in place.
EDIT: I can now access the 443 port on the master unit from the slave unit, but not the other way around!
ASKER
UPDATE:
I have now established that the XML_RPC sysnc actually works, but only once. When I set it up and it runs, all the virtual IPs, the firewall rules and the rest are successfully copied across. However after that the connectivity over the TCP/UDP port 443 is lost and cannot be restored, even though the firewall rule for the HA net on both boxes is "allow any traffic to and from HA net to and from any port on HA net"
Initially I thought this may have had something to do with the fact that the master firewall has been built about a year ago, while the backup unit is brand new. The names of the interafces in both boxes have differed slightly. For example while "LAN1" interface was mapped to "lan and lagg1" on the master unit, the backup unit's "LAN1" was mapped to "opt3 and lagg1" and so on. As a direct result of this, when the rules were synced (once), they were assigned to wrong interfaces. A simillar thing also happened to the virtual IPs.
So I have rebuilt the backup unit to precisely correspond with the underlying pfSense naming scheme of the master unit (after realizing that as far as the pfSense is concerned, re-labelling the interface names does not change their originally assigned names).
Unfortunately, although the rules and virtual IPs are now being (seemingly) synced correctly, it only works once and then I get the infamous "A communications error occurred while attempting XMLRPC sync with username" error again and the TCP/UDP port 443 on the backup unit becomes unavailable on the backup unit.
I'm running out of ideas here...
I have now established that the XML_RPC sysnc actually works, but only once. When I set it up and it runs, all the virtual IPs, the firewall rules and the rest are successfully copied across. However after that the connectivity over the TCP/UDP port 443 is lost and cannot be restored, even though the firewall rule for the HA net on both boxes is "allow any traffic to and from HA net to and from any port on HA net"
Initially I thought this may have had something to do with the fact that the master firewall has been built about a year ago, while the backup unit is brand new. The names of the interafces in both boxes have differed slightly. For example while "LAN1" interface was mapped to "lan and lagg1" on the master unit, the backup unit's "LAN1" was mapped to "opt3 and lagg1" and so on. As a direct result of this, when the rules were synced (once), they were assigned to wrong interfaces. A simillar thing also happened to the virtual IPs.
So I have rebuilt the backup unit to precisely correspond with the underlying pfSense naming scheme of the master unit (after realizing that as far as the pfSense is concerned, re-labelling the interface names does not change their originally assigned names).
Unfortunately, although the rules and virtual IPs are now being (seemingly) synced correctly, it only works once and then I get the infamous "A communications error occurred while attempting XMLRPC sync with username" error again and the TCP/UDP port 443 on the backup unit becomes unavailable on the backup unit.
I'm running out of ideas here...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Check if slave.firewall.ip resolve to an ip address and if the port 443 is open in the rules of slave firewall for that ip.