So all things considered, my situation is relatively speaking a correct configuration right?

@MalagaFirewall8 I tested the same scenario again after increasing the test system to 4 vCPU. The issue still occurs, so this does not look like a simple “not enough CPU” problem. Test system during this run pfSense Plus: 26.03.1 FreeBSD: 16.0-CURRENT OpenVPN: 2.6.20 CPU: 4 vCPU For this run I restored the original helper stack and added temporary timestamp wrappers around: /usr/local/sbin/ovpn_auth_verify /usr/local/sbin/openvpn.attributes.sh The wrappers logged helper start/end timestamps and return codes, then called the original scripts. I also sampled OpenVPN counters, CPU, load, and helper/PHP process counts during the reconnect storm. Result The problem still appears with 4 vCPU: total=469 with_vip=417 no_vip=52 undef=51 total=536 with_vip=420 no_vip=116 undef=98 CPU did spike during the storm, for example: cpu us=62 sy=29 id=8 But it was not permanently pinned at 0% idle. The behavior is wave-like: connections build up, UNDEF / no_vip increases, then the status sometimes drops back down before the next reconnect wave. During the storm we saw the expected helper/runtime processes: fcgicli php-cgi -f /usr/local/sbin/openvpn_connect_async.php /bin/sh /usr/local/sbin/openvpn.connect_async.sh /bin/sh /usr/local/sbin/ovpn_auth_verify php-fpm openvpn The timestamp wrappers showed many helper calls completing with rc=0, so it is not simply that every helper process hangs forever. However, under reconnect storm conditions the helper/runtime path still falls behind badly enough that clients remain in UNDEF / no virtual IP and later hit TLS/handshake timeouts. Earlier tests also showed: both helpers enabled → bad reconnect behavior / high UNDEF both helpers disabled/no-op → reconnect behavior much better only tls-verify disabled → still bad only client-connect/client-disconnect disabled → still bad replacing openvpn.connect_async.sh with an older version → did not solve it So my current conclusion is: This is probably not just UDP buffers and not just CPU capacity. It looks more like a regression or bottleneck in the pfSense/OpenVPN helper runtime path on the newer stack — likely around fcgicli, PHP helper execution, openvpn_connect_async.php, openvpn.tls-verify.php, or OpenVPN deferred client-connect handling under mass reconnect load. Disabling the helpers is not a safe production workaround, but it remains the clearest diagnostic: removing the helper path from the hot path makes reconnect recovery much better.

That sounds like the right direction. I’d keep the final broad block/reject while you still have the old allow-all rule around, mostly because it makes mistakes visible in the rule counters/logs. Once the per-client pass rules are complete and the allow-all is gone, the implicit deny can do the same job. For rollout, aliases per static tunnel IP are not wasted if they make the rule set readable for the next person.

@Gertjan Thanks again! I only reply quickly: it seems it even works without pass rules, at least I had the impression. I now adapted my setup according to your suggestions, following rule on both WAN-interfaces: [image: 1780590972256-c44879d4-c6a4-43f3-9364-631cd9af37ad-grafik.png] I have to test through all the variants tomorrow or so (4 remotes in the client.conf now). Great tip with "This firewall", very handy. Have a nice evening!

Troubleshooting & Workarounds so far: Main Workaround: Turn off pfBlocker. Suricata on/off made no difference. pfBlocker IP blocks on but DNSBL off worked. pfBlocker IP blocks on and DNSBL with malware & other filters on but porn filter off works, but connections are slower to establish. Note the porn filter is the single biggest filter list. Of course testing the different DNSBL options takes a lot of time as after each change pfBlocker must be reloaded, which with a lot of lists can take 30 min to an hour each time. I'll do more testing as time allows, but hopefully this may help someone else. What is odd to me is that it only affects the Tun VPN's as Tap VPN's are so much more complicated. If anyone has any other ideas they would like me to test/try let me know!

That definitely sounds frustrating. Since you're seeing both certificate generation errors and TLS key export problems, it feels like there may be multiple bugs involved rather than a simple configuration mistake. If anyone else is testing 25.11, it would be interesting to know whether these OpenVPN issues appeared after a fresh install or only after upgrading. Sometimes checking the periodo entre datas between snapshots and recent fixes can also help identify whether a regression was introduced in a specific build.

