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

    Peer to Peer (SSL/TLS) connection going into limbo

    Scheduled Pinned Locked Moved OpenVPN
    9 Posts 2 Posters 1.6k 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.
    • morgensternM
      morgenstern
      last edited by

      We have 8 separate site to site OpenVPN links between the HQ whitebox running pfsense+ 22.05 and a bunch of SG-1100s, based at various home offices across the UK, all now running pfsense+ 23.01.

      These site2site links provide the home offices mainly with connectivity to the Avaya IP Office control unit for their desk IP phones. Not much other traffic goes through the tunnel.

      Since the switch to the SSL/TLS method from the previously used shared key, I started noticing a problem with the server (HQ) end of the tunnel going into a limbo state, if the client end disconnects however briefly from internet.

      When this occurs, the server end of the OpenVPN tunnel reports "Waiting for response from peer"

      pfsense_openvpn.png

      When this happens the IP phone on the client / home office end loses dial tone and if it gets rebooted, it does not finish the boot sequence properly.

      This can only be resolved on the server end, by restarting the misbehaving OpenVPN service from the Status screen.

      After the status will say "Adding routes to system" for a bit and then go to "Connected (Success)." This then allows the IP phone to be rebooted properly and continue functioning.

      Suffice to say I have the Service Watchdog running on both ends of all separate tunnels. But it does not look like the service actually terminates. It just hangs.

      1 Reply Last reply Reply Quote 0
      • morgensternM
        morgenstern
        last edited by

        Anyone? I'm sure we aren't the only ones experiencing it and I find it a serious enough problem to deserve a deep dive.

        By the way, I'm sure this problem was present in a similar form even before I upgraded our HQ machine to pfsense+. The "Waiting for response from peer" would occasionaly show on the HQ side of various tunnels but the connection has never gone stale the way it does now.

        It's definitely something to do with the TLS authentication mechanism, because it was never an issue with the preshared key tunnels.

        morgensternM 1 Reply Last reply Reply Quote 0
        • morgensternM
          morgenstern @morgenstern
          last edited by morgenstern

          @morgenstern

          Update:

          It's happened again on the site2site link between the HQ and one of the SG-1100s

          02.JPG
          01.JPG

          Towards the top of the log I restarted the OVPN service on the HQ side which had fixed it.

          morgensternM 1 Reply Last reply Reply Quote 0
          • morgensternM
            morgenstern @morgenstern
            last edited by

            @morgenstern

            <rant>

            This sad story of TLS auth problems is now reaching its conclusion in form of me abandoning OpenVPN site to site tunnels in favour of IPsec with mutual PSK. (After about five years of beutiful friendship 😢 )

            Mind you when OpenVPN still officially supported the PSK method it worked absolutely fine.

            The routing is now actually much simpler with IPsec and it requires almost no FW rule creation as it's done automatically.

            I am just surprised and a little dismayed by the fact that this issue isn't affecting anybody else.

            Was I the last person in the world using the site 2 site OpenVPN tunnels?

            </rant>

            M 1 Reply Last reply Reply Quote 0
            • M
              michmoor LAYER 8 Rebel Alliance @morgenstern
              last edited by

              @morgenstern looking at your OpenVPN logs and google searching “ openvpn tls keys out of sync” I see fixes….have you tried any of them?
              Regardless imo I would stick with IPsec anyway because of the speed and simplicity of it.

              Firewall: NetGate,Palo Alto-VM,Juniper SRX
              Routing: Juniper, Arista, Cisco
              Switching: Juniper, Arista, Cisco
              Wireless: Unifi, Aruba IAP
              JNCIP,CCNP Enterprise

              1 Reply Last reply Reply Quote 0
              • morgensternM
                morgenstern
                last edited by

                @michmoor Thanks, yeah I'l probably do that.

                morgensternM 1 Reply Last reply Reply Quote 0
                • morgensternM
                  morgenstern @morgenstern
                  last edited by

                  @morgenstern Only thing that worries me is if it's possible that the IPsec psk authentication will eventually get deprecated by Netgate the same way it has been done with OpenVPN?

                  M 1 Reply Last reply Reply Quote 0
                  • M
                    michmoor LAYER 8 Rebel Alliance @morgenstern
                    last edited by

                    @morgenstern This isn’t a Netgate thing it’s how the package is maintained and developed. OpenVPN has deprecated shared keys.
                    IPsec psk is part of the standard and I have seen no RFC that hints at deprecation.

                    Firewall: NetGate,Palo Alto-VM,Juniper SRX
                    Routing: Juniper, Arista, Cisco
                    Switching: Juniper, Arista, Cisco
                    Wireless: Unifi, Aruba IAP
                    JNCIP,CCNP Enterprise

                    morgensternM 1 Reply Last reply Reply Quote 0
                    • morgensternM
                      morgenstern @michmoor
                      last edited by

                      @michmoor Cool, thanks for clarifying that 👍

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