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

    OpenVPN client cannot access second pfSense host

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    4 Posts 3 Posters 2.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.
    • E
      Eric Scace
      last edited by

      Hi all โ€”

      The attached configuration uses two Netgate appliances to implement High Availability.
      Englewood IT schematic 2021 08 01 sanitized.jpg
      (At the moment there is only one WAN. Later dual-WAN will be added.)

      OpenVPN provides remote access to clients.

      This general works fine, but there is a minor, annoying, lingering problem: an OpenVPN client cannot access the second (standby) pfSense appliance with its assigned LAN address (e.g., 10.160.0.3 in this diagram).

      The OpenVPN client can SSH into the console port of the Cisco switch. The switch can be instructed to ping the pfSense appliance at 10.160.0.3 successfully.

      The OpenVPN client can ping the current primary pfSense appliance at the group address (10.160.0.1) and its individual address (10.160.0.2)... and can log-in to its web configurator at those addresses successfully.

      However, the OpenVPN client cannot ping nor log-in to the second pfSense appliance (on standby).

      A local on-site device behind the Cisco switch can access the pfSense appliance at 10.160.0.3 successfully with pings and log-ins.

      There must be some peculiarity of how OpenVPN is working that precludes either routing to the second pfSense appliance or perhaps returning the response from that appliance.

      Any suggestions?

      โ€” Eric

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

        @eric-scace
        This is an expected behavior, because the secondary has no route to the OpenVPN clients virtual IP.

        You can find how to workaround this by adding a masquerading rule in the docs: Troubleshooting VPN Connectivity to a High Availability Secondary Node

        E 1 Reply Last reply Reply Quote 0
        • E
          Eric Scace @viragomann
          last edited by

          @viragomann Thank you! That's exactly what I needed to know โ€” and it fits all my observations perfectly. (And I'm sorry to have overlooked that one troubleshooting article.)

          S 1 Reply Last reply Reply Quote 0
          • S
            sgw @Eric Scace
            last edited by sgw

            Could someone post an example for the necessary NAT rule(s), please?
            EDIT: got it already, at least I think so ๐Ÿ˜Š

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