@Gertjan ok thanks

Okay, I've moved to my new house which is not on comcast so I don't have the ability to test this in production any more. Hopefully someone else picks up my patches.

@eegclbugs said in OpenVPN - make Client Specific Overrides persistent after reboot: with a script and not with the GUI for each user individually. You're already close to the answer ^^ If you found this : [image: 1779291236149-99d2d10a-8edf-4b54-9294-543f6218e683-image.png] you actually use this : [image: 1779291275273-b52bf3f7-9b15-456a-b197-75f3670153cd-image.png] That file can be found here : /usr/local/www/vpn_openvpn_csc.php Read that file (it's a script, world's most known : php) The bottom part is what your browser shows you. The top part is where the user's input (the pfSense admin), is validated, stored in the "one and unique pfSense config file" and you also find where the scs file are created etc. So ... if your script can use this script as a source, model (etc) you'll have the best of both worlds : Your script adds/edit/whateber the scs file. The - your - info is stored into the "one and unique pfSense config file" so when pfSense restarts, everything is setup according to its "one and unique pfSense config file" info. And you can still use the GUI to look/edit/delete things. Btw : this is a 'how I would do it solution'. Commanding pfSense from the command line without doing it the 'pfSense' way is generally a bad idea.

@Gertjan said in ifconfig option in OpenVPN server config for Peer to Peer necessary?: Then restart the openvpn server (client) and see what happens. That's one idea I had, but since the traffic is routed to the remote side via IP 10.0.0.2 this will break my connection. It's a router to router connection, but this must also possible with the "Remote Access" mode? So whats the exactly benefit of the peer to peer Mode?

It's now fixed in Plus and CE: https://forum.netgate.com/post/1242673

It's only ignored, not a fatal error, so it's not critical to remove yet. They do not have a timeline for its removal, so there's no hurry to change it at the moment. We usually drop options to "legacy" when they cause a failure or otherwise have a negative impact. Leaving them in place as they are now increases the compatibility of the generated configuration files with a wider range of OpenVPN client versions.

@Autourdupc said in OpenVPN issue when unautorized login attempt: One side, external : LAN2 with NAS2 -> Freebox (router) -> WAN Other side, office : LAN1 with NAS1 -> pfsense (router) -> Freebox (router) -> WAN Purpose : NAS1 sends backup to NAS2 Replace 'Freebox' with 'Livebox' and you have exactly my same setup. I backup my work Synology diskstation to my home Syno diskstation, using Hyper Backup on one side (work) and the counterpart 'The Vault' at the home side. Since I have fiber at home and at work, this has became a usable option. Renting 10 Tera somewhere was way more expensive. Previous upload speeds (VDSL) made this nearly impossible anyway. I used OpenVPN in the beginning ... but then I started to think : the communication channel is 'ssh' and the distance isn't that far. SSH means : traffic is TLS encrypted. The data copied are already encrypted Macrium Reflect backup files. Do I really need an encrypted VPN channel over an encrypted channel with data already encrypted ? Btw : the data is company related (a hotel) and we don't store private client info, maybe just their name, and their bills and so on. Since I stopped using VPN, my backups always terminate every night, and it takes some 60 minute s or so to transfer something like 250 Gbytes. I do use OpenVPN for remote admin access. Just UDP. Never had any issues with that. The only 'VPN' "errors" I see are these : [image: 1778046306704-e46a8a08-5bbd-4e60-8c34-9876e6a2fd1e-image.png] and these are, imho, just packets from scanners trying. The OpenVPN isn't restarted.

@Gertjan Thanks, I appreciate your research. That was a while ago when I got services working as I expected. Once I was confident, I understood what the expected SMB handshake should look like, I could see there was a ton of congestion, and the packets were just getting dropped. I don't remember exactly what I uninstalled or disabled to improve SMB traffic, however. Assigning the ovpns1 to an interface is an interesting choice. I believe configuring firewall rules on the OpenVPN tab may achieve a similar result.

@Gertjan Are there by any chance any other logs I can check?

After the adjustment, it has been working well for some time now, and the issue appears to be resolved.