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

    Issue with XMLRPC after adding a NAT rule

    HA/CARP/VIPs
    2
    7
    3.4k
    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.
    • M
      mattiav
      last edited by

      Hi all,
      Our setup is 2 pfsenses in HA with CARP address
      first have public ip address .19
      second have public ip address .20
      and there is a CARP with another public ip .18

      I'm on manual NAT
      when i add this NAT rule to be seen as CARP ip on WAN
      Capture d’écran de 2022-04-13 15-49-12.png

      I have this error appearing after adding the rule
      A communications error occurred while attempting to call XMLRPC method restore_config_section: Request timed out due to default_socket_timeout php.ini setting

      do i need to do an exception?
      the HA sync doesn't pass via HA sync interface?
      the config is well replicated on backup host
      Thanks

      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @mattiav
        last edited by

        @mattiav said in Issue with XMLRPC after adding a NAT rule:

        A communications error occurred while attempting to call XMLRPC method restore_config_section: Request timed out due to default_socket_timeout php.ini setting

        Do you sync over WAN? Otherwise it's not clear to me, why you get this error.

        But anyway, setting the CARP VIP as translation address for pfSense itself, is a very bad idea at all. At least, when you sync this rule to the secondary.

        This would result in both nodes trying to use the CARP VIP for outbound traffic. But this is occupied by the master, hence any outbound connection from the secondary will fail.

        M 1 Reply Last reply Reply Quote 0
        • M
          mattiav @viragomann
          last edited by

          @viragomann
          Thanks for your answer,
          No i don't sync over WAN, i have a dedicated interface on each node
          here the conf of the first node
          Capture d’écran de 2022-04-14 12-04-40.png
          the .106 ip is the backup node sync interface

          here the conf of the backup node
          Capture d’écran de 2022-04-14 12-10-15.png

          For you tips for CARP VIP as translation address for pfSense itself, i will reduce it to only the destination port i need.
          But i still don't understand why that rule affect the sync, and you?
          Thanks

          V 1 Reply Last reply Reply Quote 0
          • V
            viragomann @mattiav
            last edited by

            @mattiav
            No. So the error is also appearing, when you specify a destination port or address?
            Maybe something else to see in the system log?

            Possibly there are the interface orders different on both nodes? Check Status > interfaces for accordance of all interfaces.

            M 1 Reply Last reply Reply Quote 0
            • M
              mattiav @viragomann
              last edited by

              @viragomann
              If i add destination port on my NAT rule, the error is not appearing anymore

              i checked the interface orders, and they are the same on both nodes

              Here the logs on node 1 when i have the error
              Capture d’écran de 2022-04-14 13-59-31.png

              and here the logs on node1 when there is no errors
              Capture d’écran de 2022-04-14 13-59-16.png

              thanks again :)

              V 1 Reply Last reply Reply Quote 0
              • V
                viragomann @mattiav
                last edited by

                @mattiav
                So that's sadly not more than you've already stated above.
                There is no hint, what went wrong.

                Maybe something on the secondary?

                Or maybe this: https://forum.netgate.com/topic/150505/xmlrpc-restore_config_section-error

                M 1 Reply Last reply Reply Quote 1
                • M
                  mattiav @viragomann
                  last edited by

                  @viragomann
                  i think it's that
                  https://forum.netgate.com/topic/150505/xmlrpc-restore_config_section-error

                  because my rule to NAT with CARP ip make the backup node not able to reach the gateway
                  so as it explain on that like you sent

                  Filter reload sees the down gateway and resets states, terminating the connection currently used for XMLRPC.

                  it make sense
                  Thanks you very much, i think you resolve my issue :)

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