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

    pfSense 2.5 OpenVPN Issues - User Auth

    Scheduled Pinned Locked Moved OpenVPN
    3 Posts 2 Posters 649 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.
    • X
      Ximulate
      last edited by

      Like others, I've been wrestling with OpenVPN issues since the 2.5 update.

      In my case, I've narrowed it down to User Auth. My OpenVPN server was set-up to Server Mode: Remote Access (SSL/TLS + User Auth). This all worked fine prior to the 2.5 update.

      If I switch to "Remote Access (SSL/TLS)" (disable User Auth), OpenVPN works fine.

      X 1 Reply Last reply Reply Quote 0
      • X
        Ximulate @Ximulate
        last edited by

        Well, that was last night. No changes, but now we're back to no connections. This time its reporting:

        TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
        TLS handshake failed
        SIGUSR1[soft,tls-error] received, process restarting
        

        Further, last night, I wasn't able to establish a connection with "TLS Encryption and Authentication" enabled. But, it worked with just "TLS Authentication" and "Remote Access (SSL/TLS)".

        I can access the GUI externally on port 443 (which I opened so I could remotely troubleshoot this problem.) I'm running V2.5 of the OpenVPN client (I exported the bundle from client export.)

        My test router updated to 2.5 without issue. I then updated three remote routers, where OpenVPN failed immediatly after the 2.5 update. Two of the three are on the same ISP (different locations). I've been comparing and testing settings, but so far nothing seems to be working.

        D 1 Reply Last reply Reply Quote 0
        • D
          divsys @Ximulate
          last edited by

          @ximulate The simple change that has worked for me so far: make sure "Do not check" is set on the server's certificate Depth Check option. This seems to bypass a potential bug with Certificate tests that can be pretty random seeming. May not solve your issue but probably won't hurt and helped me.

          -jfp

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