@karpia8 Is this an OpenVPN access server, where 172.20.20.0/24 is the tunnel network? If so I don't expect, that there is any impact due the IPSec settings.

Tonight at a restaurant, using Wi-Fi, I got 4 Mbps on speedtest in the browser. I then connected to VPN, and got the same 4 Mbps on the speedtest. I think that's strong evidence that my home ISP is not throttling. I then turned off both Wifi and VPN. Got 220 Mbps on speedredt in the browser. With VPN, could not even get the speedrest going. OpenVPN showed about 80 bytes/s throughput, ie. Less than 1 kilobit/s as I saw before in my OP. Perhaps it is the cell carrier throttling. I'm using US Mobile, a T-Mobile MVNO. I will ask them what's going on. They are not supposed to throttle VPNs, and I believe it's illegal here. I would like to rule out any technical problems with my pfSense config, though, before I contact the CPUC and FCC.

Did a little more research. tls-auth will use the auth algorithm so both sides need to match. tls-crypt is hard coded to use AES-256-CTR/SHA256 and the auth algorithm is not used

It really looks like there is an issue with the pfSense GUI. I exported ca.crt and ca.key to the local filesystem. Then I used the openssl command in the SSH console to generate user.crt and user.key signed with the exported ca.crt. The next step was to create a user with certificates (but the certificate manager generates an empty certificate and key). Go to the certificate manager, edit the existing empty certificate and key, and copy the data from the .crt and .key files on the filesystem. Everything works fine, including OpenVPN. So I don't know what could be causing the issue in the GUI...

@Enso_ Or : @Enso_ said in Moving from shared key to SSL/TLS - Can't access web interface anymore: Is there a way to achieve this switch without risking being locked out? Create a second OpenVPN server access, and work with that one to set up the original OpenVPN server. Although, I would do what @viragomann said.

@viragomann Thank you Viragomann!! That was it!. My remote clients is now able to access everything. So in summary, not only do I add the remote LAN subnets, but also add the remote Tunnel network into the remote networks peer to peer settings (shown in neon green). [image: 1717357110516-bitmap.png]

@Antibiotic Oh, haha.... No, it's actually the "Compact-RED" theme, but with the Dark Reader browser extension enabled.

@JonathanLee No sure what you mean. Never used these before.

Was not showing the newer version Just upgraded to v 2.7.2 via cmd: certctl rehash And it works! Thanks

@madbrain Anyone ?

@viragomann I lost patience and just rebuilt the OpenVPN tunnel completely. In hindsight, I suspect that merely reimporting the TLS key from the server on the client side would've done it. Thanks very much for your help.

@codechurn said in Open VPN Server: I didn't realize that OpenVPN required me to install a client to use it Not really needed, but as Microsoft products like to talk with Microsoft Products, its the same for OpenVPN product. You can of course use any 'OpenVPN' client, as long as it is compatible with OpenVPN, and you manage to make it work ^^ But it works, and during massive home works situations around 2020/2021/2022 it was fully tested. Half the planet was using it.

@Luvirini said in OpenVPN daemon stops working: 2.7.1 ?, You've re invented the reason why "2.7.2" came out @Luvirini said in OpenVPN daemon stops working: to autostart services that have crashed The system blow up tool ? This one : [image: 1716809100678-7ca9edc3-7ed9-4bba-bf38-a9fa6e363c13-image.png] ? Won't help you very much. VPn will blow up, core dumps, OpenVPN gets restarted, rinse and repeat. After several cycles, system stability can become an issue. Just upgrade to 2.7.2 and call it a day. Service_Watchdog is useful for system developers, so they do not have to baby-sit their "not-ready-code" all the time. Edit : Just to motivate you : I'm using pfSense, and OpenVPN server for more then a decade. Never had it seg-fault on me.

I've managed to solve this problem. First, ipv6 was a red herring. I just got lucky that the ipv4's kept being assigned in the right order. The real issue was that, when there are multiple VPNs, there is a little selection window that allows you to specify which VPNs the client specific override is assigned to. This determines which folder the config file is written to. I found out the csc was written to the wrong location, because when making a second client override, the configuration will default to selecting the next server, not the one you selected last.

@JKnott Thank you. I believe I have been able to resolve this. The solution was to push a route via OpenVPN along with having additional phase2 IP routes specified. I did not set the default route for the Remote Site Office to use the Remote Office as I wanted general internet traffic to avoid the VPN. So far, this appears to be working as required. Matthew