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

    OpenVPN client drops after assigning interface

    OpenVPN
    openvpn client openvpn openvpn problem tls tls error
    4
    10
    2.1k
    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.
    • mgiM
      mgi
      last edited by mgi

      Hello,

      Still fighting with client OVPN connection on pfSense/Netgate.

      I have (I believe) a quite simple client configuration.

      dev ovpnc2
verb 3
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_client2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 10.10.10.254
tls-client
client
lport 0
management /var/etc/openvpn/client2/sock unix
remote OVPN_SERVER_FQDN 1194 udp4
auth-user-pass /var/etc/openvpn/client2/up
auth-retry nointeract
route 10.0.0.0 255.0.0.0
…
capath /var/etc/openvpn/client2/ca
cert /var/etc/openvpn/client2/cert 
key /var/etc/openvpn/client2/key 
tls-auth /var/etc/openvpn/client2/tls-auth 1
data-ciphers AES-128-CBC:AES-128-GCM:AES-192-CBC:AES-192-GCM:AES-256-CBC:AES-256-GCM
data-ciphers-fallback AES-128-GCM
allow-compression asym
resolv-retry infinite
comp-lzo no
route-nopull

      After I assign the ovpnc2 port to an interface, the connection stops working (nothing in the log), and I can see that all routes disappear.

      Then, when I try to restart the connection under Status / OpenVPN, I just get TLS errors in the log.

      Apr  2 19:04:14 pfSense openvpn[2402]: SIGUSR1[soft,tls-error] received, process restarting
Apr  2 19:04:24 pfSense openvpn[2402]: VERIFY KU ERROR
Apr  2 19:04:24 pfSense openvpn[2402]: OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Apr  2 19:04:24 pfSense openvpn[2402]: TLS_ERROR: BIO read tls_read_plaintext error
Apr  2 19:04:24 pfSense openvpn[2402]: TLS Error: TLS object -> incoming plaintext read error
Apr  2 19:04:24 pfSense openvpn[2402]: TLS Error: TLS handshake failed

      To fix the errors, I have to unassign the interface, disable and re-enable the client config. I don’t have to do any change in the config, and that puzzles me.

      Because of this, I can’t properly create FW and NAT rules for different connections.

      I’m running the version 22.01 on SG-2100 and the openvpn version is 2.5.4.

      Did anyone see such behavior before?

      V mgiM 2 Replies Last reply Reply Quote 0
      • V
        viragomann @mgi
        last edited by

        @mgi said in OpenVPN client drops after assigning interface:

        route 10.0.0.0 255.0.0.0

        Why you are routing the whole 10.0.0.0/8 over the VPN???
        This includes your own local subnet.

        mgiM 1 Reply Last reply Reply Quote 0
        • mgiM
          mgi @viragomann
          last edited by

          @viragomann because many of my customers use 10.x.y.z networks and it’s much easier to cover that by one aggregated route.

          I see no problem with the routing as my network is local and direct route + more specific. I’m already using the same config on my EdgeRouter, but I need to migrate it to pfSense.

          I’m more confused about why assigning a port to an interface is causing TLS errors.

          1 Reply Last reply Reply Quote 0
          • mgiM
            mgi @mgi
            last edited by

            I also enabled verbosity level 11, but didn’t get anything more useful.

            …
Apr  2 20:56:08 pfSense openvpn[66365]: Incoming Ciphertext -> TLS
Apr  2 20:56:08 pfSense openvpn[66365]: SSL state (connect): SSLv3/TLS read server certificate request
Apr  2 20:56:08 pfSense openvpn[66365]: VERIFY WARNING: depth=0, unable to get certificate CRL: CN=OpenVPN Server
Apr  2 20:56:08 pfSense openvpn[66365]: VERIFY WARNING: depth=1, unable to get certificate CRL: CN=OpenVPN CA
Apr  2 20:56:08 pfSense openvpn[66365]: VERIFY OK: depth=1, CN=OpenVPN CA
Apr  2 20:56:08 pfSense openvpn[66365]: Certificate does not have key usage extension
Apr  2 20:56:08 pfSense openvpn[66365]: VERIFY KU ERROR
Apr  2 20:56:08 pfSense openvpn[66365]: SSL alert (write): fatal: unknown CA
Apr  2 20:56:08 pfSense openvpn[66365]: OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Apr  2 20:56:08 pfSense openvpn[66365]: TLS_ERROR: BIO read tls_read_plaintext error
Apr  2 20:56:08 pfSense openvpn[66365]: TLS Error: TLS object -> incoming plaintext read error
Apr  2 20:56:08 pfSense openvpn[66365]: TLS Error: TLS handshake failed
…

            I’m still confused why the port assignment can break it so bad.

            mgiM 1 Reply Last reply Reply Quote 0
            • mgiM
              mgi @mgi
              last edited by

              So I discovered two things today:

              1. When I make two changes to the VPN (e.g. change and revert debug level), the VPN comes up.

              2. When I restart the VPN from CLI using the pfSsh.php playback svc restart openvpn client 2 command, I can replicate the same behaviour. Even stop and start doesn’t help, and I have to change the VPN config in the web gui and save. Weird…

              1 Reply Last reply Reply Quote 0
              • M
                MrHobbles
                last edited by

                I just wanted to say that I have exactly the same issue, and it's been driving me nuts since 2.6.0 was released.

                Then I tried your trick of changing log level and back again...and it worked. VPN came up.

                How odd.

                mgiM 1 Reply Last reply Reply Quote 0
                • mgiM
                  mgi @MrHobbles
                  last edited by

                  @mrhobbles

                  Yeah, it's weird.

                  I'm now 99% done migrating my network to pfSense, so the client VPN is stable when I'm not touching the interface or rules.

                  I'm not sure if this might have something to do with S2S with OpenVPN AS or if it is a general issue.

                  I plan to replace the OVPN AS with pfSense VM when I have some time, so hopefully, that will work better.

                  1 Reply Last reply Reply Quote 0
                  • J
                    JohnSheridan
                    last edited by

                    Hi,

                    I have the same issue and narrowed it down to the following:

                    • the client had an old certificate without EKU (extended key usage). Clients with newer certificates with EKU work.
                    • the problem is, that "remote-cert client" comes into the openvpn server configuration, enforcing exactly the check of the above.
                    • this options comes in the config if I restart the daemon ("Status=>OpenVPN"), regardless of the "Client Certificate Key Usage Validation" configuration option in the web interface
                    • however, if I save the configuration in the web interface, the option does NOT come when it is not ticked and the server works. But after a restart, the option is back in the config.

                    I filed bug #13077, but it was immediately rejected, but I am really able to reproduce this again and again. Before the upgrade to 2.6.0 (before this new option actually was introduced) everything was working flawlessly.

                    I recreated the certificates for now, as it then works with or without that option.

                    1 Reply Last reply Reply Quote 1
                    • J
                      JohnSheridan
                      last edited by

                      Seems to be fixed now via bug #13056:

                      https://redmine.pfsense.org/projects/pfsense/repository/1/revisions/48cf54f850c5bf4fe26a8e33deb449807e71c204/diff

                      The diff works for me, the remote-cert-tls option can now be turned off again even over a server restart.

                      mgiM 1 Reply Last reply Reply Quote 1
                      • mgiM
                        mgi @JohnSheridan
                        last edited by

                        @johnsheridan Thanks for the info and testing. That makes sense. I’ll have a look at those files and patch.

                        This will be probably fixed in one of the next releases then.

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post