Continuing my monolouge here It seems like openSSL might have done some changes, that affects openVPN clients versioned 2.6.xx+ I think also something that affects certificate encryption. And i noticed a new settings field in the 2.7 openVPN Client export. [image: 1695188692911-f799358e-e425-4e15-8293-191dcf8cddec-image.png] My steps to reproduce: Have a Win PC with an openVPN Client export installer (latest from pfS 2.6) - Current Windows Installers (2.5.8-Ix04): If you try to connect to the pfS 2.6 openVPN server , all is good. Then you get/receive a pfSense 2.7 Client export install file , and install it (to install the new conf+certs for that connection) - Current Windows Installers (2.6.5-Ix001): Now if i try to connect to the "Old pfS 2.6" OVPN Server, I get asked for uid/pwd as usual. But after entering that correct, i get another "gui prompt" , asking for the cert passwd. [image: 1695189784507-7ef967d0-5eb3-4afd-8f0c-8a95c1f77d81-image.png] Since i never used/generated a cert passwd, i can't login anymore. Connecting to the 2.7 OVPN server, with the new client, does not ask for a cert passwd. It might be an "Odd test" , but I think someone could have both 2.7 & 2.6 openVPN servers in prod. Could Netgate confirm the above issue/situation ? /Bingo

I was able to get my ISP to give me a publicly accessible IP address for my WAN. This has solved my problem. Thanks for all the suggestions.

Yes, the CSO sets the routes within OpenVPN, so that the traffic is routed to the proper client. The "Remote Networks" field in the server settings sets the routes for the entered networks to the OpenVPN server in pfSense. Thanks again for your help, viragomann - I now have a setup that seems to work well :-) I am not quite sure yet what the difference is between "remote networks" in the server settings and "remote networks" in the CSO... Cheers, Jarle

@viragomann Here is the OpenVPN tab: [image: 1695075529041-d73061bc-c188-4aca-951e-d2acca9f8847-image.png]

[image: 1695058346462-7a56e8a4-1c89-45ec-9987-edb7bd193813-image.png] another interface WAN, it is working... so, this BUG on OpenVPN?

@petrt3522 Didn't know you were using a OpenVPN client. I used the wrong reply button - should have replied to @pwood999 @pwood999 522 was talking about a OpenVPN server process. /var/etc/openvpn/server1/sock These lines : Jul 18 13:12:55 pfSense-MX80 openvpn[5843]: MANAGEMENT: CMD 'state 1' Jul 18 13:12:55 pfSense-MX80 openvpn[5843]: MANAGEMENT: CMD 'status 2' is the widget questioning for the list with connected users. The 'socket' (file based) is only available locally. I'm not using the pfSense OpenVPN as a client myself, so, in that case, I can't tell, but I presume the widget can also connect to the openvpn client service socket and collect data about the Openvpn link. Again : presuming here. Btw : no intended. @petrt3522 the subject is wrong : Repeating connect & disconnect in logs. These log lines do not show any "OpenVPN" reconnections.

Anyone else struggeling with OTP after 2.7.0 update?

@Stef93 It gets stranger. When I use the client export utility to get the IOS config and then import it into the OpenVPN app on my iPad, it DOES connect, although I still cannot see anything on the permitted subnet. The iPad was just a test, I don't plan on using this via a mobile device.

@Hudson-1 So I expect, that pings to public IPs are working. However, 8.8.8.4 is not a good advice. The server doesn't respond to ping requests obviously. Try 8.8.8.8 instead.

@viragomann After the latest patch Fix OpenVPN selecting wrong interface address when VIPs are present (Redmine #14646) https://redmine.pfsense.org/issues/14646 I could be able to route out my traffic and the OPENVPN client works as it is requested.

@viragomann thank you, I'll check that out

Fixed !! ... I am so used to working on smaller 100% fibre based networks with min 1Gbe connectivity. I forget this is more complex. And takes longer to replicate. When you try and resolve the namespace it comes up with the primary DNS being the one furthest away that did not have a valid replication. Thanks John!

Also, even if your client is up-to-date, if your certs use a weak hash like SHA1, then builds of OpenVPN based on OpenSSL 3 will refuse those certificates as well. Nothing the client or server can do about that, you have to issue new certificates that don't use weak hashes. If it's the encryption on the PKCS#12 bundle that isn't being read by the OS, you can always install the client manually and then export an inline configuration with the certs inside rather than using PKCS#12, or you can export a PKCS#12 bundle separately from the certificate manager using a higher level of encryption. Any version of the export package newer than 1.9 should be capable of exporting a stronger PKCS#12 bundle directly in the export package: https://redmine.pfsense.org/issues/13255

Hi @Stef93 Thanks for the suggestion! However it looks like the client end of the tunnel (10.10.10.2) is NAT'ing the traffic prior to putting it in the tunnel. So by the time it reaches the pfSense OpenVPN NAT Policy it is already NAT'd. I was able to solve the issue by creating a similar NAT Bypass rule using the the GL-iNet NAT interface. And that seems to be working. I appreciate your feedback!

@Stef93 Turned out that I have missed to add a Client Specific Override, but couldn't get it to work anyway. Reading a bit more on Client Specific Override I found out that changing the tunnel network from /24 to /30 didn't need any override and then I got it working. Thanks, you lead me to the solution!