@dlogan The client connections to a single instance happen within OpenVPN. pfSense gets no notice if a client is connected or not. Gateways can only be added to OpenVPN instances and now your goal is to do all connections with a single instance for whatever reason. So you can only have a single gateway for all naturally. You can monitor the client connections in the OpenVPN dashboard widget or in Status > OpenVPN. You may also add additional gateways to the OpenVPN instance and monitor a remote IP, but there is no way for pfSense to do a gateway failover as you did before, since there is only a single gateway.

Solved. We informed the openVPN server running on Debian about the LAN behind the pfsense with iroute stanza in /etc/openvpn/ccd/ and it can access the cloud pcs now. Thank you

@nogbadthebad amen brother that worked thank you. not the wife can work and stop giving me the side eye as to why the network is going up and down..lol

I was waiting for a "fix" of the pSense software, hoping this would fix it. After installing the latest version of the software, which I installed on the Netgate device from scratch, I found that actually the culprit is not the Netgate/pfSense firmware, but the problem is related to pfBlockerNG. After the installation of the new firmware, I re-loaded my latest configuration from backup, and everything seemed to be working when I checked, impatiently, when actually the software was still installing my (to be) installed packages, like pfBlockerNG. All in all I found that pfBlockerNG needs to be de-activated when rebooting the device, and then activated after startup. Then everything works as it should. Next step is trying to find out why pfBlockerNG is giving me this problem. pfBlockerNG is blocking based on IP (geo-IP) and based on DNSBL (DNS black listing). I definitely did not block my country (NL) and I just use (a lot) of very common DNSBL lists. Any ideas/suggestions are welcome.

@sjgieson Nevermind, I figured out routing all Internet at least. The solution is to make sure you default gateway is your Virtual Wan on your Default allow LAN to any rule. In my case it was called "DHCP_WAN", so now I can send all traffic out. I tried this earlier but I had a custom config line in the client side of OpenVPN, that was told to do to force all traffic out the VPN. This custom config was tripping up my LAN rules/routes. So don't do that. I appear to be back in business now.

@daddygo said in Degraded OpenVPN connectivity to NordVPN after upgrade 2.4.5 to 2.5.2: Other people would be very happy with your results (6 / 14 ms and 7.5 / 15.4), so let it go, because everything is perfect. BTW: These differences depend mostly on the load on the network (I think of everything here), check between 3 and 5 at night or during peak hours. +++edit: do not insist on numbers so rigidly Hi, I think my last response got interpret in a way I did not intended it to. My last email with the graphs/data, was not about showing how the numbers support my experience that 2.5.2 in my situation has degraded OpenVPN connectivity. But was in response to your email on September 24th. In that email you showed your graphs/data and stated that OpenVPN works just fine for you on 2.5.2. The intention of my last email with the graphs/data, was exactly to demonstrate that these graphs/data do not show what I am experiencing in OpenVPN degradation and therefore not helpful in investigating my issue with OpenVPN. Indeed when looking at the graphs/data for 2.4.5 and 2.5.2 and comparing them, there is little difference and one could think there is no issue. However, I still am having an issue with OpenVPN on 2.5.2. That is why I ended my last response with 'So these graphs/data do not point me into a direction as where the cause could be. Or am I overlooking something?'. So if you have other suggestions as in how to investigate, please share your thoughts on this. Thank you so far!

@wisheh I suspect, that your outbound NAT is in manual mode. So you might have to add a rule to the OpenVPN interface.

@sysgi1 Anyone? Is there any issue with OpenVPN in a multi-ip environment? I think something is broken in the last version (I never had this problem prior to 21.05 upgrade) Thank you

I'm going to make the assumption that HOME is an interface that you assigned to the VPN client. In pfSense, traffic applies to the interface where the traffic arrives. So in this case, on HOME you need to allow traffic from source 192.168.0.0/24, but instead you have source as LAN net. LAN net will never be the source for traffic arriving at that interface.

@bcruze Guess not. Showing version numbers is important to know, I agree, and is also important for hackers. Most "payware" VPN services compile their own VPN version from the open source tree.

Bah, I hate posting and then saying Nevermind, but I already found some closure. After multiple attempts on my Linux Desktop, I decided to just get the Certificate data straight out of terminal with the openssl command without the -noout. Entering this text in the text box (the BEGIN CERTIFICATE / END CERTIFICATE contents) with absolutely no modification worked. I compared the two entries side by side, and it looks like my Text Editor was still adding markup language. It's a silly thing, but if someone searches for this in the future, all I can say is keep trying to make sure your certificate data is getting imported with absolutely no modification from your text editor.

@audiobahn This is just an OpenVPN server on the NetGate with various devices connecting. I resolved my issue by redoing the OpenVPN server without the use of a TLS cert. Oddly enough, the DNS resolver suddenly stopped working and still has issues even after restarting the service. Haven't been able to reboot it yet. hmmmm... glad you got yours working