Just a follow-up, since there's been no reply. I've concluded that it's related to or at least severely exacerbated by this issue in 24.11 with the dashboard impacting the system load: https://redmine.pfsense.org/issues/15969

It's kind of like the observer effect--it seems most prone to happening when I'm investigating it happening, or more particularly, when I've accidentally left a tab running the dashboard open. Earlier this week I logged in to get some info on a DHCP lease, forgot to log out and went on my merry way, came back a couple hours later to find that most of the OpenVPN connections had gone down again, plus there were a bunch of entries in system.log relating to php-fpm and connections being refused for loading the dashboard widgets. I restarted php-fpm and the gui from the console menu, and the VPN connections all came back online within a short period of time.

I'll be glad when 25.03 comes out so this problem is fixed!

@viragomann Thanks!!! It works!

@phil80

It works, syntax is wrong.
You have to specify time that token is valid for:
auth-gen-token 86400;
auth-gen-token 0; --->>Set to 0 never expires

For me it works on both Android clients and on windows also.

We use duo push mfa and when we change networks, we see in log that session token is used for reauth...

Also, if reneg-sec on server is 36000 and this option is not set on client it will still renegotiate after 3600 seconds because this is hard coded to 3600 if not set. And SMALLER number is used, so if server has 3600000 seconds set, and client has nothing specified, 3600 applies.

My settings:

reneg-sec 7200;
push "reneg-sec 7200";
auth-gen-token 86400;
status /var/log/openvpn-status.log;

Works like charm for 400 openvpn clients.

This is a config.

client setenv SERVER_POLL_TIMEOUT 4 nobind remote IP 1194 tcp dev tun dev-type tun ns-cert-type server reneg-sec 604800 sndbuf 100000 rcvbuf 100000 auth-retry nointeract verb 3 cipher AES-256-GCM ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM auth SHA256 ca /config/openvpn/keys/ca.crt cert /config/openvpn/keys/phone1.crt key /config/openvpn/keys/phone1.key

@Lagan said in OpenVPN Client Specific Overrides ot updated until server restarted:

I would like the new override to take effect when I restart the client.

Hummm.

It's possible that a save on the "Client Specific Overrides" page doesn't restart the OpenVPN server - I doesn't seem to do that.
Maybe it isn't needed, as the server has a setting :

client-config-dir /var/etc/openvpn/server1/csc/

that tells the server to look into that folder for client special settings, the "Client Specific Overrides".

Anyway, I did restart the server, then connected the client and it got the '.30' IP.

I believe that is not affected.
I can only see tls crypt (without V2) being enabled in my config.

Yes, I tried that too.
I tried to ping the client's tunnel IP - unsuccessfully.

@viragomann That worked. You are awesome! Thank you so much.

@viragomann I did found out what it was wrong.
The error was in front of my face all the time and I did not were seeing it.

2a767b14-aa92-4d90-a04b-70b5a149cf15-image.png

I have to put in IPv4 networks BOTH networks not only the one on my side...
Thanks a lot for let me see it! 😇

You can check with your mobile phone.
whatismyip.com should return your home IP.

-Rico

@Rico No, and no log entries though we don't have OpenVPN set up.

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 77412 root 10 20 0 798M 677M nanslp 0 937:11 1.18% suricata 86659 root 10 20 0 850M 721M nanslp 0 547:29 0.65% suricata 99674 unbound 4 20 0 113M 87M kqread 2 7:30 0.23% unbound 19999 root 1 20 0 14M 4100K CPU0 0 0:00 0.08% top 69725 root 5 68 0 17M 3168K uwait 0 3:54 0.02% dpinger 69646 root 5 68 0 21M 3260K uwait 0 4:25 0.01% dpinger 71901 root 1 20 0 13M 2768K kqread 0 2:12 0.01% tail_pfb

I have setup Wireuard instead but am having DNS issues, have looked at several solutions. I can connect to devices via RDP on the other side of the wireguard tunnel but can't reslove dns on my side.
Starting a new post here:
https://forum.netgate.com/topic/196948/wireguard-dns-resolution-issue

Thanks for the input.

Hi @Gertjan, thank you for answering. I´m not the only one, who is disappointed about openvpn makers suddenly treat their recent defaults as incompatible. As far as I know there is no easy (for people doing other stuff than openvpn too) documentation and/or recommendations for a soft transition.
I think the pfsense could be upgraded to 2.6.x easily, leaving the old vpn connections intact, but still using old standards. 2.7.x probably will not come up after upgrade if VPN connections were not altered before updating. But I don´t find any documentation, what to change to have a smooth transition from 2.6.x to 2.7.x.
"yust update to 2.7.2" is not a viable solution!
My hope was someone with knowledge about openvpn beyond using the wizards, could share some knowledge about paths for transition without interrupting vpn services for all who have to upgrade.

Hm, so only IPs and subnets, nothing that needs to be resolved? That should load as soon as pf does, which should be before the openvpn resyn at boot.

Do you see any errors in the OpenVPN or system logs when this happens? Or any sort of difference in the process ordering?

@timcin
This issue cannot has nothing to do with pfSense. So this is the wrong place to request support for it.
You should ask in a Raspy forum, how to enable an OpenVPN client service.