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

    Inability to access LAN over OpenVPN after minor changes

    Scheduled Pinned Locked Moved OpenVPN
    6 Posts 2 Posters 740 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
      Phenom
      last edited by

      Hello all,

      I'm sure I'm overlooking something basic, could potentially be subnet overlapping but it wouldn't explain the behavior. Summary of original config:

      PFSense 2.4.0-Release on ESXi 6.5
      Went through OpenVPN Wizard to make a remote access server on UDP 1194
      Original LAN was 10.0.0.0/24 and tunnel network was 10.0.252.0/24 (I realize now I was a dunce for using this pool, don't hit me too hard.)

      All was well though, functioned fantastic for well over two years.

      Come the weekend, I had to upgrade my Comcast modem for Docsis 3.1 so I could get that wonderful gigabit speed. Changes happened in the process:

      Altered LAN to 10.32.0.0/24
      Altered Tunnel network to 10.32.252.0/24
      Upgraded PFSense to 2.4.3

      Between swapping out the modem and those two changes, despite having gone over every rule with a magnifying glass and even deleting the server and re-creating it and re-exporting the profile.. I can connect to the OpenVPN server fine, navigate to the PFsense hosting it from Site B via https://10.32.0.1 but I cannot even ping any of the devices on its LAN, whereas prior to these changes it was perfectly fine.

      I did a route print to verify all was well, and at a glance it seemingly is:
        10.32.0.0    255.255.255.0      10.32.252.1      10.32.252.2    291

      I did look through here to see if anyone had a similar issue but couldn't find someone reporting this exact behavior. I apologize if I missed an obvious answer. Any help would be greatly appreciated.

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

        Does the LAN device have internet access?

        Does the firewall on the device allow access from the new tunnel network?

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

          Yes, all devices behind the PFsense adjusted to the 10.32 change with no issues and all have internet access/can communicate with one another locally fine.

          And, I believe so, though I'd need to know how to double check to for sure. Should be noted though that just in case that was the problem, before I deleted the server and re-used the wizard to make the server, I did change the tunnel network back to 10.0.252.0/24 to no avail.

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

            Also the firewall rules on the OpenVPN interface allow access?

            Do you run multiple OpenVPN instances on pfSense?

            You may use the Packet Capture tool from the Diagnostic menu to investigate packet flow on incoming and outgoing interfaces.

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

              @viragomann:

              Also the firewall rules on the OpenVPN interface allow access?

              Yes, set to allow all, initially just IPV4, also added IPV6.
              @viragomann:

              Do you run multiple OpenVPN instances on pfSense?

              No, just the one.
              @viragomann:

              You may use the Packet Capture tool from the Diagnostic menu to investigate packet flow on incoming and outgoing interfaces.

              I'll test that out and report back soon.

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

                So, bit later than I wanted. But think I've discovered the problem lies with authentication.

                May 8 23:21:14 openvpn 65105 Authenticate/Decrypt packet error: packet HMAC authentication failed
                May 8 23:21:14 openvpn 65105 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:(remote site wan):7003 (via ::ffff:(pfsense wan address)%em0)
                May 8 23:21:16 openvpn 65105 Authenticate/Decrypt packet error: packet HMAC authentication failed
                May 8 23:21:16 openvpn 65105 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:(remote site wan):7003 (via ::ffff:(pfsense wan address)%em0)
                May 8 23:21:20 openvpn 65105 Authenticate/Decrypt packet error: packet HMAC authentication failed
                May 8 23:21:20 openvpn 65105 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:(remote site wan):7003 (via ::ffff:(pfsense wan address)%em0)
                May 8 23:21:28 openvpn 65105 Authenticate/Decrypt packet error: packet HMAC authentication failed
                May 8 23:21:28 openvpn 65105 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:(remote site wan):7003 (via ::ffff:(pfsense wan address)%em0)
                May 8 23:21:45 openvpn 65105 Authenticate/Decrypt packet error: packet HMAC authentication failed
                May 8 23:21:45 openvpn 65105 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:(remote site wan):7003 (via ::ffff:(pfsense wan address)%em0)

                Starts blasting en masse the moment I try to ping/navigate to anything on the LAN. Not sure how to rectify that, given my setup is identical (short of lan address) to how it was setup when it was working for two years.  Google-fu all points to configurations far more advanced than mine on Ubuntu servers or OpenWRT, not sure how to decipher and apply to mine.

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