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

    pfSense HA with OpenVPN behind NAT

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 2 Posters 911 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.
    • P
      parushev
      last edited by parushev

      Hi all,

      I have a private network of 192.168.100.0/24. My public IP is 78.83.163.141.

      I have two VMs running pfSense Community Edition 2.6.0 and respectively OpenVPN Server 2.5.4.
      Both VMs have a single network interface set as WAN with addresses from the private network: 192.168.100.10 and 192.168.100.11.
      I've configured a HA between them with CARP IP 192.168.100.12.

      The OpenVPN server is set to UDP 61194 with tunnel network of 192.168.104/24.
      I've added an outbound NAT for 192.168.104/24 to the CARP IP 192.168.100.12 (so all OpenVPN packets to be routed through the CARP).

      I've added a NAT on my public IP, port 61194 to 192.168.100.12, port 61194 (public to CARP).

      The whole thing works except:

      • list itemI see as client IP the IP of the router, not the real public IP address of the client

      • list itemI receive the following error when connecting

      Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1683797029) 2023-05-11 12:23:49 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
TLS Error: incoming packet authentication failed

      and in the server logs I see

      MULTI: bad source address from client , packet dropped

      After a lot of the messages above, the client connects, but sometimes the process times out and it retries.

      I'd appreciate any help so I can clear those errors. If you need more information, I'd be glad to share it.

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

        @parushev said in pfSense HA with OpenVPN behind NAT:

        list itemI see as client IP the IP of the router, not the real public IP address of the client

        So your router does masquerading on inbound traffic.
        Possibly you can change that.

        list itemI receive the following error when connecting

        Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1683797029) 2023-05-11 12:23:49 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

        TLS Error: incoming packet authentication failed

        and in the server logs I see

        MULTI: bad source address from client , packet dropped

        Does the client address change?

        P 1 Reply Last reply Reply Quote 0
        • P
          parushev @viragomann
          last edited by

          @viragomann thank you for taking your time answering.

          I'll try the masquerading thing. Read about it but wanted to make sure by asking.

          What do you mean by "does the client address change"?
          The client is a friend's PC (OpenVPN client 2.6.0), behind a home router which has public static IPv4.

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

            @parushev said in pfSense HA with OpenVPN behind NAT:

            What do you mean by "does the client address change"?

            Masquerading is what your router does if you see the internal router IP instead of the public IP of the client.
            Some consumer router do this by default, so the access is normally accepted by the destination device. Because access from outside of the local subnet is usually blocked by the devices system firewall by default.

            But there should be an option to disable it on the router.

            The client is a friend's PC (OpenVPN client 2.6.0), behind a home router which has public static IPv4.

            When the client sends a packet to you, the source address is translated into his public address by his router. This must not be disabled, otherwise routing won't be possible. And the public IP is what you want to see.
            On your router it shouldn't be translated again, but as mentioned above, some consumer router do this with default settings.

            P 1 Reply Last reply Reply Quote 0
            • P
              parushev @viragomann
              last edited by

              @viragomann thank you for your information.

              Without touching anything else, by changing the NAT to the direct IP of the MASTER node and reconfiguring the OpenVPN server to listen on the WAN, not the WAN CARP, the VPN works without any error message. Of course, I again see the private IP of my router as a connected client since I haven't changed anything.

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

                @parushev
                Is CARP working well? Check the system log for regarding entries.

                Is the OpenVPN server down on the secondary?

                Do you have a single router or is it an HA system as well?

                How are your pfSense boxes connected to it? Is there a switch or another device in between?

                Are they installed on bare metal or virtualized?

                Note: When a device is talking to the CARP VIP, it resolves the VIP and get the CARP MAC address and send the packet to this. However, pfSense uses its real interface address (WAN in your case), when replying.
                Some devices don't love this behavior. Maybe you're affected of this.

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