Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    XMLRPC sync problems!

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    4 Posts 2 Posters 3.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B
      bubble1975
      last edited by

      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 2011

      Any advice much appreciated!!  Anything else I should be doing to troubleshoot?

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        your firewall rules not permitting sync since changing the port?

        1 Reply Last reply Reply Quote 0
        • B
          bubble1975
          last edited by

          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: active

          fire02:

          [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: active

          So 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
          ^C

          Oddly 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 loss

          I 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>

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.