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

    CARP - Not able to access the LAN IP of the Backup pfSense machine

    HA/CARP/VIPs
    3
    18
    3.8k
    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.
    • V
      viragomann
      last edited by

      You can't reach the backup directly from 192.168.1.0, packets must be routed over the master, cause the static route point to the LAN VIP. This is also true for responses from the backup.

      To get this work the best way is to add an outbound NAT rule to the master, translating packets destined for the backup to the LAN address.
      To get this work independently which one is the master, add an host alias including the two LAN addresses of master and backup.
      Then add a new outbound NAT rule (outbound NAT must be set to manual or hybrid rule generation mode), select the LAN interface, at source enter 192.168.1.0/24, at destination select network an enter the alias you've added first, you may also restrict the rule to the specific dest port and at translation address select interface address.

      If you have rule sync on this rule will be synced to the backup and will also fit in case if this one is the master.

      1 Reply Last reply Reply Quote 0
      • P
        pglover19
        last edited by

        @viragomann:

        You can't reach the backup directly from 192.168.1.0, packets must be routed over the master, cause the static route point to the LAN VIP. This is also true for responses from the backup.

        To get this work the best way is to add an outbound NAT rule to the master, translating packets destined for the backup to the LAN address.
        To get this work independently which one is the master, add an host alias including the two LAN addresses of master and backup.
        Then add a new outbound NAT rule (outbound NAT must be set to manual or hybrid rule generation mode), select the LAN interface, at source enter 192.168.1.0/24, at destination select network an enter the alias you've added first, you may also restrict the rule to the specific dest port and at translation address select interface address.

        If you have rule sync on this rule will be synced to the backup and will also fit in case if this one is the master.

        I'm somewhat new to pfsense so please be patience with me. Based on your comments there are 2 options. It looks like you are recommending the last option. If yes, can you provide more detail steps.

        Thanks.

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

          No, I suggested only one solution.
          With this outbound NAT rule the source address of packets which are destined to the other pfSense box will be translated to the pfSense LAN address when they are going out the LAN interface. This way responses to these requests are directed back to the other pfSense.

          To set this up
          add an IP alias in Firewall > Aliases > IP. Enter a name (e.g. FW1a2), type = "Host(s)", at hosts below enter the masters LAN IP 10.1.1.1 at IP and a description beside, click "add host" and enter the LAN IP of backup 10.1.1.3 and a description.

          Got to Firewall > NAT > Outbound. Ensure that the rule generation mode is set to manual or hybrid.
          Add the suggested NAT rule:
          Interface: LAN
          Protocol: TCP
          Source: Network <the alias="" name="" you="" have="" set="" up="" first,="" e.g.="" fw1a2="">Destination: Network 192.168.1.0/24
          Address: Interface address
          Enter a description below and save the rule.

          That's it. Hope, it's a bit more clearly now.</the>

          1 Reply Last reply Reply Quote 0
          • P
            pglover19
            last edited by

            @viragomann:

            No, I suggested only one solution.
            With this outbound NAT rule the source address of packets which are destined to the other pfSense box will be translated to the pfSense LAN address when they are going out the LAN interface. This way responses to these requests are directed back to the other pfSense.

            To set this up
            add an IP alias in Firewall > Aliases > IP. Enter a name (e.g. FW1a2), type = "Host(s)", at hosts below enter the masters LAN IP 10.1.1.1 at IP and a description beside, click "add host" and enter the LAN IP of backup 10.1.1.3 and a description.

            Got to Firewall > NAT > Outbound. Ensure that the rule generation mode is set to manual or hybrid.
            Add the suggested NAT rule:
            Interface: LAN
            Protocol: TCP
            Source: Network <the alias="" name="" you="" have="" set="" up="" first,="" e.g.="" fw1a2="">Destination: Network 192.168.1.0/24
            Address: Interface address
            Enter a description below and save the rule.

            That's it. Hope, it's a bit more clearly now.</the>

            Got it… One clarification. On the NAT Outbound, please confirm the source and destination. Your first post seems to be different than your last post.

            Once again, thank you so much.

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

              Sorry, that was a mistake.
              It should be
              Source: Network 192.168.1.0/24
              Destination: Network <the alias="" name="" you="" have="" set="" up="" first,="" e.g.="" fw1a2="">of course.</the>

              1 Reply Last reply Reply Quote 0
              • P
                pglover19
                last edited by

                @viragomann:

                Sorry, that was a mistake.
                It should be
                Source: Network 192.168.1.0/24
                Destination: Network <the alias="" name="" you="" have="" set="" up="" first,="" e.g.="" fw1a2="">of course.</the>

                Does not seem to be working.. Do I need to specify anything in the "Translation Address" field?

                Capture.PNG
                Capture.PNG_thumb

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

                  "Interface address" is fine here.
                  The alias contains both LAN addresses of master and backup?

                  Please post a screenshot of the outbound NAT page.

                  1 Reply Last reply Reply Quote 0
                  • P
                    pglover19
                    last edited by

                    @viragomann:

                    "Interface address" is fine here.
                    The alias contains both LAN addresses of master and backup?

                    Please post a screenshot of the outbound NAT page.

                    Here you go…

                    Capture10.PNG
                    Capture10.PNG_thumb
                    Capture_20.PNG
                    Capture_20.PNG_thumb

                    1 Reply Last reply Reply Quote 0
                    • P
                      pglover19
                      last edited by

                      Well I got the LAN interface working on the pfsense backup machine.  It was the ports on my switch….

                      Now I am troubleshooting the WAN interface on the pfsense backup machine. For some reason, I cannot ping the WAN interface (192.168.50.3) on the backup pfsense machine. I am able to ping the pfSense master WAN  IP (192.168.50.2) and the WAN Virtual IP (192.168.50.254) from the 192.168.1.0/24 subnet.. What in world is my problem?

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by

                        Why would you care about reaching the secondary's WAN interface in that fashion?

                        It should work as long as there is outbound NAT out the primary's WAN. if not you will probably be looking at an asymmetric routing issue.

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

                        1 Reply Last reply Reply Quote 0
                        • P
                          pglover19
                          last edited by

                          @Derelict:

                          Why would you care about reaching the secondary's WAN interface in that fashion?

                          It should work as long as there is outbound NAT out the primary's WAN. if not you will probably be looking at an asymmetric routing issue.

                          Based on my setup, should I be able to reach the pfSense backup WAN IP (192.168.50.3/24) while the pfSense master machine is active and without an outbound NAT?

                          I assume when the backup becomes the master, I should be able to ping the pfSense backup WAN IP (192.168.50.3/24).

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

                            Yes, it should be reachable if your WAN interfaces and the WAN VIP are in the same network segment and if the firewall rules allow the ping to WAN.

                            1 Reply Last reply Reply Quote 0
                            • P
                              pglover19
                              last edited by

                              @viragomann:

                              Yes, it should be reachable if your WAN interfaces and the WAN VIP are in the same network segment and if the firewall rules allow the ping to WAN.

                              I am only able to ping the pfSense backup WAN IP (192.168.50.3) only when there is a failover and the pfSense backup becomes the master. The failover seems to be working fine. Just I cannot figure out this issue.

                              You mentioned firewall rules and outbound NAT rules. Can you provide some detail on specific things to check..

                              1 Reply Last reply Reply Quote 0
                              • DerelictD
                                Derelict LAYER 8 Netgate
                                last edited by

                                That is because when the secondary is CARP master it is the node that receives the traffic on the LAN CARP VIP. Again, what are you trying to prove by accessing the secondary's WAN interface from the inside when it is not CARP MASTER?

                                Why did you X.X out the IP addresses on the WAN side in your diagram? Makes it pretty hard to communicate specifics back to you. They are RFC1918. Who cares about protecting/hiding them?

                                Can you ping the secondary's WAN IP address from the primary? Then it's working.

                                Can you ping the secondary's LAN address from LAN? Then it's working.

                                Can the secondary resolve names, check for updates, and check for packages while it is NOT CARP master? Then it's working.

                                Chattanooga, Tennessee, USA
                                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                1 Reply Last reply Reply Quote 0
                                • P
                                  pglover19
                                  last edited by

                                  @Derelict:

                                  That is because when the secondary is CARP master it is the node that receives the traffic on the LAN CARP VIP. Again, what are you trying to prove by accessing the secondary's WAN interface from the inside when it is not CARP MASTER?

                                  Why did you X.X out the IP addresses on the WAN side in your diagram? Makes it pretty hard to communicate specifics back to you. They are RFC1918. Who cares about protecting/hiding them?

                                  Can you ping the secondary's WAN IP address from the primary? Then it's working.

                                  Can you ping the secondary's LAN address from LAN? Then it's working.

                                  Can the secondary resolve names, check for updates, and check for packages while it is NOT CARP master? Then it's working.

                                  Here is the diagram with the WAN IP addresses unmasked…

                                  Drawing1.jpg
                                  Drawing1.jpg_thumb

                                  1 Reply Last reply Reply Quote 0
                                  • P
                                    pglover19
                                    last edited by

                                    @Derelict:

                                    That is because when the secondary is CARP master it is the node that receives the traffic on the LAN CARP VIP. Again, what are you trying to prove by accessing the secondary's WAN interface from the inside when it is not CARP MASTER?

                                    Why did you X.X out the IP addresses on the WAN side in your diagram? Makes it pretty hard to communicate specifics back to you. They are RFC1918. Who cares about protecting/hiding them?

                                    Can you ping the secondary's WAN IP address from the primary? Then it's working.

                                    Can you ping the secondary's LAN address from LAN? Then it's working.

                                    Can the secondary resolve names, check for updates, and check for packages while it is NOT CARP master? Then it's working.

                                    I cannot ping the pfSense backup WAN IP address (192.168.50.3) from the pfSense master machine (see attachment).
                                    I can ping the pfSense backup LAN IP address (10.1.1.3) from the pfSense master machine (see attachment)

                                    Capture_100.PNG
                                    Capture_100.PNG_thumb
                                    Capture_200.PNG
                                    Capture_200.PNG_thumb

                                    1 Reply Last reply Reply Quote 0
                                    • P
                                      pglover19
                                      last edited by

                                      @Derelict:

                                      That is because when the secondary is CARP master it is the node that receives the traffic on the LAN CARP VIP. Again, what are you trying to prove by accessing the secondary's WAN interface from the inside when it is not CARP MASTER?

                                      Why did you X.X out the IP addresses on the WAN side in your diagram? Makes it pretty hard to communicate specifics back to you. They are RFC1918. Who cares about protecting/hiding them?

                                      Can you ping the secondary's WAN IP address from the primary? Then it's working.

                                      Can you ping the secondary's LAN address from LAN? Then it's working.

                                      Can the secondary resolve names, check for updates, and check for packages while it is NOT CARP master? Then it's working.

                                      I got it working.. On the WAN interface on the backup pfSense machine, I had to untick the "Block private networks and loopback addresses" and "Block bogon networks" options. See attachments.

                                      Capture_100.PNG
                                      Capture_100.PNG_thumb
                                      Capture_200.PNG
                                      Capture_200.PNG_thumb

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