XMLRPC sync problems!
-
Hi Y'all,
I recently noticed that XMLRPC sync doesn't seem to be working on my pfSense Master/Slave pair. For example, if I change a firewall rule on the master, I see this error message (in the logs and on the top right of the web page via the scrolling error banner):
php: : New alert found: A communications error occured while attempting XMLRPC sync with username admin https://192.168.100.2:443
Now, I think this used to work before I enabled port 443 (with a cert) for the web configurator on both sides, so that may have something to do with it? Not sure. The sync is using a dedicated CARP interface between the two machines, with master:192.168.100.1 and slave:192.168.100.2. Only the master is configured to sync, as instructed, and other items seem to be working like master/slave virtual IPs and such, so I know the network is working. It almost seems like it's having trouble authenticating to the slave or something.
I have:
2.0-RELEASE (amd64)
built on Tue Sep 13 17:33:40 EDT 2011Any advice much appreciated!! Anything else I should be doing to troubleshoot?
-
your firewall rules not permitting sync since changing the port?
-
Unfortunately no, it doesn't seem to be that. I still haven't solved it yet. But, if you have a minute to look at my setup, it looks like this:
fire01:
[2.0-RELEASE][admin@fire01]/root(1): ifconfig bce3
bce3: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=c00b8 <vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso,linkstate>ether d4:be:d9:a8:80:39
inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
inet6 fe80::d6be:d9ff:fea8:8039%bce3 prefixlen 64 scopeid 0x4
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
status: activefire02:
[2.0-RELEASE][admin@fire02]/root(9): ifconfig bce3
bce3: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=c00bb <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso,linkstate>ether d4:be:d9:a8:7e:65
inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255
inet6 fe80::d6be:d9ff:fea8:7e65%bce3 prefixlen 64 scopeid 0x4
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
status: activeSo the link seem up. The firewall rules for these interfaces are ALLOW ALL from ALL to ALL, completely open (on both sides). It's a dedicated crossover link, no switch involved, so I have the firewall rules wide open for those links. When I ping from fire01 to fire02 on this interface:
[2.0-RELEASE][admin@fire01]/root(2): ping 192.168.100.2
PING 192.168.100.2 (192.168.100.2): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
^COddly enough, when I ping coming from the other direction, I get a slightly different response:
[2.0-RELEASE][admin@fire02]/root(10): ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
^C
–- 192.168.100.1 ping statistics ---
95 packets transmitted, 0 packets received, 100.0% packet lossI just don't know what's up. The link light on both sides in blinking rapidly as if traffic is going back and forth. I've tried a different cable, thinking the first one went bad, but the new cable produced exactly the same results.</full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso,linkstate></up,broadcast,running,simplex,multicast></full-duplex></performnud,accept_rtadv></vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso,linkstate></up,broadcast,running,simplex,multicast>
-
link light blinking rapidly wouldn't be indicating traffic (if it actually is the link light, should have a different light for activity if it has one at all), that's more likely to indicate link cycling on the NIC. I have seen NICs not play nicely when directly connected, does it behave better if you throw a small switch between? That'd at least confirm or deny that suspicion.