I used a pre-built access server VM downloaded from OpenVPN. Incoming connections via port forwarding from the PVE host. There is one public IP on the PVE host and all the VMs are on a private subnet. The entire local network including the access server is virtual, hosted on Proxmox Virtual Environment (PVE). The open access server in my case is at the remote location (remote from my perspective) but to avoid confusion I'll refer to the server side as local and the client side (my house) as remote. Also I can access them via a SSH tunnel / port forward so it's all pointing to something being wrong with my VPN config. These things do work locally host-to-host on the remote network so I know they are not refusing connections. It didn't last long as I discovered that nothing other than ping worked. I set up my first site to site VPN using OpenVPN and was excited when I could ping hosts on the other side. ![]() I did find something that suggested the MTU might be to blame, but I haven't adjusted that from the defaults and I suspect there is a more fundamental explanation. Sorry if this has already been answered but I have spent hours googling and although there are quite a few results that seem to be my issue on the surface, the details aren't the same. Problem there is, that sombody makes the certificate's whell try to talk to concrete there is no isseu he says.Looking for some expert help here please. If i look at this cert it has a signature like this: Signature Digest: RSA-SHA1 (Weak Digest) VERIFY ERROR: depth=0, error=CA signature digest algorithm too weak: OpenSSL: error:0A000086:SSL routines::certificate verify failed: ![]() TLS_ERROR: BIO read tls_read_plaintext error TLS Error: TLS object -> incoming plaintext read error (in config Crypto HW: AES-NI and BSD Crypto both enabled (and reboot done) Note: OpenSSL hardware crypto engine functionality is not available SIGUSR1 received, client-instance restarting VERIFY WARNING: depth=1, unable to get certificate CRL: Open VPN TLS Error: Unroutable control packet received from I guess this is what also can produce these Undef connections shown.Īnd there is just one solution : train your OpenVPN client users to disable their connection when they are not using the OpenVPN and/or start to "move" with their device (I know : easily said then done)Īfter running a few tests this morning (nobody works at this time except me :-) ) So some (or many) of the OpenVPN connections are what I call 'stale', they didn't finish the client server renegotiation. The connections gets lost, and reconnects etc etc. This means their connection drops, and comes back, drops again, etc.Įvery time, the OpenVPN tries to reconnect against the server. ![]() They have the OpenVPN client activated, and they start to "move". If you have a lot of users, this can happen : Then it seems to be working beter but the connections keep comming as Undef also it seems that after a while there are less Undef's but if we look after about 30 minutes more then half of them are undef again I know, that means you have to some maintenance, deployment, but that's ok, as issue isn't about admin's confort, but said in OpenVPN Connections undefined: And I had to make sure that my OpenVPN don't use a OpenVPN client from early "2000" but a more recent one, like the one shown here. I had to ditch non supported Data Encryption Algorithms, and that ment I had to re export clienst config files. OpenVPN 2.6.8, that comes with pfSense 2.7.2 works just fine. But you also keep the now know security issues. I get it : you stick with the old versions as they work fine for you. Read this first : Home > pfSense Software > OpenVPN the very first pinned post.Ģ.6.0 is depreciated, as is any OpenVPN before " 2.6" and OpenSSL binaries. Using PFsense 2.6 the problems come when we use 2.7 or higher.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |