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

Issue with XMLRPC after adding a NAT rule

Scheduled Pinned Locked Moved HA/CARP/VIPs
7 Posts 2 Posters 3.4k 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.
  • M
    mattiav
    last edited by Apr 13, 2022, 7:52 PM

    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 Apr 14, 2022, 1:34 PM Reply Quote 0
    • V
      viragomann @mattiav
      last edited by Apr 14, 2022, 1:34 PM

      @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 Apr 14, 2022, 5:03 PM Reply Quote 0
      • M
        mattiav @viragomann
        last edited by Apr 14, 2022, 5:03 PM

        @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 Apr 14, 2022, 5:33 PM Reply Quote 0
        • V
          viragomann @mattiav
          last edited by Apr 14, 2022, 5:33 PM

          @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 Apr 14, 2022, 6:02 PM Reply Quote 0
          • M
            mattiav @viragomann
            last edited by Apr 14, 2022, 6:02 PM

            @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 Apr 14, 2022, 6:24 PM Reply Quote 0
            • V
              viragomann @mattiav
              last edited by Apr 14, 2022, 6:24 PM

              @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 Apr 14, 2022, 6:53 PM Reply Quote 1
              • M
                mattiav @viragomann
                last edited by Apr 14, 2022, 6:53 PM

                @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
                7 out of 7
                • First post
                  7/7
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                  This community forum collects and processes your personal information.
                  consent.not_received