@ptz-m Server's were still on openvpn 2.4, which seems not capable of fully disabling it, after updating to 2.5 and setting 'allow-compression no' the warning is gone.

@jimp Did you get that working somehow? I tried send via Microsoft NPS server (Radius) the Cisco Vendor Attribute "ip:route 10.0.0.0 255.255.255.0 192.168.1.1 100" from somewhere, but I am not sure if that is the correct format, as could not find specific/clear documentation.

I tried to deal with this problem independently, but unfortunately, it didn't work out. For some reason, I didn't contact the PC engineer on this issue but changed my vps server to another windows server vps, and it seems that there were no more errors. The next time such errors occur, I will contact an engineer who will tell me what is wrong and how to solve this problem. The problem is that I don't always have the money to pay for the work of an engineer, and I want to continue to work comfortably. It's good that now there are many good vps servers, and everyone can choose the best one for themselves.

@zabi Hi!

Thanks for that, but I'm not at the site and won't get crazy changing stuff. And when I get a chance to be at the site I'm going to just replace the VM HDD with a 2.4.5 version.

Weird thing, today it behave as expected.

@viragomann
Hi virgomann thank you very much, that did the trick.
:)

I now applied the patch from:
https://redmine.pfsense.org/issues/11829
and it seemed to help.

Probably this: https://redmine.pfsense.org/issues/11545

@ptz-m For me restarting the service from web GUI didn't work. It was crashing within seconds. It only came back after a full firewall reboot.

I am facing issue with TAP config, there is a server location in inside the pfsense network, using tap we are accessing that server from outside the network from different locations and different system, the issue is, some users able to access the server few of them are not, the users who are unable to access server are able to access other VPN clients.

@viragomann I see.

I can ping and route from LAN successfully.
I can not ping or route from openVPN.

@shaw22 I would add reneg-sec 0 on the client so the server is controlling if you choose to change it in the future.

@pfsense7515

if it's a server

/usr/local/sbin/pfSsh.php playback svc restart openvpn server 1

if it's a client

/usr/local/sbin/pfSsh.php playback svc restart openvpn client 1

server/client can be 1 or 2 or 3 etc etc

check with

ps uxaww | grep openvpn

So I've managed to resolve this - basically I recreated the vpn server via the wizard having completely deleted the old server. ( I also deleted and recreated all certificates but I'm not sure if this was actually required).

Once I did that then the client export was showing the server in the drop-down list.

I tried many many different things to get my openvpn server working after the upgrade and I ran into this as a secondary issue when rebuilding it.

I have a feeling that this was actually because the recreated server was in peer-peer mode when I created it via the Add button and not the wizard - I didnt notice, and so the server would have been the wrong type for clients / exports.

@johnpoz 'You sure your in the correct mode? They will not be there if your not in remote access mode - ie peer to peer no those settings will not be there.'

Thank you, that was exactly what the issue was.

@jagradang Hi! I have my 2.5.0 config backed up but I went back to 2.4.5 p1 because of the many problems with unbound and with 2.5.1 off course the multiwan port forwarding being broken. But openvpn was not one of the issues. Now when I am running 2.4.5 p1 I swear not to touch 2.5 line of release. The ease of mind with 2.4.5 p1 is simply amazing. For example when I was running 2.5.0 every couple of days I needed to reboot it to keep everything running. With 2.4.5 p1 I now have 3+ Weeks uptime and counting. I haven’t seen those uptimes ever when I was on 2.5.x.

Keep your 2.4.5 p1 and steer clear of 2.5.x like it’s COVID-19.

@jagradang yes 2.6 typo.